Biometric at powerup to unlock LUKS?

Hey all,

I’m running Fedora 38 on a Framework Laptop 13 and have managed to use the fingerprint scanner as an alternative to entering the password for my user account when logging in to a Gnome session.
However, there are some things left to be desired, compared to earlier Windows experience I have made. This was back in the Windows 7 days with a Lenovo W530 so it was possible ages ago already.

  • user account would be recognized from the fingerprint. In Fedora, the user account needs to be picked first, and then a matching fingerprint is required. On Windows it was possible to just swipe a finger and the OS would recognize what account is related to the fingerprint, and go to that user’s session right away. Much easier if multiple users are present
  • boot time authentication: the W530 could be powered on using only the fingerprint scanner. In case the finger was recognized, the laptop would power on, unlock the BitLocker partition, boot from it, and go right to the desktop of the user whose finger was used to power on. That’s a massive timesaver. In Fedora, I have to wait about 10 seconds after powering on until I can enter the LUKS passphrase manually, then wait another 20 seconds until I am greeted with the logon screen which sometimes fails to offer the fingerprint option. Only when escaping from the logon and picking the same user again, it is all of a sudden possible to authenticate by fingerprint

I think what happened on the Lenovo W530 and Windows was already TPM-based and nothing specific that was only possible due to some Lenovo hack.
While I love Fedora and Linux in general a thousand times over Windows, I must still say that it seems ages behind regarding comfort in this regard. I can live with longer boot times, but logon might be so much more streamlined. Are there any plans to get there one day? Or have I missed something and it’s already possible?

Thanks for any enlightenment on this topic!
Cheers,
Joe

While I do not use windows and have not for some time there is one fact to keep in mind.
Microsoft works hard with almost all hardware and computer manufacturers to ensure that drivers and software functions perfectly with each system sold – and with windows specifically.

The FOSS community does not have that luxury nor cooperation at all and most drivers must be reverse engineered to function with the hardware. While the goal is the same, it does require the hardware vendors to support linux and most do not directly do so.

There are 2 downsides to this. First there is a built in delay while the drivers are created or updated for new hardware. Secondly there are likely some features of the hardware that may never be fully supported by reverse engineering software support.

The linux FOSS community does wonderfully at providing functional software but can never do so at the pace (and in some cases quality) as provided by the hardware manufacturers. After all, they build the hardware and provide the drivers for windows to support that hardware.

Hi Jeff,

thank you for your reply.
I totally agree. It’s a Microsoft monopoly, and with that in the background, it’s actually a miracle how well hardware suppot in Linux works in general, also for devices that were specifically (maliciously?) built with a Windows-only tunnel vision. It’s great that capable people invest so much time in making basically just any device useful in Linux, thereby cheating hardware manufacturers as well as Microsoft. I love this ecosystem for being just that. So I’m not complaining and hopefully didn’t sound like I would.
I would love to contribute but my skills aren’t sufficient for this. So I can only sit there and wonder how Linux feels so much better than Windows in most cases whereas in some it is really lacking hard. Just wondering as the feature I described exists on the dark side since about 2010, and still nothing similar available for Linux.

As far as I understand it, it works like this. Forgive me if this is completely wrong but there isn’t much documentation about the details of this and I might be much too naive to comprehend it entirely:

  • fingerprints are managed by a desktop application / control panel. It was a custom Lenovo piece of software back in the day. As far as I remember, managing fingerprints was not possible in the BIOS. → this management component would need to be added
  • in case the boot-time authentication was activated, the fingerprint data are not only stored in a safe location inside the OS, but also inside the TPM. This allows fingerprint recognition at all times → if not already done, somebody needs to figure out how to make the key data available through the TPM
  • also depending on the activation of boot-time authentication, the system will shut down but leave the fingerprint scanner on → driver support required for this mode, and the fingerprint hardware probably needs some additions, too (eventually some standby hardware and logic needs to be able to read the fingerprint scanner, and validate its actions, and eventually power on the system)
  • once a finger was detected and validated, the system powers on → hardware support required. In case of a Framework laptop, this means the power button is not pushed but only touched (fingerprint sensor is built into that button), but both might be cleverly combined as well
  • in the pre-logon phase, Windows detects that the TPM authenticated the user already, and forwards to the respective desktop environment → logon routines need to look up data that might have been left in the TPM this way
  • in case the system was powered on normally, the logon screen would appear, and fingerprint recognition would be available for any user who registered their fingers previously. An identified fingerprint would immediately log the respective user in, without the need to pick the account first → all fingerprint data needs to be available before anybody logged in

So there’s a lot of work involved but at least it’s proven to be possible.
Storing the fingerprints and processing fingerprint reader actions might have been provided by the Intel Management Engine (ME) instead of the TPM, I’m not sure. Back in the day the ME appeared like a cool feature. And if this functionality requires that ME be activated, I would rather forget about it entirely.

It is clear that Microsoft sit in their own nest and hardware manufacturers are like the birds who build it. This has become more evident than ever in their random choice of CPUs and mainboard features being supported by, or required for Windows 11. A win-win for them as well as the manufacturers, users being their hostages to bear whatever they inflict on them.
I have deliberatly picked a Framework laptop because they claim they love Linux and do their best to support it.
It might be best to talk to them first.

Well, thanks for your input on this. I’ll be patiently waiting.

Cheers,
Joe

Not cheating the hardware mfgrs since the hardware is still used (and paid for) but does bypass the monopoly on the drivers. In fact, having a driver available for linux makes it possible for more users to have that device in action. A win for the hardware side.