Why Android Cannot Verify Your PIN
Imagine a scenario where the Android operating system directly verifies a user lock screen PIN. If an attacker gains root access, they could modify the OS code to always return a successful verification. They would bypass the lock screen entirely. To solve this problem, Android removes the responsibility of password verification from the main operating system. It delegates this critical task to a dedicated subsystem called Gatekeeper.
Gatekeeper consists of a userspace daemon named gatekeeperd running in Android and a Hardware Abstraction Layer running inside an isolated secure environment. This environment typically takes the form of a Trusted Execution Environment like ARM TrustZone. When a user enters a PIN, the framework passes the raw input to the daemon. The daemon immediately forwards it down to the Gatekeeper HAL in the TEE. The TEE performs the actual mathematical verification and returns the result. This architectural split ensures that even a fully compromised Android OS cannot see the verification logic or access the underlying cryptographic secrets.
The following sequence diagram illustrates this verification flow. This illustration helps clarify the strict boundary between the insecure Android OS and the secure TEE. Notice how the daemon acts merely as a messenger while the actual verification happens safely inside the secure silicon.
This hardware separation protects the verification logic. We still need a way to protect the stored password hashes from being stolen.
Defeating Offline Dictionary Attacks
When attackers steal a database of password hashes, their next step usually involves an offline dictionary attack. They use specialized hardware on a desktop PC to rapidly guess the password. If the Gatekeeper hashes were standard cryptographic hashes, extracting the files from the device would allow an attacker to crack them easily. To prevent this, Gatekeeper binds the PIN hash directly to the physical device.
To secure a new PIN, the Gatekeeper HAL inside the TEE derives a secure hash. This hashing process incorporates a hardware-specific secret key that physically resides in the device silicon. The key never leaves the TEE. It remains completely inaccessible to the Android OS.
During an authentication attempt, the framework sends the entered PIN to the TEE. The HAL hashes the input again using that exact same hardware secret. The TEE then compares this newly generated hash against the stored hash. Because the hash relies on a hardware-bound secret, an extracted password file remains entirely useless on any other device. The attacker cannot mount an offline attack because they lack the physical hardware key.
While hardware binding prevents offline attacks, we must also handle attackers trying to guess the PIN directly on the device.
Enforcing Rate Limits on Short PINs
Most users secure their devices with a four or six-digit PIN for convenience. A four-digit PIN has only ten thousand possible combinations. Attackers can use a simple script to guess every combination in seconds. If the Android OS handled rate limiting, an attacker with root access could simply disable the timeout logic and rapidly test every combination.
Gatekeeper solves this by enforcing strict rate limiting directly inside the TEE. The Gatekeeper HAL tracks the number of failed authentication attempts internally. After a specific threshold, the TEE implements an exponentially increasing timeout. If an attacker roots the device and tries to feed PINs directly to the HAL, the TEE will refuse to process them until the timeout expires.
The TEE securely stores this timeout state so that the timer persists across device restarts. If an attacker reboots the device hoping to clear the timeout memory, the TEE reads the securely stored state during boot and resumes the countdown. This makes online brute-force attacks against short PINs mathematically impractical. Even a completely compromised device cannot bypass the hardware timer.
With the device authenticated and attackers thwarted, Gatekeeper needs a secure way to prove this successful authentication to other secure components.
Proving Authentication with Hardware Tokens
Upon successful verification, Gatekeeper cannot simply return a boolean success value to Android. If it did, a compromised OS could fake that success signal when asking KeyMint to decrypt sensitive application data. The secure storage system needs cryptographically sound proof that the user actually entered the correct PIN.
To provide this proof, Gatekeeper generates a Hardware Authentication Token upon a successful verification. This token contains a secure user ID representing the authenticated user and a timestamp of the exact authentication event. Most importantly, the token includes a cryptographic HMAC generated by the TEE. This HMAC proves the authenticity of the token.
The following diagram shows how this token travels through the system. This flow explains how KeyMint trusts Gatekeeper without ever trusting Android. Notice how Android only acts as a courier for the token.
Android receives this authentication token and stores it. When an application needs to use a cryptographic key stored in KeyMint, Android passes the token along with the request. KeyMint verifies the HMAC using a shared secret established between Gatekeeper and KeyMint entirely within the TEE. Because Android never sees this shared secret, it cannot forge a valid token. KeyMint can then confidently enforce policies, like requiring user authentication within the last five minutes, before decrypting a specific key.
Recap and Next Steps
The Gatekeeper subsystem shifts the responsibility of user authentication out of the vulnerable Android OS. It places this logic into the Trusted Execution Environment. By binding password hashes to physical hardware secrets, the system renders offline brute-force attacks impossible. Enforcing exponentially increasing timeouts inside the TEE prevents online guessing attacks against short PINs.
Finally, the generation of Hardware Authentication Tokens allows Gatekeeper to prove successful authentication securely. This architecture ensures that user credentials and device decryption keys remain safe even if the main operating system falls under attacker control. In the next article, we look at how KeyMint actually manages those encryption keys.