Slashdot Mirror
Exchanging Pictures To Generate Passwords
Roland Piquepaille writes "Today, Ileana Buhan, a Romanian computer scientist, is presenting her PhD Thesis at the University of Twente in the Netherlands. She is using biometrics to protect confidential information when it is exchanged between two mobile devices. This is a very innovative approach to security. Buhan's biometric application will generate almost unbreakable passwords from photos taken by the connected users. Here is how it works. 'To do this, two users need to save their own photos on their PDAs. They then take photos of each other. The PDA compares the two photos and generates a security code for making a safe connection.'"
This sounds like interesting work as I'm sure that the hashing of the photos to generate the passwords is quite interesting research. But from the summary (on the uni site) the work is quite flawed as a security measure. If I see Alice and Bob taking pictures of each other in order to establish a secure link then all I need to do is photograph them both covertly and I can regenerate their password.
Slashdot: where don knuth is an idiot because he cant grasp the awesome power of php
and how they had to have this cyborg dolphin with cracking it...
so...if the dolphins go extinct....then it'll be secure?
Procedure: Alica and Bob have their own picture stored on their own phone. They each take a picture of the other so each has a picture pair (Alice+Bob) and construct a symmetric key from the picture pair.
Crack: Eve takes a picture of Alice and Bob to get a picture pair (Alice+Bob) and constructs the same symmetric key.
And since Ms. Ileana Buhan is on Facebook, we have her photo along with her friends...say 'cheese!'
Why am I reminded of the recently invented Japanese cigarette machine, which used a camera and image analysis software to determine if the user is old enough to buy the cigs. Of course, it was easily defeated by simply holding up a picture of grandma in front of the camera.
... between this, and simply generating a shared key? Honestly, I don't see any difference. In effect, that is more-or-less what this does... generate a shared key for later communication. Big deal. It doesn't matter whether it is "biometric" at all... other than the fact that so far "biometric" data has been far easier to fool.
And the "SecureGrip" project is a joke. In order for anyone in their right mind to stake their life on a biometric security device for their gun, it would have to reject others almost perfectly, and accept the legitimate owner infallibly... the latter being the more important of the two by far.
We are nowhere near that kind of perfection. I wouldn't touch something that uses even the most recent versions of "SecureGrip" with a 10-foot pole, much less pay money for it.
Why is that? If using random hashes make a password unbreakable then what's the ground breaking part of this? It's been known for decades that you need a very good random hash (and importance is proven with recent Debian comment-out code including gpg tools).
This application has some 'cool factor' since it would make your shoot pictures of your friends in order to protect your 'important' communication between them, but real problem in here is not hashing, it is password generation algorithm. If it has weaknesses your random hash (ie. salt) won't make it any secure. And also how applications reach/use this password is another factor.
Biometrics have a good 'cool factor' but they indeed put other problems into security. As other posters mentioned you can shoot picture of Alice and Bob, considering it uses facial information, you can mimic it. It is like you could get finger prints left on some fingerprint scanners. Besides libraries using those biometric data need to a lot more time to be proven as secure than textual password algorithm we use today.
I might be a conservative about this but I still believe that even though biometrics can put some additional security, they still need to be harvested with memorized (ie. textual or verbal) passwords. If you don't harvest them, then you add possible attack vector of biometric data encoder to underlying authentication stack code as well.
Easy, use a 12 gauge shotgun to randomize a new key.
I preferred the shake to sync method where two phones would be held together and shaken randomly. Both phones take accelerometer measurements and use the pattern they were shaken in as a shared secret.
I wish to remain anomalous
Biometrics is using something about you, your person, to measure or provide unique indentity. This is as much a biometric as a thumb scanner.
jsut athnoer menagiensls ltitle psrhae for you to dcoede. Why do we wtsae our tmie dnoig tihs?
That's generally not an issue, as there are enough algorithms (such as the Diffie-Hellman Key Exchange) which can generate a secret shared key. These processes can be done at any time, over any channel and require transmitting around a kilobyte of information between Alice and Bob. Since this can be done at any time, what is the point of taking the pictures? Most of the key-agreement protocols are anonymous, so there is no good way to verify that Bob is actually Bob, which is what this intends to solve.
So, two users get together and associate the key which they make at the time with the photos they take of each other. The photos become the out-of-band channel that links Alice and Bob and allows for some level of authentication. This is basically a simpler solution to the key distribution problem we've already experienced with RSA - one that doesn't require a company like Verisign or a complicated "web of trust" solution. Alice trusts that Bob is Bob because Alice associated this shared secret key when she saw him AND she can see his picture when she receives the communication.
Potential hacks? Since we're talking about mobile phones, the retrieval of the shared secret key would be almost trivial if we came into contact with the device. Even if it's not, we can associate Bob's photo with someone else and masquerade as Bob. What if we don't have possession of the device? Well, then the vulnerabilities are the same as any other symmetric-key encryption system...and AES has yet to be broken.
My UID is a prime number. Yeah, I planned that.
Just upload the following:
A picture of your highschool.
A picture of your first pet.
A picture of your first car.
THL phish sticks
Using biometrics means the actual pics need not be exchanged, but would they have to be taken from the same angle? Also, wouldn't an app sophisticated enough to do this accurately tax the limited memory of most mobile devices? As to security, assuming the would-be eavesdropper could tell that the salt was biometrically derived AND both knew and had access to pics of the people communicating, why would they bother to go through the trouble of cracking the encryption just to find out that so-and-so was seen necking with what's-his-name at a party?
The most exciting phrase to hear in science, the one that heralds new discoveries, is not 'Eureka!' but 'That's funny...
One option would be to assume that the two images are a pair of asymmetric keys, given some shared asymmetric encryption function which is derived once the two images are uploaded. It doesn't matter, then, if either image (but not both) falls into the hands of someone wanting to break the encryption - without knowing the function used, having what is effectively a private key for one side of the communication won't help.
A second option is to just use them as seeds for generating key pairs and instead of trading images, use an established method for key exchange to copy the keys across.
Thirdly, you could generate completely random key pairs, then use the photographs as part of the encryption mode between blocks. (This would go back to needing the photographs shared, but even if both photographs were obtained by someone, it wouldn't help them much in decrypting any message.)
Fourthly, you could generate a digital signature, where the signature assumes the image is appended to the message, with the signature as the first part of the encrypted message. This adds a little to the authentication, but also as the signature is non-deterministic, it makes those decryption techniques which involve some sort of pattern analysis of the encrypted data much less useful - you don't know where the text starts.
Next, you could use different slices of the images to pre-generate different keypairs. You could then specify a key by specifying the offset into the image. A variant of that is to pre-generate keys randomly and use the image content at a given offset as a pointer into the key table.
Lastly, you could prepend the message with the image, use a compression algorithm and then encrypt the compressed data. The reason for compressing is that it hides patterns in the data still visible when encrypted. By prepending the image, you absolutely drown out any possibility of residual information that could be used.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
It looks like everybody is missing the most important part of this article. The computer geek in question is a SHE!!!1!!!!~
We need photos.
-- Will program for bandwidth
It might be a good idea to take a picture of Bob and Alice shaking hands, to be certain the handshake is secured, too. If there's proof the handshake really took place, you know you're connected to who you're supposed to be connecting with!