Device A Attacker Device B
eavesdrop on following traffic DH public key: P Kax DH public key: P Kbx Simple pairing confirm: Cai Simple pairing confirm: Cbi Simple pairing number: N ai
Passkey accepted Simple pairing number: N bi
Passkey accepted 20x
Figure 5.2: Eavesdropping on Passkey Entry to Obtain the PIN
While the Passkey Entry method was designed to be secure against man-in-the- middle attacks, this does not hold if the the same passkey is used again after the first attempt to pair two devices failed. In the next section we describe this attack in detail.
5.2
Background to Attacking Passkey Entry
In the following, we describe the theoretical man-in-the-middle attack on the Blue- tooth Passkey Entry method as presented in [99]. For the attack to work, the attacker only needs to be able to control the radio channel between two Bluetooth devices, and needs to be in possession of a device capable of communicating on the Bluetooth channels. The attacker does not require access to the memory of the devices or manipulation of the devices in any form.
5.2.1 Outline of the Attack
The attack targets the Secure Simple Pairing protocol in Bluetooth Version 2.1 and higher when Passkey Entry is used in authentication stage 1. The attack works if the PIN is reused in a second attempt to pair two devices after the first attempt has failed. This is naturally the case if one of the devices uses a fixed PIN. But even if this is not the case and the user chooses the PIN and enters them on both devices, it seems plausible to assume that the user will reuse the same PIN when his first attempt to pair the two devices has failed just a few minutes ago.
The attack consists of two major steps: At first, the attacker eavesdrops on an SSP process between two legitimate devices as shown in Figure 5.2 and records all messages exchanged during the initial DH-exchange and authentication stage 1. After recording Na20, the attacker interrupts the SSP session by jamming the
148 Chapter 5. Excursus: Attacking Bluetooth 2.1+ in Passkey Entry Mode
wireless channel. Because of a design weakness in Passkey Entry, the attacker is now able to calculate the PIN that was used in the legitimate pairing process. Second, when the devices initiate a new pairing process and the PIN is reused, the attacker uses it to impersonate device A to device B and vice versa. By acting as a man-in-the-middle on the Diffie-Hellman key agreement, the attacker is able to negotiate link keys with each of the devices and can authenticate using the PIN. The attacker is now able to forward the data sent between two Bluetooth devices such that they appear to function normally. The attacker can eavesdrop on the commu- nication between the two devices, can manipulate the data exchanged, and insert new traffic. As the link key is reused for authentication of all future connections, the attacker is additionally able to impersonate one device to the other even in the absence of the second device.
In the following we detail the steps of this attack.
5.2.2 Obtaining the PIN
During the legitimate pairing process the attacker records the initial DH key ex- change, i.e., PKax and PKbx and the Passkey Entry exchange, i.e., twenty Nai/Nbi and Cai/Cbi values each for a total of 82 values.
Recall that the commitments Cai and Cbi are calculated by the legitimate devices for every single bit rai and rbi of the PIN, as described in Section 5.1:
Device A: Cai = f 1(P Kax, P Kbx, N ai, rai) Device B: Cbi = f 1(P Kbx, P Kax, N bi, rbi)
f 1 is a cryptographic hash function. All values in this equation are available to
the attacker, except for the individual bits of the PIN rai (by device A) and rbi (by device B). Therefore, the attacker can deduce rai and rbi by „brute forcing“ if they are 0 or 1 by calculating f 1 on the known input and on both potential values of the PIN bits. Thus, the attacker can easily determine the PIN as soon as he has received Na20. If the attacker was unable to correctly receive all information from both parties, he still has a chance to calculate the correct PIN by calculating either rai or rbi for each i, because rai = rbi when the same PIN is entered on both devices, which should be true in a legitimate pairing attempt. The attacker is now in possession of the PIN used in the legitimate pairing run.
5.2.3 Using the PIN
To profit from knowledge of the PIN, the attacker has to prevent that the legitimate pairing process succeeds. This can be done by jamming the communication channel after Na20 was received by the attacker. Also, instead of jamming the connection, the attacker could manipulate Na20 or Nb20 on the air, so that the verification by B or A will fail. The attacker then has to initiate a new connection to the honest devices. As shown in Figure 5.3, the attacker can now impersonate A to B (noted
5.2. Background to Attacking Passkey Entry 149
Device A MITM B‘ MITM A‘ Device B
DH public key: P Kax DH public key: P Ka‘x
DH public key: P Kbx DH public key: P Kb‘x
Simple pairing confirm: Cai Simple pairing confirm: Ca‘i
Simple pairing confirm: Cbi Simple pairing confirm: Cb‘i
Simple pairing number: N ai Simple pairing number: N a‘i
Passkey accepted Passkey accepted
Simple pairing number: N bi Simple pairing number: N b‘i
Passkey accepted Passkey accepted
20x
Figure 5.3: Man-in-the-Middle Attack on Passkey Entry Reusing the PIN
A‘) and B to A (noted B‘) using his own Diffie-Hellman values and reusing the PIN. As a consequence, the attacker will share a link key with device A and (another) link key with device B. Note that the devices will accept new DH values from previously known devices as the Bluetooth standard explicitly states that „a device may, at any time, choose to discard its public-private key pair and generate a new one“ ([12] vol. 2, p. 889).
When the attack was successful, the attacker will forward the data from A to B and back. The attacker is then able to eavesdrop on and manipulate the data sent between the two Bluetooth devices, although they appear to function normally.
5.2.4 Countermeasures
When users are able to enter the PIN on both devices, the users can avoid this attack by not using the same PIN twice. However, changes to the behavior of Bluetooth devices or even changes to the Bluetooth standard would mitigate the reused PIN attack even when the user is not aware that such an attack exists. We will now describe two such changes.
A Stopgap Solution
The Bluetooth standard explicitly demands freshly chosen nonces each time the protocol is repeated in the Numeric Comparison method (see [12] vol. 2 p. 891), but fails to demand a fresh PIN each time the Passkey Entry method is run. In fact, the standard gives no requirements about the PIN other that it has six digits („from 000000 to 999999”) (see [12] vol. 1, p. 60) and that it may be generated by a pseudo- random number generator (see [12] vol. 2, p. 857). There is no minimum length, and no guidelines how and when to choose the PIN.
150 Chapter 5. Excursus: Attacking Bluetooth 2.1+ in Passkey Entry Mode
We suggest that devices that display a PIN that the user has to enter on the other devices do not use a fixed PIN and always choose the PIN using a good random number generator. User generated PINs should be verified by devices to be at least 20 bit with 1 as the most significant bit, and devices should not accept the same PIN twice in Passkey Entry mode. The Bluetooth standard could easily be updated to include these guidelines without breaking compatibility to existing devices, unless they use a fixed PIN.
Fixing Authentication Stage 1 Passkey Entry
The DH key exchange is run directly before the vulnerable authentication stage 1. It results in an unauthentic key DHkey shared between the parties which know the corresponding private DH parameters. So far, the DHkey is only used in authenti- cation stage 2 and the following link key calculation, but not in authentication stage 1 with Passkey Entry. We suggest that this DHkey should be used in authenti- cation phase 1 when Passkey Entry is used. Transmitting N ai/N bi only encrypted with DHkey would prevent the attack discussed in this chapter. A passive observer could not decrypt N ai/N bi, and thus could no longer determine the PIN in a pas- sive attack. Adding this change to a new Bluetooth specification would remove the reused-PIN vulnerability for new Bluetooth devices connecting to each other. However, guessing a fixed PIN would still be possible with an average of ten at- tempts, as described by Lindell [99]. While this is obviously much more suspicious for the user than two attempts, this is still a threat for automatically re-pairing devices. Therefore, the above suggestions about choosing the PIN should also be followed.
Using a standardized proven secure password authenticated key agreement protocol, e.g., the IEEE P1363.2 BPKAS-SPEKE Protocol as described in Section 4.3.4, would solve these issues completely, including the linearization attack on the PIN described by Lindell [99]. However, such a change would be harder to implement compared to the above suggestions, as it requires significant changes to the implementations of the Bluetooth protocol.
5.2.5 Passkey Entry with Fixed PIN vs. Just Works
The security provided by Passkey Entry when used with a fixed PIN is the same as that of Just Works: Active attackers will always succeed, and the devices cannot prevent or detect the attack. However, the attack on Passkey entry requires two runs of the pairing protocol, while the attack on Just Works requires only one.
5.3. Related Work 151
5.3
Related Work
5.3.1 Attacks on Bluetooth
Bluetooth 1.1 was the first major release. Bluetooth 1.2 was an update, and current versions are still compatible to it. Bluetooth 2.0 added Enhanced Data Rate (EDR). All these versions use the same insecure pairing process, which is examined in [84, 95, 138].
Bluetooth 2.1 introduced a new security architecture called Secure Simple Pairing, so the old attacks do not work anymore. Lindell [99] described an attack on the Passkey Entry pairing method that we implemented in this chapter. No implementation of the attack was done. Lindell also proposed a fix of the protocol: Encrypting the whole authentication stage 1 using DHkey. We created an implementation of the attack and suggest a different fix to prevent the attack in Section 5.2.4.
The Numeric Comparison pairing method was proven secure in [100].
While Secure Simple Pairing is meant to provide protection against downgrading attacks where an attacker replaces the capabilities for user input of the legitimate devices, it does not resist a man-in-the-middle-attack when the attacking device only supports the Just Works method as described by Hypp¨onen [78]. Both legitimate devices will pair to the attacker without requiring authentication. The attack is called a no-input-no-output-attack, or NINO in short, because of the user input capabilities of the attacking device. NINO attacks can be detected because no user input is required for the pairing, and the legitimate devices know that the connection is not authentic. Therefore, it can be considered as an attack on the way how the security of Bluetooth connections is presented to the user in common devices. To the best of our knowledge, the NINO attack was not implemented so far.
5.3.2 General Tools for Bluetooth Analysis
There are many tools for general purpose Bluetooth analysis. We evaluated them regarding their applicability for attacking Passkey Entry, i.e., recovering the PIN from an observed pairing or acting as man-in-the-middle during a live Passkey Entry pairing session.
USB Protocol Analyzers (software or hardware) can be used to analyze the data exchanged between a consumer Bluetooth USB dongle and the PC. However, it does not help in attacking Secure Simple Pairing, since the pairing itself is executed on the dongle and not in the Bluetooth driver on the computer. The same applies to analysis of a Bluetooth driver within the operating system.
The Frontline FTS4BT [17] is a commercial closed-source wireless analysis tool in USB dongle format that comes with a proprietary Windows software. It is designed for companies developing Bluetooth products. It allows monitoring of Bluetooth channels and sniffing of packets. Apparently, it is possible to manipulate certain regular consumer Bluetooth dongles to make them work with the commercial wireless analysis software of Frontline [115]. However, a pairing process cannot be monitored.
152 Chapter 5. Excursus: Attacking Bluetooth 2.1+ in Passkey Entry Mode
GR-Bluetooth [140] was created by Spill and Ossmann in 2009 as a GNU Radio implementation of the Bluetooth baseband layer. It is intended for experimentation and teaching, but it does not include a complete software stack. Sniffing on packets is supported, but there is no frequency hopping. We did not reuse any code from this project.
None of these tools facilitate recovering the PIN during the Passkey Entry pairing because they cannot be used to capture packets exchanged by other stations during their pairing process.
Ubertooth One [19] is an open-source ARM Cortex-M3 processor-based USB dongle with a CC2400 wireless transceiver. It supports Bluetooth monitoring mode, which is the equivalent to Wi-Fi promiscuous mode, allowing the user to observe traffic and read data sent over the air. Ubertooth One supports the basic data rate of 1 Mbit/s, but currently no packet injection or attacks on pairing, although it could be possible with later revisions. The target audience of Ubertooth One are technically interested persons.