[RFC PATCH v1] fscrypt: support encrypted and trusted keys

[Eric Biggers]

On Thu, Jul 29, 2021 at 11:07:00AM +0200, Ahmad Fatoum wrote:
> >> 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.
> 
> I'd appreciate your feedback on my CAAM series if you think the defaults
> can be improved. Trusted keys are no longer restricted to TPMs,
> so users of other backends shouldn't be dismissed, because one backend
> can be used with fscrypt by alternative means.

I already gave feedback:
https://lkml.kernel.org/keyrings/YGOcZtkw3ZM5kvl6@gmail.com
https://lkml.kernel.org/keyrings/YGUHBelwhvJDhKoo@gmail.com
https://lkml.kernel.org/keyrings/YGViOc3DG+Pjuur6@sol.localdomain

> >>>> - 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?
> 
> The users I meant are humans, e.g. system integrators. They need to think about
> 
> burning fuses, signing bootloaders, verifying kernel and root file systems,
> 
> encrypting file systems and safekeeping their crypto keys. Ample opportunity for
> 
> stuff to go wrong. They would benefit from having relevant kernel functionality
> 
> integrate with each other instead of having to carry downstream patches, which
> we and many others[1] did for years. We now finally have a chance to drop this
> technical debt thanks to Sumit's trusted key rework and improve user security
> along the way.
> 
> So, Eric, how should we proceed?
> 

It is probably inevitable that this be added, but you need to document it
properly and not make misleading claims like "The key material is generated
within the kernel" (for the TPM "trust" source the default is to use the TPM's
RNG, *not* the kernel RNG), and "is never disclosed to userspace in clear text"
(that's only guaranteed to be true for non-malicious userspace).  Also please
properly document that this is mainly intended for accessing key wrapping
hardware such as CAAM that can't be accessed from userspace in another way like
TPMs can.

- Eric