Recent research on the security of match-on-chip fingerprint sensors
pointed out Goodix ones specifically as having flawed and low-quality firmware. (It also pointed out that Linux does not authenticate fingerprint readers at all, the protocol to do so being proprietary to Microsoft.) How relevant is this to the Goodix sensor used in (at least 13th gen Intel and 7040 AMD) Framework 13s?
Fingerprint readers and face cameras have never been secure. They shouldn’t be used as a substitute for a password. It’s not new.
There’s “painstakingly glitch or decap the reader” insecure and “bitbang a bit of data onto the bus” insecure. The contribution of the article is pointing out that a reader that should (on Windows) have been at the former level is in fact at the latter due to a flaw in the firmware (allowing an unauthenticated fingerprint store to be selected before transitioning to authenticated mode).
It’s just not possible to have actual security with fingerprint readers, as fingerprints are not secret.
Plenty of fingerprints all over the laptop.
For example, I don’t believe you can use a fingerprint to unlock encrypted drives on linux. If you ask for a way to make it work, you’ll be told not to do it, that fingerprints are not secret.
No need to decap chips with fuming nitric acid when you can learn to lift prints and fool readers on youtube.
And then there is the fact that Microsoft’s own Surface Pro has no security with its fingerprint reader. Plain USB, no authentication. Microsoft doesn’t even consider fingerprints on their own hardware to be worth anything. Not even an attempt at authentication.
Fingerprint readers are insecure whatever operating system you use.
See this article for an attack vector.
And if you are worried about insecurity then you should also worry about this potential problem. Note that the BIOS that Framework uses is noted as having the problem.
This is why it is so important that Framework invest in maintaining the BIOS/firmware on their laptops. Nirav posted that they have boosted the team working on this, but I really hope we start to see a better cadence of releases. For security, bug fixes and functionality.
was kind of wondering if I’d see this pop up here…not responsible for that research, but let’s just say some really (really) similar things 
UEFI (and sort of by extension physical) security is a rather deep rabbithole that’s often best served by critically examining your own threat model and making changes there (ie: “wow, vendor BIOS is really bad, I’m going to just shut down my computer when I leave it/go thru customs/whatever”). You can go grep for integer additions/multiplications near alloc calls in Coreboot if it is any comfort, too. imho the most robust way of solving this is to push (UEFI, hardware) manufacturers to stuff every little thing they parse into a TPM (or similar) prior to handling any of the complexities of the format - this way, your software at least has a chance to identify there’s been a compromise…Of course, this comes with its own barrel of snakes. I guess my point here is simply “fix these bugs” does not put a lid on these things.
If someone unplugging your fingerprint reader is within your personal threat model, so is connecting arbitrary USB devices - $ grep "usb:" /lib/modules/$(uname -r)/modules.alias | cut -f 3 -d ' ' | uniq | wc -l will tell you just how many unique kernel modules can be loaded just by providing a VID/PID pair! That’s all at least as accessible - yes, probably those exploits are harder to write, but if you’re concerned about more than an opportunistic stranger/friend with a Rubber Ducky-du-jour, that’s not really a factor…
Anyway, not really sure what my overall thrust was here - I guess just a hope at injecting some realism and deferring a little to Mickens when it comes to boot-time attacks. Fixes like this should be applied, but it’s not something to rake Framework over the coals for if they’re not hitting Patch Tuesday-like cadence. Maybe I’m just getting old 
If there’s information on your laptop that you feel needs to be incredibly secure even in the face of a threat that has physical access to the machine, you should probably be using a hardware security key, with passcode/pin, that you always remove and keep with you when not in use.
For most of us, myself included, there’s probably not much valuable data on our laptops that hasn’t already been leaked by Experian (for those in the States) or any number of online retailers and services with terrible security. I lean more toward convenience than extreme security personally but don’t blame anyone who disagrees.
That said, match-on-chip does seem like it suffers from the same basic design problem that pre-immobilizer cars had. Ask Hyundai/Kia how that’s been going.
Yeah, I think this is important context to keep in mind.the attacker must have physical access to your machine in order to pull off these attacks. It’s great that Microsoft commissioned these findings to help improve readers in the future but unless your computer must be secure from even a sophisticated targeted attack then I don’t think it’s worth losing sleep over. That’s especially true if you haven’t taken additional security measures like encrypting your drives.
Quite frankly, if your information or data is so valuable, you wouldn’t have it on a laptop that you take out into the wilds anyway. Once the laptop is stolen the possibility of someone getting the data off it is still high. Anyone involved in any sort of espionage, industrial or otherwise, is highly likely to have access to the information required to get around any security measure, including disk encryption.
I am amused by the desire for disk encryption in these threads. Quite frankly I see this as just a case of ‘having the warm fuzzies’. Yeah, sure it may take someone another month to access your data, but anyone with access to suitable tools will get at that data if they really want it.
Mickens is nice for those of us who only ever come into contact with authorities of countries who at least pay some lip service to due process, but that hasn’t always been true for me (hopefully in the future…). He’s not entirely wrong, but there’s a place between his “Mossad” and “not Mossad”, and it’s one where (simplifying some details) I’m currently less screwed that I could’ve been if I went all the way to “not Mossad”.
(Of course, that’s a place where I never use single-factor biometric authentication. It’d still be nice for it to be as functional as it could be, which is what ths post was about.)
I’d argue that the fact that a highly sophisticated actor might be able to break a lock doesn’t mean that the lock is worthless. It can, after all, prevent some folks from gaining access.
I think we’re fully off into the weeds now, but:
I am amused by the desire for disk encryption in these threads. Quite frankly I see this as just a case of ‘having the warm fuzzies’.
Disk encryption is extremely effective if you expect it to solve problems it can solve (a powered off computer not disclosing its storage contents). Look to any in depth reporting around authorities interacting with it (DPR, San Bernadino, etc.). As long as the keys are reasonably complex and not sitting in memory, it’s pretty much a best case scenario. Like everything, it’s an part of a defensive system. Not the whole thing.
Mickens is nice for those of us who only ever come into contact with authorities of countries who at least pay some lip service to due process, but that hasn’t always been true for me (hopefully in the future…). He’s not entirely wrong, but there’s a place between his “Mossad” and “not Mossad”, and it’s one where (simplifying some details) I’m currently less screwed that I could’ve been if I went all the way to “not Mossad”.
(Of course, that’s a place where I never use single-factor biometric authentication. It’d still be nice for it to be as functional as it could be, which is what ths post was about.)
This is very true. I’ve made similar remarks (though maybe not from experience, eek) when people have cited that to me before.
On the subject: Is a fingerprint reader required for Microsoft/Windows Hello certification of some sort? It would not surprise me if that was more largely the reason for its being, which makes it a bit of dead weight hardware for the rest of us. Understandable, but unfortunate.
edit: eh, apologies for not grokking Discourse quoting fully…
Has anyone attempted to modify the power button of Framework 13 ? Like removing features such as the fingerprint reader?
If the context is to eliminate risk of exploit, just don’t use it. Revoke any fingerprints if you were using it and use password login.
But if you really wanted to, you can cut or tape over the USB data pins or VBUS (usb power) pin. Framework-Laptop-13/Fingerprint Reader at main · FrameworkComputer/Framework-Laptop-13 · GitHub
Also, I think I recall that the Chromebook power button doesn’t have fingerprint and can be used.
~edit~
Looks like the Chromebook power button actually says it’s compatible.
Framework | Power Button - Chromebook
Made for Framework Laptop Chromebook Edition. Also compatible with the Framework Laptop.
Quick update here, we got an updated driver/firmware however the update has stability issues that we are debugging with Goodix. we hope to have an updated version in about 2 weeks.
I had some goodix firmware pop up via fwupd, and it failed to update.
This is what fwupdmgr is reporting to me:
Framework Laptop 16 (AMD Ryzen 7040 Series)
│
└─Fingerprint Sensor:
│ Device ID: 6dc14cd3f5a7e031a01b561fa9619f84c5fb8b07
│ Summary: Match-On-Chip fingerprint sensor
│ Current version: 01000252
│ Vendor: Goodix (USB:0x27C6)
│ Install Duration: 10 seconds
│ Serial Number: UIDD17D3F88_XXXX_MOC_B0
│ Update State: Failed
│ Problems: • An update is in progress
│ Last modified: 2024-04-17 05:38
│ GUID: 1e8c8470-a49c-571a-82fd-19c9fa32b8c3 ← USB\VID_27C6&PID_609C
│ Device Flags: • Supported on remote server
│ • Device stages updates
│ • Device can recover flash failures
│ • Updatable
│ • Signed Payload
│
└─Fingerprint Sensor Upgrade Fingerprint Reader Update:
New version: 01000334
Remote ID: lvfs
Release ID: 86579
Summary: Firmware for the Goodix Fingerprint Print Moc Sensor
Licence: Proprietary
Size: 193.4 kB
Created: 2024-03-04
Urgency: Medium
Tested by Framework:
Tested: 2024-04-05
Distribution: ubuntu 24.04
Old version: 01000334
Version[fwupd]: 1.9.16
Tested by Framework:
Tested: 2024-03-13
Distribution: fedora 39 (workstation)
Old version: 01000332
Version[fwupd]: 1.9.13
Tested by Framework:
Tested: 2024-03-13
Distribution: fedora 39 (workstation)
Old version: 01000332
Version[fwupd]: 1.9.14
Tested by Framework:
Tested: 2024-03-13
Distribution: fedora 39 (workstation)
Old version: 01000252
Version[fwupd]: 1.9.14
Tested by Framework:
Tested: 2024-03-09
Distribution: ubuntu 24.04
Old version: 01000332
Version[fwupd]: 1.9.14
Vendor: Framework
Duration: 10 seconds
Release Flags: • Trusted metadata
• Is upgrade
• Tested by trusted vendor
Description:
Fix physical MITM vulnerability that was found from blackwinghq - a touch of pwn part 1.
Checksum: 0e4de0a705142ffedeabfe59d584aec53e2ab30ce1fd41e5244137a22940eeb8
fwupdmgr --version
compile com.hughsie.libxmlb 0.3.15
compile org.freedesktop.Passim 0.1.5
compile com.hughsie.libjcat 0.2.1
compile org.freedesktop.fwupd 1.9.15
runtime org.freedesktop.fwupd-efi 1.4
compile org.freedesktop.gusb 0.4.8
runtime org.freedesktop.Passim 0.1.5
runtime org.freedesktop.gusb 0.4.8
runtime com.hughsie.libjcat 0.2.1
runtime org.kernel 6.8.5-301.fc40.x86_64
runtime org.freedesktop.fwupd 1.9.15
This is on Fedora 40
Since is Fedora Beta 40 your problem may be related to the bug fixed with this MR. First of all verify you have at least libxmlb-0.3.18 installed. More info on this issue elsewhere in the forum.
This is the version that deployed the fw-16 3.03 firmware successfully.
Also the libxmlb-0.3.16 was the version that introduced the regression, I’m still on 0.3.15 as per the post above.
Just posted here that I got some goodix firmware to update and it started the update and now is stuck. I didn’t see any other comms re goodix update.