On Sun, 2021-01-31 at 07:09 -0500, Mimi Zohar wrote:

On Sat, 2021-01-30 at 19:53 +0200, Jarkko Sakkinen wrote:

quoted

On Thu, 2021-01-28 at 18:31 +0100, Ahmad Fatoum wrote:

quoted

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 |