Why does Gnome fingerprint unlock not unlock the keyring?
mjg59.dreamwidth.org
mjg59.dreamwidth.org
Microsoft pushed the reader industry to adopt their protocol almost 6 years ago and it's universally implemented in almost all laptops (citation needed; maybe I'm wrong here and it's not as universal).
They even have an open source reference implementation - https://github.com/microsoft/SecureDeviceConnectionProtocol - https://github.com/Microsoft/SecureDeviceConnectionProtocol/...
Yet Fprintd still doesn't support it to date. https://gitlab.freedesktop.org/libfprint/libfprint/-/issues/...
So the problem really isn't with the fingerprint readers (at least on modern laptops) it's that fprintd is horribly outdated with current tech
The other problem with Linux is that SDCP needs to be implemented in tandem with TPM support. Another area where Linux Distros are at least 10 years behind Windows.
However systemd has been slowly making strides with PCRLock
I am also pretty sure (but citation needed) that Microsoft has fallback code for image-matching fingerprint readers that run that code in a VM in some kind of trusted execution environment so that Windows Hello also works on old fingerprint readers
This current tech? https://www.theregister.com/2023/11/22/windows_hello_fingerp...
'Fixing' this doesn't make your machine any less pwned if you let them touch it.
The point of the system is to protect against an attacker who steals the laptop so it is a complete failure.
I don't really understand the way that people who apparently should know better still frame the issue as a "Linux" problem, instead of a "hardware vendors" problem.
When vendors cooperate, open-source is on par with other OSs (see AMD and Intel), but when they don't then it's amazing that things are working to the level that they do, and I am thankful.
Neither does blaming Linux developers.
But the fact is, Linux developers are doing their best to cooperate, while hardware vendors aren't. It's not about assigning blame, it's about describing the objective state of facts.
Saying "[this is yet] another area where Linux Distros are at least 10 years behind Windows" has a certain unpleasant tone that reeks of blame.
How do you figure? This just strikes me as insecurity. Regardless of the fact that your quote represents a nonsensical claim, Linux's lack of hardware support isn't something worth dancing around, it's just reality.
You could say that about any kind of criticism related to someone's tone, and nobody could prove you wrong. I'm just sharing my own opinion about the quote.
But considering the other comments on this thread, it's fair to say that my opinion is shared by many other people here - so either we're all insecure, or my quote really has a certain unpleasant tone that reeks of blame.
The people that want to run Linux on their machines, make efforts in that direction, either by ensuring that the hardware they run Linux on is compatible, or invest time/money in making it compatible. When hardware vendors provide documentation and man power it's "easy", when they don't it's hard or impossible or, like in this specific case, only the basic capabilities of the hardware can be exploited.
Using my Fedora installation on a XPS Plus was plug and play, no login needed.
I have a Samsung Book with Windows 11 that I can't do the same. :(
I entered the wrong password to a fake MSFT account and that let me create a local account.
Setting up fingerprint scanning was part of the OOBE.
If this isn’t possible for you, try downgrading to Win10, setting it up, and upgrading.
https://www.theverge.com/2023/11/22/23972220/microsoft-windo...
Let me disagree, I think this is a problem of capitalism, not Linux. TPM is a closed-source technology, defective by design.
I don't think that my computer requires a fingerprint sensor to function.
As an aside, Appleland isn't the promised land either.
Apple laptops with a fingerprint reader lack the interface to be unlocked with depth cameras, like any Windows Hello certified camera. This means biometric authentication requires another connected fingerprint reader when the lid is closed.
Apple phones on the other hand have the opposite problem. They have a depth camera and can use your face to unlock, but lack the hardware for fingerprint unlocking. This means you have to lift them up and point them at your face while other phones have built-in fingerprint readers beneath their screens.
Why?
Because they unlock the device in advance before you request it by action. Watch the small lock. It unlocks before you swipe up.
Example?
You ask a stranger to take a photo of your group. I think a normal situation. Not an issue with an iPhone SE (1st Gen - 3rd Gen). Just open the camera app from the lock screen and pass it, the photographer just needs to know “red button” and cannot access anything. Same with FaceID? You’re likely in trouble because you probably didn’t covered the front camera while passing the smartphone - it is completely unlocked because FaceID unlocks the device as soon as it recognizes the you. Apple has broken a security promise which we all know and expect. And usually the screen turns on when the phone is picked up (FaceID starts searching) and even if not - by habit many will touch the side-button and launch the camera app from the lock—screen.
Workaround?
Turn FaceID off. Or always remember not to look at the device and cover cameras with your fingers (FaceID can be quick). Guess what? Only the first one works for me.
Previously?
Stealing an iPhone handed over for photography was useless. Investigating private data was not possible.
Please note that an unlocked iPhone allows access to all data. And resetting your passwords via E-Mail. I don’t know if the E-Mail is enough to reset the Apple ID.
I’m afraid FaceID was considered too slow by Apple and they decided to make it “feel faster” by scanning for the owner already before the owner swipes up to unlock. It could be secure - only unlock if the user actually requests it by swiping up. The tiny “lock icon” also part of the problem. Within iOS itself a use of FaceID is much more obvious, users note when it is happening.
PS: GNOME and seahorse are nice - when you login in with password it is automatically unlocked. It handles changes of the password also through the shell well, it recognizes the mismatch and ask only once for the old password. Maybe the reason why I didn’t feel the need for “password managers”.
Picture this:
- Owner hands over phone locked (whether or not in camera)
- Photographer sort of takes its time, acting not too sure about themselves to divert attention while subtly manipulating device so that screen shuts down (wait for screen sleep, or press power button if in camera), claims "oh I made a mistake / screen has shut down" or something to that effect all the while smoothly presenting device as if both demonstrating the fact and asking for help, facing it towards owner so that they can look, yet quickly presses power button which kicks in FaceID which provides haptic feedback as a cue to swiftly turn it around, swipe up, and keep a finger on screen. Photographer runs away, phone is unlocked.
What works: press power button five times, dismiss emergency screen, and only then hand it over. This invalidates authentication and requires pin to unlock (think `sudo -k`).
- emit a loud alarm
- call the emergency number
- send messages to your emergency contacts
And yes it also locks the phone. But that’s not something I would like to use just to get photographed by a stranger ;)
That said, while waiting for a train at a station, I've had shady people ask me to "place an urgent call" attached with a weird story told in terms that were triggering all sorts of "Nigerian prince scam" alarms, plus when you get like five in a row over an hour of waiting there's certainly something fishy going on here - could just as well be some sort of distraction for an accomplice to steal luggage. No way I'm handing my phone over in such circumstances, however locked.
Losing a Nokia 5110 was bad. Losing an iPhone as “average” user is worse. Losing an iPhone while unlocked is even less unfortunate - you probably need to reset every account, inform contacts and so on.
Imagine the other side. You dropped or lost your phone and nobody will let you make a simple call because this devices are so fragile and important.
Question? Is it possible to initiate a call and then lock the phone? Then a handover should be save?
* if you’re this paranoid, do not give your phone to a stranger
To be honest. At the moment a device of any kind is left unattended accessible for others security is already violated. Ability for physical manipulation allows for literally everything - same status as harmful software.
Because I’m not paranoid enough I hope for the best and rely on the login and hardware encryption. Or here on a nickname :)
Anyway. It is a valid use case well handled by Apple and Google in the past. They designed the lock screen for this.
It’s effectively a kiosk mode.
Was this ever a thing? I've never heard about a phone handed over for photography being stolen. I'm sure it probably happened to someone somewhere, but I don't think it's a big enough problem to re-engineer how the phone works to prevent it.
It seems I have either misunderstood it's functionality or it's completely broken. Is it literally only protecting the "login keyring", in which case what is the point when I can still login and seemingly do everything anyway?
In the gui "seahorse" I can view all openssh and gpg keys without having unlocked the login keyring.. very confused by this!
These are stored system-wide, within NM's connection profiles (likely /etc/NetworkManager/system-connections/whatever.nmconnection).
> In the gui "seahorse" I can view all openssh and gpg keys without having unlocked the login keyring
This is unlocked when you first log in, or unlock your session (pam_gnome_keyring.so stashes the password when called from 'auth' and retrieves it & uses it to unlock the user's keyring when called from 'session'); but I don't believe the keyring is locked when the session is locked, only when the system suspends/hibernates.
But since I don't have a fingerprint reader i can't verify that those things wouldn't work when logging in without password.
Edit: as a test I deleted the secrets stored by discord and Element, after restarting the programs both of them were able to login without reentering password. So while they are storing something within login keyring, it doesn't seem to be anything important, and actual credentials are stored elsewhere.
When did we forget that biometrics were supposed to be a convenience and not a replacement for true authentication against any real adversary? As the entire concept of using irreplaceable parts of yourself as key is broken since the start...
Who is the adversary here? The point of all this is to at best protect against untrained thief, but with biometrics, never against anything more...
Before the first guy started implementing biometric unlock. If you can use it to unlock things, then it is an upper bound on the security level for whatever it can unlock.
> As the entire concept of using irreplaceable parts of yourself as key is broken since the start...
Yes, obviously. A password that can never be changed is a huge security downgrade from a normal password.
You would have to compare the fingerprints on the PC, or you would have to have a authenticated channel between the fingerprint reader and the PC, otherwise you would open yourself to device spoofing attacks. I think an attack like that was discovered recently for Windows notebooks.
This scheme would mean that root can access your keys without the fingerprint (unlike on a Mac I think), but the root account already has other ways to get your passwords.
Similar, you might be vulnerable against an attack where somebody confiscates your locked PC, freezes your RAM modules, and reads them out later. But you could encrypt the passwords in locked state using the TPM to make this much more difficult. And again, people who can do these attacks have much easier ways of getting your passwords, such as rootkits, or simply forcing you to put your finger on the sensor.
Similar to how BitLocker works, I assume. Windows has the keys to decrypt the hard disk, but it requires a valid login + the TPM to actually give it out.
I'm not a crypographer so I won't claim to know details, but I think there are schemes to keep secrets safely encrypted in RAM, and only when the OS says OK it uses the TPM do decrypt the secrets.
This fails of course when there is a bug in the OS, you can manipulate the CPU directly, or get between the CPU and the TPM, but then we are in "other side of the airtight hatchway" land anyway. I mean it is always a matter of what is my threat scenario, and what level of comfort do I want.
Reliably mapping to the same key while not dropping down to abysmal entropy probably makes this intractably, hence the need for a TPM.
Maybe some people in this thread think they're in that intersection, but I don't think anybody actually is.
I prefer things exactly as they are currently. I don't want my fingerprint reader to be able to unlock the keychain. However, I do use it for quickly unlocking a laptop who's keychain is already unlocked. I do this probably 10 to 15 times a day. If I had to type my long-ass password every single time, then I start to not want to lock the laptop if I'm only running to the bathroom or something, which is a very bad practice.
This all assumes that nobody can break into the secure silicone of the the fingerprint scanner (or the PC) of course, but that is a pretty high bar.
[1] https://github.com/microsoft/SecureDeviceConnectionProtocol
[2] https://www.theverge.com/2023/11/22/23972220/microsoft-windo...
I know this because I own a bunch of Thinkpads and I swapped out a keyboard for one that had been unused for several years, and my fingerprint came back piggyback. I had to configure the password change, but I didn't have to retrain it on my fingerprint. (the fingerprint reader circuit board lives right under the touchspot, and plugs into the motherboard via a short cable; the motherboard and OS installed had no notion of fingerprints before this because the keyboard I swapped out did not have a fingerprint reader)
Not sure if that's a security issue for discarded hardware? but I found it quite strange.
> 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.
I'll provide a broader explanation: you cannot encrypt your key with a fingerprint.
A genuine "throw away the key" lock is only possible when the decryption key is completely erased from memory during the screen lock, and you cannot use your fingerprint or face image as a key by itself.
A screen lock using stored secret is inherently incapable of providing encryption at rest. It's like a password on a sticky note.
A "throw away the key" is only possible with a password, or a smartcard.
Partly because many secure enclave type applications have undergone formal verification and verification through something like CC EAL, which should reduce the likelihood of glaring oversights etc.
One final aspect, more for hardware enclaves though, is that they're often designed specifically to resist the kinds of physical attacks people may try - as security products, they've very likely considered power rail glitching and how to reset the enclave if there's a glitch. Similarly, the physical ICs may be produced with physical features to try to prevent successfully decapping the chip, like sensing wires you'll disrupt, and inbuilt EM shielding.
> [WebAuthn, TPM, U2F/FIDO2, Seahorse,]
> tpm-fido: https://github.com/psanford/tpm-fido :
>> tpm-fido is FIDO token implementation for Linux that protects the token keys by using your system's TPM. tpm-fido uses Linux's uhid facility to emulate a USB HID device so that it is properly detected by browsers.
TPM > TPM software libraries: https://en.wikipedia.org/wiki/Trusted_Platform_Module#TPM_so...
TPM > Virtualization; virtual TPM devices: https://en.wikipedia.org/wiki/Trusted_Platform_Module#Virtua...
WebAuthn: https://en.wikipedia.org/wiki/WebAuthn