diff options
| author | Eric Biggers <ebiggers@google.com> | 2020-01-21 11:22:05 -0800 |
|---|---|---|
| committer | Gina Dimino <gdimino@google.com> | 2020-07-21 19:58:55 +0000 |
| commit | 7cee8f29c2df1afcea04b02386726f0c1fae8b69 (patch) | |
| tree | 10b37b2fdc5dc0bad08d9043fd19aba5f99df0a8 /9_security-model | |
| parent | ca55e5cc150f37d34ebf4fa37519d6a6e321dd09 (diff) | |
| download | platform_compatibility_cdd-7cee8f29c2df1afcea04b02386726f0c1fae8b69.tar.gz platform_compatibility_cdd-7cee8f29c2df1afcea04b02386726f0c1fae8b69.tar.bz2 platform_compatibility_cdd-7cee8f29c2df1afcea04b02386726f0c1fae8b69.zip | |
CDD: mandate non-reversible FBE key derivation function
The kernel portion of FBE originally used an AES-128-ECB based Key
Derivation Function (KDF) to derive per-file keys. While this met the
original security requirements, it is not a standard KDF and it does not
follow cryptographic best practices. For example, it is reversible, so
if a single file's key was compromised then all other files protected by
the same FBE policy were too. It is also inflexible, making it hard to
add new features to FBE and encouraging poor practices like reusing the
FBE master keys for both encryption and key derivation.
Android R supports a new FBE policy version which uses HKDF-SHA512
to derive all subkeys from the master key. It can be enabled using an
fstab option like "fileencryption=aes-256-xts:aes-256-cts:v2". It is
also the default setting when the shipping API level is >= R. Kernel
support is in android-4.14 and later, and in the upstream Linux kernel.
So, start requiring that a strong KDF be used and that FBE keys are not
used for different cryptographic purposes. As with the other storage
encryption format requirements, this only applies to new devices; this
is covered by the paragraph at the beginning of section 9.9.
This requirement does not require any special hardware support, and the
new KDF performs as well or better than the old KDF.
Bug: 144509061
Change-Id: Ie8b8df0a19be21dcfb7aed18aa3ac7e9c7e2b893
Diffstat (limited to '9_security-model')
| -rw-r--r-- | 9_security-model/9_9_full-disk-encryption.md | 12 |
1 files changed, 11 insertions, 1 deletions
diff --git a/9_security-model/9_9_full-disk-encryption.md b/9_security-model/9_9_full-disk-encryption.md index 55d6f19d..365cf375 100644 --- a/9_security-model/9_9_full-disk-encryption.md +++ b/9_security-model/9_9_full-disk-encryption.md @@ -36,7 +36,7 @@ https://source.android.com/security/encryption/file-based.html) (FBE). ### 9.9.3\. File Based Encryption -Encrypted devices: +If device implementations are encrypted, they: * [C-1-1] MUST boot up without challenging the user for credentials and allow Direct Boot aware apps to access to the Device Encrypted (DE) storage @@ -61,6 +61,16 @@ file names (instead of Adiantum) if the device has Advanced Encryption Standard (AES) instructions. AES instructions are ARMv8 Cryptography Extensions on ARM-based devices, or AES-NI on x86-based devices. If the device does not have AES instructions, the device MAY use Adiantum. +* [C-1-13] MUST use a cryptographically strong and non-reversible key +derivation function (e.g. HKDF-SHA512) to derive any needed subkeys (e.g. +per-file keys) from the CE and DE keys. "Cryptographically strong and +non-reversible" means that the key derivation function has a security strength +of at least 256 bits and behaves as a [pseudorandom function +family](https://en.wikipedia.org/w/index.php?title=Pseudorandom_function_family&oldid=928163524) +over its inputs. +* [C-1-14] MUST NOT use the same File Based Encryption (FBE) keys or subkeys +for different cryptographic purposes (e.g. for both encryption and key +derivation, or for two different encryption algorithms). * The keys protecting CE and DE storage areas: |