|
|
## 9.9\. Data Storage Encryption
|
|
|
|
|
|
All devices MUST meet the requirements of section 9.9.1.
|
|
|
Devices which launched on an API level earlier than that of this document are
|
|
|
exempted from the requirements of sections 9.9.2 and 9.9.3; instead they
|
|
|
MUST meet the requirements in section 9.9 of the Android Compatibility
|
|
|
Definition document corresponding to the API level on which the device launched.
|
|
|
|
|
|
### 9.9.1\. Direct Boot
|
|
|
|
|
|
Device implementations:
|
|
|
|
|
|
* [C-0-1] MUST implement the [Direct Boot mode](
|
|
|
http://developer.android.com/preview/features/direct-boot.html) APIs even if
|
|
|
they do not support Storage Encryption.
|
|
|
|
|
|
* [C-0-2] The [`ACTION_LOCKED_BOOT_COMPLETED`](
|
|
|
https://developer.android.com/reference/android/content/Intent.html#ACTION_LOCKED_BOOT_COMPLETED)
|
|
|
and [`ACTION_USER_UNLOCKED`](https://developer.android.com/reference/android/content/Intent.html#ACTION_USER_UNLOCKED)
|
|
|
Intents MUST still be broadcast to signal Direct Boot aware applications that
|
|
|
Device Encrypted (DE) and Credential Encrypted (CE) storage locations are
|
|
|
available for user.
|
|
|
|
|
|
### 9.9.2\. Encryption requirements
|
|
|
|
|
|
Device implementations:
|
|
|
|
|
|
* [C-0-1] MUST encrypt the application private
|
|
|
data (`/data` partition), as well as the application shared storage partition
|
|
|
(`/sdcard` partition) if it is a permanent, non-removable part of the device.
|
|
|
* [C-0-2] MUST enable the data storage encryption by default at the time
|
|
|
the user has completed the out-of-box setup experience.
|
|
|
* [C-0-3] MUST meet the above data storage encryption
|
|
|
requirement via implementing [File Based Encryption](
|
|
|
https://source.android.com/security/encryption/file-based.html) (FBE) and
|
|
|
[Metadata Encryption](https://source.android.com/security/encryption/metadata).
|
|
|
|
|
|
### 9.9.3\. Encryption Methods
|
|
|
|
|
|
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
|
|
|
after the `ACTION_LOCKED_BOOT_COMPLETED` message is broadcasted.
|
|
|
* [C-1-2] MUST only allow access to Credential Encrypted (CE) storage after
|
|
|
the user has unlocked the device by supplying their credentials
|
|
|
(eg. passcode, pin, pattern or fingerprint) and the `ACTION_USER_UNLOCKED`
|
|
|
message is broadcasted.
|
|
|
* [C-1-13] MUST NOT offer any method to unlock the CE protected storage
|
|
|
without either the user-supplied credentials, a registered escrow key or a
|
|
|
resume on reboot implementation meeting the requirements in
|
|
|
[section 9.9.4](#9_9_4_resume_on_reboot).
|
|
|
* [C-1-4] MUST use Verified Boot.
|
|
|
* [C-1-5] MUST encrypt file contents and filesystem metadata using
|
|
|
AES-256-XTS or Adiantum. AES-256-XTS refers to the Advanced Encryption Standard
|
|
|
with a 256-bit cipher key length, operated in XTS mode; the full length of the
|
|
|
key is 512 bits. Adiantum refers to Adiantum-XChaCha12-AES, as specified at
|
|
|
https://github.com/google/adiantum. Filesystem metadata is data such as file
|
|
|
sizes, ownership, modes, and extended attributes (xattrs).
|
|
|
* [C-1-6] MUST encrypt file names using AES-256-CBC-CTS
|
|
|
or Adiantum.
|
|
|
* [C-1-12] If the device has Advanced Encryption Standard (AES)
|
|
|
instructions (such as ARMv8 Cryptography Extensions on ARM-based devices, or
|
|
|
AES-NI on x86-based devices) then the AES-based options above for file name,
|
|
|
file contents, and filesystem metadata encryption MUST be used, not 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 and filesystem metadata:
|
|
|
|
|
|
* [C-1-7] MUST be cryptographically bound to a hardware-backed Keystore.
|
|
|
This keystore MUST be bound to Verified Boot and the device's hardware
|
|
|
root of trust.
|
|
|
* [C-1-8] CE keys MUST be bound to a user's lock screen credentials.
|
|
|
* [C-1-9] CE keys MUST be bound to a default passcode when the user has
|
|
|
not specified lock screen credentials.
|
|
|
* [C-1-10] MUST be unique and distinct, in other words no user's CE or DE
|
|
|
key matches any other user's CE or DE keys.
|
|
|
* [C-1-11] MUST use the mandatorily supported ciphers, key lengths and
|
|
|
modes.
|
|
|
|
|
|
* SHOULD make preinstalled essential apps (e.g. Alarm, Phone, Messenger)
|
|
|
Direct Boot aware.
|
|
|
|
|
|
The upstream Android Open Source project provides a preferred implementation of
|
|
|
File Based Encryption based on the Linux kernel "fscrypt" encryption feature,
|
|
|
and of Metadata Encryption based on the Linux kernel "dm-default-key" feature.
|
|
|
|
|
|
### 9.9.4\. Resume on Reboot
|
|
|
|
|
|
Resume on Reboot allows unlocking the CE storage of all apps, including those
|
|
|
that do not yet support Direct Boot, after a reboot initiated by an OTA. This
|
|
|
feature enables users to receive notifications from installed apps after the
|
|
|
reboot.
|
|
|
|
|
|
An implementation of Resume-on-Reboot must continue to ensure that when a
|
|
|
device falls into an attacker’s hands, it is extremely difficult for that
|
|
|
attacker to recover the user’s CE-encrypted data, even if the device is powered
|
|
|
on, CE storage is unlocked, and the user has unlocked the device after receiving
|
|
|
an OTA. For insider attack resistance, we also assume the attacker gains access
|
|
|
to broadcast cryptographic signing keys.
|
|
|
|
|
|
Specifically:
|
|
|
|
|
|
* [C-0-1] CE storage MUST NOT be readable even for the attacker who physically has
|
|
|
the device and then has these capabilities and limitations:
|
|
|
|
|
|
* Can use the signing key of any vendor or company to sign arbitrary
|
|
|
messages.
|
|
|
* Can cause an OTA to be received by the device.
|
|
|
* Can modify the operation of any hardware (AP, flash etc) except as
|
|
|
detailed below, but such modification involves a delay of at least an
|
|
|
hour and a power cycle that destroys RAM contents.
|
|
|
* Cannot modify the operation of tamper-resistant hardware (eg Titan M).
|
|
|
* Cannot read the RAM of the live device.
|
|
|
* Cannot obtain the user’s credential (PIN, pattern, password) or
|
|
|
otherwise cause it to be entered.
|
|
|
|
|
|
By way of example, a device implementation that implements and complies with all
|
|
|
of the descriptions found [here](https://source.android.com/devices/tech/ota/resume-on-reboot)
|
|
|
will be compliant with [C-0-1].
|
