To prevent keys from being compromised if an attacker acquires read
access to kernel memory, some inline encryption hardware supports
protecting the keys in hardware without software having access to or the
ability to set the plaintext keys. Instead, software only sees "wrapped
keys", which may differ on every boot. The keys can be initially
generated either by software (in which case they need to be imported to
hardware to be wrapped), or directly by the hardware.
Add support for this type of hardware by allowing keys to be flagged as
hardware-wrapped and encryption policies to be flagged as needing a
hardware-wrapped key. When used, fscrypt will pass the wrapped key
directly to the inline encryption hardware to encrypt file contents.
The hardware is responsible for internally unwrapping the key and
deriving the actual file contents encryption key.
fscrypt also asks the inline encryption hardware to derive a
cryptographically isolated software "secret", which fscrypt then uses as
the master key for all other purposes besides file contents encryption,
e.g. to derive filenames encryption keys and the key identifier.
Bug: 147209885
Change-Id: I58d1a37f5ba8cf178b80036b813e0bc99512ef3b
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
Barani Muthukumaran5 years agocommitted bySatya Tangirala