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.'"

18 of 123 comments (clear)

  1. Re:Been done before by MoFoQ · · 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?

  2. Re:Oh Dear by arth1 · · Score: 4, 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.

  3. What is the difference... by Jane+Q.+Public · · Score: 3, Insightful

    ... 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.

  4. I preferred shake to sync by aj50 · · 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.

    --
    I wish to remain anomalous
  5. Re:Oh Dear by WarJolt · · Score: 3, Funny

    Cameras can steal your passwords; Maybe theres some validity to what they say about cameras stealing your soul.

  6. Re:Crack by gsgriffin · · Score: 3, Informative

    Still missing it. It has nothing to do with who is in the picture. It has to do with the actual data in the file that stores the image. Put a badge on a person in a photo and the data of the jpg file will change. You could take 20 pictures of the same person standing in the same spot, and you will come up with 20 different files (binary code in the jpg, that is). 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.

    --
    jsut athnoer menagiensls ltitle psrhae for you to dcoede. Why do we wtsae our tmie dnoig tihs?
  7. Re:"and generates a security code" by ASBands · · Score: 3, Interesting

    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.
  8. Re:Oh Dear by Anonymous Coward · · 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.

  9. Re:Oh Dear by wvmarle · · Score: 4, 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.

  10. Security challenge!!!! by gandhi_2 · · Score: 5, Funny
    If you "lose" your picture, you can always "reset" your picture or have it emailed to you.

    Just upload the following:

    A picture of your highschool.

    A picture of your first pet.

    A picture of your first car.

  11. Re:Oh Dear by wvmarle · · Score: 4, Insightful

    Take the pictures for this purpose only and then delete them after making the keys, problem solved.

  12. Re:Oh Dear by QRDeNameland · · Score: 4, Funny

    Would that be pornometrics?

    --
    Momentarily, the need for the construction of new light will no longer exist.
  13. Re:Oh Dear by ASBands · · Score: 4, 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 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, so if you think this post is unclear, read there, too.

    --
    My UID is a prime number. Yeah, I planned that.
  14. Images as a seed by jd · · Score: 4, Interesting
    That is a fairly poor way of generating a seed. I don't claim to be an expert on encryption (but you can call me one if you like), but I would use one of several different approaches, depending on the situation and the compute power available.

    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)
  15. Everybody missing what is important by rossz · · 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.

    --
    -- Will program for bandwidth
  16. Re:Oh Dear by yvesdandoy · · Score: 5, Interesting

    Face pictures would be the public key and genitals ones the private one !

    Problem solved. :))))))))))

  17. Re:Oh Dear by smallfries · · Score: 4, 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.

    --
    Slashdot: where don knuth is an idiot because he cant grasp the awesome power of php