Linux-FSCrypt Archive on lore.kernel.org
 help / color / Atom feed
* Using TPM trusted keys (w/ v2 policies?)
@ 2020-01-16 19:32 Omar Sandoval
  2020-01-16 19:53 ` Eric Biggers
  0 siblings, 1 reply; 2+ messages in thread
From: Omar Sandoval @ 2020-01-16 19:32 UTC (permalink / raw)
  To: linux-fscrypt; +Cc: Sergey Anpilov, Pavlo Kushnir

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: https://www.kernel.org/doc/html/latest/security/keys/trusted-encrypted.html
2: https://lore.kernel.org/linux-fscrypt/20180118131359.8365-1-git@andred.net/

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Using TPM trusted keys (w/ v2 policies?)
  2020-01-16 19:32 Using TPM trusted keys (w/ v2 policies?) Omar Sandoval
@ 2020-01-16 19:53 ` Eric Biggers
  0 siblings, 0 replies; 2+ messages in thread
From: Eric Biggers @ 2020-01-16 19:53 UTC (permalink / raw)
  To: Omar Sandoval; +Cc: linux-fscrypt, Sergey Anpilov, Pavlo Kushnir

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: https://www.kernel.org/doc/html/latest/security/keys/trusted-encrypted.html
> 2: https://lore.kernel.org/linux-fscrypt/20180118131359.8365-1-git@andred.net/

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
(https://lkml.kernel.org/linux-fscrypt/20191119222447.226853-1-ebiggers@kernel.org/).

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
(https://android-review.googlesource.com/c/kernel/common/+/1200864/25).  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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, back to index

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-01-16 19:32 Using TPM trusted keys (w/ v2 policies?) Omar Sandoval
2020-01-16 19:53 ` Eric Biggers

Linux-FSCrypt Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-fscrypt/0 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/ https://lore.kernel.org/linux-fscrypt \
		linux-fscrypt@vger.kernel.org
	public-inbox-index linux-fscrypt

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-fscrypt


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git