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

On Wed, 3 Feb 2021 at 19:16, Jan Lübbe [off-list ref] wrote:

On Wed, 2021-02-03 at 17:20 +0530, Sumit Garg wrote:

quoted

On Tue, 2 Feb 2021 at 18:04, Jan Lübbe [off-list ref] wrote:

quoted

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

quoted

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.

User authentication, AFAIK most of the HSMs or PKCS#11 require that
for key import. But IIUC, your suggested approach to load plain key
into kernel keyring and say it's *trusted* without any user
authentication, would it really be a trusted key? What prevents a
rogue user from making his key as the dm-crypt trusted key?

There is user authentication at the level of key rings. So an untrusted user
cannot load or link keys they have no write permission for.

Here, I meant user authentication to the trust source (TPM or a TEE)
which provides assurance for a key to be trusted. So what happens in
case of user-space compromises (an untrusted user gaining root
access)?

As we already have user type keys, which don't have these restrictions and are
accepted by most subsystems, any use of kernel keyrings must already make sure
that the proper keys are used.

The major value add of trusted keys over user keys is this trust
assurance provided by the underlying trust source.

With asymmetric keys we have trusted key *rings*:
# keyctl show %:.secondary_trusted_keys
Keyring
 638775388 ---lswrv      0     0  keyring: .secondary_trusted_keys
1071890135 ---lswrv      0     0   \_ keyring: .builtin_trusted_keys
 816294887 ---lswrv      0     0       \_ asymmetric: Debian Secure Boot CA: 6ccece7e4c6c0d1f6149f3dd27dfcc5cbb419ea1
 630436721 ---lswrv      0     0       \_ asymmetric: Debian Secure Boot Signer 2020: 00b55eb3b9
Here, a key is trusted because of it's presence in a keyring, not because it has
a specific type. For example, fs-verity uses this mechanism as well.


For the trusted key *type*, my understanding is that trusted refers to only
being able to load and access them in specific "trusted" system states (via TPM
PRC, TEE initialization via secure boot or SoC specific hardware status checks).
So for example protecting against loading a data-encryption key into an unsigned
kernel.

Along with that trusted keys assures protection against any
unauthorized user access to plain key payload.

quoted

quoted

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.

I am not sure why you would call the standardized TEE interface [1] to
be platform-specific, it is meant to be platform agnostic. And I think
we can have openssl_tee_engine on similar lines as the
openssl_tpm2_engine.

Sorry, I meant platform-specific in the sense that some platforms use TPMs,
while others use TEEs. The trusted key type was also suggested several times as
the correct abstraction for SoC-specific key encapsulation hardware (instead of
custom interfaces), so there will likely be platforms which don't have a TPM or
TEE, but still trusted keys.

Agree and for that particular reason we are trying to add an
abstraction layer in trusted keys subsystem so that other trust
sources apart from TPM or TEE can be supported as well.

-Sumit

Regards
Jan

quoted

[1] https://globalplatform.org/specs-library/tee-client-api-specification/

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