From: Kyle Moffett Subject: Re: [PATCH 01/19] User-space API definition Date: Mon, 6 Sep 2010 14:00:47 -0400 Message-ID: References: <272391166.1009231283787434910.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> <169108422.1009631283788251084.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Herbert Xu , linux-crypto@vger.kernel.org, Nikos Mavrogiannopoulos , Neil Horman , linux-kernel@vger.kernel.org, David Howells To: Miloslav Trmac Return-path: Received: from mail-ew0-f46.google.com ([209.85.215.46]:57631 "EHLO mail-ew0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753217Ab0IFSBJ convert rfc822-to-8bit (ORCPT ); Mon, 6 Sep 2010 14:01:09 -0400 In-Reply-To: <169108422.1009631283788251084.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> Sender: linux-crypto-owner@vger.kernel.org List-ID: On Mon, Sep 6, 2010 at 11:50, Miloslav Trmac wrote: > ----- "Herbert Xu" wrote: >> On Mon, Aug 23, 2010 at 11:37:40AM -0400, Miloslav Trmac wrote: >> > I have seriously considered the keyring API, and this is what I ca= me >> up with - but I'd love to be shown a better way. >> >> FWIW adding a second key management system to the kernel is >> totally out of the question. >> >> If the existing system doesn't work for you, find a way to build >> on it so that it does. =C2=A0Adding a second system that pretty much >> does the same thing is unacceptable. > It does _not_ do the same thing, same as ramfs and file descriptors d= o not do the same thing although they are both related to files. > > The kernel keyring service is basically a system-wide data storage se= rvice. =C2=A0/dev/crypto needs a quick way to refer to short-lived, usu= ally 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. 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 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). 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. This would be especially true if the session keys are actually generated by a keyring+cryptoapi operation in the kernel. 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. Cheers, Kyle Moffett