dsd’s weblog

Steve Berryman has been kindly hosting the code for some of my projects since the end of 2006 (dsd.object4.net). The server is going away now, so it’s time to move.

My new home is kindly hosted by Ryan Gibbons and is accessible at http://projects.reactivated.net. My git repositories are no longer available over http, they are instead accessible through git://projects.reactivated.net/~dsd/PROJECTNAME
gitweb is also available as before, and nightly snapshots for some projects will be generated here.

Many thanks for Steve and now Ryan for taking this administrative workload off my back and allowing me to focus on developing the software!

I remember playing a DOS game on my 386 computer, probably when I was about 10 years old. The game presented an unlabeled map of Europe on-screen, then proceeded to ask me to click on Portugal, Germany, Switzerland and all the other countries in a different order each time you played the game.

The game kept track of my high scores in terms of both the number of countries I got right/wrong, and also the time it took me to identify them all. I played this repeatedly, trying to beat my own records. I learned a lot about European geography this way, and it was fun. It’s similar to this online game except the game I’m thinking of had metrics to keep track of your performance and highlighted the right answer whenever you clicked on the wrong country.

This is a great example of hard fun, one of the principles of educational constructionism behind the OLPC project. As such, I’m considering writing a clone of the game for the XO laptop.

I’d love to dig out the old DOS game again, but I can’t remember what it was called! Does anyone else know of its name, or have any recollection of this game?

On the Gentoo kernel maintenance front, I’ve been slacking lately. After launching the project, my fingerprint scanning efforts soon started to eat almost all of the time I’m willing to spend in front of a computer. Then comes a busy xmas/new year, quick week in the US, exam revision and now exams; it’s been a few months since I put proper time into the Gentoo kernel front. I’m feeling a little guilty as this inactivity all started at pretty much the same time as when I became the kernel project lead.

Yet, the Gentoo kernel bug list shows only 23 bugs open, plus no critical/widespread unsolved issues at a cursory glance (when I was doing this singlehandedly, I usually had problems keeping this count below 40). This is all thanks to Maarten Bressers, Duane Griffin and Mike Pagano. Unfortunately Maarten is tied up with other issues at the moment, but Duane pops up from time to time and singlehandedly solves some tricky-looking issues and Mike is very active and is doing a fine job keeping things shipshape.

Before getting involved with Gentoo kernel bugs and genpatches maintenance, all 3 of the aforementioned people had no prior involvement with the kernel. One of the things that prompted me to write this post was to get up today and see an IRC conversation, where Mike uses some diagnostic knowledge he’s gained from a Gentoo kernel bug to make a suggestion to another user who is having trouble booting their system (which I am quite confident will solve the issue). Definitive proof that Mike has become a skilled and efficient bug-attacking machine.

If other developers are wondering how I managed to recruit these “newbies” into enthusiastic and productive contributors, my process was as follows:

1. Write a maintenance guide giving people enough information to get started
2. Encourage the interested respondents to ask lots of questions (I think this is the most important part — be clear that you’re available to be consulted).
3. Advertise it in the Gentoo Weekly Newsletter.
4. Wait for some questions to come in (and answer them).

All in all, it was quite time consuming to write the initial document and then answering questions, but the fact that I can then be largely inactive for a few months and still have things running smoothly tells me that it was worth the investment.

I’ve been back in Boston this week, and I spent some time visiting the OLPC offices in Cambridge. People aren’t joking when they talk about laptops hanging from the ceiling.

Formal testing is a big thing at the moment, so I spent some time helping out testing the upcoming release branches. I also sneaked in a few bug fixes here and there, and managed to solve some irritating interface quirks.

This was my first interaction with the laptops, and I must say, those little XO machines are incredible. I’m overly impressed on all accounts, especially with the vast level of improvement of the currently-being-finished Update.1 software release over the current stable Ship2 release. There are a number of great people there, from an interesting variety of origins - mirroring the multicultural aims of the organisation, I suppose. Many thanks to those who helped me fit in and get started.

Recent writing-related updates:

• The LWN article detailing my fprint project is now public.
• Patrick Guignot’s LinuxFR article has been translated by kang on a previous post.
• Years after writing the original version, my writing udev rules documentation continues to generate a lot of feedback. I updated it to reflect changes in recent udev releases.
• While handling some zd1211rw bugs, I improved my knowledge and contributed some kernel documentation regarding unaligned access to memory. I also transformed this into a more general article which was published in the December 5th edition of LWN (now freely available).

A while ago, Microsoft released a new revision to their fingerprint reader product. The new revision includes some extra security and the open source software that I’ve previously written for the earlier models does not work with the new revision as a result.

The newly added security is a challenge-response algorithm, where the device challenges the authenticity of the driver soon after the device is plugged into the computer:

1. The device sends a 16 byte challenge
2. The driver sends a 16 byte response

The challenge produced by the device changes on every plugin and is probably just a random number. The driver then receives the challenge, applies a known secret algorithm to it, and sends the resultant data as a response. The device also knows the secret algorithm, and hence knows the correct response that the driver should send back. If the driver does not send back the correct response, the driver is not able to operate the useful functions of the device.

Naturally this poses a challenge for an open source driver implementation - unless we know the secret challenge-response algorithm, we are unable to operate the device. Previously, all reverse engineering of these devices has been done through bus traffic analysis alone (looking at the USB packets sent and received by the official Windows drivers, and making educated guesses as to what each packet means). It would not be practical to attempt to apply the same reverse engineering techniques to determine the secret challenge-response algorithm - we’re effectively talking about breaking 128 bit encryption by analysing a data set…

So, I got in contact with a 3rd party and we performed chinese wall reverse engineering on this particular part of the Microsoft driver. The 3rd party looked at disassembled instruction code of the Windows driver and documented the algorithms without reproducing any of their code. I received the documentation, and produced a clean-room reimplementation of the authentication scheme in my driver.

The secret challenge-response algorithm in use is simply AES with a specific decryption key.

I have released libfprint v0.0.5 which now supports these devices out of the box. Enjoy!

fprint is featured in the November 21 edition of LWN, which should be helpful in spreading the word further!

The article mentions that libfprint does not support identification (one-to-many fingerprint matching) yet. I just released libfprint v0.0.4 which adds identification support, and fprint_demo v0.4 which includes a GUI to demonstrate it. Talk about yesterday’s news ;-)

Torkild Retvedt contributed a logo, which you can see above. I’m happy to consider further logo submissions, but I do like Torkild’s and it will do very nicely for an initial project logo. Thanks Torkild!

Patrick Guignot spotted the LWN article, did some further research, and then published an article about fprint on linuxfr.org. I have only seen the google translation, but I must say, translation artifacts aside, that is an extremely well written article which has hit on exactly what I’m trying to achieve. I’ve written to Patrick to see if he’ll translate it into English or give me permission to find someone else to do so - I will publish any results here.

Update: Patrick doesn’t know English well enough to write his own translation. Any French-speaking volunteers who wouldn’t mind spending some time translating this into English?

Things are still busy with my new project. Here are a few more fprint releases which add some crucial features:

1. libfprint v0.0.3 adds support for the Authentec AES1610 found in various common laptops/tablets, contributed by Anthony Bretaudeau. These fingerprint readers only see a small area of the finger so imaging performance isn’t great, but it is usable!
2. pam_fprint v0.2 adds an enrollment application contributed by Vasily Khoruzhick, and has been fixed not to activate itself for logins over SSH.
3. fprint_demo v0.2 and v0.3 add various bits of functionality: enrollment GUI, image saving functionality, plus the ability to count and plot detected minutiae points.

fprint_demo v0.3 showing minutiae plotted on scan image

The fprint project has kicked off to a good start. Thanks to everyone who provided feedback so far. Any extra help spreading the word is much appreciated!

Immediately after the initial release, Vasily Khoruzhick contributed a fix for my aes2501 driver, as his is mounted in his laptop 180 degrees rotated, it’s upside down (actually I’m not sure which way round mine is supposed to go, but thanks to Vasily it now works either way). I also modified the aes2501 driver to perform fewer USB transactions, resulting in much improved image quality and overall scanning experience.

Jan-Michael Brummer contributed a driver for the UPEK TouchChip fingerprint sensor (USB ID 0483:2015) found in the Samsung P35 laptop. Jan-Michael indicates that the image processing performance is good but not brilliant.

libfprint v0.0.2 has been released with the above changes and a few others.

I also have been working on a simple demonstration GUI which may also help development in future. It’s called fprint_demo. Here’s a screenshot:

fprint_demo v0.1

Gentoo ebuilds for all released fprint components can be found here.

If you’ve been following my previous work with DigitalPersona fingerprint readers on Linux, you’ll be aware that what was an active and exciting project was reduced to almost nothing when it became apparent that open source fingerprinting code was possibly in conflict with U.S. export control laws.

Well, after studying the export control documents in detail, I discovered that these restrictions simply do not apply. I decided to propose my 3rd year university project as an open source software project to really sort out the state of fingerprinting on Linux. This project is now underway. For an overview, look at this poster.

The core project component, libfprint, aims to make it easy for application developers to add fingerprinting support to their applications - be it imaging or verification (or in future, identification). libfprint strives to provide you a single API for manipulating fingerprint readers in the most generic of fashions. Internally, a variety of different devices are supported through a driver-like abstraction. These devices do differ tremendously, but libfprint works to wrap that up so that as an application developer, you don’t care what type of device the user has plugged in.

As this is an academic project, it was necessary to keep development closed while I implement the fundamentals myself. I’m now at a point where I’m able to release this as open source and accept contributions in the normal way. I plan to keep this project going beyond the academic project schedule and I’d love to see a community forming. In the long term I’m aiming for inclusion with major distros, integration into desktop environments, etc.

Quick summary of where things are at:

• libfprint is relatively stable and works well with most devices
• a PAM module named pam_fprint has been created, which allows you to use your fingerprint to login to your system
• The code is all in git repositories, there are initial releases but there are no guarantees of stability or forwards-compatibility
• API documentation is mostly complete, but is subject to change without notice
• I’ve been working hard to get a decent amount of content on the project website

Hardware currently supported:

1. UPEK TouchStrip (found in many ThinkPads) - works great, we already knew this as ThinkFinger is quite successful
2. DigitalPersona/Microsoft devices - these work fantastically well
3. Authentec AES2501 - an imaging device, swipe sensor, works well (requires a little extra care while scanning).
4. Authentec AES4000 - an imaging device I haven’t really played with before. Image quality isn’t that brilliant, but it’s good enough for fingerprint login if you’re careful.

I’m very happy with the project so far. I’m pretty sure I’m the first person to fully implement open source fingerprint login for the DigitalPersona devices, the AES2501, and the AES4000, plus I’ve done it in a generic way which interchangeably works with all supported devices.

• fprint project homepage
• Download info
• Mailing list

Please direct all questions/bug reports to the mailing list, please don’t use the comment form on this post for anything other than comments.