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 _______________________________________________ fprint mailing list [email protected] http://lists.reactivated.net/mailman/listinfo/fprint
