Bluetooth Security Essentials

Designed in the mid-1990s as a means of connecting a keyboard to a computer without wires, Bluetooth has quickly become a technology with far more potential than eliminating cable clutter. Today, Bluetooth is omnipresent, in desktop PCs, laptops, PDAs and mobile phones, and an array of peripheral devices. Microsoft introduced comprehensive Bluetooth support for desktops and laptops in Windows XP Service Pack 2 (SP2), and for smart phones and Pocket PCs in Windows CE. Bluetooth now connects wireless headsets to phones and computers, connects laptops and PDAs to mobile phones and built-in modems, aids in the exchange of electronic business cards, and lets you print documents and create Personal Area Networks (PANs), among other new and evolving uses. As with its better-known cousin Wi-Fi, security questions have arisen about Bluetooth, and in recent months, terms such as Bluejacking and Bluesnarfing have entered the security professional's lexicon. Let's take a look at the fundamentals of Bluetooth, including its security features and potential risks, and walk through the process of securing your Bluetooth implementation.

How Bluetooth Works
Understanding how Bluetooth works is crucial to understanding the risks you face if you use it. Communication between devices is accomplished through Bluetooth radios that operate in the 2.4GHz frequency spectrum. This band, reserved globally for industrial, scientific, and medical (ISM) use, is a shared resource that other services use—most notably, 802.11b and 802.11g Wi-Fi devices. Bluetooth was designed with interference from competing services in mind, so it uses a frequency-hopping spread spectrum technology that exploits 79 channels of 1MHz each. A device's Bluetooth radio makes 1600 hops per second across the channels. Bluetooth radios are low-power devices—typically 1 megawatt (MW)—and their range is 10 meters, although the standard allows for radios as powerful as 100MW with ranges as wide as 100 meters.

Bluetooth is used primarily for ad-hoc connections and doesn't require the presence of Access Points (APs). Each device can initiate communication with as many as seven other devices in a piconet. As in Wi-Fi and wired networks, each Bluetooth device has a unique 48-bit address called the Bluetooth device address. The Bluetooth standard defines standard profiles or services that devices can offer. These profiles include the Generic access profile, the Serial port profile, the Generic Object Exchange profile, and profiles that build upon them, such as the Human interface device profile for keyboards and mouse devices, the Dial-up networking profile for modem access, and the Headset profile for wireless headsets.

Before two Bluetooth-enabled devices can communicate with each other, they must be paired. Pairing is a process by which devices agree to communicate with each other. The process of pairing begins with one Bluetooth-enabled device searching for another. The searching device sends anonymous inquiry messages across 32 of the 79 radio channels in an inquiry scan. Figure 1 shows the results of an inquiry scan. Devices that are willing to be discovered listen for inquiry scan messages and respond with their Bluetooth device address and some additional information. The searching device then sends a page request to the desired device's Bluetooth device address, at which point the searching device becomes a master. When a device responds to a page request, it becomes a slave. At this point, the devices aren't paired, but the master can send a request for the slave's friendly name (i.e., a description of the device). The description can be hard-coded but is often customizable and can use as many as 248 bytes to identify the device.

After devices are discovered, the searching device typically selects a device with which to pair. The pairing method depends on the Bluetooth devices' mode of security operation. Three modes of operation are available:

Table 1 shows the various results of pairing two devices that operate in different security modes. Without authentication, the link between paired devices can't be encrypted. If no authentication is required, the devices will simply be paired. (Authentication and optionally encryption might be required if the master attempts to access a service on the slave that requires them.)

An example of an application that requires no authentication or encryption is an electronic business-card exchange between Bluetooth-enabled phones. If authentication is required—for example, when a laptop connects to a Bluetooth phone to use the Dial-up networking profile—both the master and slave request a passkey. Although the passkey can be hard-coded—as is the case with some Bluetooth devices that have no UI, such as a Bluetooth wireless headset—the request usually goes to the user, who enters a value on both Bluetooth devices. The Bluetooth stack on the device uses the passkey, which is never transmitted between devices, to create a temporary initialization key, which then protects the transmission of either a unit key or key material for the creation of a combination key. The unit key or combination key becomes the link key. Once a link key has been established, it typically resides in a database so that the next time the devices attempt communication, the pairing process need not be repeated.

Communication between paired devices doesn't use the Bluetooth device addresses of the master and slave devices. Instead, communication relies on an access code derived from the Bluetooth device address of the master of the piconet, and the master assigns every slave device a three-bit logical transport address. All devices in the piconet examine received packets for an access code that belongs to a piconet of which they're a member. Piconet devices silently drop packets with unknown access codes. In packets with valid access codes, slaves look for the logical transport address to determine whether the packet is destined for them. Master devices process all packets received with a matching access code and use the logical transport address to determine who sent the packet. When encryption is required for communication between a master and a slave, Bluetooth devices derive an encryption key from four factors: the link key that both the master and slave device established during the pairing procedure, the result of the most recent authentication operation, the clock of each device, and a random number that the master and slave share. Only the payload information in packets is encrypted—the header isn't.

If you use encryption, the clock of the slave is updated with each communication with a master to ensure that they stay synchronized. If the clocks drift too far apart, the master and slave might not be able to communicate because the master's Bluetooth device address and the clock settings determine the radio channels the master and slave use, as well as the pattern of frequency hopping between them. Clock drift is one reason why two devices might need to go through the pairing procedure again.

Bluestumbling, Bluesnarfing, and Bluejacking
In recent months, Bluetooth has endured a number of accusations about weaknesses. The more sensational claims are really about weaknesses in individual implementations of the Bluetooth stack and the services that use it, not in the Bluetooth standard itself. The more common attacks that exploit these weaknesses are as follows:

If a link between paired devices isn't encrypted, a malicious user can easily impersonate one of the devices and send false packets to the other. Another security problem—common to a certain class of Bluetooth devices, such as the UI-bereft wireless headsets—is the use of hard-coded passkeys (which are often publicly known). If a device is a slave and is discoverable, an intruder who knows the passkey can connect to it quite easily, usually without the knowledge of the owner. Yet another problem involves the use of unit keys between devices. Remember that during the pairing process, Bluetooth devices create either a unit key or a combination key as the link key. The combination key is composed of key material from both the master and the slave devices. However, either the master or the slave creates a unit key, and all paired devices use it. If one device (Device A) knows the unit key of a device it's paired with (Device B), Device A can subsequently impersonate Device B if Device A can manipulate Device B's Bluetooth device address. Even if Device A can't manipulate Device B's device address, Device A can eavesdrop on communication between Device B and any other device that Device B pairs with—if Device A can eavesdrop on the initial pairing.

Manufacturers' Bluetooth implementations can also be a cause for concern. Authentication and encryption between Bluetooth devices is possible because both devices in a pairing share a common secret—the link key. If this key is compromised, eavesdropping on communications between the paired devices becomes a possibility. Some Bluetooth implementations have weak protection around the storage of the link keys.

Perhaps the most troubling aspect of Bluetooth is the lack of anonymity surrounding its use. If Bluetooth is enabled on your device, you should consider your privacy to be compromised. Although Bluetooth is largely limited to mobile devices and desktop computers, it isn't hard to imagine a future in which Bluetooth-enabled vending machines dispense merchandise and send a bill to your Bluetooth-enabled mobile phone. In this scenario, your identity and actions are vulnerable to compromise in many ways. The most obvious way is the phone billing. Some unique identifier associated with you—such as the Bluetooth device address—would need to be recorded for billing purposes. The second means of compromising your privacy is the ability to discover your Bluetooth-enabled devices by repeatedly performing an inquiry scan. In the vending-machine scenario, if your Bluetooth device is configured as discoverable, and if the Bluetooth device address is known and linked to you, an eavesdropper could determine that you walked by the vending machine at a known date and time, even if you didn't buy anything. The third privacy-compromising method is possible even if your device isn't discoverable, as long as you have an active link between two devices (e.g., your mobile phone and your wireless headset). If a surreptitious monitoring station such as our vending machine can eavesdrop on the communication between the devices as they pair and can capture the piconet's access code, the monitoring station needs only to listen for the access code in communications between the paired devices. If your piconet's access code can be attributed to you in some other fashion, the pairing of active devices doesn't even require eavesdropping.

The Bluetooth standard has other theoretical and known weaknesses, but they're either extremely difficult to exploit or require unrealistic conditions, so I won't discuss them further here. For more information, you might want to consult the official Bluetooth Web site (http://www.bluetooth.org), the National Institute of Standards and Technology (NIST) Special Publication SP 800-48 "Wireless Network Security" (http://csrc.nist.gov/publications/nistpubs/800-48/NIST_SP_800-48.pdf), or the @stake paper "War Nibbling: Bluetooth Insecurity" (http://www.atstake.com/research/reports/acrobat/atstake_war_nibbling.pdf).

Securing Bluetooth
A basic security rule is to disable anything you don't need or use—great advice for users who have Bluetooth-equipped devices. If your laptop, PDA, or mobile phone comes equipped with Bluetooth and you aren't using it, turn it off. Doing so will prevent anyone from exploiting vulnerabilities in the device's implementation or configuration and will also considerably add to the device's battery life. If you use Bluetooth occasionally, I recommend turning off the Bluetooth radio when it's not in use. For example, I use Bluetooth on my PDA when synching to my desktop, and I turn off the Bluetooth radios on each device when I'm not using them. I also use Bluetooth on my cell phone with a wireless headset while driving, and I make sure to turn the Bluetooth radio off when it isn't required.

If you must leave Bluetooth enabled—for example, if you're using your cell phone as a modem—I recommend ensuring that your device isn't discoverable. Most Bluetooth-equipped devices differentiate between being on and being on and discoverable. On a Windows XP SP2 laptop with a Bluetooth radio, you can make sure your laptop isn't discoverable by launching the Control Panel Bluetooth Devices applet, selecting the Options tab, and ensuring that the Turn discovery on check box is cleared, as Figure 2 shows. The method for ensuring that PDAs and cell phones can't be discovered depends on the device. On my Windows-based smart phone, for example, I can ensure that my phone can't be discovered by selecting Start, Settings, Bluetooth, Bluetooth, and making sure my phone's Bluetooth radio is set to Off or On, and never Discoverable.

If you need to pair Bluetooth devices, I recommend never doing so in a public place, such as a mass-transit center or a coffee house. Instead, pick somewhere quiet where there's little chance of someone eavesdropping on Bluetooth radio signals. To begin the pairing procedure, you'll need to make one of your devices discoverable. Never make both discoverable, and always disable discoverability on the slave afterward. If you use a desktop with a Bluetooth keyboard and mouse, you'll need to keep your Bluetooth radios turned on, but you don't need to keep your devices in discoverable mode.

When pairing devices, you should use authentication and encryption on the link between devices, where possible. Figure 3 shows the dialog box that appears when I attempt to pair my Windows XP SP2 desktop with my smart phone. If you don't use a passkey, you can't enable authentication and encryption. In this example, I elected to have Windows select a passkey for me, and the system prompted me to enter the passkey onto my smart phone, as Figure 4 shows.

Most implementations of the Bluetooth protocol, including the Windows XP SP2 implementation, provide options for preventing Bluetooth devices from connecting to a system and for alerting the user when permitted devices want to connect. You can see these options on Figure 2's Options tab. Some implementations go further and let you determine that only previously paired devices can connect to a host.

If you pair multiple Bluetooth devices, I recommend selecting a unique, random passkey for each pairing. By using multiple random passkeys, you eliminate the risk of reusing the same one, in the unlikely event of an intruder cracking it. If a pairing is lost or broken and you need to pair the devices again, I recommend using a different passkey.

One Bluetooth implementation that deserves special scrutiny is that of PANs, particularly those that provide access to the Internet through a suitably equipped cell phone. When connecting to other devices in a PAN, you're essentially making TCP/IP-based connections. Windows XP SP2 ships with an enhanced version of the Internet Connection Firewall (ICF), called the Windows Firewall. Before establishing a PAN or using DUN, you should ensure that your connection is appropriately protected by Windows Firewall. Figure 5 shows the Advanced tab of the Control Panel Windows Firewall applet, in which the Bluetooth Network Connection has been firewall-protected.

Finally, when procuring Bluetooth devices, do some research into the security of the devices you're considering. For example, check whether the devices use unit or combination link keys. If you're examining devices that have no UI in which to enter a passkey, check whether the device has a hard-coded passkey that's common to all such devices or unique to that particular device in some way. Most important, ensure that the devices support authentication and encryption of the link between paired devices.

The Future of Bluetooth
More and more devices are shipping with Bluetooth radios, and the wireless standard can only grow in usage. As Bluetooth use becomes more widespread, so will reports about vulnerabilities in the protocol and its implementations. Judging from the vulnerabilities identified so far, you'll minimize the risk of using Bluetooth by adhering to this article's advice. As you would with any IT asset, you should build into your patch-management processes the necessary steps to analyze reports about Bluetooth vulnerabilities, determine whether they pose a risk to your organization, and update each to eliminate vulnerabilities where required. To learn more about Bluetooth's emerging security features, sign up for a free Adopter-level account on the Bluetooth Special Interest Group (SIG) Web site at http://www.bluetooth.org. Doing so will give you access to authoritative documents about Bluetooth and enhancements to its security.