Date: Fri, 05 May 2006 21:15:44 +0300 From: Alin-Adrian Anton <aanton@spintech.ro> To: Fredrik Lindberg <fli+freebsd-hackers@shapeshifter.se> Cc: freebsd-hackers@freebsd.org, Cesar <listas@itm.net.br> Subject: Re: Fingerprint Authentication Message-ID: <445B9650.50009@spintech.ro> In-Reply-To: <445B59EE.6040701@shapeshifter.se> 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> <445B59EE.6040701@shapeshifter.se>
next in thread | previous in thread | raw e-mail | index | archive | help
Fredrik Lindberg wrote: > 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. > In that case, it means the "matching" is a proabilistic distance-computing algorithm. This sux, for any sort of real remote logins. -- Alin-Adrian Anton GPG keyID 0x183087BA (B129 E8F4 7B34 15A9 0785 2F7C 5823 ABA0 1830 87BA) gpg --keyserver pgp.mit.edu --recv-keys 0x183087BA "It is dangerous to be right when the government is wrong." - Voltaire
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?445B9650.50009>