2

When trying to pair 2 bluetooth LE devices (e.g. 2 iPhones), a popup shows up that requires to input a code displayed on the other device. I am aware of the concept of out-of-band authentication, and why it is necessary.

  1. Device A generates a code.
  2. Device A requests Device B to enter the code.
  3. Device B shows a popup to the user.
  4. Device B sends the entered code to Device A.
  5. Device A compares the received code to the previously generated code.

However, I am trying to answer these questions:

  • How is the code calculated in the first place? From a keypair?
  • Isn't sending the code from device B to device A subject to a passive MITM attack? How is this communication authenticated?
  • Beware when you say Out of Band. This term is used in the Bluetooth Specification to define one of the association models. The one you explained is named Passkey Entry. – Yuriko Mar 8 '16 at 11:10
1

The idea behind this is that the code generated by Device A must be transmitted separately to Device B. Any method of communication will do: email, text message, phone call, etc.

To answer your questions:

How is the code calculated in the first place? From a keypair?

This depends on the software of the device. Some vendors will generate a random 4 digit pin. Some will generate a passcode. It's up to the vendor how they wish to generate it, and how much entropy they want to have. TeamViewer uses this same type of method for its remote desktop software. They allow the user to choose the length, and type of passcode. Using a key-pair to generate passcodes seems like overkill, and they're most likely using some type of pseudo-random number generator.

Isn't sending the code from device B to device A subject to a passive MITM attack? How is this communication authenticated?

This depends on how/if the communication is secured. It's possible that a secure protocol is used to encrypt the communication between the devices. This could be a standardized protocol like SSL/TLS, or it could be proprietary. As long as the communication is secured in some way the passcode would be sent encrypted to the device, and would be less likely to be subject to a MitM attack.

If the passcode is sent in the clear for everyone to see, then yes I would say a MitM attack is very possible.

  • Thanks a lot, great answer. Do you know how the 2 devices can make sure that they both have the same code? – desktop Nov 17 '14 at 13:57
  • The one that generates the code most likely keeps it in memory until it receives a connection request. Compares the one received to the one in memory. – RoraΖ Nov 17 '14 at 14:03
  • If I get it correctly - BLE does NOT dictate how the code is sent from B to A? – domen Nov 17 '14 at 14:37
  • BLE dictates how two devices should communicate. The passcode is something that I'm guessing iPhone itself has added as a feature. – RoraΖ Nov 17 '14 at 14:54
2

Bluetooth 4.0 pairing depends on both devices agreeing to the same 128-bit "temporary key". In most practical cases the key is generated (zero-extended) from a passkey. According to the spec, the passkey is generated pseudo-randomly.

(all quotes from https://www.bluetooth.com/specifications/adopted-specifications)

The Passkey Entry STK generation method uses 6 numeric digits passed out of band by the user between the devices. A 6 digit numeric randomly generated passkey achieves approximately 20 bits of entropy.

The specification also determines which device generates (and displays) the key and which one expects user input.

The bluetooth pairing protocol uses a "bit commitment" scheme, designed to prevent MitM attacks. Basically, both devices exchange a "confirm value" based on multiple parameters including the temporary key (passcode) and a private random number. The private random number is disclosed at a later stage, proving that the device indeed had known the passcode at the beginning of the process.

The passkey Entry method provides protection against active “man-in-the-middle” (MITM) attacks as an active man-in-the-middle will succeed with a probability of 0.000001 on each invocation of the method.

The scheme was found to be fundamentally flawed, allowing an active MITM attacker to determine the passkey on-the-fly and pretend that it was known before pairing. A detailed description of the flaw can be found here: https://eprint.iacr.org/2013/309.pdf.

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.