Fingerprint unlock for boot/bios

[Spunkie]

Device Information:

• Framework Laptop 13 (AMD Ryzen™ 7040 Series)
• Framework Laptop 16 (AMD Ryzen™ 7040 Series)

BIOS VERSION:

03.05/03.03

Standalone Operation:

• No

Description:

It would be a really nice feature to have, especially for businesses, for the ability to require a fingerprint on boot and/or access bios/admin/secure boot/boot selection menus. Lenovos implementation of this has been very good.

Expected behavior:

• Register some fingerprints from within your OS of chose, windows/linux.
• Reboot into bios and enable biometric requirement for boot and/or bios
  • if not already set, have the user create a strong boot and/or admin password
• Reboot and now directly after the framework boot logo it displays a screen that prompts for biometric auth
  • Should have an option to cancel/skip to password prompt
  • The very first time a fingerprint is successfully used, it should password prompt as well
  • Should allow 3-5 fingerprint read attempts before falling back to password prompt
    • Rebooting should allow more fingerprint attempts. Not sure what the max number of attempt should be before requiring a password prompt. So far I've never hit lenovos limit even after multiple restarts 🤷
  • When the fingerprint reader is not available for whatever reason fallback to password prompt
    • Maybe display a notice about it in the bios
    • When turning on standalone mode I imagine the bios should warn you about turning off biometrics?

Bonus Points:

• Seemless login
  • After successfully entering a fingerprint at boot, the fingerprint get carried into the OS environment and used to auth into the users session "seemlessly".
    • aka the user never sees the login screen
    • based on which fingerprint is used, it knows which OS user to login to
      • in windows this seems to be accomplished by tying into windows-hello
    • This is another thing that lenovo does already.
  • Usually requires some kind of driver/app installed within the OS to work
• Fingerprint registration and management from within the bios
  • List existing fingerprints
  • Allow fingerprints to be named/renamed
  • Allow new fingerprints to be registered
    • Promt user to name the new fingerprint
    • If a fingerprint being registered already exist display a notice with a shortcut to manage(rename/delete) that preexisting fingerprint.
  • Allow the deletion of fingerprints
  • Any changes to fingerprint settings also requires a password prompt?

Operating System:

• Windows 11 Pro
• Arch Linux KDE

[JohnAZoidberg]

It's an interesting idea but I'm not sure it's worth the effort.

Would auto-unlocking LUKS with Linux fingerprint login cover your use-case?
Similar to Bitlocker on Windows, Linux can configure LUKS to automatically unlock your disk if your TPM PCRs are as expected: https://community.frame.work/t/guide-setup-tpm2-autodecrypt/39005
Then you can log into your user account with the fingerprint.

I think that would give you even better security properties than the proposed approach of fingerprint in UEFI with unencrypted disk.

[Spunkie]

Thanks for the reply @JohnAZoidberg

It's an interesting idea but I'm not sure it's worth the effort.

Well anecdotally, literally 100% of my users I've switched from lenovo to frameworks have expressed disappointment in the missing feature.

Would auto-unlocking LUKS with Linux fingerprint login cover your use-case?

And no I don't really think that would cover our use-case. Certainly a LUKS/LUKS2/bitlocker integration would be nice if added as part of a UEFI fingerprint unlock but it does not replace it. Some of our users already use LUK2 with passkey(yubikeys) auth, but they still prefer having UEFI fingerprint unlock in addition to that.

The whole point is to conveniently restrict access to the computer/bios itself, not the OS. It should still function even when there is no disk/OS installed or even after a fresh OS install when nothing(ignoring initial fingerprint registration) has being configured.

[JohnAZoidberg]

Ok I think I understand your request and it is very specific. We can consider this as a future improvement, but there are lots of pieces missing to make that work.

The whole point is to conveniently restrict access to the computer/bios itself, not the OS. It should still function even when there is no disk/OS installed or even after a fresh OS install when nothing(ignoring initial fingerprint registration) has being configured.

What's the threat model where this is needed on top of restricting access to the disk/OS?

Evil maid attack that swaps out the SSD and returns the system? Or somebody steal the system and re-use it with a new SSD?

Maybe we can figure out an alternative easier solution to address the concerns of your threat model.

[Spunkie]

Thanks again for the quick response @JohnAZoidberg

What's the threat model where this is needed on top of restricting access to the disk/OS?
Evil maid attack that swaps out the SSD and returns the system? Or somebody steal the system and re-use it with a new SSD?

I feel like ability to restrict access to the bios/secure boot/boot selection should speak for itself. Also combined with default boot order settings in the bios it can also be used to completely restrict the ability to boot to an "unexpected" disk/usb without biometric auth first. Which is a huge win in my book.

The threat model is a pretty wide range:

• toddlers/cats spamming keys on the keyboard, unexpectedly messing up bios settings
• employees/family messing up bios settings they should not be touching
  • This is also why lenovo bios optionally has 3 separate levels of passwords: Admin, Manager, and User level passwords. And allow locking down bios read/write permissions to those different levels.
    • So a user can be setup to only have view access to bios/boot options but a admin/manager level password/fingerprint would be required to actually change any of those bios settings or select another boot device.
    • This is also why a password prompt is asked the very first time a fingerprint is used to boot. Based off the password entered the system knows if a fingerprint belongs to a admin, manager, or user.
    • Also having these separate passwords relieve concerns about onboarding/offboarding.
      • I don't need to know/track a users boot passwords as long as I have an admin/manager password set I know I can still get into the device and do what needs to be done. Even if the device was offboarded unexpectedly.
        • aka the user dies, leave the company, changes hardware, gets grounded, or simply forgot their password.
      • While not a good idea security wise, in times of need it also offers me a weird flexibility in being able to have devices temporally loaned between people.
        • travel, repairs, shortages, conventions, presentations, illness/hospital stays, there's an endless number of reasons I might want to temporally shuffle hardware between users really...
        • Handover process:
          • UserA create a new OS account for them and then physically hands over the device to UserB
          • UserA enters in their fingerprint to boot
          • UserB logs into their OS account and registers their fingerprints, reboot
          • UserB enters fingerprint to boot, UserA auths that fingerprint with their bios/boot password
          • UserB can now use the device for short term without worry about a bios/boot/login password
          • UserA didn't need to reveal/change their bios/boot pass and can clean up access easily when they get their device back by simply deleting the fingerprint/OS account
        • I know this process sounds complicated but the handoff can be accomplished in just a few minutes if the user is prepped.
          • Doing this with passwords instead of biometrics is normally a sticking point that prevents loaning devices between people even that it makes sense to do so.
            • It easily 2x/3x the numbers of steps and is ripe for typos and frustration
            • Often results in the bios/boot password simply being turned off temporally
• yes, evil maid types of attacks as well
• state level actors

---

Maybe we can figure out an alternative easier solution to address the concerns of your threat model.

Obviously the simpler solution would be a password to do all the same things. Especially since a password prompt is used as a backup for the biomentic auth, so it's a prerequisite anyways.

But in my experience, end users will simply not use a password solution for a bios/boot auth, it's seen as far too much of an inconvenience. Even if forced, users will typically set a comically low complexity password or simply lie and disable the bios/boot password all together. Fingerprint for bios/boot auth on the other hand, users seem to love.

End users especially enjoy the "seemless" OS login feature. And since it lowers the perceived inconvenience so much, it means I can easily convince users to set an extremely complex password for not only the bios/boot password but also their windows login password. End users might only need to enter in these passwords a handful of times in the entire lifetime of their device. Which is a hell of a lot lower than, "every time I boot".

---

Anecdotally, my users just like the act of needing to enter in their fingerprint to boot in general. It seems to provide them with a level of comfort.

[JohnAZoidberg]

Thanks for the thorough explanations!

It sounds like setting a BIOS password, using passwordless disk encryption, and using fingerprint for OS login would get you 90% of the way to where you want.
Solves the daily need of seamless boot and locks out unwanted BIOS setting access.
Do your users ever need to access the BIOS settings? Probably not, right? Then you could set that password while setting up the system for them.

restrict the ability to boot to an "unexpected" disk/usb
There's already a BIOS setting to disable USB boot. Would that be helpful or do you expect your users to occasionally boot from USB during normal usage?
For disk access, also I assume your users do not need to open their system and change disks. So you could enable intrusion detection that forces entering the BIOS password when the chassis was opened.