AGM A9 32Gb+4Gb Dual LTE [112/118] Keys and credentials
Макгруп McGrp.ru
Задайте вопрос
Зарегистрироваться

AGM A9 32Gb+4Gb Dual LTE [112/118] Keys and credentials

AGM A9 32Gb+4Gb Dual LTE [112/118] Keys and credentials
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/ repository, which can be integrated into the boot loader used for loading Android.
Device implementations with Advanced Encryption Standard (AES) crypto performance above 50
MiB/seconds:
[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.
9.11. Keys and Credentials
The Android Keystore System allows app developers to store cryptographic keys in a container and
use them in cryptographic operations through the KeyChain API or the Keystore API . Device
implementations:
[C-0-1] MUST at least allow more than 8,192 keys to be imported.
[C-0-2] The lock screen authentication MUST rate-limit attempts and MUST have an
exponential backoff algorithm. Beyond 150 failed attempts, the delay MUST be at least 24
hours per attempt.
SHOULD not limit the number of keys that can be generated
When the device implementation supports a secure lock screen, it:
[C-1-1] MUST back up the keystore implementation with secure hardware.
[C-1-2] MUST have implementations of RSA, AES, ECDSA and HMAC cryptographic
algorithms and MD5, SHA1, and SHA-2 family hash functions to properly support the
Android Keystore system's supported algorithms in an area that is securely isolated from
the code running on the kernel and above. Secure isolation MUST block all potential
mechanisms by which kernel or userspace code might access the internal state of the
isolated environment, including DMA. The upstream Android Open Source Project (AOSP)
meets this requirement by using the Trusty implementation, but another ARM TrustZone-
based solution or a third-party reviewed secure implementation of a proper hypervisor-
based isolation are alternative options.
[C-1-3] MUST perform the lock screen authentication in the isolated execution
Page 112 of 118

Содержание

Похожие устройства

Скачать