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-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
