[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()
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 biometric authentication methods do not meet the spoof and imposter acceptance rates as
described in
section 7.3.10
:
[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()
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 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)
method or the
DevicePolicyManager.setPasswordQuality()
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
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
Page 126 of 132
