Bluetooth Hacking

Bluetooth is a wireless technology that enables any electrical device to wirelessly communicate in the 2.5 GHz ISM (license free) frequency band. It allows devices such as mobile phones, headsets, PDA's and portable computers to communicate and send data to each other without the need for wires or cables to link to devices together. It has been specifically designed as a low cost, low power, radio technology, which is particularly suited to the short range Personal Area Network (PAN) application. (It is the design focus on low cost, low size and low power, which distinguishes it from the IEEE 802.11 wireless LAN technology).
The Main Features of Bluetooth:
- Operates in the 2.4GHz frequency band without a license for wireless communication.
- Real-time data transfer usually possible between 10-100m.
- Close proximity not required as with infrared data (IrDA) communication devices as Bluetooth doesn't suffer from interference from obstacles such as walls.
- Supports both point-to-point wireless connections without cables between mobile phones and personal computers, as well as point-to-multipoint connections to enable ad hoc local wireless networks.
- It uses unlicensed ISM (Industrial, Scientific and Medical) band, 2400 - 2483.5 MHz, Modulation - Gaussian frequency shift keying,. Frequency Hopping Spread Spectrum - 1600 hops/sec, amongst 79 channels, spaced at 1 MHz separation.

When and How was it Conceived?
Bluetooth was originally conceived by Ericsson in 1994, when they began a study to examine alternatives to cables that linked mobile phone accessories.
Where did the Name Come From?
Bluetooth was named after Herald Blatand (or Bluetooth), a tenth century Danish Viking king who had united and controlled large parts of Scandinavia which are today Denmark and Norway. The name was chosen to highlight the potential of the technology to unify the telecommunications and computing industries
SIG Membership?
Since its original foundation, the Bluetooth SIG has transitioned into a not-for-profit trade association, Bluetooth SIG, Inc. Membership is open to all companies wishing to develop, market and promote Bluetooth products at two levels - Associate and Adopter Members.
Bluetooth Security
1 The Bluetooth pairing & authentication process
The Bluetooth initialization procedures consist of 3 or 4 steps:
1. Creation of an initialization key (Kinit).
2. Creation of a link key (Kab).
3. Authentication.
After the 3 pairing steps are completed, the devices can derive an encryption key to hide all future communication in an optional fourth step.
Before the pairing process can begin, the PIN code must be entered into both Bluetooth devices. Note that in some devices (like wireless earphones) the PIN is fixed and cannot be changed. In such cases, the fixed PIN is entered into the peer device. If two devices have a fixed PIN, they cannot be paired, and therefore cannot communicate. In the following sections we go into the details of the steps of the pairing process.

1 Creation of Kinit
The Kinit key is created using the E22 algorithm, whose inputs are:
1. a BD_ADDR.
2. the PIN code and its length.
3. a 128 bit random number IN_RAND.
This algorithm outputs a 128-bit word, which is referred to as the initialization key (Kinit).
Figure 1 describes how Kinit is generated using E22. Note that the PIN code is available at both Bluetooth devices, and the 128 bit IN_RAND is transmitted in plaintext. As for the BD_ADDR: if one of the devices has a fixed PIN, they use the BD_ADDR of the peer device. If both have a variable PIN, they use the PIN of the slave device that receives the IN_RAND. In Figure 1, if both devices have a variable PIN, BD_ADDRB shall be used. The Bluetooth device address can be obtained via an inquiry routine by a device. This is usually done before connection establishment begins
This initialization key (Kinit) is used only during the pairing process. Upon the creation of the link key (Kab), the Kinit key is discarded.

Figure 1: Generation of Kinit using E22

2.1.2 Creation of Kab
After creating the initialization key, the devices create the link key Kab. The devices use the initialization key to exchange two new 128 bit random words, known as LK_RANDA and LK_RANDB. Each device selects a random 128 bit word and sends it to the other device after bitwise xoring it with Kinit. Since both devices know Kinit, each device now holds both random numbers LK_RANDA and LK_RANDB. Using the E21 algorithm, both devices create the link key Kab. The inputs of E21 algorithm are:
1. a BD_ADDR.
2. The 128 bit random number LK_RAND.
Note that E21 is used twice is each device, with two sets of inputs. Figure 2 describes how the link key Kab is created.

Figure 2: Generation of Kab using E21

2.1.3 Mutual authentication
Upon creation of the link key Kab, mutual authentication is performed. This process is based on a challenge-response scheme. One of the devices, the verifier, randomizes and sends (in plaintext) a 128 bit word called AU_RANDA. The other device, the claimant, calculates a 32 bit word called SRES using an algorithm E1. The claimant sends the 32 bit SRES word as a reply to the verifier, who verifies (by performing the same calculations) the response word. If the response word is successful, the verifier and the claimant change roles and repeat the entire process. Figure 3 describes the process of mutual authentication. The inputs to E1 are:
1. The random word AU_RANDA.
2. The link key Kab.
3. Its own Bluetooth device address (BD_ADDRB).
Note that as a side effect of the authentication process, both peers calculate a 96 bit word called ACO. This word is optionally used during the creation of the encryption key. The creation of this encryption key exceeds our primary discussion and shall not be described in this paper.

Figure 3: Mutual authentication process using E1

2.2 Bluetooth cryptographic primitives
As we described above, the Bluetooth pairing and authentication process uses three algorithms: E22, E21, E1. All of these algorithms are based on the SAFER+ cipher with some modifications. Here we describe features of SAFER+ that are relevant to our attack.

2.2.1 Description of SAFER+
SAFER+ is a block cipher with a block size of 128 bits and three different key lengths: 128, 192 and 256 bits. Bluetooth uses SAFER+ with 128 bit key length. In this mode, SAFER+ consists of:
1. KSA - A key scheduling algorithm that produces 17 different 128-bit subkeys.
2. 8 identical rounds.
3. An output transformation - which is implemented as a xor between the output of the last round and the last subkey.
Figure 4 describes the inner design of SAFER+, as it is used in Bluetooth.

Figure 4: Inner design of SAFER+
The key scheduling algorithm (KSA)
The key scheduling algorithm used in SAFER+ produces 17 different 128-bit subkeys, denoted K1 to K17. Each SAFER+ round uses 2 subkeys, and the last key is used in the SAFER+ output transformation. The important details for our discussion are that in each step of the KSA, each byte is cyclic-rotated left by 3 bit positions, and 16 bytes (out of 17) are selected for the output subkey. In addition, a 128 bit bias vector, different in each step, is added to the selected output bytes.
The SAFER+ Round
As depicted, SAFER+ consists of 8 identical rounds. Each round calculates a 128 bit word out of two subkeys and a 128 bit input word from the previous round.
3 Bluetooth PIN Cracking


3.1 The Basic Attack:

Table 1: List of messages sent during the pairing and authentication process. ``A'' and ``B'' denote the two Bluetooth devices.
# Src Dst Data Length Notes
1 A B IN_RAND 128 bit plaintext
2 A B LK_RANDA 128 bit XORed with Kinit
3 B A LK_RANDB 128 bit XORed with Kinit
4 A B AU_RANDA 128 bit plaintext
5 B A SRES 32 bit plaintext
6 B A AU_RANDB 128 bit plaintext
7 A B SRES 32 bit plaintext


Assume that the attacker eavesdropped on an entire pairing and authentication process, and saved all the messages (see Table 1). The attacker can now use a brute force algorithm to find the PIN used. The attacker enumerates all possible values of the PIN. Knowing IN_RAND and the BD_ADDR, the attacker runs E22 with those inputs and the guessed PIN, and finds a hypothesis for Kinit. The attacker can now use this hypothesis of the initialization key, to decode messages 2 and 3. Messages 2 and 3 contain enough information to perform the calculation of the link key Kab, giving the attacker a hypothesis of Kab. The attacker now uses the data in the last 4 messages to test the hypothesis: Using Kab and the transmitted AU_RANDA (message 4), the attacker calculates SRES and compares it to the data of message 5. If necessary, the attacker can use the value of messages 6 and 7 to re-verify the hypothesis Kab until the correct PIN is found. Figure 6 describes the entire process of PIN cracking.
Note that the attack, as described, is only fully successful against PIN values of under 64 bits. If the PIN is longer, then with high probability there will be multiple PIN candidates, since the two SRES values only provide 64 bits of data to test against. A 64 bit PIN is equivalent to a 19 decimal digits PIN.


Figure 6: The Basic Attack Structure.


4 The Re-Pairing attack

4.1 Background and motivation
This section describes an additional attack on Bluetooth devices that is useful when used in conjunction with the primary attack described in Section 3. Recall that the primary attack is only applicable if the attacker has eavesdropped on the entire process of pairing and authentication. This is a major limitation since the pairing process is rarely repeated. Once the link key Kab is created, each Bluetooth device stores it for possible future communication with the peer device. If at a later point in time the device initiates communication with the same peer - the stored link key is used and the pairing process is skipped. Our second attack exploits the connection establishment protocol to force the communicating devices to repeat the pairing process. This allows the attacker to record all the messages and crack the PIN using the primary attack described in this paper.

4.2 Attack details
Assume that two Bluetooth devices that have already been paired before now intend to establish communication again. This means that they don't need to create the link key Kab again, since they have already created and stored it before. They proceed directly to the Authentication phase (Recall Figure 3). We describe three different methods that can be used to force the devices to repeat the pairing process. The efficiency of each method depends on the implementation of the Bluetooth core in the device under attack. These methods appear in order of efficiency:
1. Since the devices skipped the pairing process and proceeded directly to the Authentication phase, the master device sends the slave an AU_RAND message, and expects the SRES message in return. Note that Bluetooth specifications allow a Bluetooth device to forget a link key. In such a case, the slave sends an LMP_not_accepted message in return, to let the master know it has forgotten the link key. Therefore, after the master device has sent the AU_RAND message to the slave, the attacker injects a LMP_not_accepted message toward the master. The master will be convinced that the slave has lost the link key and pairing will be restarted. Restarting the pairing procedure causes the master to discard the link key. This assures pairing must be done before devices can authenticate again.
2. At the beginning of the Authentication phase, the master device is supposed to send the AU_RAND to the slave. If before doing so, the attacker injects a IN_RAND message toward the slave, the slave device will be convinced the master has lost the link key and pairing is restarted. This will cause the connection establishment to restart.
3. During the Authentication phase, the master device sends the slave an AU_RAND message, and expects a SRES message in return. If, after the master has sent the AU_RAND message, an attacker injects a random SRES message toward the master, this will cause the Authentication phase to restart, and repeated attempts will be made. At some point, after a certain number of failed authentication attempts, the master device is expected to declare that the authentication procedure has failed (implementation dependent) and initiate pairing.
4. The three methods described above cause one of the devices to discard its link key. This assures the pairing process will occur during the next connection establishment, so the attacker will be able to eavesdrop on the entire process, and use the method described in Section 3 to crack the PIN.
In order to make the attack ``online'', the attacker can save all the messages transferred between the devices after the pairing is complete. After breaking the PIN (0.06-0.3 sec for a 4 digit PIN), the attacker can decode the saved messages, and continue to eavesdrop and decode the communication on the fly. Since Bluetooth supports a bit rate of 1 Megabit per second, a 40KB buffer is more than enough for the common case of a 4 digit PIN.
Notes:
1. The Bluetooth specification does allow devices to forget link keys and to require repeating the pairing process. This fact makes the re-pairing attack applicable.
2. Re-Pairing is an active attack, that requires the attacker to inject a specific message at a precise point in the protocol. This is most likely needs a custom Bluetooth device since off-the-shelf components will be unable to support such behavior.
3. If the slave device verifies that the message it receives is from the correct BD_ADDR, then the attack requires the injected message to have its source BD_ADDR ``spoofed'' - again requiring custom hardware.
4. If the attack is successful, the Bluetooth user will need to enter the PIN again - so a suspicious user may realize that his Bluetooth device is under attack and refuse to enter the PIN.
5 Countermeasures
This section details the countermeasures one should consider when using a Bluetooth device. These countermeasures will reduce the probability of being subjected to both attacks and the vulnerability to these attacks.

1. Since Bluetooth is a wireless technology, it is very difficult to avoid Bluetooth signals from leaking outside the desired boundaries. Therefore, one should follow the recommendation in the Bluetooth standard and refrain from entering the PIN into the Bluetooth device for pairing as much as possible. This reduces the risk of an attacker eavesdropping on the pairing process and finding the PIN used.
Most Bluetooth devices save the link key (Kab) in non-volatile memory for future use. This way, when the same Bluetooth devices wish to communicate again, they use the stored link key. However, there is another mode of work, which requires entering the PIN into both devices every time they wish to communicate, even if they have already been paired before. This mode gives a false sense of security! Starting the pairing process every time increases the probability of an attacker eavesdropping on the messages transferred. We suggest not to use this mode of work.
2. Finally, the PIN length ranges from 8 to 128 bits. Most manufacturers use a 4 digit PIN and supply it with the device. Obviously, customers should demand the ability to use longer PINs.
3.Instead of passing messages in plain text, they should be encoded before transmission.

The Future of Bluetooth
The next version of Bluetooth, currently code named Lisbon, includes a number of features to increase security, usability and value of Bluetooth. The following features are defined:
- Atomic Encryption Change
- Extended Inquiry Response
- Sniff Subrating QoS Improvements
- Simple Pairing
Types of attacks in Bluetooth
The SNARF attack:
It is possible, on some makes of device, to connect to the device without alerting the owner of the target device of the request, and gain access to restricted portions of the stored data therein, including the entire phonebook (and any images or other data associated with the entries), calendar, realtime clock, business card, properties, change log, IMEI (International Mobile Equipment Identity [6], which uniquely identifies the phone to the mobile network, and is used in illegal phone 'cloning'). This is normally only possible if the device is in "discoverable" or "visible" mode, but there are tools available on the Internet that allow even this safety net to be bypassed.
The BACKDOOR attack:
The backdoor attack involves establishing a trust relationship through the "pairing" mechanism, but ensuring that it no longer appears in the target's register of paired devices. In this way, unless the owner is actually observing their device at the precise moment a connection is established. Device grants access to services. This means that not only can data be retrieved from the phone, but other services, such as modems or Internet, WAP and GPRS gateways may be accessed without the owner's knowledge or consent. Indications are that once the backdoor is installed, the above SNARF attack will function on devices that previously denied access, and without the restrictions of a plain SNARF attack, so we strongly suspect that the other services will prove to be available also.
The BLUEBUG attack:
The bluebug attack creates a serial profile connection to the device, thereby giving full access to the AT command set, which can then be exploited using standard off the shelf tools, such as PPP for networking and gnokii for messaging, contact management, diverts and initiating calls. With this facility, it is possible to use the phone to initiate calls to premium rate numbers, send sms messages, read sms messages, connect to data services such as the Internet, and even monitor conversations in the vicinity of the phone. This latter is done via a voice call over the GSM network, so the listening post can be anywhere in the world. Bluetooth access is only required for a few seconds in order to set up the call. Call forwarding diverts can be set up, allowing the owner's incoming calls to be intercepted, either to provide a channel for calls to more expensive destinations, or for identity theft by impersonation of the victim.
Scanning for Bluetooth addresses
The Bluetooth address itself is a unique 48bit device identifier, where the first 3 bytes of the address are assigned to a specific manufacturer by the IEEE (www.ieee.org/), and the last 3 bytes are freely allocated by the manufacturer. For example, the hexadecimal representation of a Sony Ericsson P900 phone's Bluetooth address may look like 00:0A:D9:EB:66:C7, where the first 3 bytes of this address (00:0A:D9) are registered to Sony Ericsson by the IEEE, meaning that all P900 phones will have their Bluetooth address starting with same 3 bytes. The last 3 bytes (EB:66:C7) of the sample address are assigned to this device by Sony Ericsson and should be different for each P900 phone -- but is not always, unfortunately.
In theory, enabling the non-discoverable mode on a Bluetooth device should protect users from unauthorized connections, yet in practice it is still quite possible to find these devices. There are software tools available which allow brute-force discovery of non-discoverable devices. An example of such an application is RedFang by Ollie Whitehouse, a small application which simply tries to connect to a unique Bluetooth address one by one, until finally a hidden device answers the request sent that was sent to that particular address. Author's initial test is a minimum of 6 seconds to achieve a good level of accuracy (it varies from 2.5 to 10 seconds, on average). It is certainly possible to find a hidden device in less than 3 seconds, The address space used by Sony Ericsson has 16,777,216 possible addresses. If we assume 6 seconds are required per device, the total scan would take us 1165 days, meaning we would need more than 3 years to discover all hidden Sony Ericsson phones in a conference room.
Conclusion:
With the advancement of digital convergence on M-commerce, usuage of bluetooth in connecting different devices is going to be significant. But to make communication more secure advancement in the prospect of security must not be neglected.