By Christoph Wegener and Marcel Holtmann
Bluetooth has seen an incredible rise in popularity since its introduction in 1998. Today, Bluetooth technologies play a part in connecting cellphones, headsets, printers, PC mice, or even access points. Retailers even offer Bluetooth TV adapters that let you transmit images, multimedia messages (MMS), or MP3s to your TV set.
Owners of Bluetooth devices use their mobile phones and PDAs confidently, often without much thought to how to protect their data and identity, and yet, like any wireless technology, Bluetooth is intentionally designed to initiate and receive connections from other devices within the broadcast range, and built-in safeguards like encryption and authentication are surprisingly less than perfect.
This article describes some common attack techniques and shows how the Bluetooth 2.1 specification [1] is attempting to meet the challenge of Bluetooth security.
In asynchronous mode, Bluetooth devices have a maximum bandwidth of 723.2Kbps in one direction and 57.6Kbps in the other. In synchronous mode, they achieve 433.9Kbps in both directions. The Bluetooth 2.0 specification was the first to introduce Enhanced Data Rate (EDR), thus boosting the maximum data rate to 3MBps. The range that Bluetooth devices achieve depends on their transmitter power and is defined by the specs: Class 3 devices are allowed to transmit at a maximum of 1mW and thus have a range of 10 meters; 100mW devices (class 1) can transmit over a maximum distance of 100 meters. Bluetooth Version 2.1 is now available: Although the specification itself is from mid 2007, it took until 2008 to manufacture the first devices that supported it. The theoretical range as defined in the specifications does not impose an absolute limit on the device. An attacker with the right technology can target Bluetooth devices at ranges of several hundred meters (up to 1.2km); and even standard devices typically have a de facto range of about 40 meters.
The Bluetooth protocol model is shown in Figure 1. The Link Manager layer sits on top of the Bluetooth Radio and Baseband layers, which handle the physical wireless transmission of the data. The Link Manager layer is responsible for connection management and also provides the cryptographic security mechanisms for authentication and encryption. The SAFER+ algorithm, a 128-bit block cipher used by Bluetooth, is implemented in this layer.
The Host Controller Interface (HCI) sits on top of the Link Manager and separates the low-level layers from the protocol layer. The Bluetooth Special Interest Group (SIG) defines application profiles to improve interoperability. Besides basic services such as the Generic Access Profile (GAP), the Serial Port Profile (SPP), or the Dialup Networking Profile (DUN), there is a Headset Profile (HSP), and many more. The profiles are not part of the Bluetooth specifications (or core).
The connection process uses inquiries and paging. A Bluetooth device issues an inquiry to find out if there are any other Bluetooth devices in its range. This procedure returns the addresses and timing of any devices it discovers. In the paging request that then follows, a communication channel to one of these devices is opened. The device that opens the connection becomes the master and the other device is the slave.
After connecting, the master defines a hopping sequence, which in turn defines a piconet - an ad hoc mini-network of two or more Bluetooth devices. Piconets always connect exactly one master with up to seven active slaves. Besides the active slaves, passive slaves (parked devices) can also exist. The number of slaves is restricted by the amount of memory available on the Bluetooth chip. Today's chips typically support seven slaves, irrespective of whether they are actively involved in the piconet.
Just like any wireless networking technique, Bluetooth comes with some risk of traffic sniffing or man-in-the-middle attacks. Note that - in contrast to wireless LAN connections - Bluetooth provides no communication between devices until they have been integrated with a piconet. A Bluetooth device without an active connection thus does not transmit data, making it more difficult for an attacker to target a victim.
The specification also defines cryptographic security mechanisms to secure communications between the Link Manager and protocol stack. These mechanisms are provided by the HCI and are based on link keys. In Bluetooth 2.0, they are 128-bit combination keys, which are typically only used for a link between two specific devices. The devices store the keys as connection keys. The keys comprise the device addresses and a secret, random number that must be transferred securely. For this to happen, each device uses another (public) random number, the device address, and a PIN of up to 16 bytes. The PIN is either entered by the user or preconfigured, which is typically the case with headsets. The consequence of this approach is that two devices with different, fixed PINs will be unable to link up.
If two devices want to use encryption, they first need to mutually authenticate and generate a link key. This procedure is known as pairing, and it requires a PIN code. Once a link key has been generated, it is fine to use it for any following authentication. Encryption is always an option when at least one device has authenticated against the other. Encryption is based on a stream cipher known as E0; however, encryption is optional, which is one of the weaknesses of the Bluetooth specification.
Thanks to the BlueZ Linux Bluetooth stack, Bluetooth attacks are easy to trace without investing in an expensive protocol analyzer; instead, Linux users can turn to the hcidump tool. hcidump logs and analyzes the data from HCI upwards in the stack (Figure 1). Having said this, you will need detailed knowledge of the Bluetooth protocols to understand what you have discovered.
Pairing occurs at Link Manager level using cryptographic methods to perform authentication and encryption. These methods are hard-coded in the hardware, and there is no way of modifying them for the host stack (BlueZ in this case). The host stack simply has to pass in the PIN to the Link Manager and then store the link key for any further authentication. Both of these transactions are handled by the HCI using commands and events.
In the hcidump example shown in Listing 1 you can see how a connection is established. The connection requires pairing, and the PIN used here is 1234. Although you can see the PIN in hcidump, it is not transmitted in the clear. After checking the PIN, the Link Manager generates the link key and hands it on to the host stack. This authentication should occur before the connecting device gains access; however, some connections do without this kind of authentication.
For instance, the Bluetooth standard provides a means for RS-232 serial port emulation using the RFCOMM protocol. For certain RFCOMM channels, the phone is not asked for a PIN or the Link Key. Armed with this knowledge, an intruder can often use RFCOMM to open a connection without authentication.
| Listing 1: hcidump |
01 # hcidump -X -V1 02 < HCI Command: Create Connection (0x01|0x0005) plen 13 03 bdaddr 00:0E:6D:10:11:C6 ptype 0xcc18 rswitch0x01 clkoffset 0x0000 04 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 05 HCI Event: Command Status (0x0f) plen 4 06 Create Connection (0x01|0x0005) status 0x00 ncmd 1 07 HCI Event: PIN Code Request (0x16) plen 6 08 bdaddr 00:0E:6D:10:11:C6 09 10 < HCI Command: PIN Code Request Reply (0x01|0x000d) plen 23 11 bdaddr 00:0E:6D:10:11:C6 len 4 pin '1234' 12 HCI Event: Command Complete (0x0e) plen 10 13 PIN Code Request Reply (0x01|0x000d) ncmd 1 14 status 0x00 bdaddr 00:0E:6D:10:11:C6 15 HCI Event: Link Key Notification (0x18) plen 23 16 bdaddr 00:0E:6D:10:11:C6 key D869FD6A03D997162D8971D8E587A89B type 0 17 HCI Event: Connect Complete (0x03) plen 11 18 status 0x00 handle 42 bdaddr 00:0E:6D:10:11:C6 type ACL encrypt 0x00 |
Many Bluetooth security problems are not a direct result of the technology itself, but of buggy implementations of it. Several attack techniques have developed around the technique of circumventing the pairing process (as described in the preceding section).
Several attack methods have appeared in the wild. The best known exploits for Bluetooth devices are BlueJack, BlueSnarf, and BlueBug. BlueJacking involves sending messages to a cellphone; this is a technique that some people use to get to know people (and also known as "Toothing").
BlueSnarfing contains the word "snarf", which you may be familiar with as a term for making an unauthorized copy of something. This exploit type downloads data from a cellphone, such as a phone book or calendar, images, or even the IMEI number that identifies the phone on the mobile network. This information gives the attacker the ability to create a perfect clone of the phone and thus unlock stolen or locked phones.
Finally, BlueBugging gives the attacker full access to the cellphone's AT commands and thus the ability to send and receive text or email - and even the power to use the phone for making calls. The AT command set [6], which was originally developed for Hayes modems in the 1970s, is a system of short, text string commands that direct the process of initiating, terminating, and negotiating parameters for phone-based connections. AT commands are still supported on Bluetooth-based phones, and an intruder with sufficient access can use the AT command set to obtain data and send commands to a Bluetooth device.
Beyond these better known attacks are a number of lesser known exploits such as HeloMoto, BlueSmack, BlueStab, BlueBump, BlueSpoof, BlueDump, and so on.
Just as the BlueZ Linux Bluetooth stack lets the phone owner analyze traffic, it also provides the attacker with tools for targeting Bluetooth devices. Other tools such as the bluez-utils toolset, obexftp, and cu, and minicom give Linux users the ability to test for BlueSnarf and BlueBug security issues.
An attack involves several steps:
Step 1: Locate devices in the vicinity.
# hcitool scan Scanning ... 00:1C:CC:F3:21:98 BlackBerry 8310 00:0F:DE:6C:32:A4 T610 00:18:42:ED:75:E6 Nokia N95 00:17:F2:B2:A1:44 Chris's MacBook 00:21:E9:22:DD:A0 Marcel's iPhone 00:1C:D8:0F:7D:73 BlueAnt V1 V5.0 00:0E:6D:10:11:C6 Nokia 6310i
Step 2: Connect.
An attack can occur once the victim's Bluetooth address is known. For a BlueBug attack, it is quite sufficient to create a RFCOMM terminal device using a command such as:
rfcomm bind 42 00:0E:6D:10:11:C6 17
This command creates a TTY /dev/rfcomm42 and binds it to RFCOMM channel 17 on the phone with the addresses of 00:0E:6D:10:11:C6. Channel 17 supports a connection to the AT parser without authentication or encryption. After setting this up, the attacker can use a terminal program such as minicom or cu to run AT commands. Individual phone book entries can be read using special ETSI specification commands.
Step 3: Run Commands.
# cu -l /dev/rfcomm42 Connected. AT+CPBS="ME" OK AT+CPBR=1 +CPBR: 1,"",,"Christina Applegate" OK ~. Disconnected.
Attackers can also use programs such as gnokii and gammu that group the required AT commands and provide a simplified syntax.
The Bluetooth SIG reworked device pairing with the Bluetooth 2.1 specifications. Secure Simple Pairing was designed to replace legacy pairing and thus enhance security. Devices that comply with the Bluetooth 2.1 specification encrypt all connections - this means that devices can pair without user interaction. The Bluetooth 2.1 specification also aims to make device pairing simpler and more intuitive for users.
The basic idea behind Secure Simple Pairing is that the user only needs to perform one of the following three actions to set up a secure connection:
To identify the various pairing options and their security ratings, each link key is also type classified. For Bluetooth devices with a specification version of 2.0 or lower, this was either the Unit Key or Combination Key type. Secure Simple Pairing now additionally generates unauthenticated or authenticated link keys. Authenticated link keys provide protection against man-in-the-middle attacks. This involves users comparing numbers or entering a password on pairing. For automatic pairing based on the just-works model, an unauthenticated link key is created. It can be converted to an authenticated link key at a later stage.
To enhance security, Secure Simple Pairing relies on Elliptic Curve Diffie-Hellman (ECDH) Public Key cryptography. This means that an unauthenticated link key (although generated by the Just Works model) is still more secure than a combination link key generated with a fixed PIN. A further distinction is made between debug link keys and link keys created by a link key renew procedure.
The Bluetooth specifications before 2.0 defined three security modes. Secure Simple Pairing now introduces a 4th security mode and, at the same time, deprecates security modes 1 and 3. Devices that comply with Bluetooth specification 2.1 are not allowed to use modes 1 and 3. Additionally, security mode 4 is mandatory for connections between 2.1 class devices, although security mode 2 is still allowed for a connection between a class 2.1 and a class 2.0 device.
Besides the new security mode 4, the Bluetooth 2.1 specification also defines four new security levels that apply to devices with legacy pairing support: SDP, Low, Medium, and High.
SDP Security Level is a special service discovery mode. Low Security Level is used for all connections that do not require authentication and wherever the Just Works model is considered to be sufficient (e.g., sending visiting cards via the OBEX Push profile). Medium Security Level is the new service-level security mainly used for headsets that would typically use a fixed PIN. High Security Level is for profiles that require maximum security.
| Secure Simple Pairing Models |
|
Four models define Secure Simple Pairing behavior. All of these models are characterized by the I/O capabilities of the Bluetooth device. Bluetooth devices are distinguished by their support for either inputting and displaying (6-digit) numbers or just providing a yes/ no selection. These models, in turn, specify supported user interactions and thus the level of security provided. Model 1: Numeric comparison. Used if both devices can display a 6-digit number and confirm the comparison with a reference value by issuing yes or no. This method is used to pair two phones, for example. Numeric comparison results in an authenticated link key with man-in-the-middle (MitM) protection. Model 2: Just Works. If at least one of the devices is unable to either display or enter a 6-digit number, the Just Works model is used. This model does not provide any MitM protection, but it is still regarded as providing more security than devices with fixed PINs. Model 3: Out-of-band. If the devices support alternative authentication using, say, NFC, the cryptographic parameters for the public key method can be exchanged via this external channel. Model 4: Passkey entry. If one of the devices does not have a display option, but supports inputting a 6-digit number, a passkey is entered. A typical example of this is pairing a keyboard with a computer or laptop. User interaction achieves MitM protection in this case, too. |
Tests in public locations show that the attacks described in this article really are feasible. In just 14 minutes, Adam Laurie found 46 vulnerable cellphones at the Houses of Parliament in London, England. A test during London's rush hour revealed 336 devices, of which 119 were definitely vulnerable, in just 1 hour and 45 minutes.
Many vendors attempt to play down the threat of Bluetooth attacks. The low Bluetooth connection range, for instance, is often bandied about as a security feature; however, the range can be extended substantially for targeted attacks (or the attacker can just follow the victim at a safe distance to make things easier). Also - and this is probably more important - there are typically so many people within an assumed radius of 10 meters at public locations that mass attacks - for collecting (and possibly selling) data or delivering malware - scale easily.
The argument that devices have to be visible is not defensible from a technical point of view. Any device whose BD_ADDR can be detected is vulnerable whether or not the device is visible. The same applies to manufacturers advising users to hide the model or device by changing its name.
Vendors also claim that it is easier to steal a phone than to grab the data via Bluetooth. Well, maybe, but a phone user will quickly notice that the phone is gone the next time they need to call somebody, but they will typically not notice that data has been sniffed over a wireless connection. The risk of the perpetrator being caught and the phone owner taking corrective steps is thus far lower.
Used in a security-conscious way, Bluetooth does not need to be less secure than an ordinary IP network, but many users are totally unaware of the dangers. And some devices - such as most headsets - just can't be secured. This makes it all the more vital to promote security awareness amongst users and thus increase the pressure on device manufacturers.
With Secure Simple Pairing, the Bluetooth specification provides a new method designed to improve security, especially with autonomous devices. The use of public key cryptography puts Secure Simple Pairing in a good position to genuinely achieve more security. But the potential benefit is compromised by backward compatibility and the attempts to simplify user interaction, and buggy implementations could again turn out to be a security risk.
| INFO |
|
[1] Bluetooth SIG: Bluetooth Core Specification v2.1, July 2007
[2] Roger Weeks, Edd Dumbill and Brian Jepson: Linux Unwired, April 2004 [3] Marcel Holtmann and Mark Niemann: Bluetooth Security Revealed, February 2005 [4] IrDA: Object Exchange Protocol OBEX, Version 1.3, January 2003 [5] ETSI: GSM 07.07 - AT command set for GSM Mobile Equipment (ME), 1998 [6] AT Commands: http://en.wikipedia.org/wiki/Hayes_command_set |