Home | History | Annotate | Download | only in 9_security-model
      1 ## 9.10\. Device Integrity
      2 
      3 The following requirements ensures there is transparancy to the status of the
      4 device integrity. Device implementations:
      5 
      6 *    [C-0-1] MUST correctly report through the System API method
      7 `PersistentDataBlockManager.getFlashLockState()` whether their bootloader
      8 state permits flashing of the system image. The `FLASH_LOCK_UNKNOWN` state is
      9 reserved for device implementations upgrading from an earlier version of Android
     10 where this new system API method did not exist.
     11 
     12 Verified boot is a feature that guarantees the integrity of the device
     13 software. If a device implementation supports the feature, it:
     14 
     15 *    [C-1-1] MUST declare the platform feature flag
     16 `android.software.verified_boot`.
     17 *    [C-1-2] MUST perform verification on every boot sequence.
     18 *    [C-1-3] MUST start verification from an immutable hardware key that is the
     19 root of trust and go all the way up to the system partition.
     20 *    [C-1-4] MUST implement each stage of verification to check the integrity
     21 and authenticity of all the bytes in the next stage before executing the code in
     22 the next stage.
     23 *    [C-1-5] MUST use verification algorithms as strong as current
     24 recommendations from NIST for hashing algorithms (SHA-256) and public key
     25 sizes (RSA-2048).
     26 *    [C-1-6] MUST NOT allow boot to complete when system verification fails,
     27 unless the user consents to attempt booting anyway, in which case the data from
     28 any non-verified storage blocks MUST not be used.
     29 *    [C-1-7] MUST NOT allow verified partitions on the device to be modified
     30 unless the user has explicitly unlocked the boot loader.
     31 *    [SR] If there are multiple discrete chips in the device (e.g. radio,
     32 specialized image processor), the boot process of each of those chips is
     33 STRONGLY RECOMMENDED to verify every stage upon booting.
     34 *    [SR] STRONGLY RECOMMENDED to use tamper-evident storage: for when the
     35 bootloader is unlocked. Tamper-evident storage means that the boot loader can
     36 detect if the storage has been tampered with from inside the
     37 HLOS (High Level Operating System).
     38 *    [SR] STRONGLY RECOMMENDED to prompt the user, while using the device, and
     39 require physical confirmation before allowing a transition from boot loader
     40 locked mode to boot loader unlocked mode.
     41 *    [SR] STRONGLY RECOMMENDED to implement rollback protection for the HLOS
     42 (e.g. boot, system partitions) and to use tamper-evident storage for storing the
     43 metadata used for determining the minimum allowable OS version.
     44 *    SHOULD implement rollback protection for any component with persistent
     45 firmware (e.g. modem, camera) and SHOULD use tamper-evident storage for
     46 storing the metadata used for determining the minimum allowable version.
     47 
     48 The upstream Android Open Source Project provides a preferred implementation of
     49 this feature in the [`external/avb/`](http://android.googlesource.com/platform/external/avb/)
     50 repository, which can be integrated into the boot loader used for loading
     51 Android.
     52 
     53 If device implementations report the feature flag [`android.hardware.ram.normal`](
     54 https://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_RAM_NORMAL)
     55 , they:
     56 
     57 *    [C-2-1] MUST support verified boot for device integrity.
     58 
     59 If a device implementation is already launched without supporting verified boot
     60 on an earlier version of Android, such a device can not add support for this
     61 feature with a system software update and thus are exempted from the
     62 requirement.
     63