3

I need to implement secure pairing between two devices based on a short shared PIN code with no trusted third party. If you think about the way bluetooth devices pair you won't be far off -- my device displays a code, I tell you, "the code is 40YA," you type it in on your device and we've got a secure connection.

The protocol should protect against MITM and eavesdropping attacks, and the PIN needs to stay valid and secure for at least a few hours. In other words, if an offline attack on the PIN is possible it should require at least a few hours to complete.

Does such a protocol exist? Bonus points if a reasonably bright non-cryptographer can understand it. :)

Update: Is Diffie-Hellman key exchange what I'm looking for?

Improve this question
4

David's answer and further research has led me to the EKE (Encrypted Key Exchange) protocol described by Bellovin & Merritt here:

https://www.cs.columbia.edu/~smb/papers/neke.pdf

and by Wikipedia here:

http://en.wikipedia.org/wiki/Encrypted_key_exchange

EKE is specifically designed for this sort of task -- amplifying a short shared password into a fully secure link. The protocol was patented but the patent expired in 2011. There is now an RFC for using EKE with EAP:

http://tools.ietf.org/html/rfc6124

Improve this answer
1
  • +1 That's what should be used for easy Wifi setup! – curiousguy Jun 30 '12 at 2:14
1

  1. One end generates a random challenge and broadcasts it to the other side.

  2. One side displays a random PIN, the other prompts for the PIN.

  3. The hash of the challenge combined with the PIN is then used as an encryption key for the next message (which is also HMAC protected, just like SSL). The side that prompted for the PIN sends a "connected" message encrypted with the hash and containing a random nonce. The other side replies with an acceptance.

  4. Further communications are encrypted with the nonce.

No MITM attack is possible because if the MITM doesn't tamper with the data, he doesn't know the key, and so can't change any data without corrupting the protocol but if he does tamper with the data, he won't have the correct connected message to send.

The side that sends the challenge can store it and keep it valid for as long as desired. No offline attack is possible because the challenge contains no PIN data and the response is based on the random nonce which an offline attacker could not know.

Improve this answer
5
  • 1
    Thanks for the reply. Maybe I'm misunderstanding, but can't you do an offline attack against the PIN based on the message in step 3? The derived key looks like Hash(Challenge + PIN), you know the challenge, and the PIN is fairly short. Just brute force until you decrypt the message and you've found the PIN. – n8gray Jun 28 '12 at 17:02
  • How would you know when you've decrypted it correctly? You don't know what the random nonce is and that's all the message contains. – David Schwartz Jun 28 '12 at 19:41
  • 1
    Ah, I see. I thought you were saying to encrypt the string "connected" with a key based on the challenge and PIN. (It's hard to understand textual protocol descriptions.)This looks similar to EKE but without using Diffie-Hellman key exchange. One disadvantage here is that if an attacker records the traffic and somehow gets access to the PIN later they can decrypt the entire conversation. – n8gray Jun 28 '12 at 21:32
  • @n8gray: Unfortunately though, this does point out the problem with doing this: It's complicated enough that it's not realistic to try to do it. You'd be much better off just picking a scheme that's been tested and evaluated professionally. – David Schwartz Jun 28 '12 at 21:34
  • That's exactly why I asked the question here -- to learn about existing approaches instead of trying to roll my own. Thankfully your answer and some other research has led me to investigate EKE, which looks like a pretty solid solution. – n8gray Jun 28 '12 at 21:42
1

I would closely follow Bluetooth > v2.1 here. Meaning that you have the following stages:

  1. Unauthenticated Diffie-Hellman key exchange between your two devices. After the DHE is finished, each device computes a (cryptographically secure) hash function over the shared DH key. This hash can then be called "PIN" or whatever, but it is not secret information!

  2. One device now displays the hash, and you can either compare it to the hash on the other device yourself, or you enter the hash on the other device and the device compares.

  3. Either way, if the hash does not match on both sides you abort the pairing run.

What is nice about this approach is that it does not require any secret information, either in-band or out-of-band. Also, the relatively weak security of a short PIN (aka hash) is only relevant during the short pairing process itself. So, an attacker would have to perform an active MiTM during the DH key-exchange and find Diffie Hellman parameters which, together with Alice and Bobs parameters, hash to the same value. Since he will likely only control one of the initial Diffie Hellman values (the one where he initiates the exchange), it might not even be possible.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.