1## 9.9\. Data Storage Encryption 2 3All devices MUST meet the requirements of section 9.9.1. 4Devices which launched on an API level earlier than that of this document are 5exempted from the requirements of sections 9.9.2 and 9.9.3; instead they 6MUST meet the requirements in section 9.9 of the Android Compatibility 7Definition document corresponding to the API level on which the device launched. 8 9### 9.9.1\. Direct Boot 10 11Device implementations: 12 13* [C-0-1] MUST implement the [Direct Boot mode]( 14http://developer.android.com/preview/features/direct-boot.html) APIs even if 15they do not support Storage Encryption. 16 17* [C-0-2] The [`ACTION_LOCKED_BOOT_COMPLETED`]( 18https://developer.android.com/reference/android/content/Intent.html#ACTION_LOCKED_BOOT_COMPLETED) 19and [`ACTION_USER_UNLOCKED`](https://developer.android.com/reference/android/content/Intent.html#ACTION_USER_UNLOCKED) 20Intents MUST still be broadcast to signal Direct Boot aware applications that 21Device Encrypted (DE) and Credential Encrypted (CE) storage locations are 22available for user. 23 24### 9.9.2\. Encryption requirements 25 26Device implementations: 27 28* [C-0-1] MUST encrypt the application private 29data (`/data` partition), as well as the application shared storage partition 30(`/sdcard` partition) if it is a permanent, non-removable part of the device. 31* [C-0-2] MUST enable the data storage encryption by default at the time 32the user has completed the out-of-box setup experience. 33* [C-0-3] MUST meet the above data storage encryption 34requirement via implementing [File Based Encryption]( 35https://source.android.com/security/encryption/file-based.html) (FBE) and 36[Metadata Encryption](https://source.android.com/security/encryption/metadata). 37 38### 9.9.3\. Encryption Methods 39 40If device implementations are encrypted, they: 41 42* [C-1-1] MUST boot up without challenging the user for credentials and 43allow Direct Boot aware apps to access to the Device Encrypted (DE) storage 44after the `ACTION_LOCKED_BOOT_COMPLETED` message is broadcasted. 45* [C-1-2] MUST only allow access to Credential Encrypted (CE) storage after 46the user has unlocked the device by supplying their credentials 47(eg. passcode, pin, pattern or fingerprint) and the `ACTION_USER_UNLOCKED` 48message is broadcasted. 49* [C-1-13] MUST NOT offer any method to unlock the CE protected storage 50without either the user-supplied credentials, a registered escrow key or a 51resume on reboot implementation meeting the requirements in 52[section 9.9.4](#9_9_4_resume_on_reboot). 53* [C-1-4] MUST use Verified Boot. 54* [C-1-5] MUST encrypt file contents and filesystem metadata using 55AES-256-XTS or Adiantum. AES-256-XTS refers to the Advanced Encryption Standard 56with a 256-bit cipher key length, operated in XTS mode; the full length of the 57key is 512 bits. Adiantum refers to Adiantum-XChaCha12-AES, as specified at 58https://github.com/google/adiantum. Filesystem metadata is data such as file 59sizes, ownership, modes, and extended attributes (xattrs). 60* [C-1-6] MUST encrypt file names using AES-256-CBC-CTS 61or Adiantum. 62* [C-1-12] If the device has Advanced Encryption Standard (AES) 63instructions (such as ARMv8 Cryptography Extensions on ARM-based devices, or 64AES-NI on x86-based devices) then the AES-based options above for file name, 65file contents, and filesystem metadata encryption MUST be used, not Adiantum. 66* [C-1-13] MUST use a cryptographically strong and non-reversible key 67derivation function (e.g. HKDF-SHA512) to derive any needed subkeys (e.g. 68per-file keys) from the CE and DE keys. "Cryptographically strong and 69non-reversible" means that the key derivation function has a security strength 70of at least 256 bits and behaves as a [pseudorandom function 71family](https://en.wikipedia.org/w/index.php?title=Pseudorandom_function_family&oldid=928163524) 72over its inputs. 73* [C-1-14] MUST NOT use the same File Based Encryption (FBE) keys or subkeys 74for different cryptographic purposes (e.g. for both encryption and key 75derivation, or for two different encryption algorithms). 76 77* The keys protecting CE and DE storage areas and filesystem metadata: 78 79 * [C-1-7] MUST be cryptographically bound to a hardware-backed Keystore. 80 This keystore MUST be bound to Verified Boot and the device's hardware 81 root of trust. 82 * [C-1-8] CE keys MUST be bound to a user's lock screen credentials. 83 * [C-1-9] CE keys MUST be bound to a default passcode when the user has 84not specified lock screen credentials. 85 * [C-1-10] MUST be unique and distinct, in other words no user's CE or DE 86 key matches any other user's CE or DE keys. 87 * [C-1-11] MUST use the mandatorily supported ciphers, key lengths and 88 modes. 89 90* SHOULD make preinstalled essential apps (e.g. Alarm, Phone, Messenger) 91Direct Boot aware. 92 93The upstream Android Open Source project provides a preferred implementation of 94File Based Encryption based on the Linux kernel "fscrypt" encryption feature, 95and of Metadata Encryption based on the Linux kernel "dm-default-key" feature. 96 97### 9.9.4\. Resume on Reboot 98 99Resume on Reboot allows unlocking the CE storage of all apps, including those 100that do not yet support Direct Boot, after a reboot initiated by an OTA. This 101feature enables users to receive notifications from installed apps after the 102reboot. 103 104An implementation of Resume-on-Reboot must continue to ensure that when a 105device falls into an attacker’s hands, it is extremely difficult for that 106attacker to recover the user’s CE-encrypted data, even if the device is powered 107on, CE storage is unlocked, and the user has unlocked the device after receiving 108an OTA. For insider attack resistance, we also assume the attacker gains access 109to broadcast cryptographic signing keys. 110 111Specifically: 112 113* [C-0-1] CE storage MUST NOT be readable even for the attacker who physically has 114the device and then has these capabilities and limitations: 115 116 * Can use the signing key of any vendor or company to sign arbitrary 117 messages. 118 * Can cause an OTA to be received by the device. 119 * Can modify the operation of any hardware (AP, flash etc) except as 120 detailed below, but such modification involves a delay of at least an 121 hour and a power cycle that destroys RAM contents. 122 * Cannot modify the operation of tamper-resistant hardware (eg Titan M). 123 * Cannot read the RAM of the live device. 124 * Cannot obtain the user’s credential (PIN, pattern, password) or 125 otherwise cause it to be entered. 126 127By way of example, a device implementation that implements and complies with all 128of the descriptions found [here](https://source.android.com/devices/tech/ota/resume-on-reboot) 129will be compliant with [C-0-1]. 130