glad to see support for my fingerprint reader I hope you can soon resolve legal issues and merge libdfp with fprint project getting support for also this device:)
PS: please trash my previous message as sent by different account, sorry On Thursday 06 December 2007 23:28:03 Daniel Drake wrote: > 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 _______________________________________________ fprint mailing list [email protected] http://lists.reactivated.net/mailman/listinfo/fprint
