Migration to trusted keys: sealing user-provided key?

[Jan Lübbe]

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.

> We upstreamed "trusted" & "encrypted" keys together in order to address
> this sort of problem.   Instead of directly using a "trusted" key for
> persistent file signatures being stored as xattrs, the "encrypted" key
> provides one level of indirection.   The "encrypted" key may be
> encrypted/decrypted with either a TPM based "trusted" key or with a
> "user" type symmetric key[1].
> 
> Instead of modifying "trusted" keys, use a "user" type "encrypted" key.

I don't see how this would help. When using dm-crypt with an encrypted key, I
can't use my existing key material.

Except for the migration aspect, trusted keys seem ideal. Only a single exported
blob needs to be stored and can only be loaded/used again on the same (trusted)
system. Userspace cannot extract the key material. 

To get to this point on systems in the field without re-encryption of the whole
storage, only the initial trusted/encrypted key creation would need to allow
passing in existing key material.

> Mimi
> 
> [1] The ima-evm-utils README contains EVM examples of "trusted" and
> "user" based "encrypted" keys.

I assume you refer to
https://sourceforge.net/p/linux-ima/ima-evm-utils/ci/master/tree/README#l143
"Generate EVM encrypted keys" and "Generate EVM trusted keys (TPM based)"?

In both cases, the key used by EVM is a *newly generated* random key. The only
difference is whether it's encrypted to a user key or a (random) trusted key.

Best 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 |