A bit later than anticipated, I have created initial releases for the dpfp project, a driver for DigitalPersona and Microsoft USB fingerprint readers.

My last attempt at the driver/library thing failed – I learned more about the device, and decided I should take a few steps back and work with a different design.

So far, the rewrite is working out, so I’m releasing an early version for people to try. The driver provides a simple character device interface, and the library provides a nice API to that interface. libdpfp includes an example program which you can use to scan your fingerprint to a PGM file.

This isn’t for general usage yet. There are basic instructions in the README file in the dpfp-driver distribution.

If you have questions, please don’t ask them in comments on my weblog, use the mailing list instead. Enjoy!

Mikko gave his Black Hat Europe presentation about the security issues with Microsoft/DigitalPersona’s fingerprint readers recently, which seems to have been a success.

It has gained media attention, with a few reports floating around in addition to the one I linked to recently. itnews.com.au has one of the better ones, including comments from Digital Persona. At least Mikko found one way to get through to them :)

Mikko’s slides are online here and it looks like audio will be published soon on this page. Mikko explains the lack of encryption and references the dpfp project in a few places for some of the discoveries. He also explains some of the device optics and demonstrates how the lack of encryption can be exploited to allow finger replay attacks.

Danny van Dyk pointed out an interesting article about Mikko’s work on the Microsoft fingerprint scanners: Forscher hacken Microsofts Fingerprint Reader.

It’s in German, here’s Google’s English translation: Researchers chop Microsofts finger print reader.

The last paragraph, in real English:

Kiviharju wonders why Microsoft didn’t implement any Encryption. Quote: “Some experts who contacted me were as astonished as I was. It would have been a good product, but in the end, Microsoft screwed it.”

dpfp driver and library are progressing steadily, hoping to make an initial release within the next few days.

Looking for hardware hackers

I’d like to thank Joaquin Custodio for donating a Digital Persona U.are.U 4000B fingerprint reader, which completes my collection of every type of product in the range! It will be interesting to finally confirm whether there are any differences at all between the 4000B device and the MS hardware.

Actually, Joaquin sent me a total of 7 UareU 4000B readers! 6 of them are incomplete: no chassis or cable, and they have defects in the glass surface.

These standalone units are intended for distribution to interested hardware hackers. There is some persistant and flashable memory on the device (some form of EEPROM) as well as a central IC. There is also an easily accessible 15-pin interface to the board.

It’s not clear if dumping the device memory contents will prove useful, but it’s an interesting possibility. If anyone is interested and has access to the kind of equipment needed to hack on this kind of thing, please send me an email and I’ll send you a device. Joaquin also tells me that there are plenty more units available.

Encryption, round 2

I was sent the URL to Black Hat Europe‘s list of accepted papers. Particularly interesting is a paper titled Hacking fingerprint Scanners – Why Microsoft’s Fingerprint Reader Is Not a Security Feature.

The speaker, Mikko Kiviharju, made the same discovery that the fingerprints from the Microsoft devices are not encrypted at all, and will be talking about ways that the lack of encryption can be used to fool the system.

After reading that blurb, I found Mikko’s email address and sent him an email detailing my findings with the encryption control bit in the device firmware.

Naturally, Mikko was interested and is now investigating the encryption mechanism in use. And he’s quite the man for the job:

Mikko Kiviharhju has worked several years as a research scientist in the fields of data security and cryptology within Finnish government.

There’s not much to report yet, I am sending Mikko the various logs we have so that he can perform further analysis. So far, he has identified a possible bug in the encryption algorithm: 3 rows of every encrypted image are never encrypted. You can see this clearly in the image I posted last time. That is slightly weird.

Yesterday, I successfully obtained images my Microsoft fingerprint reader. After cleaning up the driver a little, I decided to try my other device.

A little background:

There are 3 ranges of devices which we believe are all very similar:

1. Digital Persona UareU 4000
2. Digital Persona UareU 4000B
3. Microsoft fingerprint reader (and products containing them)

The 4000B is basically a USB2 version of the 4000, and we think the Microsoft devices include ‘repackaged’ 4000B devices. My driver will hopefully support all 3. I own #1 and #3 and have sniffed logs from all 3 device types in my posession.

I plugged in my UareU 4000, and it sprang into life with my driver. I scanned a fingerprint and it gave me this:

Hmm. The data is very jumbled and is probably encrypted. I checked my logs, and sure enough – the data that comes from the 4000 and 4000B devices is jumbled and doesn’t show the same neat structure in comparison to the MS device.

A while ago, I had compared the 4000B firmware with the firmware for the MS devices. There is just one single bit difference between the two, suggesting that the devices are actually identical, yet the 4000B is sending encrypted data and the MS device is not?

I uploaded the 4000B firmware to my MS device, and sure enough, it then started sending encrypted images too. In other words, we have found the single bit in the firmware which turns encryption on and off.

This still leaves the problem that my 4000 device is still sending encrypted images. The firmware is quite different from the 4000B, but by looking at patterns in the byte data, I made an educated guess where the “encryption bit” would be in the UareU 4000 firmware. I uploaded the modified version to my device, and sure enough, it now sends unencrypted images.

I’m glad it turned out to be so easy.

Over the last couple of days, I found the time to finish off the dpfp kernel-side driver so that it exports fingerprint data into userspace, to make it easier to investigate the image format.

I had it working relatively easily. Running a small program on /dev/dpfp0 produces 7 data files, one of which is the fingerprint data, the others are interrupt data and other blocks of data that are probably interesting but we don’t know the purpose of.

I was going to leave it at that (others seem to be very interested in the image format), but I thought I might as well have a quick look at the fingerprint data and see if I can find anything interesting. I had glanced at some data previously, but had not done anything with my findings – it’s awkward to work with until you reach the stage where you can obtain data with just a single command.

I noticed the strange structure that I saw before: the data appears to be separated into chunks, each chunk being separated by 26 zero bytes. Each chunk is about 358 bytes long, so I decided that one chunk may be equivalent to one row of pixels in an image.

I noticed that the final part of the transfer ends right in the middle of the zeroes. I also noticed that the number of zeroes between chunks varies a little here and there.

Unusual, but not totally out of the question. Maybe each chunk starts and ends with zeroes, which would mean each chunk starts halfway through these series of zeroes I was seeing. That would explain why the transfer ends halfway through a block of zeroes.

Picturing that in an image scenario (where 0 = black), I realised that this would result in two black columns down the left and right side of the image. I then recalled an image that Jose M Robles sent me recently: a raw image from a fingerprint scanner (not really sure which one) which had black columns down either side. Jose has been doing a fantastic job throwing around theories about the image format, sending me histograms, pixel averages, sample images like that one, etc. Jose’s experiments also seemed to indicate that the encryption was weak, and at this point, things were starting to fall together.

After a few more calculations I decided that the image data starts after a 64-byte header. I also deduced the width (358 + 26 zeroes = 384 pixels) and height (exactly 259 ‘rows’ of pixels are included in the transfer). I cut out the header and replaced it with a PGM header.

I was both happy and amazed to see the result:

No encryption whatsoever, despite DigitalPersona’s claims (PDF).
Update: Those claims may be true. The UareU 4000 isn’t advertised to be included in the MS devices, we just put 2 and 2 together and saw all the simlarities. Now that I have looked closer at the UareU 4000 behaviour, it looks like encryption may be in place on those devices (but not the MS ones).
Another update: I discovered that the devices do support encryption but the Microsoft devices ship with encryption turned off.

This isn’t a real fingerprint scan – I actually scanned one of my toes, to protect the identity of my innocent fingers. Proper scans look more fingerprint-like.

3 imagemagick commands later (invert colours, increase brightness, decrease gamma) and it is perfect for processing:

Fancy stuff. It is lucky that those solid black columns are there, otherwise this wouldn’t have been anything like as obvious. I’ll be rewriting the driver soon, to be more simplistic and to export PGM images straight from the /dev node.

I’ve been receiving plenty of emails about the dpfp driver, so I set up a site and mailing list where interested people can keep track of things.

I’ve also recieved a donation of two Digital Persona fingerprint scanners from Gerrie Mansur of Security Database B.V. My keyboard was originally donated by Tony Vroon from Gentoo. Thanks!

• Website: http://dpfp.berlios.de
• Mailing List: https://lists.berlios.de/mailman/listinfo/dpfp-dev
• List Archives: http://lists.berlios.de/pipermail/dpfp-dev/
• Code and Tools: In subversion

I just sent a Status update to the list to get things going. Things are progressing nicely, it won’t be long before we can easily dump fingerprint data to userspace and start a big investigation into the image format.

Quick update on the dpfp project:

I recently upgraded to amd64, and running my existing code caused an instant kernel panic on plugin to my new system. Fixing that problem sprung the device into action – I now get the expected responses, where I was just getting silence before. Looks like my x86 was hiding the stupid bug in the early versions of my driver.

After working through the rest of the intitialization routine, I now have a driver which gets as far as turning on the light which illuminates your finger when you put it on the sensor, and my driver receives an interrupt when you put your finger there.

I’m beginning to think that my earlier assumptions about the sensor in my keyboard being identical to the sensor in the digitalPersona UareU 4000 product may be wrong. Unlike my keyboard, the UareU 4000 does not have an endpoint (a USB channel) where firmware can be uploaded. If the 4000 is not firmware-based, and my keyboard sensor is, then that suggests a fairly significant difference between the two devices.

Update: This statement is wrong. Indeed, the UareU does not have a bulk-out endpoint for uploading firmware, but the same is true for my Microsoft device. Firmware is uploaded over the control endpoint (a 2-way channel present on most USB devices designed for simple request/response commands) which is slightly stupid, but hey. I have also analyzed the UareU protocol now, and I can now accurately say that these devices are almost identical. My driver will support both product ranges. More on this soon.

digitalPersona are very keen to claim that the devices are different, but they only discuss differences in the available software, so I’m not entirely convinced by that alone.

I’m still not sure how to interpret the mass of data recieved from the device when a finger is placed on the sensor. I’ll be publishing a breakdown of what I do know soon, in hope that other people will be able to lend suggestions or other contributions into solving this problem.

Driver source can be found here: http://dev.gentoo.org/~dsd/dpfp/

As a sidenote, I’ve also been hacking on zd1211 devices, stay tuned for more info on that…