9.11. Keys and Credentials

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.

All Android device implementations MUST meet the following requirements:

  • SHOULD not limit the number of keys that can be generated, and MUST at least allow more than 8,192 keys to be imported.
  • 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.
  • When the device implementation supports a secure lock screen it MUST back up the keystore implementation with secure hardware and meet following requirements:
    • MUST have hardware backed implementations of RSA, AES, ECDSA and HMAC cryptographic algorithms and MD5, SHA1, SHA-2 Family hash functions to properly support the Android Keystore system's supported algorithms.
    • MUST perform the lock screen authentication in the secure hardware and only when successful allow the authentication-bound keys to be used. The upstream Android Open Source Project provides the Gatekeeper Hardware Abstraction Layer (HAL) that can be used to satisfy this requirement.

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 hardware-backed keystore, unless it declares the android.hardware.fingerprint feature which requires a hardware-backed keystore.

9.11.1. Secure Lock Screen

Device implementations MAY add or modify the authentication methods to unlock the lock screen, but MUST still meet the following requirements:

  • The authentication method, if based on a known secret, MUST NOT be treated as a secure lock screen unless it meets all following requirements:
    • The entropy of the shortest allowed length of inputs MUST be greater than 10 bits.
    • The maximum entropy of all possible inputs MUST be greater than 18 bits.
    • MUST not replace any of the existing authentication methods (PIN, pattern, password) implemented and provided in AOSP.
    • MUST be disabled when 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_SOMETHING.
  • The authenticaion method, if based on a physical token or the location, MUST NOT be treated as a secure lock screen unless it meets all following requirements:
  • The authentication method, if based on biometrics, MUST NOT be treated as a secure lock screen unless it meets all following requirements:
    • It 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.
    • It 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).
    • It 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() method with a more restrictive quality constant than PASSWORD_QUALITY_BIOMETRIC_WEAK.
  • If the authentication method can not be treated as a secure lock screen, it:
  • If the authentication method is based on a physical token, the location, or biometrics that has higher false acceptance rate than what is required for fingerprint sensors as described in section 7.3.10, then it: