Summary of a paper on Bluetooth MITM attacks

Made a short summary for a paper on Bluetooth MITM attacks, you can read the whole paper here (pdf).

TL;DR: Bluetooth MITM attacks are possible. Most important threat is through jamming (for newer versions of Bluetooth at least). The main solution the paper proposes is not relevant for our usecase (I think). But the problem caused by the jamming can be solved by users that are aware of the situation, which we can enforce by having them go through a more complicated authentication process.

...This makes RF communication easier to use than wired or infrared communication, but it also makes eavesdropping easier. Moreover, it is easier to disrupt and jam wireless RF communication than wired communication...

So if we feel the need to, we should protect against eavesdropping

...In Bluetooth versions up to 2.0+EDR, pairing is based exclusively on the fact that both devices share the same Personal Identiﬁcation Number (PIN) or passkey ... It has been shown that MITM attacks on Bluetooth communications (versions up to 2.0+EDR) can be performed...

Older versions (4.x is in most newer divices, the Samsung Galaxy S8 is the first phone with 5.0 source) of bluetooth rely solely on PIN/password. It has been proven to be vulnerable to MITM attacks

...Bluetooth versions 2.1+EDR (Enhanced Data Rate) and 3.0+HS (High Speed) add a new speciﬁcation for the pairing procedure, namely Secure Simple Pairing (SSP) ... protection against passive eavesdropping and Man-in-the-Middle attack (MITM) attacks...

Newer Bluetooth versions (2.1, 3.0) use SSP to protect against passive eavesdropping (listening only). SSP uses Elliptic Curve Diﬃe-Hellman public-key cryptography, which is currently considered safe.

...However, it has been shown that MITM attacks against Bluetooth 2.1+EDR and 3.0+HS devices are also possible...

Basicly, SSP provides different levels of security, attacker can force weak version on victem devices.

Connection mode	Possibility of MITM attack
SSP with Just Works	Yes
SSP-OOB	No
SSP numeric comparison, both devices IO	No
Impersenation without input/output	Yes
Jam in PHY	Yes
Using RF fingerprints as keys	No
By adding an additional window at the user interface level	No

...Finally, a frustrated user thinks that something is wrong with his/her Bluetooth devices and deletes previously stored link keys. After that the user initiates a new pairing process by using SSP, and the MITM can forge messages exchanged during the I/O capabilities exchange phase by pretending as legitimate user...

This is related to the PHY jamming, users may remove existing paired devices and initiate a new pairing process with the attacker. At this point the attacker has full access.

This jamming seems to be the most dangerous one for our usecase (and I think it also applies to the newer versions of Bluetooth, i.e. 4.0 or higher). The main practical solution proposed is enforcing the use of SSP-OOB. OOB (Out Of Bound) basically means authenticating over different channel than standard Bluetooth, which doesn't really apply to our project I think.

Some counter measures are proposed in the paper. Adding a challenge-response type verification isn't one of them though. However I think that adding an additional challenge-response type verification can be helpful. This is because the problem is caused by the victim having to reconnect and possibly reconnecting with the attacker, and having the additional verification should make it less likely the victim actually pairs with the attacker.

ericcornelissen / NervousFish

Summary of a paper on Bluetooth MITM attacks #80