Xiaomi Pocophone F1 64Gb+6Gb Dual LTE [113/118] Secure lock screen
Макгруп McGrp.ru
Задайте вопрос
Зарегистрироваться

Xiaomi Pocophone F1 64Gb+6Gb Dual LTE [113/118] Secure lock screen

Xiaomi Pocophone F1 64Gb+6Gb Dual LTE [113/118] Secure lock screen
environment and only when successful, allow the authentication-bound keys to be used.
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.
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 hardware-backed keystore and support the key
attestation, unless it declares the android.hardware.fingerprint feature which requires a hardware-backed
keystore.
9.11.1. Secure Lock Screen
If device implementations have a secure lock screen and include one or more trust agent, which
implements the TrustAgentService System API, then they:
[C-1-1] MUST indicate the user in the Settings and Lock screen user interface of situations
where either the screen auto-lock is deferred or the screen lock can be unlocked by the
trust agent. The AOSP meets the requirement by showing a text description for the
"Automatically lock setting" and "Power button instantly locks setting" menus and a
distinguishable icon on the lock screen.
[C-1-2] MUST respect and fully implement all trust agent APIs in the DevicePolicyManager
class, such as the KEYGUARD_DISABLE_TRUST_AGENTS constant.
[C-1-3] MUST NOT fully implement the TrustAgentService.addEscrowToken() function on a
device that is used as the primary personal device (e.g. handheld) but MAY fully
implement the function on device implementations typically shared.
[C-1-4] MUST encrypt the tokens added by TrustAgentService.addEscrowToken() before storing
them on the device.
[C-1-5] MUST NOT store the encryption key on the device.
[C-1-6] MUST inform the user about the security implications before enabling the escrow
token to decrypt the data storage.
If device implementations add or modify the authentication methods to unlock the lock screen, then
for such an authentication method to be treated as a secure way to lock the screen, they:
[C-2-1] MUST be the user authentication method as described in Requiring User
Authentication For Key Use .
[C-2-2] MUST unlock all keys for a third-party developer app to use when the user unlocks
the secure lock screen. For example, all keys MUST be available for a third-party
developer app through relevant APIs, such as createConfirmDeviceCredentialIntent and
setUserAuthenticationRequired .
If device implementations add or modify the authentication methods to unlock the lock screen if
based on a known secret then for such an authentication method to be treated as a secure way to
lock the screen, they:
[C-3-1] The entropy of the shortest allowed length of inputs MUST be greater than 10 bits.
[C-3-2] The maximum entropy of all possible inputs MUST be greater than 18 bits.
Page 113 of 118

Содержание

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

Скачать