CDD: Update CDD language for biometrics and lockscreen.
This CL makes CDD changes that are aimed at providing more explicit
guidance on creating secure biometric based unlocks, and on
consolidating the CDD language for secure lockscreens to make the
authentication model consistent with our security bar.
More specifically, it changes the following things:
(1) A new section similar to "7.3.10 Fingerprint Sensors" that's more
generic and applicable to all biometric sensors. Should have mostly
the same constraints but slightly altered where necessary.
(2) Language that deals with match-on-chip solutions for biometrics.
(3) A new requirement in 9.11 that mandates keeping a minimum
Sleep timeout of at most 15 seconds.
(4) New requirements in "9.11.1 Secure Lock Screens" that:
(a) Constrain what a primary authentication can be.
(b) Adds information related to alternate biometric unlocks and
adhering to the SAR/IAR bar that was introduced in the 8.1 CDD
(c) Adds requirements around 'passive' biometric unlocks like Face
when used to unlock keystore keys.
(d) Clarifies some language around falling back to requiring primary
auth every 72 hours for all non-primary modes of authentication
(5) Removes the API requirement to return false for both the KeyguardManager.isKeyguardSecure() and the KeyguardManager.isDeviceSecure() methods.
Bug: 73723272
Bug: 77656214
Bug: 111053551
Test: --
Change-Id: Iede9eba5ac79de56802cd830c3dc4e521f40e098
diff --git a/7_hardware-compatibility/7_3_sensors.md b/7_hardware-compatibility/7_3_sensors.md
index f902c1c..0656888 100644
--- a/7_hardware-compatibility/7_3_sensors.md
+++ b/7_hardware-compatibility/7_3_sensors.md
@@ -482,7 +482,7 @@
* [C-2-15] MUST deliver samples to applications within 5 milliseconds from
the time when the data is available on any of the above physical sensors
to the application.
-* [C-2-16] MUST not have a power consumption higher than 0.5 mW
+* [C-2-16] MUST NOT have a power consumption higher than 0.5 mW
when device is static and 2.0 mW when device is moving
when any combination of the following sensors are enabled:
* `SENSOR_TYPE_SIGNIFICANT_MOTION`
@@ -518,7 +518,9 @@
* `TYPE_MAGNETIC_FIELD`
* `TYPE_MAGNETIC_FIELD_UNCALIBRATED`
-### 7.3.10\. Fingerprint Sensor
+### 7.3.10\. Biometric Sensors
+
+#### 7.3.10.1\. Fingerprint Sensors
If device implementations include a secure lock screen, they:
@@ -545,8 +547,8 @@
a secure channel to the TEE.
* [C-1-7] MUST have all identifiable fingerprint data encrypted and
cryptographically authenticated such that they cannot be acquired, read or
-altered outside of the Trusted Execution Environment (TEE) as documented in the
-[implementation guidelines](
+altered outside of the Trusted Execution Environment (TEE), or a chip with a
+secure channel to the TEE as documented in the [implementation guidelines](
https://source.android.com/devices/tech/security/authentication/fingerprint-hal.html)
on the Android Open Source Project site.
* [C-1-8] MUST prevent adding a fingerprint without first establishing a chain
@@ -560,6 +562,10 @@
* [C-1-11] MUST, when upgraded from a version earlier than Android 6.0, have
the fingerprint data securely migrated to meet the above requirements or
removed.
+* [C-1-12] MUST completely remove all identifiable fingerprint data for a
+user when the user's account is removed (including via a factory reset).
+* [C-1-13] MUST not allow unencrypted access to identifiable fingerprint data
+or any data derived from it (such as embeddings) to the Application Processor.
* [SR] Are STRONGLY RECOMMENDED to have a false rejection rate of less than 10%,
as measured on the device.
* [SR] Are STRONGLY RECOMMENDED to have a latency below 1 second, measured from
@@ -568,6 +574,52 @@
* SHOULD use the Android Fingerprint icon provided in the Android Open Source
Project.
+#### 7.3.10.2\. Other Biometric Sensors
+
+If device implementations include one or more non-fingerprint-based-biometric
+sensors and make them available to third-party apps they:
+
+* [C-1-1] MUST have a false acceptance rate not higher than 0.002%.
+* [C-SR] Are STRONGLY RECOMMENDED to have a spoof and imposter acceptance rate
+not higher than 7%.
+* [C-1-2] MUST disclose that this mode may be less secure than a strong PIN,
+pattern, or password and clearly enumerate the risks of enabling it, if the
+spoof and imposter acceptance rates are higher than 7%.
+* [C-1-3] MUST rate limit attempts for at least 30 seconds after five false
+trials for biometric verification - where a false trial is one with an adequate
+capture quality
+(ACQUIRED_GOOD) that does not match an enrolled biometric
+* [C-1-4] MUST have a hardware-backed keystore implementation, and perform the
+biometric matching in a Trusted Execution Environment (TEE) or on a chip with
+a secure channel to the TEE.
+* [C-1-5] MUST have all identifiable data encrypted and cryptographically
+authenticated such that they cannot be acquired, read or altered outside of the
+Trusted Execution Environment (TEE), or a chip with a secure channel to the TEE
+as documented in the [implementation guidelines](
+https://source.android.com/devices/tech/security/authentication/fingerprint-hal.html)
+on the Android Open Source Project site.
+* [C-1-6] MUST prevent adding new biometrics without first establishing a chain
+of trust by having the user confirm existing or add a new device credential
+(PIN/pattern/password) that's secured by TEE; the Android Open Source Project
+implementation provides the mechanism in the framework to do so.
+* [C-1-7] MUST NOT enable third-party applications to distinguish between
+biometric enrollments.
+* [C-1-8] MUST honor the individual flag for that biometric (ie:
+`DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT`,
+`DevicePolicymanager.KEYGUARD_DISABLE_FACE`, or
+`DevicePolicymanager.KEYGUARD_DISABLE_IRIS`).
+* [C-1-9] MUST completely remove all identifiable biometric data for a user when
+the user's account is removed (including via a factory reset).
+* [C-1-10] MUST not allow unencrypted access to identifiable biometric data or any
+data derived from it (such as embeddings) to the Application Processor outside
+the context of the TEE.
+* [C-SR] Are STRONGLY RECOMMENDED to have a false rejection rate of less than 10%,
+as measured on the device.
+* [C-SR] Are STRONGLY RECOMMENDED to have a latency below 1 second, measured from
+when the biometric is detected, until the screen is unlocked, for each
+enrolled biometric.
+
+
### 7.3.11\. Android Automotive-only sensors
Automotive-specific sensors are defined in the
diff --git a/9_security-model/9_11_keys-and-credentials.md b/9_security-model/9_11_keys-and-credentials.md
index 67338a6..7b314dc 100644
--- a/9_security-model/9_11_keys-and-credentials.md
+++ b/9_security-model/9_11_keys-and-credentials.md
@@ -40,6 +40,9 @@
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 timout 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
@@ -49,122 +52,197 @@
### 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:
+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.
-* [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`](https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#KEYGUARD&lowbarDISABLE&lowbarTRUST&lowbarAGENTS)
-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.
+Device implementations:
-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-SR] Are STRONGLY RECOMMENDED to set only one of the following as the primary authentication
+method:
+ * A numerical PIN,
+ * An alphanumerical password, or
+ * 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).
+ [Requiring User Authentication For Key Use](
+ https://developer.android.com/training/articles/keystore.html#UserAuthentication).
* [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`](https://developer.android.com/reference/android/app/KeyguardManager.html#createConfirmDeviceCredentialIntent%28java.lang.CharSequence, java.lang.CharSequence%29)
-and [`setUserAuthenticationRequired`](https://developer.android.com/reference/android/security/keystore/KeyGenParameterSpec.Builder.html#setUserAuthenticationRequired%28boolean%29).
+ 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`](
+ https://developer.android.com/reference/android/app/KeyguardManager.html#createConfirmDeviceCredentialIntent%28java.lang.CharSequence, java.lang.CharSequence%29)
+ and [`setUserAuthenticationRequired`](
+ https://developer.android.com/reference/android/security/keystore/KeyGenParameterSpec.Builder.html#setUserAuthenticationRequired%28boolean%29).
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:
+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.
+ greater than 10 bits.
* [C-3-2] The maximum entropy of all possible inputs MUST be greater than
-18 bits.
-* [C-3-3] MUST not replace any of the existing authentication methods
-(PIN,pattern, password) implemented and provided in AOSP.
-* [C-3-4] 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`.
+ 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`.
-If device implementations add or modify the authentication methods to unlock
-the lock screen if based on a physical token or the location, then for such an
-authentication method to be treated as a secure way to lock the screen, they:
+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 have a fall-back mechanism to use one of the primary
-authentication methods which is based on a known secret and meets the
-requirements to be treated as a secure lock screen.
-* [C-4-2] MUST be disabled and only allow the primary authentication 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-4-3] The user MUST be challenged for the primary authentication
-(e.g.PIN, pattern, password) at least once every 72 hours or less.
-
-If device implementations add or modify the authentication methods to unlock
-the lock screen based on biometrics, then for such an authentication method to
-be treated as a secure way to lock the screen, they:
-
-* [C-5-1] MUST have a fall-back mechanism to use one of the primary
-authentication methods which is based on a known secret and meets the
-requirements to be treated as a secure lock screen.
-* [C-5-2] MUST be disabled and only allow the primary authentication to
-unlock the screen when the Device Policy Controller (DPC) application has set
-the keguard feature policy by calling the method
-[`DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_FINGERPRINT)`](http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setKeyguardDisabledFeatures%28android.content.ComponentName,%20int%29).
-* [C-5-3] MUST have a false acceptance rate that is equal or stronger than
-what is required for a fingerprint sensor as described in section 7.3.10, or
-otherwise MUST be disabled and only allow the primary authentication to unlock
-the screen 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_BIOMETRIC_WEAK`.
+* [C-4-1] MUST meet all requirements described in
+ [section 7.3.10.2](#7_3_10_2_other_biometric_sensors).
+* [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 keguard 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`).
+* [C-4-4] MUST challenge the user for the recommended primary authentication
+ (e.g. PIN, pattern, password) at least once very 72 hours or less.
+* [C-4-5] MUST have a false acceptance rate that is equal or stronger than
+ what is required for a fingerprint sensor as described in section
+ [section 7.3.10](#7_3_10_biometric_sensors),
+ or otherwise
+ MUST be disabled and only allow the recommended primary authentication
+ to unlock the screen 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_BIOMETRIC_WEAK`.
* [C-SR] Are STRONGLY RECOMMENDED to have spoof and imposter acceptance rates
-that are equal to or stronger than what is required for a fingerprint sensor as
-described in section 7.3.10.
+ that are equal to or stronger than what is required for a fingerprint
+ sensor as described in [section 7.3.10](#7_3_10_biometric_sensors).
+* [C-4-6] MUST have a secure processing pipeline such that an operating
+ system or kernel compromise cannot allow data to be directly injected to
+ falsely authenticate as the user.
+* [C-4-7] MUST be paired with an explicit confirm action (eg: a button press)
+ to allow access to keystore keys if the application sets `true` for
+ [`KeyGenParameterSpec.Built.setUserAuthenticationRequired()`](
+ https://developer.android.com/reference/android/security/keystore/KeyGenParameterSpec.Builder.html#setUserAuthenticationRequired%28boolean%29)
+ and the biometric is passive (e.g. face or iris where no explicit
+ signal of intent exists).
+* [C-SR] The confirm action for passive biometrics is STRONGLY RECOMMENDED to
+ be secured such that an operating system or kernel compromise cannot spoof
+ it. For example, this means that the confirm action based on a physical
+ button is routed through an input-only general-purpose input/output (GPIO)
+ pin of a secure element (SE) that cannot be driven by any other means
+ than a physical button press.
-If the spoof and imposter acceptance rates are not equal to or stronger than
-what is required for a fingerprint sensor as described in
-[section 7.3.10](#7_3_10_fingerprint_sensor) and 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`, then:
+If the biometric authentication methods do not meet the spoof and imposter
+acceptance rates as described in [section 7.3.10](#7_3_10_biometric_sensors):
-* [C-6-1] MUST disable these biometric methods and allow only the primary
-authentication to unlock the screen.
-* [C-6-2] MUST challenge the user for the primary authentication
-(e.g.PIN, pattern, password) at least once every 72 hours or less.
+* [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) after any 4-hour idle timeout
+ period. The idle timeout period is reset after any successful confirmation
+ of the device credentials.
+* [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 if such an authentication method will be used to unlock
-the keyguard, but will not be treated as a secure lock screen, then they:
+the lock screen and a new authentication method is based on a physical token
+or the location:
-* [C-7-1] MUST return `false` for both the [`KeyguardManager.isKeyguardSecure()`](http://developer.android.com/reference/android/app/KeyguardManager.html#isKeyguardSecure%28%29)
-and the [`KeyguardManager.isDeviceSecure()`](https://developer.android.com/reference/android/app/KeyguardManager.html#isDeviceSecure%28%29)
-methods.
-* [C-7-2] 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-7-3] 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-7-4] MUST NOT authenticate access to keystores if the application has
-called [`KeyGenParameterSpec.Builder.setUserAuthenticationRequired(true)`](https://developer.android.com/reference/android/security/keystore/KeyGenParameterSpec.Builder.html#setUserAuthenticationRequired%28boolean%29)).
+* [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 72
+ 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 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.
+* [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 after any 4-hour idle
+ timeout period. The idle timeout period is reset after any successful
+ confirmation of the device credentials.
+* [C-7-10] MUST NOT be treated as a secure lock screen and MUST follow the
+ constraints listed in C-8 below.
+
+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 authenticate access to keystores when the application
+ sets `true` for
+ [`KeyGenParameterSpec.Builder.setUserAuthenticationRequired()`](
+ https://developer.android.com/reference/android/security/keystore/KeyGenParameterSpec.Builder.html#setUserAuthenticationRequired%28boolean%29)).
### 9.11.2\. StrongBox
