Hashing Out the Next Step in Biometric Security

ergo98 writes "CNN is running a story about biometric hashing. Using this technique, biometric inputs (such as facial characteristics) are altered based upon individual characteristics in a hopefully one-way process. The goal is to continue to reduce the risk of a back-end data exposure."

Comments

Biometric Encryption

[bitkid]

That sounds pretty old. Ever heard of Biometric encryption? The idea is to use a one-way hash on the biometrics, but also accounting for the fuzzy-ness in the reading. If the readings match, then the same hash comes out. Otherwise something random. See here...

• http://cervisia.org/biometrics_encryption.php
• http://www.rsasecurity.com/rsalabs/staff/bios/ajue ls/publications/fuzzy-vault/fuzzy_vault.pdf
• http://www.bioscrypt.com/

Isn't there a -1, WRONG?

[Spy der Mann]

Dude, you MUST study basic cryptography. Even MD5 is one way. Sure, you can guess WHICH strings can produce a determinate hash. But of those thousands (maybe millions) of combinations, can you really guess which one was ACTUALLY used?

Anyway, the RSA is constantly working on getting better and better hashes. We got SHA-256, SHA-512 and SHA-1024. And these are way more advanced than SHA1.

Unless of course, you're running quantum cryptography.

Anyway, all it has to be done to create a "virtually unbreakable" hash is to make it large enough so that it can't be "cracked", so to speak. When SHA-2 collisions are found, we'll have SHA-3 and its variants, which will probably be 2048, 4096, 8192 bits... and so on.

Re:Isn't there a -1, WRONG?

[Mathinker]

Although I agree that the GP seems pretty clueless with respect to basic cryptography, as you say, I have to correct you and the numerous following posters about the "irreversibility" of cryptographic hash functions.

It is true that theoretically, these functions map an infinite domain of messages into hashes and therefore every hash has an infinite number of possible pre-images. This theoretical irreversibility is dependent on any random string being considered a possible pre-image.

In practice, if one hashes a message with very little entropy, e.g., an English ASCII message is known to have 2+ bits of information/byte so given a 128-bit hash one would expect to be able to be able to find only O(1) English ASCII pre-images of lengths up to 512 bytes (rounding 2+ down to 2). If the message were to additionally be known to include a signature by a known public key using a 160-bit hash function you could then invert messages whose English text was up to 1152 bytes long!

Your "solution" for making "virtually unbreakable hash" functions just makes this problem much worse. And the idea that you seem to espouse, that just making a hash "large enough" is going to make it useful cryptographically is just ridiculous.

The first thing that should be taught in a "basic cryptography" course is that doing cryptography right is hard. Read the "Beware of Snake Oil" section Phil Zimmerman wrote in the manual for PGP 2.6.2...

(Oh, one more thing --- you should beware of throwing around buzzwords like "RSA" and "quantum cryptography" until you check out what they really mean --- or at least check your typing)

More Misdirection from the Biometric Community

[tiny69]

Biometrics is one mechanism for authentication. The three mechanisms for authentication are generally grouped into, something you know (password), something you have (swipe card), and something you are (biometrics). If either of the first two become compromised, they can be changed. Biometric features on your body cannot be changed. This is the major flaw behind biometrics. So the biometric community periodically playes games with the data on the backend hoping to misdirect the users away from the major flaw. "See, we hash your data, so it's secure...."

A story that is still relavent whenever biometrics is brought up:

http://www.hindustantimes.com/news/7242_1301216,00 180008.htm

Re:Compromises?

[Achromus]

RTFA. If you do, you'll see that IBM describes a technique for making "cancellable biometrics", in which companies can alter the way the hash is distorted. If the hash is compromised, the company could change the distortion applied to the face, and obtain a new hash.

This isn't a hash, it's a salt

[Anonymous Coward]

Combine your data plus each provider's own distortion = password plus salt.

And for a reason

[melted]

Crooks aren't that smart. After Mercedes implemented fingerprint readers in some of their cars, there were several reports that some owners got their fingers cut off by thieves. These fingers, of course, could not start the car (no self-respecting fingerprint reader relies on fingerprint alone anymore), but that was not much of a relief for folks whose fingers got cut off.

Vender Lock-in for Questionable benefit

[logicnazi]

I find it interesting that IBM choose to distort the date in their biometric scanners before storage. Since the type of distortion is likely to be secret, proprietary, or just plain difficult to duplicate it effectively locks in any organization into the IBM scanners. Since their system database would only contain IBMs hashes of biometric data buying even one none IBM scanner would require rescanning every user.

Now perhaps I am jumping to conclusions and IBM has implemented some kind of removable card interface for hashing but I find that doubtful. Moreover, hashing biometric data is of questionable benefit in any case. Most biometric data is more easily collectable by simple investagatory techniques (covert photography, dusting for prints) than reconstructing a face from the security data. Moreover, since biometric characteristics are necessarily unchangeable potential hackers could merely use the data from some other less secure biometric security system one of your users also uses. Heck, creating a fake biometric id system and using social engineering to get someone to use it would be way easier than reversing these hashes.

Furthermore designing a secure hash to accomodate the inexact nature of biometric identification seems difficult. By it's very nature a secure hash cannot be guaranteed to map similar inputs to similar hashs. Thus either the hash will be insecure, the system too prone to false negatives to be usefull, or the biometric data must first be rounded to exact values (or for borderline cases just hash both possible ways to round). Yet a rounding scheme which avoids too many false negatives will significantly reduce the 'password' space.

In a normal system the sensor would report all the biometric measurments to the authorization server which would compare the measurements to the stored measurements and see if they are sufficently close to an authorized user. Since a secure hash can't be 'close enough' the measurements must be rounded sufficently to always give the same value for the same user. The net result will be a reduction, not increase, in security. I actually suspect IBM isn't using a secure hash in the cryptographic sense.

A more promising option in my opinion would be to implement a distinct algorithm in the sensor to check that the person had normal human features. Thus even if a hacker steals the biometric info and attempts to produce a fake he must not only duplicate those particular measurements but incorporate them into an image/texture which is otherwise human normal. Since these two algorithms can use different information it would be difficult to defeat. Furthermore since the human detection can be isolated in the sensor no vendor incompatibility issues arise and the algorithm can even be upgraded.