Re: [PATCH 01/19] User-space API definition

[Kyle Moffett]

On Mon, Sep 6, 2010 at 17:11, Nikos Mavrogiannopoulos
<n.mavrogiannopoulos@xxxxxxxxx> wrote:
> I suppose you mean the reference to the internal representation of the
> key. This might be valid for few seconds until the required operation is
> over.
>
> This is not really what I would call storage. The storage and retrieval
> of keys is being done using two ioctl() the STORAGE_WRAP and STORAGE_UNWRAP.
>
> An example of how NCR works:
> 1. A Process generates an RSA key pair
> 2. Stores the (encrypted) pair using the STORAGE_WRAP to a file.
>
> 3. Another process loads the file, unwraps it using STORAGE_UNWRAP and
> gets a reference to the key
> 4. Does an RSA decryption using the key
> 5. Discards the reference to the key
>
> Consider the reference as a file descriptor after you have opened a file
> (a wrapped key).
>
> How do you see keyring being involved in a setup like this?

Fundamentally the operations you described are *EXACTLY* the kind of
things that I believe the keyring API should support.  It does not
support them now, but that API is where the described functionality
really belongs.  Please consider just extending the keyring API to
support what you need.

For example, assuming that we automatically register 1 keyring key
type per algo it should be pretty straightforward.

You would want to write a "request_key()" handler for those key types
which can use whatever hardware support is available to automatically
generate a new random key or alternatively pass the operation off to
the /sbin/request-key process to generate and load one from userspace.
 The call might take a *long* time to complete, depending on the key
type and whether or not there is hardware support.

That would allow you to perform the "generate an RSA key" step in
either a trusted "request-key" process or directly in a piece of
hardware, helping to avoid accidental key material leaks from the
unprivileged process.

Then, you would want "KEYCTL_DECRYPT_KEY", and "KEYCTL_ENCRYPT_KEY"
which would use one key to encrypt another into a user buffer (or
decrypt a key from a user buffer).  These would probably need new LSM
hooks and maybe key DAC permission bits.

This would implement the "STORAGE_WRAP" and "STORAGE_UNWRAP"
functionality you want, but it would be extensible to much more than
just what NCR needs.  I could see this being very useful as an
extension to the existing Kerberos or NFS keyring usage.  Other
potential applications include very secure replacements for the SSH or
GPG agent programs.

For the final step of actually performing encryption/decryption of
user data you would then want generic keyctl() ops for
"KEYCTL_ENCRYPT" and "KEYCTL_DECRYPT", which would simply call
CryptoAPI with the user-provided input and output buffers.  Again,
you'd need new LSM hooks, etc.  These are very obviously extensible to
other applications.

It's getting a bit late here, so I apologize if anything I've written
above makes particularly little sense, but hopefully I've gotten the
gist across.

Cheers,
Kyle Moffett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/