![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
mjg59There's a decent number of laptops with fingerprint readers that are supported by Linux, and Gnome has some nice integration to make use of that for authentication purposes. But if you log in with a fingerprint, the moment you start any app that wants to access stored passwords you'll get a prompt asking you to type in your password, which feels like it somewhat defeats the point. Mac users don't have this problem - authenticate with TouchID and all your passwords are available after login. Why the difference?
Fingerprint detection can be done in two primary ways. The first is that a fingerprint reader is effectively just a scanner - it passes a graphical representation of the fingerprint back to the OS and the OS decides whether or not it matches an enrolled finger. The second is for the fingerprint reader to make that determination itself, either storing a set of trusted fingerprints in its own storage or supporting being passed a set of encrypted images to compare against. Fprint supports both of these, but note that in both cases all that we get at the end of the day is a statement of "The fingerprint matched" or "The fingerprint didn't match" - we can't associate anything else with that.
Apple's solution involves wiring the fingerprint reader to a secure enclave, an independently running security chip that can store encrypted secrets or keys and only release them under pre-defined circumstances. Rather than the fingerprint reader providing information directly to the OS, it provides it to the secure enclave. If the fingerprint matches, the secure enclave can then provide some otherwise secret material to the OS. Critically, if the fingerprint doesn't match, the enclave will never release this material.
And that's the difference. When you perform TouchID authentication, the secure enclave can decide to release a secret that can be used to decrypt your keyring. We can't easily do this under Linux because we don't have an interface to store those secrets. The secret material can't just be stored on disk - that would allow anyone who had access to the disk to use that material to decrypt the keyring and get access to the passwords, defeating the object. We can't use the TPM because there's no secure communications channel between the fingerprint reader and the TPM, so we can't configure the TPM to release secrets only if an associated fingerprint is provided.
So the simple answer is that fingerprint unlock doesn't unlock the keyring because there's currently no secure way to do that. It's not intransigence on the part of the developers or a conspiracy to make life more annoying. It'd be great to fix it, but I don't see an easy way to do so at the moment.
Fingerprint detection can be done in two primary ways. The first is that a fingerprint reader is effectively just a scanner - it passes a graphical representation of the fingerprint back to the OS and the OS decides whether or not it matches an enrolled finger. The second is for the fingerprint reader to make that determination itself, either storing a set of trusted fingerprints in its own storage or supporting being passed a set of encrypted images to compare against. Fprint supports both of these, but note that in both cases all that we get at the end of the day is a statement of "The fingerprint matched" or "The fingerprint didn't match" - we can't associate anything else with that.
Apple's solution involves wiring the fingerprint reader to a secure enclave, an independently running security chip that can store encrypted secrets or keys and only release them under pre-defined circumstances. Rather than the fingerprint reader providing information directly to the OS, it provides it to the secure enclave. If the fingerprint matches, the secure enclave can then provide some otherwise secret material to the OS. Critically, if the fingerprint doesn't match, the enclave will never release this material.
And that's the difference. When you perform TouchID authentication, the secure enclave can decide to release a secret that can be used to decrypt your keyring. We can't easily do this under Linux because we don't have an interface to store those secrets. The secret material can't just be stored on disk - that would allow anyone who had access to the disk to use that material to decrypt the keyring and get access to the passwords, defeating the object. We can't use the TPM because there's no secure communications channel between the fingerprint reader and the TPM, so we can't configure the TPM to release secrets only if an associated fingerprint is provided.
So the simple answer is that fingerprint unlock doesn't unlock the keyring because there's currently no secure way to do that. It's not intransigence on the part of the developers or a conspiracy to make life more annoying. It'd be great to fix it, but I don't see an easy way to do so at the moment.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
Apple devices also need PIN/password
Date: 2023-12-05 07:19 am (UTC)However: Apple devices also need PIN/password for the first login after reboot. Only after that, you can use biometrics for unlocking. (Windows Hello is different in that regard, but also considered much less secure, even though it is tied to the TPM 2.0.)
The same should work on a laptop with Gnome. When you log in the first time, it asks for the keyring password. But when the laptop is running or sleeping, you can unlock with biometrics because the keyring is already unlocked.
I wish I could login and unlock the keyring on Gnome with my PGP smartcard. Authentication with PAM (libpam-poldi) works, but unfortunately no one wrote the glue code for unlocking the keyring.
It would be a perfect setup to decrypt both LUKS and later the keyring with PGP. Many people have Yubikeys, Nitrokeys etc. nowadays.
Re: Apple devices also need PIN/password
Date: 2023-12-05 07:54 am (UTC)Re: Apple devices also need PIN/password
Date: 2023-12-05 08:05 am (UTC)Touch ID simply doesn’t work until the PIN is entered at least once after booting up.
Re: Apple devices also need PIN/password
Date: 2023-12-05 08:07 am (UTC)Re: Apple devices also need PIN/password
Date: 2023-12-07 04:45 pm (UTC)Re: Apple devices also need PIN/password
Date: 2023-12-05 08:07 am (UTC)Nick
SDCP
Date: 2023-12-05 09:35 am (UTC)This is what Windows Hello uses in Windows machines.
Re: SDCP
Date: 2023-12-05 09:43 am (UTC)Re: SDCP
Date: 2023-12-05 11:32 am (UTC)This also requires manufacturers to implement it properly, where some, like Microsoft, apparently can’t be trusted to do that:
https://www.theverge.com/2023/11/22/23972220/microsoft-windows-hello-fingerprint-authentication-bypass-security-vulnerability
Fingertips and fingertips readers aren't secure
Date: 2023-12-05 09:02 pm (UTC)https://arstechnica.com/gadgets/2023/11/researchers-beat-windows-hello-fingerprint-sensors-with-raspberry-pi-and-linux/
Second, fingertips is something you have, you can be forced touch reader and unlock device. You can't be as easily compelled to provide password.
Re: Fingertips and fingertips readers aren't secure
Date: 2023-12-05 10:57 pm (UTC)no subject
Date: 2023-12-06 06:22 pm (UTC)Relevant text is: `The team is collaborating with systemd for TPM backed secrets encryption and storage for the desktop keyring`
`
The other OS
Date: 2023-12-07 12:56 pm (UTC)Re: The other OS
Date: 2024-01-30 10:46 pm (UTC)no subject
Date: 2023-12-10 04:19 pm (UTC)Is there no privative in fingerprint readers to sign a blob only when a valid fingerprint is provided? If so you could do something like:
1) Gnome tells the TPM to start an unlock action
2) TPM generates a nonce which includes time, returns it so Gnome
3) OS sends this off to fingerprint reader
4) OS prompts the user to touch their fingerprint
5) Fingerprint matches, reader signs the nonce, returns it to OS
6) OS returns it to TPM
7) TPM verifies signature, ensures time is within acceptable window, returns secret
Some laptops have inbuilt FIDO
Date: 2024-02-04 09:16 am (UTC)Re: Some laptops have inbuilt FIDO
Date: 2024-02-04 09:29 am (UTC)Could the opposite not be done?
Date: 2024-08-27 10:43 pm (UTC)This way, the user need only enter a passphrase to initially get in but can then use their fingerprint sensor thereafter to do match-on-host processing of fingerprints. After all, if a switched on laptop is stolen after LUKS is unlocked, even on a desktop lock screen, it's usually going to be vulnerable to data remanence attacks anyway.