linux-kernel - Re: [RFC PATCH 2/8] KEYS: Provide keyctls to drive the new key type ops for asymmetric keys [ver 3]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1463051045.2484.97.camel@infradead.org>
Date:	Thu, 12 May 2016 12:04:05 +0100
From:	David Woodhouse <dwmw2@...radead.org>
To:	Mat Martineau <mathew.j.martineau@...ux.intel.com>,
	David Howells <dhowells@...hat.com>
Cc:	tadeusz.struk@...el.com, linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org, keyrings@...r.kernel.org,
	linux-crypto@...r.kernel.org
Subject: Re: [RFC PATCH 2/8] KEYS: Provide keyctls to drive the new key type
 ops for asymmetric keys [ver 3]

On Wed, 2016-05-11 at 15:17 -0700, Mat Martineau wrote:
> 
> On Wed, 11 May 2016, David Howells wrote:
> 
> > diff --git a/Documentation/security/keys.txt b/Documentation/security/keys.txt
> > index ca72b70a24b9..01c2ae28a8c0 100644
> > --- a/Documentation/security/keys.txt
> > +++ b/Documentation/security/keys.txt
> > +     If the key needs to be unlocked with a password, a logon-type key that
> > +     holds the password may be given as the password argument
> ...
> > +     If the key must be unlocked with a password before it can be used,
> > +     password_id should point to a logon-type key that holds this.
> 
> It should be noted that the password_id should be 0 if no password is to 
> be used.

Hm, I would like to properly explore the use cases for these passwords,
before any API is set in stone.

To start with, I'll insist quite strongly that we should never be
passing an encrypted key into the kernel alongside the password needed
to decrypt it. We should let userspace do that gruntwork, and pass in a
canonical DER PKCS#8 (or PKCS#1) blob. As I said before, the other way
lies madness, and requests to support all the obscure formats that keys
are stored in.

So where *might* we want a password... mostly for things like TPM and
other crypto hardware (USB tokens, HSMs). And the usage model there is
normally that the password isn't tied to the *key*, it's a password or
PIN to unlock the *device*.

So I'm not quite sure this 'password_id' makes much sense at all...
unless the idea is that you load the (encrypted) key in advance and
then request the password *later* on demand, in order to use it? Is
that something we really need to support?

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@...el.com                              Intel Corporation

Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5760 bytes)