Just wanted to explain what is going on here. Finger print readers do have their own onboard storage. In most cases they take a black and white 256x288 resolution picture of your finger when you present it. When you present your finger multiple times during the enrolling process it’s actually taking another, and another, and another picture of your finger from different angles. So it’s actually storing anywhere 10x256x288@8bit pictures each finger you enroll. That’s ~74kB for each picture 10 times for a total of around ~750kB for each person. Each scanner has about ~150 slots available for around ~11059200bytes of memory (~11MB).
The 256x288 is enough resolution to give a 1 in 100,000 incidental access. The different angles help is so when you place your finger on the scanner as long as it’s close to how you enrolled it it should accept it. So, pretty good. Depending on the time out of the sensor, it would take many, years to get into a device unless someone had a finger print that was fairly close to yours.
Now there are commands that can be sent directly to the fingerprint sensor itself. Indeed the sensor has a microcontroller that runs the whole show. It’s very much like an RP2040, just beefed up to handle image processing so it might be an M3 core and not an M0 core like the RP2040. This little bit of extra processing power and Instruction Set Architecture extensions makes is so the sensor isn’t painfully slow when processing your finger print.
When you enroll your finger, the OS sends the enroll command to the device. Normally for safes, 1 finger gets one image and that’s it. There is ether custom firmware or custom software sitting on top of this whole software stack that’s assigning 10 images to one person. When you present your finger to the scanner, it will send a message to the system saying that the finger matched this image ID and it’s confidence in that match, or it didn’t match at all. It’s up to the OS to accept a threshold of confidence as well as the firmware. For example it could be programmed so that the currently logged in user would allow for a lower level of confidence on their finger print acquisitions because that user is already signed into the computer. It makes for a better user experience without much cost to security. Whereas a threshold of confidence might be 99% that it’s the same image for logins, it only needs to be 90% for re-acquisitions and privilege escalations for the current user.
It should be noted that unless the finger print messages are signed to the host, they can be spoofed. The hardware that is acquiring the finger prints really must also have a hardware root of trust and be able to attest that "I am the same device that you’ve been talking to all along and you can prove that by checking my signature attached to this report with my public key. Otherwise replay attacks may occur.
If you are more interested in the topic, you can checkout Adafruit’s website where they sell some finger print scanners to play around with on Microcontrollers as well as including guides on how to get up and running with it.
I take it you enrolled different fingers on each OS? If you enrolled the same finger it might just be a lucky happenstance that you clobbered the same IDs that the other OS was using. I’d be intrested to see what order you enrolled in on what OS. Maybe windows sets the tone sand say "This is the first finger print image, and so you finger print scanner ARE going to put this into fingerPrintImageSlot 1. As the other OS was also using finger print image slot one for it’s print of you on it’s side the fact that it clobbered the image with another image of your same finger it didn’t actually matter.
Kind of yes. As Craig’s report where multiple OSes are using the same finger print database it clearly can be done, but the quirks of implementations are what it comes down to. Whereas fingerprintd will reject a similar enrollment as it seems to always want to use the next available slot and not clobber previous items. It’s being a kind citizen. I have a theory that Craig enrolled on Linux (Or “Other OS”) first and Windows said “Oh, Surely I’m the only OS that wants to use this hardware, and I don’t see any fingerprints enrolled in my database, so we are going to start indexing these finger prints from one all over again, previous images be damned.”
(Marking resolved as