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:
When the device implementation supports a secure lock screen, it:
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.
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:
A numerical PIN
An alphanumerical password
A swipe pattern on a grid of exactly 3x3 dots
Note that the above authentication methods are referred as the recommended primary authentication methods in this document.
If device implementations add or modify the recommended primary authentication methods and use a new authentication method as a secure way to lock the screen, the new authentication method:
If device implementations add or modify the authentication methods to unlock the lock screen if based on a known secret and use a new authentication method to be treated as a secure way to lock the screen:
DevicePolicyManager.setPasswordQuality() method with a more restrictive quality constant than PASSWORD_QUALITY_SOMETHING.If device implementations add or modify the recommended primary authentication methods to unlock the lock screen and use a new authentication method that is based on biometrics to be treated as a secure way to lock the screen, the new method:
DevicePolicyManager.setKeyguardDisabledFeatures() , with any of the associated biometric flags (i.e. KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE, or KEYGUARD_DISABLE_IRIS).If the biometric authentication methods do not meet the requirements for Class 3 (formerly Strong) as described in section 7.3.10:
DevicePolicyManager.setPasswordQuality() method with a more restrictive quality constant than PASSWORD_QUALITY_BIOMETRIC_WEAK.If device implementations add or modify the authentication methods to unlock the lock screen and a new authentication method is based on a physical token or the location:
DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) method or the DevicePolicyManager.setPasswordQuality() method with a more restrictive quality constant than PASSWORD_QUALITY_UNSPECIFIED.If device implementations have a secure lock screen and include one or more trust agent, which implements the TrustAgentService System API, they:
DevicePolicyManager class, such as the KEYGUARD_DISABLE_TRUST_AGENTS constant.TrustAgentService.addEscrowToken() function on a device that is used as a primary personal device (e.g. handheld) but MAY fully implement the function on device implementations that are typically shared (e.g. Android Television or Automotive device).TrustAgentService.addEscrowToken().If device implementations add or modify the authentication methods to unlock the lock screen that is not a secure lock screen as described above, and use a new authentication method to unlock the keyguard:
DevicePolicyManager.setPasswordQuality() method with a more restrictive quality constant than PASSWORD_QUALITY_UNSPECIFIED.DevicePolicyManager.setPasswordExpirationTimeout().The Android Keystore System allows app developers to store cryptographic keys in a dedicated secure processor as well as the isolated execution environment described above. Such a dedicated secure processor is called “StrongBox”. Requirements C-1-3 through C-1-11 below define the requirements a device must meet to qualify as a StrongBox.
Device implementations that have a dedicated secure processor:
If device implementations support StrongBox, they:
[C-1-1] MUST declare FEATURE_STRONGBOX_KEYSTORE.
[C-1-2] MUST provide dedicated secure hardware that is used to back keystore and secure user authentication. The dedicated secure hardware may be used for other purposes as well.
[C-1-3] MUST have a discrete CPU that shares no cache, DRAM, coprocessors or other core resources with the application processor (AP).
[C-1-4] MUST ensure that any peripherals shared with the AP cannot alter StrongBox processing in any way, or obtain any information from the StrongBox. The AP MAY disable or block access to StrongBox.
[C-1-5] MUST have an internal clock with reasonable accuracy (+-10%) that is immune to manipulation by the AP.
[C-1-6] MUST have a true random number generator that produces uniformly-distributed and unpredictable output.
[C-1-7] MUST have tamper resistance, including resistance against physical penetration, and glitching.
[C-1-8] MUST have side-channel resistance, including resistance against leaking information via power, timing, electromagnetic radiation, and thermal radiation side channels.
[C-1-9] MUST have secure storage which ensures confidentiality, integrity, authenticity, consistency, and freshness of the contents. The storage MUST NOT be able to be read or altered, except as permitted by the StrongBox APIs.
To validate compliance with [C-1-3] through [C-1-9], device implementations:
* [C-1-10] MUST include the hardware that is certified against the
Secure IC Protection Profile [BSI-CC-PP-0084-2014](
https://www.commoncriteriaportal.org/files/ppfiles/pp0084b_pdf.pdf) or
evaluated by a nationally accredited testing laboratory incorporating
High attack potential vulnerability assessment according to the
[Common Criteria Application of Attack Potential to Smartcards](
https://www.commoncriteriaportal.org/files/supdocs/CCDB-2013-05-002.pdf).
* [C-1-11] MUST include the firmware that is evaluated by a
nationally accredited testing laboratory incorporating High attack
potential vulnerability assessment according to the
[Common Criteria Application of Attack Potential to Smartcards](
https://www.commoncriteriaportal.org/files/supdocs/CCDB-2013-05-002.pdf).
* [C-SR] Are STRONGLY RECOMMENDED to include the hardware that is
evaluated using a Security Target, Evaluation Assurance Level
(EAL) 5, augmented by AVA_VAN.5. EAL 5 certification will likely
become a requirement in a future release.
The Identity Credential System is defined and achieved by implementing all APIs in the android.security.identity.* package. These APIs allows app developers to store and retrieve user identity documents. Device implementations:
If device implementations implement the Identity Credential System, they:
[C-0-1] MUST return non-null for the IdentityCredentialStore#getInstance() method.
[C-0-2] MUST implement the Identity Credential System (e.g. the android.security.identity.* APIs) with code communicating with a trusted application 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.
[C-0-3] The cryptographic operations needed to implement the Identity Credential System (e.g. the android.security.identity.* APIs) MUST be performed entirely in the trusted application and private key material MUST never leave the isolated execution environment unless specifically required by higher-level APIs (e.g. the createEphemeralKeyPair() method).
[C-0-4] The trusted application MUST be implemented in a way such that its security properties are not affected (e.g. credential data is not released unless access control conditions are satisfied, MACs can't be produced for arbitrary data) even if Android is misbehaving or compromised.