Message-ID: <4C853D69.2080108@gmail.com>
Date:	Mon, 06 Sep 2010 21:13:45 +0200
From:	Nikos Mavrogiannopoulos <n.mavrogiannopoulos@...il.com>
To:	Kyle Moffett <kyle@...fetthome.net>
CC:	Miloslav Trmac <mitr@...hat.com>,
	Herbert Xu <herbert@...dor.hengli.com.au>,
	linux-crypto@...r.kernel.org, Neil Horman <nhorman@...hat.com>,
	linux-kernel@...r.kernel.org, David Howells <dhowells@...hat.com>
Subject: Re: [PATCH 01/19] User-space API definition

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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists