Fingerprint Authentication

[Fredrik Lindberg]

Alin-Adrian Anton wrote:
> Fredrik Lindberg wrote:
>>
>> But that would sort of defeat the whole purpose of biometric 
>> authentication and you could really just use public keys instead
>> which would be a lot faster and easier than scanning your finger
>> at each login. :)
>>
> 
> Unless you locally encrypt your private key with information gathered by 
> the fingerprint reader, as a "password".
> 

That's exactly the problem with, at least, UPEKs driver. If you scan
one of your fingers twice you'll get two "different" BioAPI records.
That's "different" as in two binary data blobs which aren't equal.
To match these records with each other, you hand them over to the
driver which, as far as I know, hand them over to the hardware
which in turn performs some black magic and then tell you if
the records match or not.

This is actually the way BSP (Biometric Service Providers..uhh fancy
names) modules for BioAPI works.
The BSP "captures" a biometric record from somewhere (could be
hardware or it could be software), this opaque data is then used to
construct a BIR (BioAPI Record) which you store in some database.
This process is called "enrollment" in BioAPI-speak.

When you want to verify/match a record you let the BSP
"capture" a new record (and thus creating a new BIR), you now have
two BIRs which aren't bitwise equal and as they are created by a
third party module you have no idea of that they contain (except for
the BIR header). Then these two BIRs are handed over to the BSP module
again for the match process, which will return either a positive or
negative result.
In UPEKs case I was told by their representative that the matching
between two BIRs are done in hardware.

Fredrik Lindberg