Re: Migration to trusted keys: sealing user-provided key?

[Jan Lübbe]

On Tue, 2021-02-02 at 17:45 +0530, Sumit Garg wrote:
> Hi Jan,
> 
> On Sun, 31 Jan 2021 at 23:40, James Bottomley <jejb@xxxxxxxxxxxxx> wrote:
> > 
> > On Sun, 2021-01-31 at 15:14 +0100, Jan Lübbe wrote:
> > > On Sun, 2021-01-31 at 07:09 -0500, Mimi Zohar wrote:
> > > > On Sat, 2021-01-30 at 19:53 +0200, Jarkko Sakkinen wrote:
> > > > > On Thu, 2021-01-28 at 18:31 +0100, Ahmad Fatoum wrote:
> > > > > > Hello,
> > > > > > 
> > > > > > I've been looking into how a migration to using
> > > > > > trusted/encrypted keys would look like (particularly with dm-
> > > > > > crypt).
> > > > > > 
> > > > > > Currently, it seems the the only way is to re-encrypt the
> > > > > > partitions because trusted/encrypted keys always generate their
> > > > > > payloads from RNG.
> > > > > > 
> > > > > > If instead there was a key command to initialize a new
> > > > > > trusted/encrypted key with a user provided value, users could
> > > > > > use whatever mechanism they used beforehand to get a plaintext
> > > > > > key and use that to initialize a new trusted/encrypted key.
> > > > > > From there on, the key will be like any other trusted/encrypted
> > > > > > key and not be disclosed again to userspace.
> > > > > > 
> > > > > > What are your thoughts on this? Would an API like
> > > > > > 
> > > > > >   keyctl add trusted dmcrypt-key 'set <content>' # user-
> > > > > > supplied content
> > > > > > 
> > > > > > be acceptable?
> > > > > 
> > > > > Maybe it's the lack of knowledge with dm-crypt, but why this
> > > > > would be useful? Just want to understand the bottleneck, that's
> > > > > all.
> > > 
> > > Our goal in this case is to move away from having the dm-crypt key
> > > material accessible to user-space on embedded devices. For an
> > > existing dm-crypt volume, this key is fixed. A key can be loaded into
> > > user key type and used by dm-crypt (cryptsetup can already do it this
> > > way). But at this point, you can still do 'keyctl read' on that key,
> > > exposing the key material to user space.
> > > 
> > > Currently, with both encrypted and trusted keys, you can only
> > > generate new random keys, not import existing key material.
> > > 
> > > James Bottomley mentioned in the other reply that the key format will
> > > become compatible with the openssl_tpm2_engine, which would provide a
> > > workaround. This wouldn't work with OP-TEE-based trusted keys (see
> > > Sumit Garg's series), though.
> > 
> > Assuming OP-TEE has the same use model as the TPM, someone will
> > eventually realise the need for interoperable key formats between key
> > consumers and then it will work in the same way once the kernel gets
> > updated to speak whatever format they come up with.
> 
> IIUC, James re-work for TPM trusted keys is to allow loading of sealed
> trusted keys directly via user-space (with proper authorization) into
> the kernel keyring.
> 
> I think similar should be achievable with OP-TEE (via extending pseudo
> TA [1]) as well to allow restricted user-space access (with proper
> authorization) to generate sealed trusted key blob that should be
> interoperable with the kernel. Currently OP-TEE exposes trusted key
> interfaces for kernel users only.

What is the security benefit of having the key blob creation in user-space
instead of in the kernel? Key import is a standard operation in HSMs or PKCS#11
tokens.

I mainly see the downside of having to add another API to access the underlying
functionality (be it trusted key TA or the NXP CAAM HW *) and requiring
platform-specific userspace code.

This CAAM specific API (in out-of-tree patches) was exactly the part I was
trying to get rid of. ;)

Regards,
Jan

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |