You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
338 lines
19 KiB
338 lines
19 KiB
4 months ago
|
## 9.11\. Keys and Credentials
|
||
|
|
||
|
The [Android Keystore System](https://developer.android.com/training/articles/keystore.html)
|
||
|
allows app developers to store cryptographic keys in a container and use them in
|
||
|
cryptographic operations through the [KeyChain API](https://developer.android.com/reference/android/security/KeyChain.html)
|
||
|
or the [Keystore API](https://developer.android.com/reference/java/security/KeyStore.html).
|
||
|
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](https://source.android.com/security/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)](http://source.android.com/devices/tech/security/authentication/gatekeeper.html)
|
||
|
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 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.
|
||
|
|
||
|
* [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. Automotive devices, that lock the screen whenever the head unit
|
||
|
is turned off or the user is switched, MAY NOT have the Sleep timeout
|
||
|
configuration.
|
||
|
|
||
|
### 9.11.1\. Secure Lock Screen and Authentication
|
||
|
|
||
|
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
|
||
|
* 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:
|
||
|
|
||
|
* [C-2-1] MUST be the user authentication method as described in
|
||
|
[Requiring User Authentication For Key Use](
|
||
|
https://developer.android.com/training/articles/keystore.html#UserAuthentication).
|
||
|
|
||
|
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:
|
||
|
|
||
|
* [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.
|
||
|
* [C-3-3] The new authentication method MUST NOT replace any of the
|
||
|
recommended primary authentication methods (i.e. PIN, pattern, password)
|
||
|
implemented and provided in AOSP.
|
||
|
* [C-3-4] The new authentication method MUST be disabled when the Device
|
||
|
Policy Controller (DPC) application has set the password quality policy
|
||
|
via the
|
||
|
[`DevicePolicyManager.setPasswordQuality()`](
|
||
|
https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setPasswordQuality%28android.content.ComponentName,%20int%29)
|
||
|
method with a more restrictive quality constant than
|
||
|
`PASSWORD_QUALITY_SOMETHING`.
|
||
|
* [C-3-5] New authentication methods MUST either fall back to the
|
||
|
recommended primary authentication methods (i.e. PIN, pattern,
|
||
|
password) once every 72 hours or less OR clearly disclose to the
|
||
|
user that some data will not be backed up in order to preserve
|
||
|
the privacy of their data.
|
||
|
|
||
|
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:
|
||
|
|
||
|
* [C-4-1] MUST meet all requirements described in [section
|
||
|
7.3.10](#7_3_10_biometric_sensors) for **Class 1** (formerly
|
||
|
**Convenience**).
|
||
|
* [C-4-2] MUST have a fall-back mechanism to use one of the recommended
|
||
|
primary authentication methods which is based on a known secret.
|
||
|
* [C-4-3] MUST be disabled and only allow the recommended primary
|
||
|
authentication to unlock the screen when the Device Policy Controller (DPC)
|
||
|
application has set the keyguard feature policy by calling the method
|
||
|
[`DevicePolicyManager.setKeyguardDisabledFeatures()`](
|
||
|
http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setKeyguardDisabledFeatures%28android.content.ComponentName,%20int%29)
|
||
|
, 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](#7_3_10_biometric_sensors):
|
||
|
|
||
|
* [C-5-1] The methods MUST be disabled if the Device Policy Controller (DPC)
|
||
|
application has set the password quality policy via the [`DevicePolicyManager.setPasswordQuality()`](
|
||
|
https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html\#setPasswordQuality%28android.content.ComponentName,%20int%29)
|
||
|
method with a more restrictive quality constant than
|
||
|
`PASSWORD_QUALITY_BIOMETRIC_WEAK`.
|
||
|
* [C-5-2] The user MUST be challenged for the recommended primary
|
||
|
authentication (eg: PIN, pattern, password) as described in [C-1-7] and
|
||
|
[C-1-8] in [section 7.3.10](#7_3_10_biometric_sensors).
|
||
|
* [C-5-3] The methods MUST NOT be treated as a secure lock screen, and MUST
|
||
|
meet the requirements that start with C-8 in this section below.
|
||
|
|
||
|
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:
|
||
|
|
||
|
* [C-6-1] They MUST have a fall-back mechanism to use one of the recommended
|
||
|
primary authentication methods which is based on a known secret and meet
|
||
|
the requirements to be treated as a secure lock screen.
|
||
|
* [C-6-2] The new method MUST be disabled and only allow one of the
|
||
|
recommended primary authentication methods to unlock the screen when the
|
||
|
Device Policy Controller (DPC) application has set the policy with either
|
||
|
the
|
||
|
[`DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS)`](
|
||
|
http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setKeyguardDisabledFeatures%28android.content.ComponentName,%20int%29)
|
||
|
method or the
|
||
|
[`DevicePolicyManager.setPasswordQuality()`](
|
||
|
https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setPasswordQuality%28android.content.ComponentName,%20int%29)
|
||
|
method with a more restrictive quality constant than
|
||
|
`PASSWORD_QUALITY_UNSPECIFIED`.
|
||
|
* [C-6-3] The user MUST be challenged for one of the recommended primary
|
||
|
authentication methods (e.g.PIN, pattern, password) at least once every 4
|
||
|
hours or less.
|
||
|
* [C-6-4] The new method MUST NOT be treated as a secure lock screen and MUST
|
||
|
follow the constraints listed in C-8 below.
|
||
|
|
||
|
If device implementations have a secure lock screen and include one or more
|
||
|
trust agent, which implements the `TrustAgentService` System API, they:
|
||
|
|
||
|
* [C-7-1] MUST have clear indication in the settings menu and on the lock
|
||
|
screen when device lock is deferred or can be unlocked by trust agent(s).
|
||
|
For example, AOSP meets this requirement by showing a text description for
|
||
|
the "Automatically lock setting" and "Power button instantly locks" in the
|
||
|
settings menu and a distinguishable icon on the lock screen.
|
||
|
* [C-7-2] MUST respect and fully implement all trust agent APIs in the
|
||
|
`DevicePolicyManager` class, such as the
|
||
|
[`KEYGUARD_DISABLE_TRUST_AGENTS`](
|
||
|
https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#KEYGUARD&lowbarDISABLE&lowbarTRUST&lowbarAGENTS)
|
||
|
constant.
|
||
|
* [C-7-3] MUST NOT fully implement the `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).
|
||
|
* [C-7-4] MUST encrypt all stored tokens added by
|
||
|
`TrustAgentService.addEscrowToken()`.
|
||
|
* [C-7-5] MUST NOT store the encryption key or escrow token on the
|
||
|
same device where the key is used. For example, it is allowed for
|
||
|
a key stored on a phone to unlock a user account on a TV.
|
||
|
For Automotive devices, it is not allowed for the escrow token to be stored
|
||
|
on any part of the vehicle.
|
||
|
* [C-7-6] MUST inform the user about the security implications before
|
||
|
enabling the escrow token to decrypt the data storage.
|
||
|
* [C-7-7] MUST have a fall-back mechanism to use one of the recommended
|
||
|
primary authentication methods.
|
||
|
* [C-7-8] The user MUST be challenged for one of the recommended primary
|
||
|
authentication (eg: PIN, pattern, password) methods at least once every 72
|
||
|
hours or less.
|
||
|
* [C-7-9] The user MUST be challenged for one of the recommended primary
|
||
|
authentication (eg: PIN, pattern, password) methods as described in
|
||
|
[C-1-7] and [C-1-8] in [section 7.3.10](#7_3_10_biometric_sensors).
|
||
|
* [C-7-10] MUST NOT be treated as a secure lock screen and MUST follow the
|
||
|
constraints listed in C-8 below.
|
||
|
* [C-7-11] MUST NOT allow TrustAgents on primary personal devices
|
||
|
(e.g: handheld) to unlock the device, and can only use them to
|
||
|
keep an already unlocked device in the unlocked state for up to a
|
||
|
maximum of 4 hours. The default implementation of
|
||
|
TrustManagerService in AOSP meets this requirement.
|
||
|
* [C-7-12] MUST use a cryptographically secure (e.g UKEY2)
|
||
|
communication channel to pass the escrow token from the storage
|
||
|
device to the target device.
|
||
|
|
||
|
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:
|
||
|
|
||
|
* [C-8-1] The new method MUST be disabled when the Device Policy Controller
|
||
|
(DPC) application has set the password quality policy via the
|
||
|
[`DevicePolicyManager.setPasswordQuality()`](
|
||
|
https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setPasswordQuality%28android.content.ComponentName,%20int%29)
|
||
|
method with a more restrictive quality constant than
|
||
|
`PASSWORD_QUALITY_UNSPECIFIED`.
|
||
|
* [C-8-2] They MUST NOT reset the password expiration timers set by
|
||
|
[`DevicePolicyManager.setPasswordExpirationTimeout()`](
|
||
|
http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setPasswordExpirationTimeout%28android.content.ComponentName,%20long%29).
|
||
|
* [C-8-3] They MUST NOT expose an API for use by third-party apps to
|
||
|
determine the lock state.
|
||
|
|
||
|
### 9.11.2\. StrongBox
|
||
|
|
||
|
The [Android Keystore System](
|
||
|
https://developer.android.com/training/articles/keystore.html) 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:
|
||
|
|
||
|
* [C-SR] Are STRONGLY RECOMMENDED to support StrongBox. StrongBox will
|
||
|
likely become a requirement in a future release.
|
||
|
|
||
|
If device implementations support StrongBox, they:
|
||
|
|
||
|
* [C-1-1] MUST declare [FEATURE_STRONGBOX_KEYSTORE](
|
||
|
https://developer.android.com/reference/kotlin/android/content/pm/PackageManager#FEATURE_STRONGBOX_KEYSTORE%3Akotlin.String).
|
||
|
|
||
|
* [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.
|
||
|
|
||
|
* [C-SR] are STRONGLY RECOMMENDED to provide insider attack resistance (IAR),
|
||
|
which means that an insider with access to firmware signing keys cannot produce
|
||
|
firmware that causes the StrongBox to leak secrets, to bypass functional
|
||
|
security requirements or otherwise enable access to sensitive user data. The
|
||
|
recommended way to implement IAR is to allow firmware updates only when the
|
||
|
primary user password is provided via the IAuthSecret HAL. IAR will likely
|
||
|
become a requirement in a future release.
|
||
|
|
||
|
### 9.11.3\. Identity Credential
|
||
|
|
||
|
The Identity Credential System is defined and achieved by implementing all
|
||
|
APIs in the
|
||
|
[`android.security.identity.*`](https://developer.android.com/reference/android/security/identity/package-summary)
|
||
|
package. These APIs allows app developers to store and retrieve user identity
|
||
|
documents. Device implementations:
|
||
|
|
||
|
* [C-SR] are STRONGLY RECOMMENDED to implement the Identity Credential
|
||
|
System.
|
||
|
|
||
|
If device implementations implement the Identity Credential System, they:
|
||
|
|
||
|
* [C-0-1] MUST return non-null for the [IdentityCredentialStore#getInstance()](
|
||
|
https://developer.android.com/reference/android/security/identity/IdentityCredentialStore#getInstance%28android.content.Context%29)
|
||
|
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()](https://developer.android.com/reference/android/security/identity/IdentityCredential#createEphemeralKeyPair%28%29)
|
||
|
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.
|