archive mirror
 help / color / mirror / Atom feed
From: Eric Biggers <>
To: Ahmad Fatoum <>
Cc: Sumit Garg <>,
	"Theodore Y. Ts'o" <>,
	Jaegeuk Kim <>,
	Jarkko Sakkinen <>,
	James Morris <>,
	"Serge E. Hallyn" <>,
	James Bottomley <>,
	Mimi Zohar <>,
	David Howells <>,,
	linux-integrity <>,
	"open list:ASYMMETRIC KEYS" <>,
	Linux Kernel Mailing List <>,, Omar Sandoval <>,
	Pengutronix Kernel Team <>
Subject: Re: [RFC PATCH v1] fscrypt: support encrypted and trusted keys
Date: Thu, 29 Jul 2021 11:28:11 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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:

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

  reply	other threads:[~2021-07-29 18:28 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-27 14:43 Ahmad Fatoum
2021-07-27 16:38 ` Eric Biggers
2021-07-28  8:50   ` Ahmad Fatoum
2021-07-28 16:05     ` Eric Biggers
2021-07-29  5:56       ` Sumit Garg
2021-07-29  9:07         ` Ahmad Fatoum
2021-07-29 18:28           ` Eric Biggers [this message]
2021-07-28 22:22 ` Jarkko Sakkinen
2021-07-28 22:27   ` Ahmad Fatoum

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [RFC PATCH v1] fscrypt: support encrypted and trusted keys' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).