4

In the "official" Bluetooth blog, they talk about the BLE pairing mechanism, and how during phase 2 (authentication) the exchange of keys are used to protect against MITM attacks. I don't see how that is possible.

If the attacker creates a device (dx) that sits between BLE device 1 (d1) and BLE device 2 (d2), and simply passes everything through, then as d1 and d2 are exchanging keys, dx is invisible to d1 and d2. After pairing, dx can monitor communications and then, when it decides to attack, it can prevent some packets from getting through, and replay packets it saw previously (all without ever decrypting the packets).

How does BLE pairing, or specifically exchanging keys, have any impact on this?

Betty Crokker
  • 155
  • 1
  • 8
  • haven't checked whether Bluetooth 4.0 uses that, but are you aware of mechanisms like Diffie-Hellman? With those, you can establish a common secret without transporting anything compromising over a public channel. Problem solved. – Marcus Müller Feb 20 '17 at 22:36
  • Yes, there are various mechanisms I could use instead of what BLE provides, but without understanding why BLE did things the way they did, and how their various security features work together, I could be opening up a big security hole without realizing it. – Betty Crokker Feb 21 '17 at 15:20
  • @MarcusMüller Bluetooth 4.2 uses Diffie-Hellman (ECDH), but that's only protecting the connection from passive attacks. To be protected against man-in-the-middle attacks you also need authentication (e.g. provided by numeric comparison in BLE secure connections). So, problem not solved only using DH. – DrP3pp3r Feb 06 '20 at 14:04

1 Answers1

2

From the Bluetooth Sig Proprietary Information Security :

Signed Data Bluetooth with its low energy features supports the ability to send authenticated data over an unencrypted transport between two devices with a trusted relationship. This means that in some circumstances where the communication channel is not encrypted, the device could still have a method to maintain and ensure the data authentication. This is accomplished by signing the data with a CSRK. The sending devices place a signature after the Data Protocal Data Unit (PDU). The receiving device verifies the signature and, if the signature is verified, the Data PDU is assumed to come from the trusted source. The signature is composed of a Message Authentication Code generated by the signing algorithm and a counter. The counter is used to protect against a replay attack and is incremented on each signed Data PDU sent.

During the pairing mechanism, both device generates a random sequence number. Sequence number (counter) is incremented on each pach packet. They are usefull to re-order packets if they are not received in the right one, but they are also usefull against replay attacks.

For example, (d1) and (d2) are pairing. (d1) has choosen a random sequence number, 123456 and send "hi" to (d2). (dx) intercept it. (dx) can try 2 things :

  • Replay the packet with sequence number 123456, in this case, it will be rejected by (d2) because sequence number should be superior than the last one (depending of the protocol, it must be previous_sequence_number+1 or previous_sequence_number+previous_message_length) .

  • Replay the packet with sequence number 123457, in this case, the signature will be invalid and the message will be rejected.

Xavier59
  • 2,874
  • 3
  • 17
  • 34
  • 1
    Interesting ... OK, but in your scenario, what if (dx) just sends the packet on to (d2), and then waits for the response from (d2) and sends it back to (d1)? (dx) is then sitting there in the middle, but I guess the only thing it can do is cause packets to not get through? – Betty Crokker Feb 21 '17 at 16:24
  • When they talk about MitM attacks, is the focus on replaying or injecting packets, rather than just being annoying and preventing packets from getting through? – Betty Crokker Feb 21 '17 at 16:33
  • Yes, the only thing (dx) can do is dropping packet to prevent (d1) and (d2) from communicate. About the focus, from BLE security : _A MITM requires an attacker to have the ability to **both monitor and alter or inject messages** into a communication channel._ – Xavier59 Feb 21 '17 at 16:38
  • Gotcha! Can you comment on the connection between PINs and keys? I don't understand how having a longer PIN can have any impact on MitM attacks. Maybe I should start a new question for that ... – Betty Crokker Feb 21 '17 at 16:50
  • 1
    http://security.stackexchange.com/questions/151918/bluetooth-low-energy-relationship-between-pins-and-man-in-the-middle-attacks – Betty Crokker Feb 21 '17 at 17:29