Migration to trusted keys: sealing user-provided key?

[James Bottomley]

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.

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

Yes, that's what I was thinking ... especially when you can add policy
to the keys, which includes PCR locking.  Part of the problem is that
changing policy, which you have to do if something happens to update
the PCR values, is technically a migration, so your trusted keys for
dm-crypt are really going to have to be migrateable.

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

What about a third option: why not make dm-crypt store the master key
it uses as an encrypted key (if a parent trusted key is available)? 
That way you'd be able to extract the encrypted form of the key as
root, but wouldn't be able to extract the actual master key.

James