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@xxxxxxxxxx/ 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@xxxxxxxxxx/). 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
|