Xiaomi Redmi Note 8 Pro 128Gb+6Gb Dual LTE [124/132] Secure lock screen

Xiaomi Redmi Note 8 Pro 128Gb+6Gb Dual LTE [124/132] Secure lock screen
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 allow at least 8,192 keys to be imported or generated.
[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 an isolated execution
environment.
[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
environment and only when successful, allow the authentication-bound keys to be used.
Lock screen credentials MUST be stored in a way that allows only the isolated execution
environment to perform lock screen authentication. The upstream Android Open Source
Project provides the Gatekeeper Hardware Abstraction Layer (HAL) and Trusty, which can
be used to satisfy this requirement.
[C-1-4] MUST support key attestation where the attestation signing key is protected by
secure hardware and signing is performed in secure hardware. The attestation signing
keys MUST be shared across large enough number of devices to prevent the keys from
being used as device identifiers. One way of meeting this requirement is to share the
same attestation key unless at least 100,000 units of a given SKU are produced. If more
than 100,000 units of an SKU are produced, a different key MAY be used for each 100,000
units.
[C-1-5] MUST allow the user to choose the Sleep timeout for transition from the unlocked
to the locked state, with a minimum allowable timeout up to 15 seconds.
Note that if a device implementation is already launched on an earlier Android version, such a device
is exempted from the requirement to have a keystore backed by an isolated execution environment
and support the key attestation, unless it declares the android.hardware.fingerprint feature which requires
a keystore backed by an isolated execution environment.
9.11.1. Secure Lock Screen
The AOSP implementation follows a tiered authentication model where a knowledge-factory based
primary authentication can be backed by either a secondary strong biometric, or by weaker tertiary
modalities.
Device implementations:
[C-SR] Are STRONGLY RECOMMENDED to set only one of the following as the primary
authentication method:
A numerical PIN
Page 124 of 132

Содержание

Скачать