Sun et al. describe a vulnerability in the Bluetooth protocol. In particular, they show that a part of the so-called secure simple pairing (SSP) process can be attacked in a man-in-the-middle scenario. SSP is used by newer Bluetooth devices that support NIST-recommended security mode 4. Moreover, the authors propose an improvement to the Bluetooth standard to circumvent the presented vulnerability.

The paper starts with an introduction to Bluetooth security, followed by an explanation of SSP in the second section. The authors’ attack is introduced in section 3 and a countermeasure is presented in section 4. The last section concludes the easy-to-understand and well-structured paper.

The purpose of SSP is to establish secure link-level communication between two Bluetooth devices, which is the fundamental security feature all higher communication levels take advantage of. Although SSP applies elliptic curve Diffie-Hellman (ECDH) key exchange, the authors argue that the protocol is vulnerable to man-in-the-middle attacks nevertheless due to the lack of a public-key infrastructure (PKI). The Bluetooth standard foresees different means to prevent such attacks; one is the passkey entry.

The authors demonstrate that man-in-the-middle attacks on passkey entry are feasible using two approaches that depend on stages 1 and 2 of the SSP process. In particular, the generation of random values (the passkey) is attacked in two different scenarios. Therefore, the authors take advantage of the fact that passkey values are not truly random and that they can be reused. In the first scenario, the attacker intercepts phase 1 of the SSP passkey entry process, in which public keys are exchanged. In the end, this allows the attacker to determine the passkey in the second stage and to attack the protocol as a man-in-the-middle when the passkey is reused. In the second scenario, the attacker takes advantage of the hosts that do not change the passkey until an SSP session is successfully completed. The attacker interrupts the SSP session during stage 2, which forces the devices to restart the SSP session. Then, the attacker computes the passkey in a bitwise fashion.

The proposed countermeasure addresses the limitations of previous work by other authors and additionally prevents the two presented attacks in a way that does not require additional cryptographic functionality. Instead the authors use cryptographic on-board functionality that is already part of Bluetooth to modify the first stages of SSP. A comparison of the authors’ improved protocol version with the original version shows only little overhead, rendering the proposed countermeasure applicable in practice.