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

On Mon, 2021-02-01 at 16:31 +0100, Jan Lübbe wrote:

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

quoted

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:

<snip>

quoted

quoted

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

The "encrypted" asymmetric key data doesn't change, "update" just
changes the key under which it is encrypted/decrypted.

Usage::

    keyctl add encrypted name "new [format] key-type:master-key-name keylen"
        ring
    keyctl add encrypted name "load hex_blob" ring

'load' (as I understand the code) only accepts an encrypted blob.

So the only way I see to have an encrypted key with a non-random key data would
be:
- create a random temporary master key and load a copy as a user key
- encrypt the chosen key data with the temporary master key (using a new
userspace reimplementation of the kernel encrypted key blob format)
- use keyctl add encrypted dmcrypt "load <encrypted blob>" <keyring>
- create new trusted master key (OP-TEE or CAAM in our case) as 
- use keyctl update to switch to the new trusted master key
- use keyctl pipe on the trusted and encrypted keys and store both for loading
on later boots

If we'd support importing a pre-existing key into a trusted or encrypted key,
we'd do instead:
- use keyctl add trusted dmcrypt "import <unencrypted key data>"
- use keyctl pipe on the trusted key and store it for loading on later boots

This way, users wouldn't need to care which backend is used by trusted keys
(TPM/OP-TEE/CAAM/...). That would make use-cases where a random key is not
suitable as straight-forward as the those where a random key is OK.

As I said above, the "encrypted" key update doesn't change the key data
used for encrypting/decrypting storage in the dm-crypt case, it just
updates the key under which it is encrypted/signed.

Yes, the reason for using an encrypted "trusted" key, as opposed to an
encrypted "user" key, is that the "trusted" key is encrypted/decrypted
by the TPM and never exposed to userspace in the clear.

It doesn't sound like you're wanting to update the storage key in the
field, just the key used to encrypt/decrypt that key.  So I'm still not
clear as to why you would want an initial non-random encrypted key. 
Providing that key on the command line certaining isn't a good idea.

Mimi