How Google verifies your phone's fingerprint scanner is secure

As I explained earlier today, biometric authentication methods are classified into three tiers: Class 3 (formerly Strong), Class 2 (formerly Weak), or Class 1 (formerly Convenience). While all 3 can be used to unlock a device, only Class 3 and Class 2 biometrics can integrate with BiometricPrompt (ie. authenticate within apps). Class 2, however, cannot integrate with the keystore.

These distinctions are why the Pixel 7's face unlock feature (a Class 1 biometric) doesn't support verifying you within apps, while the Pixel 7's fingerprint scanner (a Class 3 biometric) can. It's also why the Fairphone 3's fingerprint scanner stopped being able to verify users in many banking or password manager apps, as it was downgraded from Class 3 to Class 2 with its Android 13 update.

The exact requirements that biometric sensors have to meet to be classified as Class 3, Class 2, or Class 1 are defined in section 7.3.10 of the Android Compatibility Definition Document (CDD). The CDD enumerates the requirements that devices have to meet in order to be certified as compatible with Android (and is a stepping stone to getting a GMS [Google Mobile Services] license). The Compatibility Test Suite (CTS) and Compatibility Test Suite Verifier (CTS-V) ensure OEMs comply with many of the CDD's requirements, but there are also other tests/programs that need to be done. One such program is the Biometric Security Program, which ensures that OEMs and biometric sensor vendors adhere to Google's criteria and testing requirements.

There are 3 different metrics used to measure biometric security performance: Spoof Acceptance Rate (SAR), Imposter Acceptance Rate (IAR), and False Acceptance Rate (FAR).

• Spoof Acceptance Rate defines the chance that a biometric accepts a previously recorded, known good sample. For example, if a device with voice unlock support is tricked into unlocking the device by an attacker who plays back a recording of the user's voice, this is called a spoof attack.
• Imposter Acceptance Rate defines the chance that a biometric accepts input that is meant to mimic a known good sample. So for example, an attacker successfully tricking a device with voice unlock support by mimicking the user's voice would be considered an imposter attack.
• False Acceptance Rate defines the chance that a biometric mistakenly accepts a randomly chosen incorrect input.

Each biometric sensor on a device has to undergo an evaluation process, which is comprised of a calibration phase and a test phase. This process is described in detail on the AOSP page titled "Measuring Biometric Unlock Security" which I recommend you check out if you're interested.

What I wanted to highlight is what OEMs do after calibrating and testing their devices' biometric sensors. As I mentioned before, the Biometric Security Program exists to validate OEMs' claims. OEMs have to submit a Biometric Compliance Report (BCR) either directly to the Android team (self-certified) or through a third-party biometric security lab. A BCR lists the biometric type, the 3 metrics described above, the security of the pipeline, and what class the biometric should be assigned.

BCRs have to be submitted for every device, with the exception of SKUs that reuse the same biometric hardware and software. The Android team reviews BCRs for devices as well as for biometric sensors submitted by the vendor. Google maintains a list of biometrics that meet Android requirements, so devices that integrate these sensors don't need additional testing.

Google also randomly takes samples of Android devices to test their biometric security. If they detect any abnormal results, like a mismatch between the SAR reported in the BCR and the SAR Google  measures in its testing, then they inform the OEM that they either need to issue an update that fixes the issue or downgrades the biometric class.