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

On Tue, 2021-02-02 at 17:45 +0530, Sumit Garg wrote:

Hi Jan,

On Sun, 31 Jan 2021 at 23:40, James Bottomley [off-list ref] 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:

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.

What is the security benefit of having the key blob creation in user-space
instead of in the kernel? Key import is a standard operation in HSMs or PKCS#11
tokens.

I mainly see the downside of having to add another API to access the underlying
functionality (be it trusted key TA or the NXP CAAM HW *) and requiring
platform-specific userspace code.

This CAAM specific API (in out-of-tree patches) was exactly the part I was
trying to get rid of. ;)

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 |