How do macOS Touch ID and Windows Hello work securely with fingerprints in place of passwords?

Question

How do macOS Touch ID and Windows Hello work securely with fingerprints in place of passwords?

As an example, macOS has been successfully using fingerprint authentication as a secure method for unlocking laptops, authorizing purchases, and even granting access to key vaults (e.g. 1Password).

This is in stark contrast to a Framework / Linux where fprintd's security model which does not consider a fingerprint to be a secure enough means of authentication due to complications in trusting the fingerprint reader hardware.

How do other OS's pull this off?

Answer 1

In general, an operating system needs to trust internal hardware. There are ways to make that trust stronger or weaker, for example by requiring a cryptographic key for authentication between the hardware and the OS (Apple does this) vs. allowing removable (USB) hardware to be trusted just based on the reported device class. In the end, though, an attacker with physical access to a running machine and the right time and tools can basically always compromise it. Thus, user authentication and local-access security is a matter of making the bar high enough, in terms of skills needed and difficulty in obtaining the right tools / having enough time, to deter attackers.

In the specific context of fingerprint readers, the details vary a little bit, but broadly speaking, they work like this.

1. The OS initializes the fingerprint reader hardware. On modern systems, this typically involves setting up a cryptographic key or other credential that the OS needs to use to extract any secrets from the fingerprint hardware. On devices where a TPM is built into the hardware (nearly all modern phones and computers), the OS may delegate handling the key material to the TPM. Without this key/credential being supplied again, the fingerprint reader won't identify anybody or yield any of its secrets.
2. The user signs into the computer (using some non-fingerprint credential), and tells the OS that they want to enroll their fingerprints for authentication. The OS typically re-authenticates the user at this point. It then tells the fingerprint reader that the user is enrolling.
3. The OS sends the fingerprint reader hardware an identifier for the user. In some cases, this involves sending the fingerprint reader a credential (such as a cryptographic key) that the fingerprint reader (or attached TPM) stores, and that the OS needs to allow a user to log in without their password. In other cases (especially before stuff like Windows Hello), the fingerprint reader might store the user's password directly, or (on Linux), simply store the user's UID. The fingerprint reader stores the OS-provided identity in internal secure storage.
4. The fingerprint reader enters enrollment mode. In this mode, it captures the unique properties of the fingerprint, and stores them in its internal storage such that it will be able to recognize that fingerprint again, while distinguishing it from all others. The captured fingerprint is associated with the OS-provided account identity/credentials.
5. After enrolling, the fingerprint reader verifies that it can identify the user's fingerprint, and sends the OS a message confirming that enrollment is complete.
6. From that point forward, the fingerprint reader first waits for the OS (specifically, the driver) to initialize it (potentially requiring the OS to authenticate itself to the reader) if it hasn't been initialized since last power loss, then waits for the user to provide a fingerprint. If the user does so, the reader checks its internal storage of fingerprint details to see if there's a match. If there is, the fingerprint reader unlocks the associated identity/credential, and sends it to the OS.

There's no inherent reason this couldn't work on Linux, and indeed, some Linux devices have fingerprint readers that can be used to authenticate. However, it may be that in a highly modular device like the Framework, the fingerprint reader hardware is considered too easy for an attacker to access, and either the Linux driver doesn't know how to authenticate to the reader or the reader hardware doesn't have the ability to enforce OS authentication. Alternatively, the concern could be that the fingerprint reader hardware is itself insufficiently secure, and an attacker could tamper with or extract its contents. Bear in mind that a modern fingerprint reader is essentially its own mini-HSM (Hardware Security Module), holding secrets (user credentials) and only releasing them in the right scenario (the correct fingerprint is presented, and the environment is trusted).

Answer 2

There is the fingerprint readers security. iPhone users repairing their screens often complain about the finger print sensor stopping to work - thats because a reader manufactured by apple is needed which as known, secure behaviour. Change the screen and the phone isnt sure it has a secure reader. Linux cannot make guarantees about the reader’s security so this fails.

There’s an unrelated question how likely it is the a random finger matches the owners fingerprint. Some very incompetent manufacturer had a reader that on average needed 20 random fingerprints for a match. So a hacker with three fingers has a huge chance that one of the 40 fingers marches. Linux cannot determine anything about the failure rate so cannot give meaningfully guarantees.