Xiaomi Pocophone F1 128Gb+6Gb Dual LTE [111/118] Full disk encryption

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 with a key of 128-bits (or greater) and a mode designed for

storage (for example, AES-XTS, AES-CBC-ESSIV).

[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 provide the user the possibility to AES encrypt the encryption key, 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 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

Page 111 of 118