1## 9.10\. Device Integrity 2 3The following requirements ensure there is transparency to the status of the 4device integrity. Device implementations: 5 6* [C-0-1] MUST correctly report through the System API method 7`PersistentDataBlockManager.getFlashLockState()` whether their bootloader 8state permits flashing of the system image. The `FLASH_LOCK_UNKNOWN` state is 9reserved for device implementations upgrading from an earlier version of Android 10where this new system API method did not exist. 11 12* [C-0-2] MUST support Verified Boot for device integrity. 13 14If device implementations are already launched without supporting Verified Boot 15on an earlier version of Android and can not add support for this 16feature with a system software update, they MAY be exempted from the 17requirement. 18 19Verified Boot is a feature that guarantees the integrity of the device 20software. If device implementations support the feature, they: 21 22* [C-1-1] MUST declare the platform feature flag 23`android.software.verified_boot`. 24* [C-1-2] MUST perform verification on every boot sequence. 25* [C-1-3] MUST start verification from an immutable hardware key that is the 26root of trust and go all the way up to the system partition. 27* [C-1-4] MUST implement each stage of verification to check the integrity 28and authenticity of all the bytes in the next stage before executing the code in 29the next stage. 30* [C-1-5] MUST use verification algorithms as strong as current 31recommendations from NIST for hashing algorithms (SHA-256) and public key 32sizes (RSA-2048). 33* [C-1-6] MUST NOT allow boot to complete when system verification fails, 34unless the user consents to attempt booting anyway, in which case the data from 35any non-verified storage blocks MUST not be used. 36* [C-1-7] MUST NOT allow verified partitions on the device to be modified 37unless the user has explicitly unlocked the bootloader. 38* [C-SR] If there are multiple discrete chips in the device (e.g. radio, 39specialized image processor), the boot process of each of those chips is 40STRONGLY RECOMMENDED to verify every stage upon booting. 41* [C-1-8] MUST use tamper-evident storage: for storing whether the 42bootloader is unlocked. Tamper-evident storage means that the bootloader can 43detect if the storage has been tampered with from inside Android. 44* [C-1-9] MUST prompt the user, while using the device, and 45require physical confirmation before allowing a transition from bootloader 46locked mode to bootloader unlocked mode. 47* [C-1-10] MUST implement rollback protection for partitions used by Android 48(e.g. boot, system partitions) and use tamper-evident storage for storing the 49metadata used for determining the minimum allowable OS version. 50* [C-SR] Are STRONGLY RECOMMENDED to verify all privileged app APK files with 51a chain of trust rooted in partitions protected by Verified Boot. 52* [C-SR] Are STRONGLY RECOMMENDED to verify any executable artifacts loaded by 53a privileged app from outside its APK file (such as dynamically loaded code or 54compiled code) before executing them or STRONGLY RECOMMENDED not to execute them 55at all. 56* SHOULD implement rollback protection for any component with persistent 57firmware (e.g. modem, camera) and SHOULD use tamper-evident storage for 58storing the metadata used for determining the minimum allowable version. 59 60If device implementations are already launched without supporting C-1-8 through 61C-1-10 on an earlier version of Android and can not add support for 62these requirements with a system software update, they MAY be exempted from the 63requirements. 64 65The upstream Android Open Source Project provides a preferred implementation of 66this feature in the [`external/avb/`]( 67http://android.googlesource.com/platform/external/avb/) 68repository, which can be integrated into the bootloader used for loading 69Android. 70 71Device implementations: 72 73* [C-0-3] MUST support cryptographically verifying file content against a 74 trusted key without reading the whole file. 75* [C-0-4] MUST NOT allow the read requests on a protected file to succeed 76 when the read content do not verify against a trusted key. 77* [C-0-5] MUST enable the above-described cryptographic file verification 78 protection for all files for the package that is installed 79 with trusted signature files as described [here]( 80 https://developer.android.com/preview/security/features/apk-verity). 81 82If device implementations are already launched without the ability to verify 83file content against a trusted key on an earlier Android version and can not add 84support for this feature with a system software update, they MAY be exempted 85from the requirement. The upstream Android Open Source project provides a 86preferred implementation of this feature based on the Linux kernel [fs-verity]( 87https://www.kernel.org/doc/html/latest/filesystems/fsverity.html) feature. 88 89Device implementations: 90 91* [C-R] Are RECOMMENDED to support the [Android Protected Confirmation API]( 92https://developer.android.com/preview/features/security.html#user-confirmation). 93 94If device implementations support the Android Protected Confirmation 95API they: 96 97* [C-3-1] MUST report `true` for the [`ConfirmationPrompt.isSupported()`]( 98https://developer.android.com/reference/android/security/ConfirmationPrompt.html#isSupported%28android.content.Context%29) 99API. 100 101* [C-3-2] MUST ensure that code running in the Android OS including its 102 kernel, malicious or otherwise, cannot generate a positive response without 103 user interaction. 104 105* [C-3-3] MUST ensure that the user has been able to review and approve the 106 prompted message even in the event that the Android OS, including its kernel, 107 is compromised. 108