Linux-FSCrypt Archive on
 help / color / Atom feed
From: Eric Biggers <>
To: Omar Sandoval <>
Cc:, Sergey Anpilov <>,
	Pavlo Kushnir <>
Subject: Re: Using TPM trusted keys (w/ v2 policies?)
Date: Thu, 16 Jan 2020 11:53:15 -0800
Message-ID: <> (raw)
In-Reply-To: <20200116193228.GA266386@vader>

On Thu, Jan 16, 2020 at 11:32:28AM -0800, Omar Sandoval wrote:
> Hi,
> We're exploring fscrypt, and we were hoping to make use of a trusted key [1] so
> that we could avoid exposing the master key to userspace. I found a patch [2]
> from a couple of years ago adding this support. However, trusted keys in the
> kernel seem to be tied to the keyring, which is not used for v2 encryption
> policies. Seeing as v1 policies are considered deprecated, what would be the
> way to move forward with this feature? Would it make sense to add minimal
> keyring integration for v2 policies in order to support this use case?
> Thanks!
> 1:
> 2:

There's already a patch that will be going into 5.6 that adds support for
passing a keyring key to FS_IOC_ADD_ENCRYPTION_KEY

But it only supports a new key type "fscrypt-provisioning" whose payload
contains the raw key.  If you wanted "trusted" key support, you'd need to add
it, probably as a new flag to FS_IOC_ADD_ENCRYPTION_KEY which indicates that the
key specified by key_id is of type "trusted".

Note that there are some major limitations to what you are trying to do.  First,
the raw key of "trusted" keys is still present in the clear in kernel memory.
Depending on your security architecture, this may not be any better than having
it be present in a root-owned userspace process.  Second, since the "trusted"
key type is not tied to a specific kernel subsystem or use, userspace could
request that the same key be used for different purposes, which could leak
information about the key to userspace.  (This is why we used a custom key type
"fscrypt-provisioning" for the new API rather than reusing "logon".)

There's also someone working on actual hardware-wrapped keys, where the key used
to encrypt file contents is never exposed to software at all
(  In my
opinion, doing TPM unsealing in the kernel is sort of a weird intermediate
state, which isn't necessarily any better than just TPM unsealing in userspace.
So if you need this feature it's going to be up to you to write the patch and
argue that it's actually useful.

- Eric

      reply index

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-16 19:32 Omar Sandoval
2020-01-16 19:53 ` Eric Biggers [this message]

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

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

Linux-FSCrypt Archive on

Archives are clonable:
	git clone --mirror linux-fscrypt/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-fscrypt linux-fscrypt/ \
	public-inbox-index linux-fscrypt

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone