[ubuntu-in] Fingerprint reader/login project announced

[Vishal Rao]

Including the Fingerprint reader project announcement below... I
believe the Fedora Fingerprint page mentions Daniel Drake to work with
for getting fingerprint support into Linux!

http://fedoraproject.org/wiki/Releases/FeatureThinkfinger  (right at the end)


---------- Forwarded message ----------
From: Daniel Drake <dsd at gentoo.org>
Date: Nov 15, 2007 5:00 PM
Subject: [fprint] Announcing fprint project
To: fprint at reactivated.net


Hi!

As I've mentioned in a few places, I've been cracking away on a new
project over the last couple of months. It's now open to the public. The
project is called "fprint" and its homepage is here:

http://www.reactivated.net/fprint

It's a wiki, but registration is not open to the public. I will
gratefully give out accounts to those who request them (just choose a
username) and I'm also looking for people to help admin it.

I'm doing fprint as an academic project (3rd year Computer Science at
the University of Manchester, UK). I've been planning it as an open
source project from the start, however, being an academic project I felt
it necessary to implement the fundamentals myself, so I held off on
making it public until I had reached a few early milestones. Sorry about
that - I know that I get a little frustrated when I see people not
making their work public from early on.

The academic project is ongoing, but I'm now able to run it as an open
source project in the normal way -- contributions encouraged and
reasonable ones accepted! Despite my earlier secrecy, I am very
interested in building a community, gaining adoptance, and hopefully
getting shipped by distributions.

The objective of my project is both simple and broad: get consumer
fingerprint scanning hardware usable on Linux. "usable" means that the
software actually processes and interprets fingerprints, not just saving
them as images. "usable" means that there is actually software which
uses fingerprint readers in a sensible fashion, and that users don't
have to download obscure package Y and compile it themselves, then come
up with some obscure way of integrating it into their workflow.

How do we approach this problem? The first thing I want to do is make it
easy for application developers to add support for fingerprinting to
their software. Once application developers can easily add
fingerprinting support to their projects, they can make it easy for
users to use their consumer fingerprint scanning hardware.

Requirements for making it easy for application developers to support
fingerprinting include:
  - Application developers should not care which type of fingerprint
scanner the user has plugged in.
  - Application developers should not care that device A is an imaging
device whereas device B does image processing in hardware.
  - Application developers should not have to write extra code to
support another fingerprint scanner product.

So that leads me to the core component of the project: libfprint
libfprint is a library aimed to make it easy for application developers
to do stuff with fingerprint readers. That includes image retrieval, but
also includes finger enrollment, finger verification, storage of
fingerprint data, etc.
At the outset, it generalises all fingerprint scanners into a single
model, and provides an API to manipulate fingerprint readers through
that model. Internally, it includes several drivers to drive different
types of hardware, and a few abstraction layers to hide the vast
differences between these different device types.

Another aim of libfprint is to support a lot of hardware. After all,
it's not easy to use your fingerprint scanner if it's not supported :)
libfprint defines an "internal API" for drivers, and another objective
is therefore to make it easy to write drivers. All current drivers are
quite small.

My project also includes working to get libfprint integrated with
existing systems.

The second component I have developed is called pam_fprint. As you might
guess, it is a PAM module which simply calls a few functions in
libfprint in order to make it possible for you to login to your computer
using your fingerprint rather than a password. pam_fprint is a
proof-of-concept at the moment, but it works. pam_fprint is naturally
driver-agnostic, hardware-agnostic, supports all the hardware that
libfprint supports, and was quite easy to write.

Some of the devices that libfprint supports are imaging devices, but we
obviously need to be able to process these images to decide if we can
log the user in or not. libfprint handles this internally, it uses
NIST's NBIS code. NBIS caused us some headaches before because NIST
indicate it is export-controlled from the US, however I have determined
that in the context of this project, there are no restrictions. See the
wiki for more details.

libfprint currently includes 4 drivers:
1. uru4000 - DigitalPersona U.are.U 4000/4000B
This is based on libdpfp. It supports the Microsoft and DigitalPersona
devices. As we know, these devices simply send images to the host computer.

2. upekts - UPEK TouchStrip
This is based on code from thinkfinger and should support all the same
devices. This device does not provide any images, it does image
processing in hardware and gives a boolean result - "match" or "no
match". Despite this device being vastly different from the others,
libfprint abstracts the differences away and provides the same API to
applications (except the image retrieval parts obviously do not work).

3. aes4000 - Authentec AES4000
Another imaging device that uses active capacitance.

4. aes2501 - Authentec AES2501
Another imaging device, active capacitance, swipe-type.

In terms of being able to login with your finger, uru4000 and upekts are
working almost perfectly. aes2501 works quite well, but works best if
you practice your scanning technique, and aes4000 works if you are
careful about always placing approximately the same part of the finger
on the sensor. There is work that can be done to improve imaging
performance on all 3 of the imaging devices.

In terms of accuracy, I have yet to see a false acceptance (i.e. scanned
finger doesn't match the original, but computer says it does). On the
AES2501 and AES4000 devices, false rejections (scanned finger does
match, but computer says it doesn't) are quite common until you've got a
good scanning technique. It's quite hard to get a false rejection for
the DP/MS devices unless you are especially trying (finger significantly
rotated, etc).

I believe that fprint is the first open source project to offer the
capability of using the DigitalPersona/AES2501/AES4000 readers to the
point where you can login with your fingerprint.

That said, it's a young project, there is plenty to do, and there will
be bugs. The code is all in git repositories but I have made initial
releases (no stability or forwards-compatibility guarantees!). I have
spent quite a bit of time putting content on the website, so I hope that
answers many of the initial questions.

The website is here:
http://www.reactivated.net/fprint/

Please use the mailing list for questions, support requests, and
development. Please don't email me directly without good reason - I
might ignore your email.

I'm hoping to get people involved with the project, not only development
- there are some admin tasks too.
http://www.reactivated.net/fprint/wiki/Project_needs
Also, I went a little out of pocket purchasing devices for the project,
and would very much appreciate any donations there (or alternatively,
donations solely for future purchases etc).
http://www.reactivated.net/fprint/wiki/Donations

Quick thankyous to people who have recently been helpful with
relicensing existing driver code etc: Cyrille Bagard, Timo Hoenig,
Vasily Khoruzhick, Pavel Machek.

Thanks and enjoy!
Daniel
_______________________________________________
fprint mailing list
fprint at reactivated.net
http://lists.reactivated.net/mailman/listinfo/fprint



-- 
"Thou shalt not follow the null pointer for at it's end madness and chaos lie."