Android protects user data including credential-encrypted storage and authentication-bound Keystore keys with user-configured lockscreen knowledge factors (LSKFs) such as PINs, patterns, and passwords. LSKFs typically are low-entropy values such as 4 or 6-digit PINs, so protection from brute-force attacks is required.
Android uses Trusted Execution Environment (TEE) or Secure Element (SE) rate-limiters to slow down, and given enough attempts, block attackers performing brute-force attacks on LSKFs. CDD 9.11 specifies the minimum security requirements and recommendations for LSKF rate-limiters. Android 16 QPR2 and higher implements significantly stronger rate-limiting policies than lower Android versions. For more details, see Stronger default rate-limiting policy in Android 16 QPR2 and higher.
Unlock protected user data with LSKFs
LockSettingsService
manages storing and verifying LSKFs. A user has only one active LSKF at a time. Assigning a new LSKF
invalidates the previous one and starts the rate-limiting policy from the beginning.
A primary rate-limiter in the TEE or SE, one of Gatekeeper
or Weaver, enforces rate-limiting for
the active LSKF. LockSettingsService prefers Weaver when an implementation is available.
Protected user data is unlocked only when the correct LSKF is provided to the primary rate-limiter. If the LSKF is incorrect, the rate-limiter increments a failure counter and enforces a timeout after certain failure counts. During a timeout, it rejects all guesses and provides the remaining timeout.
Stronger default rate-limiting policy in Android 16 QPR2 and higher
CDD 9.11 requires LSKF rate-limiting in Android 6 and higher. Historically, the required rate-limiting policy has been fairly lenient. For example, an implementation meeting the minimum requirements of Android 16 allows up to 10 guesses in the first minute, 20 in 6 minutes, 50 in 25 minutes, 110 in 24 hours, and 1800 guesses in 5 years.
While this policy is reasonably secure for LSKFs chosen uniformly at random, in practice users don't choose LSKFs uniformly at random. Some LSKFs occur much more often than others. Attackers can achieve a significant success rate by trying LSKFs in order of decreasing frequency.
For example, the study This PIN Can Be Easily Guessed found a success rate of 16.2% for guessing real-world PINs after 100 guesses and 35.5% for patterns. Attackers knowing user-specific information such as birthdays can achieve even higher success rates.
Therefore, Android 16 QPR2 and higher provides a stronger default LSKF rate-limiting policy. This policy allows up to 6 guesses in the first minute, 7 in 6 minutes, 8 in 25 minutes, 12 in 24 hours, and 19 in 5 years. No further guesses are allowed after 20 incorrect guesses. The full timeout schedule is shown in the following table. It's subject to change in future Android versions.
| Count of incorrect guesses | Timeout after incorrect guess |
|---|---|
| 0 | Not applicable |
| 1-4 | 0 seconds |
| 5 | 1 minute |
| 6 | 5 minutes |
| 7 | 15 minutes |
| 8 | 30 minutes |
| 9 | 90 minutes |
| 10 | 4 hours |
| 11 | 12 hours |
| 12 | 36 hours |
| 13 | 4 days |
| 14 | 13 days |
| 15 | 41 days |
| 16 | 123 days |
| 17 | 1 year |
| 18 | 3 years |
| 19 | 9 years |
| 20+ | No more guesses allowed |
Updated rate-limiters
Android 16 QPR2 and higher includes updated Gatekeeper and Weaver implementations that enforce the rate-limiting policy in the table.
Software rate-limiter
Android 16 QPR2 and higher includes an optional secondary rate-limiter, SoftwareRateLimiter.
It is implemented in the system server and lets devices offer a stronger rate-limiting policy when
the TEE or SE can't be updated.
Configure SoftwareRateLimiter in enforcing mode through the config_softwareLskfRateLimiterEnforcing
configuration value. In enforcing mode, SoftwareRateLimiter applies its rate-limiting
policy concurrently with the primary rate-limiter. For a given incorrect guess count, the timeout is
the longer of that required by the primary rate-limiter and that required by SoftwareRateLimiter.
In non-enforcing mode, SoftwareRateLimiter passes all verification requests to the
primary rate-limiter without applying a secondary rate-limiting policy.
Duplicate guess detection
To improve usability and enable the use of a stronger rate-limiting policy, Android 16 QPR2 and higher supports duplicate guess detection. When enabled, users aren't penalized for entering the same incorrect LSKF multiple times.
Legitimate users sometimes mis-enter the same incorrect LSKF multiple times. This results in unnecessary timeouts if counted as multiple guesses. Capable attackers don't attempt a given LSKF more than once. A policy that doesn't count duplicate guesses improves LSKF entry usability for legitimate users without making it any easier for capable attackers to guess the LSKFs, allowing for stronger rate-limiting policies to be enforced. Legitimate users are less likely to even encounter a timeout, since the user must enter 5 unique incorrect guesses instead of 5 incorrect guesses including duplicates.
On devices with Android 16 QPR2 and higher, a Weaver implementation, and SoftwareRateLimiter
configured in enforcing mode, duplicate guesses are detected and rejected before being passed to
Weaver. Such rejections don't increase the incorrect guess count. Up to 5 unique incorrect guesses
are tracked in memory. If the tracker is full, the least recent one is discarded to make room. All
tracked guesses are discarded 5 minutes after the last untracked incorrect guess is made.
Gatekeeper doesn't separate wrong guesses from other verification failures, so SoftwareRateLimiter
doesn't support duplicate guess detection when Gatekeeper is the primary rate-limiter.
Weaver implementers can choose to support duplicate guess detection in the Weaver implementation.