On 09/06/2010 08:00 PM, Kyle Moffett wrote: >> The kernel keyring service is basically a system-wide data storage >> service. /dev/crypto needs a quick way to refer to short-lived, >> usually process-local, kernel-space data structures from >> userspace. > The problem with the approach you're proposing is that we then have > two entirely separate classes of keys. First we have the existing > keyring class, which can be securely and revokably passed between > different processes with limited rights, but cannot be handed up to > the kernel's cryptoapi. I don't think this is the case. The NCR does not store any keys nor retrieves them. It does delegate the burden of that to userspace application. NCR exports a wrapped version of the key and the userspace application stores it. It could use the keyring to store the keys or could directly store them in the filesystem. > Then we have your new class, which are anonymous keys with a brand > new security model > (which doesn't even have LSM hooks yet) and what would this suggest? > and which cannot be referenced by name. Another potential issue is > that keys are never actually "unnamed", in that sense. If encryption > keys truly were "anonymous" then you would find it impossible to > reliably decrypt the data on the other end. For example, every RSA > private key should be indexed either by the X.509 DN or for bare SSH > keys by the public modulus information. > Even transient SSL session > keys are always put into an SSL session cache by apache or whatever > to allow them to be reused across multiple TCP streams! So I would > argue that an SSL implementation that uses this should actually > create or use a keyring specifically as an SSL session cache (with > keys indexed by SSL session ID). Each key of NCR contains a key ID, that is the same in public and private keys (if generated by NCR), and that could be used to index it. Secret keys have a key id specified by the user. It does not require you to use it though. > It then becomes trivial to share an SSL session cache between 3 > independent HTTPS server programs from different vendors, such that > the compromise of *any* of the processes would not in any way > compromise the security of the session keys. If you are sharing a cache, the protection given by NCR is actually not used. Unless of course you start wrapping keys to ensure that noone unauthorized except from the legitimate systems access them. Doing the crypto in user-space would be more efficient in that case. > So my recommendation would be to create some new operations of the > existing keyring code: > (1) If you *really* care about anonymous transient keys that are not > identified by an SSL session ID or similar, then add a keyring > operation for "create an anonymous key in keyring X, where the > kernel creates a proper temporary name". An SSL implementation would > default to using the process-local keyring, which means that > everything would automatically go away on process exit. > (2) Add cryptoapi hooks to automatically register keyring key types > based on the loaded cryptoapi modules. > (3) Add any necessary keyring operations for efficiently performing > zero-copy cryptoapi calls using those key types. I cannot get the big picture of you suggestions. How does this fit to NCR given the explanation on how keys are (not) stored by NCR. Is your suggestion about convenience calls to retrieve and store keys from and to keyring? Or you are suggesting NCR to be using the keyring for its internal reference of keys? If it is the latter, what would be the advantage of doing that? regards. Nikos -- 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
