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

Hi Jan,

On Sun, 31 Jan 2021 at 23:40, James Bottomley [off-list ref] wrote:

On Sun, 2021-01-31 at 15:14 +0100, Jan Lübbe wrote:

quoted

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

quoted

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.

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.

[1] https://github.com/OP-TEE/optee_os/blob/master/ta/trusted_keys/entry.c

-Sumit

quoted

quoted

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.

quoted

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