Merge "CDD: Requirements for services that have access to "android.permission.RECOVER_KEYSTORE"" into pi-dev
diff --git a/2_device-types/2_2_handheld-reqs.md b/2_device-types/2_2_handheld-reqs.md
index fcf4446..810715e 100644
--- a/2_device-types/2_2_handheld-reqs.md
+++ b/2_device-types/2_2_handheld-reqs.md
@@ -51,8 +51,16 @@
* [[7.2](#7_2_input-devices).3/H-0-2] MUST send both the normal and long press
event of the Back function ([`KEYCODE_BACK`](
http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BACK))
-to the foreground application.
+to the foreground application. These events MUST NOT be consumed by the system
+and CAN be triggerred by outside of the Android device (e.g. external hardware
+keyboard connected to the Android device).
* [[7.2](#7_2_input-devices).4/H-0-1] MUST support touchscreen input.
+* [[7.2](#7_2_input-devices).4/H-SR] Are STRONGLY RECOMMENDED to launch the
+user-selected assist app, in other words the app that implements
+VoiceInteractionService, or an activity handling the [`ACTION_ASSIST`](https://developer.android.com/reference/android/content/Intent#ACTION_ASSIST)
+on long-press of [`KEYCODE_MEDIA_PLAY_PAUSE`](https://developer.android.com/reference/android/view/KeyEvent#KEYCODE_MEDIA_PLAY_PAUSE)
+or [`KEYCODE_HEADSETHOOK`](https://developer.android.com/reference/android/view/KeyEvent#KEYCODE_HEADSETHOOK)
+if the foreground activity does not handle those long-press events.
* [[7.3](#7_3_sensors).1/H-SR] Are STRONGLY RECOMMENDED to include a 3-axis
accelerometer.
diff --git a/7_hardware-compatibility/7_1_display-and-graphics.md b/7_hardware-compatibility/7_1_display-and-graphics.md
index a2b0ec6..3ab68d0 100644
--- a/7_hardware-compatibility/7_1_display-and-graphics.md
+++ b/7_hardware-compatibility/7_1_display-and-graphics.md
@@ -21,14 +21,16 @@
### 7.1.1\. Screen Configuration
-#### 7.1.1.1\. Screen Size
+#### 7.1.1.1\. Screen Size and Shape
The Android UI framework supports a variety of different logical screen layout
sizes, and allows applications to query the current configuration's screen
layout size via `Configuration.screenLayout` with the `SCREENLAYOUT_SIZE_MASK`
and `Configuration.smallestScreenWidthDp`.
-* [C-0-1] Device implementations MUST report the correct layout size for the
+Device implementations:
+
+* [C-0-1] MUST report the correct layout size for the
`Configuration.screenLayout` as defined in the Android SDK documentation.
Specifically, device implementations MUST report the correct logical
density-independent pixel (dp) screen dimensions as below:
@@ -43,12 +45,22 @@
* Devices reporting a `xlarge` size for the `Configuration.screenLayout`,
MUST have at least 960 dp x 720 dp.
-* [C-0-2] Device implementations MUST correctly honor applications' stated
+* [C-0-2] MUST correctly honor applications' stated
support for screen sizes through the [<`supports-screens`>](
https://developer.android.com/guide/topics/manifest/supports-screens-element.html)
attribute in the AndroidManifest.xml, as described
in the Android SDK documentation.
+* MAY have a display with rounded corners.
+
+If device implementations support `UI_MODE_TYPE_NORMAL` and include a display
+with rounded corners, they:
+
+* [C-1-1] MUST ensure that the radius of the rounded corners is less than or
+equal to 32 dp.
+* SHOULD include user affordance to switch to the display mode with the
+rectangular corners.
+
#### 7.1.1.2\. Screen Aspect Ratio
While there is no restriction to the screen aspect ratio value of the physical
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_10_device-integrity.md b/9_security-model/9_10_device-integrity.md
index e40d1b8..366b7bd 100644
--- a/9_security-model/9_10_device-integrity.md
+++ b/9_security-model/9_10_device-integrity.md
@@ -38,15 +38,14 @@
* [C-SR] If there are multiple discrete chips in the device (e.g. radio,
specialized image processor), the boot process of each of those chips is
STRONGLY RECOMMENDED to verify every stage upon booting.
-* [C-SR] Are STRONGLY RECOMMENDED to use tamper-evident storage: for when the
+* [C-1-8] MUST use tamper-evident storage: for storing whether the
bootloader is unlocked. Tamper-evident storage means that the boot loader can
-detect if the storage has been tampered with from inside the
-HLOS (High Level Operating System).
-* [C-SR] Are STRONGLY RECOMMENDED to prompt the user, while using the device, and
+detect if the storage has been tampered with from inside Android.
+* [C-1-9] MUST prompt the user, while using the device, and
require physical confirmation before allowing a transition from boot loader
locked mode to boot loader unlocked mode.
-* [C-SR] Are STRONGLY RECOMMENDED to implement rollback protection for the HLOS
-(e.g. boot, Is system partitions) and to use tamper-evident storage for storing the
+* [C-1-10] MUST implement rollback protection for partitions used by Android
+(e.g. boot, system partitions) and use tamper-evident storage for storing the
metadata used for determining the minimum allowable OS version.
* [C-SR] Are STRONGLY RECOMMENDED to verify all privileged app APK files with
a chain of trust rooted in `/system`, which is protected by Verified Boot.
@@ -58,7 +57,42 @@
firmware (e.g. modem, camera) and SHOULD use tamper-evident storage for
storing the metadata used for determining the minimum allowable version.
+If device implementations are already launched without supporting C-1-8 through
+C-1-10 on an earlier version of Android and can not add support for
+these requirements with a system software update, they MAY be exempted from the
+requirements.
+
The upstream Android Open Source Project provides a preferred implementation of
-this feature in the [`external/avb/`](http://android.googlesource.com/platform/external/avb/)
+this feature in the [`external/avb/`](
+http://android.googlesource.com/platform/external/avb/)
repository, which can be integrated into the boot loader used for loading
-Android.
\ No newline at end of file
+Android.
+
+If device implementations report the feature flag
+[`android.hardware.ram.normal`](
+https://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_RAM_NORMAL)
+, they:
+
+* [C-2-1] MUST support verified boot for device integrity.
+
+If a device implementation is already launched without supporting verified boot
+on an earlier version of Android, such a device can not add support for this
+feature with a system software update and thus are exempted from the
+requirement.
+
+Device implementations:
+
+* [C-R] Are RECOMMENDED to support the [Android Protected Confirmation API](
+https://developer.android.com/preview/features/security.html#user-confirmation).
+
+If device implementations support the Android Protected Confirmation
+API they:
+
+* [C-3-1] MUST report `true` for the [`ConfirmationPrompt.isSupported()`](
+https://developer.android.com/reference/android/security/ConfirmationPrompt.html#isSupported%28android.content.Context%29)
+API.
+* [C-3-2] MUST ensure that secure hardware takes full control of display in
+such a way that Android OS cannot block it without detection by the
+secure hardware.
+* [C-3-3] MUST ensure that secure hardware takes full control of the touch
+screen.
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
