Some inline encryption hardware supports protecting the keys in hardware and only exposing wrapped keys to software. To use this capability, userspace must provide a hardware-wrapped key rather than a raw key. However, users of inline encryption in the kernel won't necessarily use the user-specified key directly for inline encryption. E.g. with fscrypt with IV_INO_LBLK_64 policies, each user-provided key is used to derive a file contents encryption key, filenames encryption key, and key identifier. Since inline encryption can only be used with file contents, if the user were to provide a wrapped key there would (naively) be no way to encrypt filenames or derive the key identifier. This problem is solved by designing the hardware to internally use the unwrapped key as input to a KDF from which multiple cryptographically isolated keys can be derived, including both the inline crypto key (not exposed to software) and a secret that *is* exposed to software. Add a function to the keyslot manager to allow upper layers to request this software secret from a hardware-wrapped key. Bug: 147209885 Change-Id: I32f3aa4f25bcf6b9d6f7d8890260533fad00dd1d Co-developed-by: Gaurav Kashyap <gaurkash@codeaurora.org> Signed-off-by: Gaurav Kashyap <gaurkash@codeaurora.org> Signed-off-by: Barani Muthukumaran <bmuthuku@codeaurora.org> Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Satya Tangirala <satyat@google.com>tirimbino
parent
d42ba87e29
commit
bb5a65771a
Loading…
Reference in new issue