[fprint] libdpfp-0.2.2 released (for new MS scanners)

[Daniel Drake]

Hi,

http://developer.berlios.de/project/showfiles.php?group_id=5701

I just released version 0.2.2 of libdpfp. dpfp is the project I started 
in 2005 in attempt to get the DigitalPersona/Microsoft fingerprint 
scanners usable under Linux.  I never succeeded, but I did reach the 
point where you can capture images. http://dpfp.berlios.de

Yes - libfprint is the replacement project for libdpfp, I'll come to 
this below...


The main change in version 0.2.2 is support for the new microsoft 
scanners with USB ID 045e:00ca.

The challenge with the introduction of this device was overcoming a 
challenge-response authentication scheme that has been added at the 
hardware level. The device is challenging the authenticity of the 
driver. When you plug the device in, the device sends 16 bytes of data 
(which changes every time) to the computer - this is the challenge. The 
driver then applies a secret algorithm to that data and sends the 
resultant 16 bytes of data back to the device - the response.

The device also knows this secret algorithm and hence knows what the 
valid response is. Unless the driver provides the correct response, the 
driver is unable to operate the useful functions of the device.

To support this device in an open source project, we clearly need to 
know the secret algorithm in question.

Up until this point, all of the reverse engineering efforts that have 
gone into libdpfp/libfprint from myself and others have been based on 
"bus traffic analysis" -- that is, we use the fingerprint scanner in the 
usual way under another operating system, while monitoring the data that 
is sent over the USB wire. Given several sessions of this logged data, 
and quite a bit of time staring at lots of numbers, it's been possible 
to determine how to write open source drivers for the hardware.

It is not realistic to determine the challenge-response algorithm by 
using bus traffic analysis. Instead, we applied a reverse engineering 
technique commonly referred to as "chinese wall":

An independent 3rd party (i.e. not me) disassembled the Windows driver 
and wrote documentation on the challenge-response algorithm in question, 
without reproducing any of the machine code behind the windows driver in 
the documentation. The documentation was sent to me. It detailed the C-R 
algorithm and nothing more. No other help or resources were provided.

I took this documentation and produced an implementation. My 
implementation is therefore a clean-room reimplementation of this 
specific part of the windows driver.

This reverse engineering method is perfectly legal and is very common in 
the computing world. Many Linux drivers are written this way. And if 
your x86/x86_64 motherboard has PhoenixBIOS as the BIOS, that's likely 
still using some code that was chinese-wall-reverse-engineered from the 
original IBM BIOS about 20 years ago.



As I have mentioned before, in addition to being an open source project, 
fprint is also my 3rd year academic project at my university. The 
university expressed a little concern about including this code within 
fprint, given that it is a step up in terms of reverse engineering from 
other code - they didn't object, just suggested I follow up on it first. 
I am confident that it is legally fine, and am prepared to take steps to 
appropriately separate the university project from the open source 
codebase if necessary (not that it is really linked anyway -- the code 
is not developed on any university computers, and is not hosted there 
either, and the university do not own copyright on any of my work). 
However, things like this take time. My supervisor passed me onto the 
3rd year projects coordinator who passed me onto the university law 
center who passed me onto a patent attorney(!?), etc....

I have not yet managed to get a proper response from the university, so 
in the mean time I am releasing this device support via an updated 
libdpfp. There's no way that libdpfp can be linked to the university.

libdpfp cannot be used for fingerprint recognition, but you can use it 
for imaging. I encourage people to look at the code, port it to 
libfprint, and publicise libfprint patches for others to use. I will not 
be commenting on such patches or merging them into libfprint just yet 
for the reasons outlined above.

I'm sorry to let university politics hold up an open source project like 
this. If I knew a quicker route, I'd take it. For now, publishing a new 
libdpfp is the best I can do.

Daniel