Exchanging Pictures To Generate Passwords 123
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.'"
Oh Dear (Score:3, Interesting)
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.
Re:Oh Dear (Score:5, Insightful)
It doesn't work like that. From what I can tell, it uses the image as a seed.
This is secure as long as that picture is kept secure and NOT given to anyone else, ever.
However, given the nature of humans, that's too tall an order. If that picture ever leaves the phone on where it was taken, the security is broken.
Re:Oh Dear (Score:5, Insightful)
Re: (Score:2, Interesting)
I can see the problem there. Since this requires people to be physically with each other to take the photo it will be such an inconvenience when trying to share stuff over the airwaves (as is the case with mobile networks, not so much for the limited range of Bluetooth) they will simply keep the photos on the phone.
Phones also have incredible amounts of storage these days meaning people don't care if they take a photo and leave it since it doesn't affect anything. This easily defeats the fancy new security
Roland Piquepaille has not proven trustworthy, IMO (Score:1, Interesting)
Re: (Score:2, Interesting)
Just let the devices make a picture of totally random crap and mix that with sound from the mic (anything it's pointed at when you hold it in your hand) and exchange it between devices. Then let the app on both phones exhcange it and hash it (the exact image is in pixels so there is no way one could ever make an exact copy of that picture and sound). This way it's just a purely random, pure text generator...
This way it's not any different from the current connecting proces somebody goes through when connect
Re: (Score:2)
As soon as you put it like that, the improvements suggest themselves. Just get the key from /dev/random, and if you want to use the camera's CCD as one of the feeds into your entropy pool, great.
Re: (Score:2)
Images as a seed (Score:5, Interesting)
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.
Re: (Score:1)
Re: (Score:1)
Well for somebody who doesn't claim to be an expert on encryption you've seem to throw out some 50 cent ideas about this...haha
Nothing is ever uncrackable...If a human thought it up...a human can crack it !!! With that being said we could start to let computers generate ideas about unbreakable encryption and never(as humans) know what they are doing. But then we may have to travel back in time to save John Connors one day !!!
Re: (Score:2, Insightful)
You would need still a copy of both photos to be able to decrypt the transmitted.
This assumes that the key-space used is large enough that a old fashioned brute-force isn't feasible.
Re:Oh Dear (Score:5, Informative)
No you've completely missed the point. Each user takes their own photograph of themselves. This never leaves their device. When a connection is to be setup the other user photographs them. There are now 4 photos in the set:
Alice's photo of Alice
Alice's photo of Bob
Bob's photo of Alice
Bob's photo of Bob
Each user now has a pair of images that should be similar (but are not the same). Alice has a photo of her and Bob, Bob has different photos of Alice and himself.
The images are hashed in some sense to generate a seed for the key. The assumption is that the image hash is robust enough that the two different images of Alice generate the same seed, and the same for Bob.
So if I now take a third pair of pictures, one of Alice and one of Bob, and the hash is robust then I can recompute their seed, and derive their key. As I said originally, it's some interesting vision work to come with a robust hash like that, but it is not actually secure.
If you still don't believe me, then reread the article and consider that the security of the system relies on Alice's picture never leaving her device. The same applies for Bob. To perform key agreement that means the same seed must be derived from the separate images.
Re: (Score:2)
Obvious flaw, is what happens when Bob and Alice are unable to take photos of eachother? If they transmit them to one another, then Eve has a change to read this image. Of course, they could also create an SSH tunnel, to transfer the keys, but.. that.. would.. be... ahh nevermind, I'm sure its been hashed out numerous times already on this thread
Re: (Score:2)
ATTFA the whole thing is based on a visual biometric program that "recognises" (ie generates the same partial key) people even when there are minor changes to their appearance. So if I take your picture and you take your picture (or a third party takes your picture) that part of the key formula is the same. If a third party takes both of our pictures within the right parameters (probably a close up full face shot or perhaps using our Drivers Licence, passport, or mugshot photo), they should have the same fu
Re:Oh Dear (Score:4, Funny)
Cameras can steal your passwords; Maybe theres some validity to what they say about cameras stealing your soul.
Re:Oh Dear (Score:5, Funny)
What if the photo is based on Bob or Alice's genitals?
For many people (fewer every year it seems), this would be a pretty good way to ensure a secret picture.
Re:Oh Dear (Score:5, Funny)
Re:Oh Dear (Score:5, Interesting)
Face pictures would be the public key and genitals ones the private one !
Problem solved. :))))))))))
Re: (Score:2)
Re:Oh Dear (Score:5, Insightful)
Every image is different, it has quite some randomness in it overall. I'm no cryptographer but can imagine that randomness is suitable to make keys.
What this unfortunately does not seem to address is the secure exchange of those keys. Making a very large secure random key and having a strong unbreakable encryption algorithm is one, exchanging those keys in a secure manner is another. Secure as in having no way of a third party listening in undetected, and getting the actual keys.
In this case the users have to take photos of themselves, and of each other: that indicates they have to be close together. Then the whole key exchange issue is trivial as it can be handed to the other party on a memory card or cable link or whatever. It is more interesting to be able to exchange those keys over a distance, over an insecure communication channel.
Re:Oh Dear (Score:5, Informative)
An image is random enough, but you can take a cryptographic hash of anything you want to - a password, a phone number, a song, an image, etc. How many ticks the processor has made in it's lifetime or the total value of all the bytes added up (modulus something) currently in memory will also be quite random, so the "using a picture" thing isn't really solving any problems. However, it does provide the basis of a framework that would allow you to move that picture (along with the one of yourself) to other devices in order to keep the shared secret key so you can continue to verify the person you're communicating with, since you can re-generate that key. Although there was nothing preventing you from just moving a keyfile in the first place. Don't forget - the more places the key is, the easier it will be for attackers to obtain.
As for the secure transmission of those keys - it's called the Diffie-Hellman Key Exchange [wikipedia.org] and it has been around for over 3 decades and remains unbroken. Alice and Bob communicate some numbers which allow them to generate the same key, but Eve has no way of generating the same number.
I also replied here [slashdot.org], so if you think this post is unclear, read there, too.
Re: (Score:1)
Secure as in having no way of a third party listening in undetected, and getting the actual keys.
if they are using PKE then they only need to know that the keys are not changed. it doesn't matter if the keys are simply overheard. the only keys transmitted are the public keys, which as their name suggests, are publishable.
You only need to worry about a man in the middle attack [wikipedia.org]. It doesn't matter if anybody else hears you. You only need to know that you have gotten the key that alice transmitted, and not eve's key.
Now, none of this may really matter. TFA is extremely thin on the details, but the way they
Just a variant of the one time pad (Score:2)
As you correctly point out, the clincher is transferring the keys in a secure manner. If you're face to face with the other person you may as well exchange memory cards containing 2 gigs of data to use as the keys. Wh
Re: (Score:1, Funny)
Re: (Score:2)
I agree with you, but see a flaw in your logic:
I would think the distance, white balance, color balance, etc. would all make a difference in the hashes generated. I mean, a difference of zoom levels on the two cameras, you taking a picture of "jane" from 4 inches away farther (or a quarter inch, depending on the resolution of the camera) could cause a completely different hash to be created (I would hope).
There is enough difference in each CCD or other type of camera to cause confusion in that...
Maybe not
Re: (Score:2)
Facial Biometric programs usually try measure a bunch of things in comparison to the size of your face like the proportional length of your nose, the proportional distance from the tip of your nose to the corners of your mouth, etc...
There are composition rules you have to go by to get it to work. Like looking straight into the camera and presenting a large enough amount of detail to be scanned.
Of course there are other things that could be measured, like complexion or eye color, or your bottom row of teeth
Re: (Score:2)
So, basically, they have taken what I said above to heart, and already "fixed" it.
Not really being into Biometrics, thanks for the input. Makes sense now, and I can see how it could work.
--Toll_Free
Standard problems? (Score:2)
Re: (Score:1)
biometrics ? (Score:1, Insightful)
so where does the bio part come in ? a picture isnt bio anything
then again this another crappy Roland article so its not suprising its short on facts and long on plagiarism
Re: (Score:2, Informative)
The quality of articles on /. is decreasing (Score:1)
Re:Been done before (Score:5, Funny)
and how they had to have this cyborg dolphin with cracking it...
so...if the dolphins go extinct....then it'll be secure?
Re: (Score:2)
or just hire a "canned tuna" company
Re: (Score:2)
I seem to remember this is how the 'password' for the encrypted information put into Johnny's head
Hmmm... I think I just figured out how to get my data through customs.
"and generates a security code" (Score:2)
and what if i eavesdrop that connection and duplicate that security code ?
Re:"and generates a security code" (Score:4, Interesting)
That's generally not an issue, as there are enough algorithms (such as the Diffie-Hellman Key Exchange [wikipedia.org]) 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.
Re: (Score:1)
However, if you can _intercept_ communications, and act like a man in the middle, then you can pretend to be Alice to Bob, while appearing to be Bob to Alice. Straight DH has no defence against this attack, you need a additional authentication stage.
issues?? (Score:1)
Re: (Score:1)
Re: (Score:2)
Crack (Score:3, Interesting)
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.
Re: (Score:2)
Crack: Eve takes a picture of Alice and Bob to get a picture pair (Alice+Bob) and constructs the same symmetric key.
Why wouldn't it have to be using the same pictures that Alice and Bob took of each other?
Re: (Score:3, Informative)
Re: (Score:2)
This process only works by handing over the exact image file that you are using as your ID. If they don't have that exact image file, it wouldn't work.
That's precisely what I meant. Alice and Bob don't even need to take pictures of eachother... they could just point and shoot in random directions, but there are clearly some convenience features inherent in using 'just taken' images of eachother.
Wrong (Score:1)
RTFA. who modded this informative? you should also RTFA.
from TFA:
...even if the user has altered his hair drastically, the system can still recognize him.
so this information IS the same if you take 100 pictures of the same person standing in the same place, or a different place, or if they cut their hair or put on a badge. the crack seems ludicrously easy.
Sadly TFA has extremely bare details. how did this become news on slashdot? I demand more details if I'm going to be bothered. Sometimes I think the admins put bad stories up just so that we can bitch about how bad they are.
Tags (Score:1)
Meh (Score:1)
This brings identity theft to a whole new level, its like how african villagers are afraid cameras will steal their soul.
No problem (Score:5, Insightful)
Mod up! Mod up! (Score:2)
Key change? (Score:1)
Option A: Hair cut.
Option B: New contact glasses
Option C: Facial surgery
This scheme seems to have the problem of biometric key schemes. As usual, how do you change a compromised key?
Re: (Score:2, Funny)
Easy, use a 12 gauge shotgun to randomize a new key.
Re: (Score:1)
Why am I... (Score:2, Interesting)
What is the difference... (Score:4, Insightful)
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.
Beside the point. (Score:2)
Exactly (Score:2)
* not for salacious reasons, but just because I know the crowd here (hey, it could be "laughed at", "or felt sorry for", etc.)
Haha (Score:2)
Re: (Score:1)
I think it can tell the difference between a 10-foot pole and the owner's palm, unless the owner is a pirate with a hook hand (which, according to the MAFIAA, has been on the rise lately).
Re: (Score:2)
...that is more-or-less what this does... generate a shared key for later communication.
Indeed. PhD worthy?
Addendum (Score:2)
Yeah, right.
This has all been done before. All it does is weaken any key that might have been generated in the first place, because rather
Re: (Score:1)
And what if... (Score:2)
Maybe such a thing would be acceptable for the FBI, but I would not touch one unless it were absolutely reliable. Not 98% of the time, or even 99. Maybe if it were 99.99% reliable... 4 nines.
Re: (Score:2)
I haven't really had time to study it, but as far as I can tell from the original paper (available as PDF from http://eprints.eemcs.utwente.nl/10783/ [utwente.nl]) this is a user-friendly mechanism for creating a session key for two parties who are in close proximity. The key isn't supposed to be permanent. The security is provided by the fact that the picture of the other party is obtained through a "side channel" (i.e., light rays and not the channel through which the actual data exchange takes place—e.g. blueto
Re: (Score:2)
It's going to rather embrassing when both users pick goatse for their photos.
And a terrible security hole!
(I'm talking about using a duplicate famous picture, you pervs)
Almost Unbreakable? (Score:3, Insightful)
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.
'Static' pic may work better (Score:1)
[ I didn't RTFA ...]
Having to match-up two different facial pics seems like a possible point of failure - Both for false-negatives and false-positives.
Either you have advanced facial-pattern software to generate a 'fingerprint' from the pic, or you do something along the lines of downsize to 32x32 pixels, convert to black and white and hope for a 85+% match.
It might work better if you have to take a picture of something that is 'more guaranteed' to be the same every time.
For instance, a snapshot of your Dri
Re: (Score:2)
> I didn't RTFA
You didn't miss anything. TFA is so content-free that it is impossible to tell what the hell this is about.
Twins??? (Score:2)
So... an identical twin, equipped with the technological veil of communications, can still break it? :D
Re: (Score:2)
I preferred shake to sync (Score:5, Interesting)
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.
Re: (Score:3, Informative)
Re: (Score:2)
Both phones take accelerometer measurements
One step closer to Steve Jobs plan to dominate the world with iPhones.
Re: (Score:2)
The problem is synchronizing the accelerometers and getting them to take the same measurements. They aren't the most precise things in the world, and if you dumb down the data enough to sync them, you lose a lot of the security.
Re: (Score:2)
Re: (Score:3, Insightful)
That'd be great, 'cept I don;t know of an easy way to cable together two iPhones, or two Blackberries, much less between two different models/manufacturers.
The shake and bake shared secret is a great idea because it requires no additional connectivity. In fact the two devices can have NO network connection, but share only similar readings during an agreed time-window.
Accelerometers are o
Re: (Score:2)
Re: (Score:1)
Then you have an excuse to ask her to come closer no? I'd be in the basement.
Security challenge!!!! (Score:5, Funny)
Just upload the following:
A picture of your highschool.
A picture of your first pet.
A picture of your first car.
Re: (Score:2)
"Dad! where's the shovel?"
And within 30 seconds on /. (Score:1, Offtopic)
... it's completely broken.
So, who's this Ph.D. candidate and her supervisor? Because, I want names. I want to know who to stay the hell away from with regards to security.
Sneakernet? (Score:1)
Sweet!! (Score:2)
Perhaps I'm missing something... (Score:2, Insightful)
Everybody missing what is important (Score:5, Funny)
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.
Re: (Score:3, Informative)
http://wwwhome.cs.utwente.nl/~balazsi/ [utwente.nl]
Re: (Score:2)
Hey, she's cute. I wonder if she would like to take advantage of a middle-aged American geek who has a weakness for Central European accents?
Re: (Score:1)
As an extra security layer (Score:2, Funny)
Doesn't Work (Score:1, Interesting)
Okay, the thing is that the connection is made based on a biometric analysis of the picture taken. It is not taking a picture simply as a seed---there are better sources of entropy than that. Alice takes a picture of Bob, this is analyzed biometrically on Alice's PDA, on the basis of which a key is constructed that is compared with the biometric data of Bob's picture of Bob on Bob's phone, and vice versa.
To break this, get a suitable picture of Alice and Bob and you're done. You can however make it secure b
Easy Problem (Score:1)
Manual key exchange between two people standing next to each other: So what?
Automated key exchange between people on different continents who have never met before: Now there's a problem!