## 9.10\. Device Integrity The following requirements ensures there is transparancy to the status of the device integrity. Device implementations: * [C-0-1] MUST correctly report through the System API method `PersistentDataBlockManager.getFlashLockState()` whether their bootloader state permits flashing of the system image. The `FLASH_LOCK_UNKNOWN` state is reserved for device implementations upgrading from an earlier version of Android where this new system API method did not exist. Verified boot is a feature that guarantees the integrity of the device software. If a device implementation supports the feature, it: * [C-1-1] MUST declare the platform feature flag `android.software.verified_boot`. * [C-1-2] MUST perform verification on every boot sequence. * [C-1-3] MUST start verification from an immutable hardware key that is the root of trust and go all the way up to the system partition. * [C-1-4] MUST implement each stage of verification to check the integrity and authenticity of all the bytes in the next stage before executing the code in the next stage. * [C-1-5] MUST use verification algorithms as strong as current recommendations from NIST for hashing algorithms (SHA-256) and public key sizes (RSA-2048). * [C-1-6] MUST NOT allow boot to complete when system verification fails, unless the user consents to attempt booting anyway, in which case the data from any non-verified storage blocks MUST not be used. * [C-1-7] MUST NOT allow verified partitions on the device to be modified unless the user has explicitly unlocked the boot loader. * [SR] If there are multiple discrete chips in the device (e.g. radio, specialized image processor), the boot process of each of those chips is STRONGLY RECOMMENDED to verify every stage upon booting. * [SR] STRONGLY RECOMMENDED to use tamper-evident storage: for when the bootloader is unlocked. Tamper-evident storage means that the boot loader can detect if the storage has been tampered with from inside the HLOS (High Level Operating System). * [SR] STRONGLY RECOMMENDED to prompt the user, while using the device, and require physical confirmation before allowing a transition from boot loader locked mode to boot loader unlocked mode. * [SR] STRONGLY RECOMMENDED to implement rollback protection for the HLOS (e.g. boot, system partitions) and to use tamper-evident storage for storing the metadata used for determining the minimum allowable OS version. * SHOULD implement rollback protection for any component with persistent firmware (e.g. modem, camera) and SHOULD use tamper-evident storage for storing the metadata used for determining the minimum allowable version. The upstream Android Open Source Project provides a preferred implementation of this feature in the [`external/avb/`](http://android.googlesource.com/platform/external/avb/) repository, which can be integrated into the boot loader used for loading Android. If device implementations report the feature flag [`android.hardware.ram.normal`]( https://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_RAM_NORMAL) , they: * [C-2-1] MUST support verified boot for device integrity. If a device implementation is already launched without supporting verified boot on an earlier version of Android, such a device can not add support for this feature with a system software update and thus are exempted from the requirement.