On Wed, Jul 28, 2021 at 10:50:42AM +0200, Ahmad Fatoum wrote:

Hello Eric,

On 27.07.21 18:38, Eric Biggers wrote:

quoted

On Tue, Jul 27, 2021 at 04:43:49PM +0200, Ahmad Fatoum wrote:

quoted

For both v1 and v2 key setup mechanisms, userspace supplies the raw key
material to the kernel after which it is never again disclosed to
userspace.

Use of encrypted and trusted keys offers stronger guarantees:
The key material is generated within the kernel and is never disclosed to
userspace in clear text and, in the case of trusted keys, can be
directly rooted to a trust source like a TPM chip.

Please include a proper justification for this feature

I've patches pending for extending trusted keys to wrap the key sealing
functionality of the CAAM IP on NXP SoCs[1]. I want the kernel to
generate key material in the factory, have the CAAM encrypt it using its
undisclosed unique key and pass it to userspace as encrypted blob that is
persisted to an unencrypted volume. The intention is to thwart offline
decryption of an encrypted file system in an embedded system, where a
passphrase can't be supplied by an end user.

Employing TPM and TEE trusted keys with this is already possible with
dm-crypt, but I'd like this to be possible out-of-the-box with
ubifs + fscrypt as well.

Why not do the key management in userspace, like tpm-tools
(https://github.com/tpm2-software/tpm2-tools)?  There are a lot of uses for this
type of hardware besides in-kernel crypto.  See
https://wiki.archlinux.org/title/Trusted_Platform_Module for all the things you
can do with the TPM on Linux, including LUKS encryption; this is all with
userspace key management.  Wouldn't the CAAM hardware be useful for similar
purposes and thus need a similar design as well, e.g. with functionality exposed
through some /dev node for userspace to use?  Or are you saying it will only
ever be useful for in-kernel crypto?

quoted

Note that there are several design flaws with the encrypted and trusted key
types:

- By default, trusted keys are generated using the TPM's RNG rather than the
  kernel's RNG, which places all trust in an unauditable black box.

Patch to fix that awaits feedback on linux-integrity[2].

It does *not* fix it, as your patch only provides an option to use the kernel's
RNG whereas the default is still the TPM's RNG.

Most people don't change defaults.

Essentially your same argument was used for Dual_EC_DRBG; people argued it was
okay to standardize because people had the option to choose their own constants
if they felt the default constants were backdoored.  That didn't really matter,
though, since in practice everyone just used the default constants.

quoted

- trusted and encrypted keys aren't restricted to specific uses in the kernel
  (like the fscrypt-provisioning key type is) but rather are general-purpose.
  Hence, it may be possible to leak their contents to userspace by requesting
  their use for certain algorithms/features, e.g. to encrypt a dm-crypt target
  using a weak cipher that is vulnerable to key recovery attacks.

The footgun is already there by allowing users to specify their own

raw key. Users can already use $keyid for dm-crypt and then do

  $ keyctl pipe $keyid | fscryptctl add_key /mnt

The responsibility to not reuse key material already lies with the users,
regardless if they handle the raw key material directly or indirectly via
a trusted key description/ID.

Elsewhere you are claiming that "trusted" keys can never be disclosed to
userspace.  So you can't rely on userspace cooperating, right?

- Eric