> 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.
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.
If you trust the hardware then it's entirely possible to tie the release of an encryption key to a fingerprint validated by that hardware. Hardware-backed keys are widely used (the entire WebAuthn ecosystem is predicated upon them being trustworthy), and having that hardware validate a fingerprint rather than merely physical presence is an improvement.
In theory you could potentially decap the enclave and read data out of it but you would need extremely high end equipment to do that and it would be obviously destructive so it's not in most people's threat model
Partly that, and partly because they were/are built with constrained functionality (do one thing well) that significantly limits the interfaces exposed, and are designed to be secure under the assumption of physical attack (which most things aren't!)
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.
>> 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.
I was wondering that myself, and just this moment tested it. Interestingly, I pressed cancel on the keyring dialog instead of entering a password.. everything seems to work fine!? I can view saved passwords for wifi networks in gnome network manager, firefox passwords can be viewed in it's manager too. So what exactly does this system protect?
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!
> I can view saved passwords for wifi networks in gnome network manager,
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.
OpenSSH keys have their own passwords. On my system there are a few things that are stored within login keyring: chromium safe storage for various electron based programs (Chromium itself, discord, vscode, unity hub), password or login token for Element (matrix client), svn password, login credentials for VM which was created using Gnome Boxes. All of which might be a software that you don't use or use in different configuration.
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.
Theoretically, if using the "it passes a graphical representation of the fingerprint back to the OS" models, it could be done if assuming a method to reliably derive strong cryptographic keys from a fingerprint scan.
Reliably mapping to the same key while not dropping down to abysmal entropy probably makes this intractably, hence the need for a TPM.
This doesn't explain why Linux doesn't communicate with the secure enclave.
Edit: I suspect closed-source hardware drivers, or collaboration with manufacturer is needed - so no fault on the Linux team, but still, an explanation as part of the article would be welcome.
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.
The cameras - i.e. FaceID - on the iPhone are unlocking the iPhone prematurely (to early).
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”.
> Or always remember not to look at the device and cover cameras with your fingers (FaceID can be quick)
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`).
I have never ever heard of a photographer running away with a phone. I think that's more in someone's fantasy than reality. I know it can happen in theory but I wouldn't lose any sleep over it.
Me neither, I merely walked from the scenario that the parent posited.
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.
Yep. The photo thing is my use case and the one where the lock screen fails to work with FaceID. But there a various use cases and this things carry the same data as a laptop.
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?
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.
Another option is to use the “Guided Access” accessibility mode which lets you lock the phone into the current app, requiring a password/optionally FaceID to unlock it. Can be activated with a triple click on the power/home button. It’s also great to use with kids to stop them switching apps.
> Stealing an iPhone handed over for photography was useless
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.
This would only work if you could somehow reliably produce a predictable string of some sort from the scan of a fingerprint, but you can't. Unless it's decrypting the keychain by an artifact of the scanning process itself, the password is stored and available somewhere on the computer, in a "secure enclave" or not. And I don't want that. If the finger scanner is just the warden of something that has the power to unlock the keychain without the password that is only stored in my grey cells, then someone can shim a fake finger scanner that pretends to have found a match.
There are protocols that you can use to authenticate the fingerprint scanner [1]. When they are not used you can indeed just shim a fake scanner and unlock the PC [2].
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.
Couldn't you have a small (meaning auditable) priviliged daemon store the keys in RAM when the keychain is unlocked once? The daemon would then release the keys when it determines that the fingerprint is correct.
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.
How are the secrets kept secret? If the encryption key is stored on disk then giving me physical access lets me extract that and gain all the secrets. The TPM has no knowledge of the biometric state so doesn't help here.
I think OP means that you enter your password to unencrypt your keyring once at boot or first use and then keep the keys in RAM. So you could not access the data when you steal the laptop while powered off, making it practically as safe as full-disk encryption.
That would be as good as full-disk encryption, but it is possible and useful to do better than that with a TPM. With physical access to a running machine, it is possible to physically extract data from RAM. Law enforcement agencies even have hotplug devices that let them switch a running computer to battery power so they can seize it while keeping it on and do this.
Yes exactly. You'd enter your password once at boot. Then the OS remembers whatever key it needs to access your keychain. The OS becomes the arbitrator to allow who accesses the keychain.
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.
Yet Microsoft unlocks the Keyring with the exact same fingerprint readers.
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).
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 line of thinking can and is used as an excuse for all sorts of security shortcomings. Yes, in threat modelling, this would be give fairly limited opportunity as an attack vector, but any successful attack could have a massive impact. It makes sense for device owners to consider this possibility in how they protect their machines, and for device manufacturers to attempt to mitigate it.
No, this line of thinking is basic threat modelling and stops us wasting time and effort on navel gazing when it would be better spent on things we can control. An invasive, non-destructive physical attacker also has access to (likely unencrypted) drives, memory buses, HIDs, audiovisual inputs...
'Fixing' this doesn't make your machine any less pwned if you let them touch it.
The linked article says it's not a problem with all implementations. This would suggest device manufacturers can defend against it, but some have chosen not to. Given the choice of a laptop where this risk is mitigated and one where it isn't, all other things being equal, I'd choose the one with protections in place.
Ok, but none of modern computing was designed around this mentality. Virtually all computers are trivially compromisable if you have physical access to the machine.
That is not what this attack does. You steal the laptop and then do a trick to unlock the secrets without giving back the laptop. Your MITM is fooling the fingerprint reader and the OS, not the user.
The point of the system is to protect against an attacker who steals the laptop so it is a complete failure.
SCDP describes a driver-level API, it doesn't tell you how to talk to the actual hardware. Vendors ship Windows drivers that implement that API but I'm not aware of any who've documented it. And while SCDP provides a secure communication channel with the biometric device, in itself that doesn't give you an ability to seal secrets to that device based on the biometric data.
My 2 year old laptop's fingerprint reader still doesn't work in Linux: Its native resolution is too high for the driver to handle, and somehow that's been an unfixable problem for years now.
> Another area where Linux Distros are at least 10 years behind Windows.
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.
Linux doesn't "have" to run on the hardware. The vendors put in all the work to make the hardware work for Windows (not Microsoft); the Linux community often has to do all the work themselves (usually starting by reverse engineering hardware, due to uncooperative vendors).
Linux does have to run on the hardware if it wants to be used by people. Blaming vendors doesn't fix the problem or get the community anywhere. This just reeks of being blinded by pride.
> Blaming vendors doesn't fix the problem or get the community anywhere.
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.
> How do you figure? This just strikes me as insecurity.
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.
Nobody was blaming vendors either. That doesn't change the fact that vast swathes of hardware vendors put much more effort into helping Windows support their hardware than Linux.
This hasn't been implemented because none of the people who value Linux and have the technical skills to implement this care about fingerprint readers, nor care to support people who do. If you don't like that, then do it yourself or pay somebody else to do it for you.
NoLsAfterMid's comment betrays an entitled attitude (e.g. "Linux should want this because I want this"), he doesn't seem to actually understand how or why things get done in the area of Linux. Linux itself doesn't "want" things, Linux itself cannot want to support particular use cases. Either somebody who wants something supported does it themself, or they pay somebody else to do it.
I am not sure why you think "Linux" wants to be used by people. There is no "Linux" in that sense.
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.
It depends on your frame of reference. To the end user or in a conversation about "can I install Linux on the family PC", maybe there is no distinction. To people posting on what is a tech forum considering the root of the issue, there is. This is the latter.
> 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.
Let me disagree, I think this is a problem of capitalism, not Linux. TPM is a closed-source technology, defective by design.
Typical over engineering that would worry about stealing the encrypted hard disk when discussing about a fingerprint scanner that would only really take a couple minutes to fool for the determined attacker...
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...
> When did we forget that biometrics were supposed to be a convenience and not a replacement for true authentication against any real adversary?
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.
just an interesting side point, your fingerprint lives persistently in the fingerprint reader, rather than "in your computer": by analogy, what I mean is something like, "if your fingerprint reader is in your mouse, then your fingerprint lives in your mouse, not at the other end of the wire plugged into the computer."
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.
Simply put: The intersection of "values Linux", "has the technical chops to implement it" and "thinks using fingerprints is actually a good idea" is an empty set.
Maybe some people in this thread think they're in that intersection, but I don't think anybody actually is.
I would put myself in that set, but it depends on what you want to use the fingerprint for whether it's a good idea.
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.
80 comments
[ 3.2 ms ] story [ 151 ms ] thread> 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
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.
Reliably mapping to the same key while not dropping down to abysmal entropy probably makes this intractably, hence the need for a TPM.
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.
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...
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.
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.
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.
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.
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.