Date: Fri, 05 May 2006 15:58:06 +0200 From: Fredrik Lindberg <fli+freebsd-hackers@shapeshifter.se> To: aanton@spintech.ro Cc: freebsd-hackers@freebsd.org, Cesar <listas@itm.net.br> Subject: Re: Fingerprint Authentication Message-ID: <445B59EE.6040701@shapeshifter.se> In-Reply-To: <445B544D.5070107@spintech.ro> References: <00fb01c66fb2$a8e157c0$0501010a@ironman> <445A5F48.60303@spintech.ro> <200605051009.49344.doconnor@gsoft.com.au> <445AF8AB.9080008@shapeshifter.se> <445B35EA.5080009@spintech.ro> <445B48E6.3070000@shapeshifter.se> <445B544D.5070107@spintech.ro>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?445B59EE.6040701>