[[!img Targus Defcon 1 Authenticator]

Introduction

The aes4000 driver supports devices based on the Authentec AES4000 chipset.

aes4000 is part of libfprint and is developed/maintained by Daniel Drake.

Supported devices

Right now I only know of a single device that uses this chip, the Targus Defcon 1 Authenticator.

Driver history

It doesn't seem to be the case any more, but I downloaded full device specifications from Authentec's website a few years ago. This driver was written based on the specs and analysing bus traffic from the Windows driver.

Device operation

This is an imaging device, which uses complex sensory electronics to detect variations in the surface of your finger - it doesn't use optics. It then presents image data to the computer but makes no attempt to interpret it - all image processing must be done in software. libfprint handles this internally.

The device offers many controls to customize the sensitivity of the fingerprint detection system, etc. Currently we just set these to sensible values and don't allow modification of them.

When ready to scan, the driver arms the scan trigger and waits indefinitely for data. The device will send fingerprint data as soon as the calibration characteristics are met - i.e. when it detects a finger on the scanner. As such, finger detection and capture is a composite operation.

Thanks to the device specifications (which are no longer available), the protocol is entirely understood, however there are some very technical details involved (capacitances of drive rings, etc!).

Security notes

The fingerprint is always sent unencrypted over the USB bus.

There is some kind of challenge and authentication scheme offered by the device, which is mentioned in the specs. Currently, aes4000 does not use such functionality, and I'm not even sure that the specs explain it enough to make an implementation possible.

Image info

The image resolution is 64x64 pixels. 8 different darkness levels are presented in the image, but with the current calibration settings we only seem to either get 0 (no finger material detected) or 7 (full darkness finger material detected).

Imaging performance

Currently, the imaging performance of this driver is not brilliant. It generally detects 10-20 minutiae for a good scan, whereas other devices detect 40+. As a result of having less minutiae points, the matching algorithm returns lower scores, meaning that we have to lower the match score threshold to get good matching results.

In comparison to other devices, extra care must be taken to get good scans, otherwise you'll be told that your fingerprints don't match when they actually do. Ensure that your finger is aligned straight with the device and that you press the same part of your finger onto the device each time. Make a conscious effort not to just scan the tip -- push your finger a little further forward than you might think necessary. Attempt to put your finger down fairly quickly - don't place it lightly and then increase pressure, because libfprint images your finger immediately and does not wait for you to increase the pressure.

Sometimes, bad images are returned where there is no finger data there at all, just a little bit of noise (this is a bug). Also, the imaging performed by this driver can be improved which would avoid that bug and potentially improve imaging performance.

Analysis of Windows driver traffic

The first image captured from the device is low quality (but has a strong distinction between foreground and background, potentially useful for edge detection). After capturing that image, the driver reads a histogram from the device and tweaks various registers on the device to increase image quality. It then takes another sample of the finger, tweaks again, samples again, etc. Samples 1, 2 and 14 from a scan are shown below to illustrate this.

[[!img http://www.reactivated.net/fprint/img/Aes4000_sample1.gif] [[!img http://www.reactivated.net/fprint/img/Aes4000_sample2.gif] [[!img http://www.reactivated.net/fprint/img/Aes4000_sample14.gif]

It seems to calibrate based on the image data that is being returned, and the histogram after sample #1. This is done dynamically - the changes made to the registers vary on each scan.

Right now, libfprint doesn't do the "sample #1" low quality scan, but dives right in and does a scan with registers configured like they were for sample #14 above. Of course, the register values should depend on finger pressure and image contrast and everything, but they currently do not.