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?

Improve this question
3
  • 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, 2017 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, 2017 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 6, 2020 at 14:04

1 Answer 1

Reset to default
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.

Improve this answer
5
  • 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, 2017 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, 2017 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, 2017 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, 2017 at 16:50
  • 1
    security.stackexchange.com/questions/151918/…
    – Betty Crokker
    Feb 21, 2017 at 17:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .