In particular this would be useful to e.g. unlock a keyring on login.
I doubt the sensor can store much else than it’s own firmware. You can however configure your software to unlock via fingerprint. Maybe if you tell us what software you want to use, somebody knows how to set that up.
On my system, user credentials (e.g. saved passwords, etc.) are encrypted with the user password. If I log in using the fingerprint sensor, I still have to enter my password at least once to decrypt these secrets.
I’m wondering if I could tell the fingerprint sensor to store the decryption key and release it when the fingerprint matches.
Alternatively the fingerprint sensor could somehow cryptographically verify that the fingerprint matched, which could then be passed to the TPM to get a decryption key.
1 Like
The software I use is:
- NixOS 24.05.20240425.7bb2ccd (Uakari)
- Nix 2.18.2
- Linux 6.8.7
- fprintd 1.94.2
- Linux-PAM 1.6.0
- GNOME 45.5
- polkit 123
- systemd 255.4
- GDM 45.0.1
- libfprint 1.94.6
- sudo 1.9.15p5
But the software is not really relevant. I understand that my system configuration is not officially supported by Framework. I want to know if this is possible in principle, and then find a way to implement it with my system.
Not an expert in this but you could probably hack something together with PAM
Another thing you can do to achieve what you want but in a slightly different way 
You can alter the firmware of the keyboard that is build uppon QMK, to create a special shortcut or key combinaison that would trigger your password.
But of course you have to be already on the input field that require the password to work as expected. It would also be revealing your password in clear before anyone looking at your screen if you call the shorcut anywhere else (word editor, a webpage, a chat…).
Of course this is not a secure way to do but … HEY ! Who else would imagine that you’ve done that on your keyboard ?
You could use KeePassXC as the desktop secret service provider (which itself will take some fiddling to get GNOME’s keyring service out of the way, without breaking ssh-agent). Then when 2.8.0 is released (hopefully soon) it should support fingerprint unlock.
Does KeePassXC use a method such as the one I described? Is it therefore possible for the fingerprint sensor to store secrets? If not, I would consider this method insecure…
From skimming through the PR that adds the feature, it uses the kernel keystore to add a layer of encryption to secrets. But it doesn’t store secrets in the fingerprint sensor. As mentioned upthread the sensor is not general purpose “keystore” hardware. If you require that under Linux, then something like a YubiKey Bio would work.
The fingerprint would have to store some kind of secret. If the fingerprint sensor simply responds “yes” or “no” to authentication requests, the logic that decrypts the secrets on authentication success could equally run without this authentication success. Therefore, access to the data available to the decryption process suffices to gain access to the secrets. The only benefit of such an arrangement is that world-readable files can hide data from unauthorized programs, but it does not protect against unsupervised (external) access to the cleartext of the filesystem.
I assume therefore that there is some (possibly small) secret stored in the fingerprint sensor. This needn’t be a user-supplied secret; the fingerprint sensor could authenticate its judgement by signing it with a hidden private key.
As far as I understand it, the protocol between Linux (or any OS) and FP readers like the goodix one on the Frameworks does do the signing/attestation that you describe. It’s not just a “cleartext” yes/no dialog going over USB to the reader.
In fact there seems to be a key pair for each finger slot, which is why you can’t share finger slots between operating systems if you multi-boot, unless you figure out a way to share the OS-side credential files/registry settings between them.
The bigger picture issue here though is that the secret(s) stored in the “secure” FP hardware are not the actual secrets you’re trying to protect. So the OS is still a single point of vulnerability, which if breached grants access to all credentials stored in the OS or userspace.
Real hardware tokens like yubikeys mitigate that because the real secrets (at least in the case of public-private key crypto based authentication methods) never leave the hardware. The token does the signing for each “transaction” (SSH session, browser passkey login) and only when asked by the (still crypto-authenticated) OS (itself on behalf of some userspace like the browser). If the OS is breached, “only” that SSH or browser session is 0wned.
I don’t know if there’s some way to bring the TPM module into this under Linux and somehow string it together with the FP reader to get the same risk reduction. I think other OSs do offer this, e.g. Android and Chrome with Titan secure hardware.
Happy to be corrected from anyone that knows this better, I’m only making somewhat educated guesses here, this is not my area.
You beat me to the punch on this and made me rewrite my reply entirely - slow typer here.
Matthew Garret has talked a little about this in the past. Yubikeys aren’t immune from this either - I have mine set up as an alternative way to log in via PAM and yet still get prompted to unlock the keyring later. The tl;dr of his write-up is that Apple (Secure Enclave) and Android (Titan) both have a secure, direct connection between the reader and the secrets provider. Microsoft has their own way of doing this (Secure Device Connection Protocol (SDCP)) between the reader and OS, but that can still lead to issues (see below). I don’t know if there’s any support, or attempts to support, similar under Linux.
From what I’ve read, it does seem like the reader is essentially just replying “yes” or “no” to if it read an enrolled fingerprint that matches the query. And as this article from ArsTechnica (or directly from the Blackwing write-up) shows, it’s not a simple problem to do securely.
What if our only concern is preventing access to the data
- remotely or by programs on the device
- physical access
but do not care if the physical access would result in later getting access to the data?
I am doing that with Windows and Fedora right now though?
Configured as same finger I assume? Then I suppose the (relatively few) slots on the FP are accessed through a numeric index, not “finger descriptors”, in the OS/FP protocol.
Same one yep, just enrolled it again after installing the second OS.
Btw is there any way to delete the stored fingers?
I’ll switch to Mint and if the storage on the chip is limited I don’t want to run out of slots
I’ve deleted fingerprints before using the Users settings UI under GNOME/Fedora. TBH I don’t know how that mapped into the reader’s slots/whether it really cleared it out or not.
The fingerprints are stored in the sensor, though, right?
I’ve previously been advised to not use fprintd because it supposedly stores fingerprints on disk, but I don’t think this is the case here—I’d assume they’re bigger than 200 bytes…
Yup that’s where they should be. As I understand it, the OS maintains credentials on disk so that it can authenticate itself to the reader (and authenticate the reader to itself). That’s why, if you’re dual-booting, you can’t use the fingerprint registered in one OS with anotherOS but have to register the finger - even if it’s the same one - with each OS.