155acee851
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> |
||
|---|---|---|
| .. | ||
| asm-generic | ||
| drm | ||
| linux | ||
| misc | ||
| mtd | ||
| rdma | ||
| scsi | ||
| sound | ||
| video | ||
| xen | ||
| Kbuild | ||