Xiaomi Redmi Note 8 Pro 128Gb+6Gb Dual LTE [122/132] Device integrity

[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 by default.

[C-SR] Are STRONGLY RECOMMENDED to encrypt file system metadata, such as file

sizes, ownership, modes, and Extended attributes (xattrs), with a key cryptographically

bound to the device's hardware root of trust.

SHOULD make preloaded essential apps (e.g. Alarm, Phone, Messenger) Direct Boot

aware.

MAY support alternative ciphers, key lengths and modes for file content and file name

encryption.

The upstream Android Open Source project provides a preferred implementation of this feature

based on the Linux kernel ext4 encryption feature.

9.9.3. Full Disk Encryption

If device implementations support full disk encryption (FDE), they:

[C-1-1] MUST use AES in a mode designed for storage (for example, XTS or CBC-ESSIV),

and with a cipher key length of 128 bits or greater.

[C-1-2] MUST use a default passcode to wrap the encryption key and MUST NOT write the

encryption key to storage at any time without being encrypted.

[C-1-3] MUST AES encrypt the encryption key by default unless the user explicitly opts

out, except when it is in active use, with the lock screen credentials stretched using a

slow stretching algorithm (e.g. PBKDF2 or scrypt).

[C-1-4] The above default password stretching algorithm MUST be cryptographically

bound to that keystore when the user has not specified a lock screen credentials or has

disabled use of the passcode for encryption and the device provides a hardware-backed

keystore.

[C-1-5] MUST NOT send encryption key off the device (even when wrapped with the user

passcode and/or hardware bound key).

The upstream Android Open Source project provides a preferred implementation of this feature,

based on the Linux kernel feature dm-crypt.

9.10. Device Integrity

The following requirements ensures there is transparency 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.

[C-0-2] MUST support Verified Boot for device integrity.

If device implementations are already launched without supporting Verified Boot on an earlier version

of Android and can not add support for this feature with a system software update, they MAY be

exempted from the requirement.

Verified Boot is a feature that guarantees the integrity of the device software. If device

Page 122 of 132