CHAPTER 10
Bluetooth Security
These days, it’s difficult to go anywhere without seeing someone chatting away on a cell phone with the ever-present wireless headset stuck in their ear. This wireless functionality is almost always provided by Bluetooth technology, and although the wireless cell phone headset is the most commonly seen use of Bluetooth, this technology is being leveraged for an increasingly diverse set of applications, from simple data transfer and synchronization to wireless mice and keyboards and hands-free mobile phone car kits.
Overview of the Technology
Bluetooth’s functionality and ubiquity on mobile devices provides some exciting opportunities for mobile application developers, but as is often the case with technology, as the use of Bluetooth has increased, so have related security problems. A variety of issues from weaknesses in the specifications to implementation flaws have put Bluetooth security in the news, with these security issues resulting in the loss of private data, eavesdropping, and unauthorized device control.
This chapter provides an introduction to Bluetooth’s operation and security characteristics. Common threats and security vulnerabilities are covered, as are recommendations for controlling the risk and increasing the security of Bluetooth-enabled devices and applications.
History and Standards
Bluetooth was originally conceived as an internal project at Ericsson Mobile Communications to create a wireless keyboard system. The technology proved to be useful for other objectives, and additional work was performed within Ericsson to apply the wireless connectivity to more generic purposes. To further the development and acceptance of the technology, the Bluetooth Special Interest Group (SIG) was formed in 1998 to help shepherd the emerging standard and promote the spread of Bluetooth to other practical applications (Bluetooth Security, p. 3). Since 1998, the Bluetooth SIG has administered and published the Bluetooth specifications and managed, marketed, and evangelized the technology.
NOTE
The book Bluetooth Security (Artech House, 2004), by Christian Gehrmann, Joakim Persson, and Ben Smeets, is referenced numerous times in this chapter.
There have been a number of official specification releases by the SIG, starting with 1.0 and leading to the most recent version, 2.1, which was made official in July 2007. In addition to the management of the official specifications by the Bluetooth SIG, IEEE working group 802.15 is tasked with standards for wireless personal area networks (WPANs), which includes Bluetooth technology. IEEE project 802.15.1 is the WPAN standard based on Bluetooth’s specification (www.ieee802.org/15/pub/TG1.html).
Common Uses
Certainly Bluetooth has come a long way since its humble origins (and rather limited scope). In 2008, the number of Bluetooth devices in the market exceeded 2 billion, according to a May 2008 press release from the Bluetooth SIG. The variety of usage scenarios continues to expand, although mobile phone headsets are still the most common use. Other uses for Bluetooth technology include:
Wireless keyboard, mouse, and printer connectivity
Device synchronization (for example, PDA to desktop)
File transfer (for example, camera phone to desktop or photo printer)
Gaming console integration (including Nintendo Wii remotes and Sony PS3 headsets)
Tethering for Internet access (using a data-enabled mobile phone as a modem for Internet access from a laptop with Bluetooth providing inter device connectivity)
Hands-free and voice-activated mobile phone kits for cars
Alternatives
Although it’s likely the most common option for personal area networking, Bluetooth is not the only choice. Numerous options exist and are being developed to provide alternatives to Bluetooth. A few of the more significant choices are discussed here briefly, although because Bluetooth is aimed at providing wireless cable replacement, wired alternatives such as serial and USB are not considered.
Certified Wireless USB A short-range, high-bandwidth solution designed to allow interoperability with/replacement of standard (wired) USB (see www.usb.org/developers/wusb/). A number of vendors have introduced or announced compatible products, and it is likely that the popularity of wired USB will carry over to Certified Wireless USB.
IrDA (Infrared Data Association) A specification for wireless communications via infrared transmission (see http://irda.org/). Many laptops, printers, and PDAs support IrDA, and external adapters are inexpensive. Additionally, data transmission rates for IrDA are higher than Bluetooth (up to 16Mbps). However, because infrared communications require line of sight between communicating systems, IrDA only lends itself to applications where endpoints are relatively immobile, which contradicts some of the flexibility and operational goals of a WPAN.
ZigBee Wireless networking technology based on the IEEE 802.15.4 standard (see www.zigbee.org/en/). ZigBee is marketed toward monitoring and sensory applications, versus the typical personal use cases with which Bluetooth is most often associated.
Kleer Kleer, a semiconductor company, has created an alternative to Bluetooth that also uses the Industrial Science and Medical (ISM) band (see www.kleer.com/products/wirelessaudiofaq.php). Kleer’s technology is currently focused on audio (although video and other data is supported). Kleer technology has been sold under the RCA brand, and they have also forged a deal with Thomson to supply RF technology for Thomson’s wireless headsets.
NOTE
For more on the rivalry between Bluetooth and Kleer’s technology, see Richard Nass’s article “Bluetooth Competition Heats Up” (http://embedded.com/columns/esdeic/197008829).
802.11 a/b/g/n Standard WLAN technology can be employed for some of Bluetooth’s standard uses, but 802.11 is typically used for infrastructure connectivity where clients need full network connectivity (typically TCP/IP). Additionally, cost, power consumption, and configuration complexity will tend to be much higher with 802.11 systems. It is expected that both 802.11 wireless networking and Bluetooth will continue to develop and thrive in their respective target markets without a great deal of functional crossover between the two technologies.
HiperLAN (1 and 2) A wireless networking standard managed by the European Telecommunications Standard Institute (ETSI). More similar in functionality to 802.11 wireless networking, HiperLAN technology has been around since the early 1990s, but its market penetration is nowhere near either Bluetooth or 802.11 WLAN.
For more on the HiperLAN standard, see the ETSI website (www.etsi.org/website/technologies/hiperlan.aspx).
HomeRF An obsolete wireless networking specification that was intended to provide personal device connectivity. The working group that managed the specification was disbanded as 802.11 and Bluetooth became more widespread.
Although there are a number of alternatives, the market momentum of Bluetooth in conjunction with its well organized and supported SIG will make Bluetooth an ideal choice for WPAN connectivity for mobile application developers for the foreseeable future.
Future
The most current Bluetooth version is v2.1 + EDR, which was published in July 2007. The next major release (likely to be v3.0, code-named “Seattle”) is designed to have much higher transmission speeds, faster connection speeds, and may include support for Ultra-Wideband (UWB) and WLAN technology. In addition, versions using even lower power levels are on the Bluetooth roadmap (see www.wirelessweek.com//Bluetooth-SIG-2009-Update.aspx).
Bluetooth Technical Architecture
The Bluetooth specification covers all aspects of Bluetooth implementation, including radio operation, topology of Bluetooth networks, individual Bluetooth device identification, and modes of operation. Additionally, the specification defines the various components of the Bluetooth stack and outlines the concept of Bluetooth profiles for aggregating and packaging functions associated with common Bluetooth use cases.
Radio Operation and Frequency
Bluetooth radios operate in the unlicensed ISM band at 2.4GHz (also used by 802.11 networking equipment, microwave ovens, and many cordless phones). Bluetooth radios implement frequency-hopping spread spectrum for data transmission. Transmission rates are up to 1Mbps for most devices, although devices running Enhanced Data Rate (available with Bluetooth versions 2.0 and 2.1) can have rates up to 2Mbps or 3Mbps.
Table 10-1 Bluetooth Radio Power Classes
The Bluetooth specification defines three transmitter power classes. The class of radio used for a Bluetooth device is determined primarily based on usage and proximity requirements and power availability (that is, AC powered versus battery powered). Table 10-1 summarizes the power classes defined by Bluetooth.
Note that in addition to the maximums specified by each power class, communicating Bluetooth devices can also negotiate the power of the radio link used for communication, which can help conserve power and optimize connectivity for particular links.
Bluetooth Network Topology
Much like 802.11a/b/g networking, Bluetooth devices can connect in an infrastructure mode (via a centralized Bluetooth access point/base station) or in ad hoc mode, where Bluetooth devices make dynamic connections among themselves without the aid or use of a centralized network infrastructure. Ad hoc mode is much more common and better suited for Bluetooth’s WPAN connectivity goals and is the networking topology that this chapter focuses on.
Bluetooth devices organize themselves dynamically in network structures called piconets. Piconets contain two or more Bluetooth devices within physical range of each other that share a frequency-hopping sequence and an operating channel. Typical examples of Bluetooth piconets would be a mobile phone with a wireless headset or a desktop computer with a Bluetooth keyboard and mouse.
Each piconet has one device called the master (which establishes the network’s operating parameters) and up to seven active slave devices. Through various network and radio control techniques, devices are able to belong to multiple piconets simultaneously, although a device may only be a master in one piconet. A scatternet is an arrangement of piconets where one or more devices acts as a master in one piconet and a slave in one or more additional piconets.
Figure 10-1 illustrates some typical piconet/scatternet arrangements.
Figure 10-1 Examples of Bluetooth piconet topologies
Device Identification
Bluetooth uses a 48-bit identifier, similar to a MAC address for an Ethernet adapter, for device identification. This identifier is referred to as the Bluetooth device address (BD_ADDR). The first three bytes of the BD_ADDR are specific to the manufacturer of the Bluetooth radio, with identification assignments controlled by the IEEE Registration Authority (see page 232 of Core Specification v2.1 + EDR on the Bluetooth website).
Modes of Operation
The Bluetooth specification outlines a variety of operational modes, the configuration of which will have a direct impact on device security. These operational modes specify options for discoverability, connectability, and bondability (often referred to as pairability).
Discoverability Modes
Discoverability refers to whether or not the configured device will respond to discovery inquiries from other Bluetooth devices. The defined discoverability modes include:
Non-discoverable Devices in this mode do not respond to inquiry scans from other devices. Note that this does not mean that the devices cannot be connected to (this characteristic is specified and controlled by the Bluetooth connectability modes).
Limited discoverable mode This mode is used by devices that need to be discoverable for a limited amount of time.
General discoverable mode This mode is used by devices that are continuously discoverable by other devices. Devices in either limited or general discoverable mode periodically listen to an inquiry physical channel and respond to inquiry scans with a set of connection configuration information that allows the scanning device to begin to initiate a connection with the responding device.
Connectability Modes
Connectability refers to whether or not the configured device will respond to paging from other devices (that is, requests to initiate a Bluetooth connect). The defined connectability modes include:
Non-connectable mode Devices in this mode never enter the page scan state, meaning they will never receive/acknowledge/respond to a page request and are not able to establish connections based on inbound page requests.
Connectable mode Devices in this mode will periodically enter the page scan state. This means that the device listens for pages on the page scan physical channel and will respond to pages (connection requests).
Pairability/Bondability Modes
Pairability refers to whether a device is capable of bonding/pairing with another Bluetooth device. The defined bondability modes include:
Non-bondable mode Devices in this mode do not respond to bonding requests and will not pair with other devices.
Bondable mode Devices in bondable mode will allow pairing with another Bluetooth device. Note that devices in bondable mode may require additional security prior to pairing (that is, PIN entry/authentication).
Bluetooth Stack
The Bluetooth specification organizes the technology in a layered stack similar to the OSI and DoD TCP/IP models. This layered model supports vendor interoperability and allows developers to encapsulate functionality and services in a clean and predictable fashion. A generalized version of the Bluetooth stack is shown in Figure 10-2 (for a more detailed discussion of the Bluetooth stack, see the “Core System Architecture” section of the Bluetooth specification (see page 94 of Core Specification v2.1 + EDR on the Bluetooth website).
Bluetooth Module Layers
The Bluetooth controller consists of the radio hardware radio components of the Bluetooth device. Starting at the bottom of the stack is the Bluetooth radio. This is where RF signals are processed. Moving a layer above is the baseband/link controller level, which handles link synchronization and data formatting between the radio and upper layers, among other tasks. The link manager level is tasked with establishing and maintaining links between Bluetooth devices.
Figure 10-2 Bluetooth protocol stack
Host Controller Interface (HCI)
The HCI is an optional implementation component that can be used to separate higher- and lower-level functions on different processors. When used, the HCI acts as a consistent interface between the two separate processors handling upper- and lower-level functions. An example where an HCI would be implemented is an external Bluetooth dongle on a laptop. The lower-level (Bluetooth module) functions are likely to be handled by the dongle, with upper-level functions managed by the laptop’s Bluetooth stack. The HCI handles communications between the two components.
Bluetooth Host Layers
The Logical Link Control and Adaptation Protocol (L2CAP) is the first layer above the HCI. L2CAP is responsible for multiplexing across multiple higher-level protocols and packaging and repackaging packets between the formats required by the various upper and lower protocol layers.
A variety of protocols exists above the L2CAP layer, including the Service Discovery Protocol (SDP), a protocol used to locate and identify Bluetooth services, and RFCOMM, a serial cable emulation protocol. At the top of the stack are the various applications and profiles offered via Bluetooth.
Bluetooth Profiles
The Bluetooth specification does not limit implementations to specific uses or applications, but is instead available to any number of applications for WPAN connectivity, limited only by the developer’s requirements and creativity. However, there are a number of common uses that many Bluetooth devices and applications are designed to fulfill, such as wireless headsets, file transfer, wireless keyboards, and data synchronization. To address these common use cases, the Bluetooth SIG has created and published a series of Bluetooth profiles. These profiles specify the communication interfaces between devices for a given service over Bluetooth.
The Bluetooth profile model also allows for new profiles to be constructed on top of existing profiles. This promotes efficiency and reuse and creates a kind of profile hierarchy. An example of this hierarchy constructed by building on existing profiles is shown in Figure 10-3.
In this example, we begin with the Generic Access Profile (GAP), which is the basis of all Bluetooth profiles. The GAP provides the lowest level and fundamental specifications related to Bluetooth operation and device interaction. Building on the GAP is the Serial Port Profile, which contains specifications for serial cable replacement and RS232 emulation. Then, building on the Serial Port Profile are a variety of other profiles, including the Hands-Free Profile (which specifies the operation of hands-free kits for mobile phones) and the Dial Up Networking Profile (which specifies the provisioning of access to Internet, dial-up, and other related services over Bluetooth). Note that this example shows only a small sampling of available Bluetooth profiles. The Bluetooth SIG publishes profile specifications separately and out of cycle from the main Bluetooth specification; the currently available profiles can be accessed via the Bluetooth SIG website (refer to www.bluetooth.com/Bluetooth/Technology/Building/Specifications/).
Figure 10-3 Sample hierarchy of Bluetooth profiles
From a security perspective, profiles are a useful construct because each profile’s services will have varying requirements. For example, devices using the File Transfer Profile will have different security requirements than devices using the Cordless Telephony Profile. Accordingly, developers are then able to use these profiles to customize and determine the Bluetooth security services that are implemented with their Bluetooth applications. Several profiles are of particular interest from a security perspective. These include the PAN Profile, which is provided to support various types of network access, and the Phone Book Access Profile (PBAP), which provides services phone book data between devices.
Bluetooth Security Features
Before getting into details on the security features and architecture of Bluetooth, it’s important to revisit and discuss some of the key characteristics of the technology and its intended user base. Bluetooth is designed to provide cable-free operation and interaction among a variety of devices, many of which tend to be consumer electronic devices. Because of the variety of devices in use and the situations for which Bluetooth is intended, no assumptions can be made about either the Bluetooth device or the technical sophistication of the device’s user. Bluetooth must be usable by novice consumers and on devices with limited or no visual display or input capabilities (headsets, keyboards, and so on). So, a key factor that complicates Bluetooth security is that many usage scenarios involve nontechnical users as well as devices that are incapable of the security mechanisms a developer may wish to use.
It is important that these issues remain at the top of mind as mobile application developers plan the design of their applications, as well as whether and how these applications will leverage or rely on Bluetooth security.
Pairing
Pairing, the process whereby two Bluetooth devices establish a link and agree to communicate, is critical to the overall security architecture of Bluetooth and is tightly integrated with other Bluetooth security features. During the pairing process, the communicating devices agree on and generate keys that are used to identify and reference relationships with other devices. In addition to being used for these identification purposes, these keys are also used to generate additional keys used for both device authentication and communication encryption.
Device Pairing Prior to Bluetooth v2.1 + EDR
In versions prior to Bluetooth v2.1 + EDR (released in July 2007), pairing between devices is accomplished through the entry of a PIN or passkey with a maximum length of 128 bits. There are two types of such passkeys: variable passkeys, which can be chosen at the time of pairing via some input mechanism, and fixed passkeys, which are predetermined (Bluetooth Security, p. 29). The type of passkey used is typically determined by a device’s input and display capabilities (for example, a Bluetooth-enabled phone with keyboard input and visual display may use a variable passkey, whereas a Bluetooth-enabled mouse may use a fixed passkey because it has neither input nor display capabilities to enter or verify a passkey).
Secure Simple Pairing with Bluetooth v2.1 + EDR
In Bluetooth v2.1 + EDR, a new method of pairing called Secure Simple Pairing was introduced. The older method of pairing is supported when connecting to legacy devices, but the use of Secure Simple Pairing is mandated for communications between Bluetooth v2.1 + EDR devices.
From a user’s perspective, Secure Simple Pairing is meant to provide additional flexibility and ease of use when pairing compatible devices that have far-ranging display and input capabilities. However, from a security perspective, Secure Simple Pairing also improves security through the introduction of Elliptic Curve Diffie-Hellman (ECDH) for key exchange and link key generation.
Rather than relying on simple PIN/passkey entry and verification, Secure Simple Pairing offers four different means for pairing compatible devices (known as association models):
NOTE
For more information on Secure Simple Pairing, see the “Bluetooth Simple Pairing Whitepaper” at the Bluetooth website.
Numeric Comparison This association model is designed for situations where both communicating devices can display a six-digit number and have inputs that allow the user to enter “yes” or “no.” A six-digit number from 000000 to 999999 is shown on both displays, and the user is prompted to respond whether the numbers are the same on both devices. If “yes” is entered on both devices, then the devices are paired successfully. Note that a primary difference between Numeric Comparison and the PIN model used in legacy pairing is the displayed number. In Numeric Comparison, this value is not used as an input to further key generation, so an attacker who can observe the displayed number cannot use it to calculate other keys. With the legacy PIN model, the PIN entered does factor into the generation of encryption keys, which makes PIN disclosure a real risk to the security of the communications.
Just Works This association model is intended for scenarios involving at least one device without the ability to display a six-digit number or to enter numbers. This mode uses the same key agreement protocol as Numeric Comparison (with protections against passive eavesdropping), but the actual method whereby the user accepts the Bluetooth connection is determined by the product manufacturer. This association model does not provide protection against man-in-the-middle attacks.
Out of Band This association model is intended for scenarios involving an out-of-band (OOB) mechanism (that is, non-Bluetooth) that is used to both discover the Bluetooth devices and exchange information during the pairing process. The actual OOB mechanism will vary, but a commonly specified use case involving a Near Field Communication (NFC) OOB mechanism is device “tapping.” This use case involves physically touching two devices together. Subsequent to the devices being tapped together, the user is asked to confirm whether the pairing request initiated by the tapping should be accepted. To provide security for the pairing process, the OOB mechanism used should provide privacy protections, including resistance to man-in-the-middle attacks.
Passkey Entry This association model is intended primarily for situations involving one device with input capabilities but no display capabilities while the other device has display capabilities. The device with a display presents a six-digit number from 000000 to 999999 on the display. The user then enters this number on the device with the input capability. If the values match, then the devices are paired successfully.
Traditional Security Services in Bluetooth
Developers and implementers are accustomed to having access to certain basic security services in the technologies they employ. Such basic security services include authentication, authorization, integrity, and confidentiality, among others. The availability of these services, the soundness of their implementations, and the extent to which the developer or implementer can customize these services for their unique requirements all help reveal the security capabilities of a given technology.
The Bluetooth specifications include a limited set of these basic security services, and as such, the level of security that can be implemented with native Bluetooth features is limited. The following security services are provided by the Bluetooth specification:
Authentication The ability to identify devices before and during connection and communication is provided by Bluetooth.
Authorization The ability to provide selected access to resources based on permissions is provided by Bluetooth.
Confidentiality The ability to protect communications during transmission over the network is provided by Bluetooth.
Noticeably absent are integrity protections and nonrepudiation services. In addition, native Bluetooth security services are provided at the device-to-device level; for instance, Bluetooth’s authentication service only authenticates a Bluetooth device. There is no provision for user-level authentication. Of course, this does not mean that user authentication services cannot be provided over a Bluetooth connection; instead, the developer must implement this service by other means at a different level in the communication stack. These limitations are important to consider as mobile developers architect their applications and consider which security options to employ.
Authentication
Bluetooth authentication is the process whereby one device verifies the identity of another device. Bluetooth authentication is a one-way process, meaning that during any given authentication procedure, only one device’s identity is verified. In use cases requiring mutual authentication, this one-way process is simply repeated with the two devices’ roles reversed.
Bluetooth authentication involves the claimant device, which is the device that will have its identify verified by the authentication process, and the verifier device, which is the device that will verify the claimant’s identity. To perform this verification, a traditional challenge-response mechanism is used. The verifier sends a random number (the “challenge”) to the claimant. Upon receipt, the claimant generates a response to this challenge and returns the response to the verifier. This response is generated based on a function involving the random number, the claimant’s Bluetooth device address, and a secret key that was generated during device pairing (see page 240 of Core Specification v2.1 + EDR on the Bluetooth website).
The Bluetooth authentication mechanism has a simple protection to prevent repeated attacks in a limited timeframe. When an authentication attempt fails, the verifier will delay its next attempt to authenticate the claimant. This delay interval will be increased exponentially for each subsequent failed attempt (see page 880 of Core Specification v2.1 + EDR on the Bluetooth website).
Authorization
Authorization in Bluetooth allows for decision making about resource access and connection configuration (that is, authentication and encryption requirements) to be made based on the permissions granted a given Bluetooth device or service. Two of the primary means of implementing authorization in Bluetooth are device trust levels and service security levels.
Device Trust Levels Bluetooth devices can have one of two trust levels in relation to other Bluetooth devices: trusted or untrusted (refer to the “Wireless Security” page at the Bluetooth website).
Trusted devices have previously been paired with the device, and will have full access to services on the Bluetooth device.
Untrusted devices have not previously been paired with the device (or the relationship has been otherwise removed), and will have restricted access to services.
Service Security Levels Bluetooth services (applications that use Bluetooth) have one of three security levels:
Service Level 1 These services require device authentication and authorization. Trusted devices will be granted automatic access to these services. Manual authentication and authorization will be required before untrusted devices are granted access to these services.
Service Level 2 These services require authentication, but do not require authorization.
Service Level 3 These services have no security and are open to all devices.
Although Bluetooth’s notions of device trust and service security levels are quite simple, the architecture of Bluetooth does provide for the implementation of more complex security and authorization policies. For more details on the construction and design of more feature-rich security models using Bluetooth, see Chapter 6 of Bluetooth Security and the Bluetooth SIG’s “Bluetooth Security White Paper” at the Bluetooth website.
Confidentiality
Confidentiality is important for private communications over wireless links because the nature of wireless networking leaves the communication between nodes subject to eavesdropping by unauthorized parties. Confidentiality of network communications in Bluetooth is provided through the use of encryption, with the use of encryption being optional and determined by the selection of one of three encryption modes during communication.
The Bluetooth specification outlines three specific encryption modes. These modes are intended to limit encryption key ambiguity and speed processing of encrypted data in both point-to-point and broadcast traffic situations. Bluetooth uses E0, a stream cipher, as the basis for the encryption processing associated with these encryption modes. The defined modes include:
Encryption Mode 1 No encryption. All traffic is unencrypted when Encryption Mode 1 is used.
Encryption Mode 2 Traffic between individual endpoints (non-broadcast) is encrypted with individual link keys. Broadcast traffic is unencrypted.
Encryption Mode 3 Both broadcast and point-to-point traffic is encrypted with the same encryption key (the master link key). In this mode, all traffic is readable by all nodes in the piconet (and remains encrypted to outside observers). Note that the notion of privacy in Encryption Mode 3 is predicated on the idea that all nodes in the piconet are trusted because all nodes will have access to the encrypted data.
Of importance to note is that when encryption is used in Bluetooth, not all parts of the Bluetooth packet are encrypted. Because all members of a piconet must be able to determine whether the packet is meant for them, the header of the message must be unencrypted. And, a part of the packet called the access code must be available to all devices to allow the radio signal to be acquired properly (Bluetooth Security, p. 34).
Bluetooth Security Modes
The Bluetooth Generic Access Profile details the procedures associated with the discovery of Bluetooth devices and specifications related to device connection (Bluetooth Security, p. 38). In addition to these discovery and connection details, the Generic Access Profile also defines four security modes in which connectable Bluetooth devices may operate. The use of these various security modes controls how Bluetooth’s basic security services are employed for any given connection:
Security Mode 1 In Security Mode 1, no security procedures are used. There is no encryption or authentication, and devices in this mode will not use any controls to prevent other devices from establishing connections.
Security Mode 2 In Security Mode 2, security is implemented after the Bluetooth link is established. In this mode, security is enforced at the service level, so it is left to the Bluetooth application or service to request security. This flexibility allows for granular and specific security policies to be implemented that apply security selectively based on the services and applications requested. This, of course, also opens the door for flaws in the implementation of these security policies that could leave the device and data at risk.
Security Mode 3 In Security Mode 3, security is implemented when the Bluetooth link is established. This is an “always-on” policy that provides security for all uses and reduces the risks associated with faulty security policies and implementations. However, this will also increase inconvenience and decrease flexibility because devices will be unable to connect without authentication (Bluetooth Security, p. 39).
Security Mode 4 Security Mode 4 was defined in the v2.1 + EDR specification, and it’s required between v2.1 + EDR devices (essentially making Modes 1 through 3 legacy modes once v2.1 + EDR becomes widespread). Like Security Mode 2, security in Security Mode 4 is implemented after link setup. However, service security requirements must be identified as one of the following:
Authenticated link key required
Unauthenticated link key required
No security required
NOTE
For more information, see NIST Special Publication 800-121: Guide to Bluetooth Security, by Karen Scarfone and John Padgette (http://csrc.nist.gov/publications/nistpubs/800-121/SP800-121.pdf).
Security “Non-Features”
In addition to reviewing the actual security features provided by Bluetooth, it is useful to acknowledge and refute two characteristics of Bluetooth communications that may be claimed as security features but do not provide any real protection:
Frequency hopping The frequency-hopping scheme that Bluetooth uses does not provide any protection against eavesdropping. There is no secret used to create the sequence of channels, and only 79 channels are used. Thus, using a series of receivers to monitor all channels would make an offline attack possible (Bluetooth Security, p. 31).
Device proximity The limited range of Bluetooth radios (up to approximately 330 feet with Class 1 radios) cannot be reliably used as a security feature. The supposed protection provided by limited signal strength can and has been defeated by attackers’ high gain antennas.
Threats to Bluetooth Devices and Networks
Wireless networks (as a general class) are subject to various threats, such as eavesdropping, impersonation, denial of service, and man-in-the-middle attacks. Bluetooth devices and networks are also subject to these issues. In addition, Bluetooth systems face additional threats, including:
Location tracking Because Bluetooth devices by their nature emit radio signals and device addresses must be both unique and known to communicating parties, Bluetooth devices are subject to location-tracking threats.
Key management issues Like many technologies that use cryptography for features such as authentication and encryption, Bluetooth devices are subject to threats related to key management, including key disclosure or tampering.
Bluejacking Bluejacking involves the sending of unsolicited messages to a victim’s Bluetooth device. This can be leveraged as a social-engineering attack that is enabled by susceptible Bluetooth devices.
Implementation issues As with any technology specification, the quality of security on Bluetooth devices is determined to some degree by product-specific implementations. Implementation flaws become threats when a product manufacturer incorrectly implements the Bluetooth specification in its device, making the device or communications subject to security issues that would not exist if the specification was implemented correctly. Implementation flaws have been at the root of many well-known Bluetooth security issues, including:
Bluesnarfing This attack allows access to a victim Bluetooth device because of a flaw in device firmware. Arbitrary data can be accessed through this attack, including the International Mobile Equipment Identity (IMEI).
Bluebugging This attack allows an attacker to access data, place calls, and eavesdrop on calls, among other activities. This attack is made possible by a firmware flaw on some mobile phones.
Car whispering This attack allows an attacker to send or receive audio via a Bluetooth-enabled hands-free automobile kit. This attack is made possible due to an implementation flaw on these kits.
NOTE
For more information on Bluetooth security issues and the listed attacks, refer to TheBunker.net (for Adam Laurie and Ben Laurie’s documentation of security issues in Bluetooth) and the trifinite.group website.
Bluetooth Vulnerabilities
This section outlines a number of known security vulnerabilities in current and legacy versions of Bluetooth (see NIST Special Publication 800-121: Guide to Bluetooth Security).
Bluetooth Versions Prior to v1.2
The unit key is reusable and becomes public when used. The unit key is a type of link key generated during device pairing, and has been deprecated since Bluetooth v1.2. This issue allows arbitrary eavesdropping by devices that have access to the unit key.
Bluetooth Versions Prior to v2.1
Short PINs are permitted. Because PINs are used to generate encryption keys and users may tend to select short PINs, this issue can lower the security assurances provided by Bluetooth’s encryption mechanisms.
The encryption keystream repeats. In Bluetooth versions prior to v2.1, the keystream repeats after 23.3 hours of use. Therefore, a keystream is generated identical to that used earlier in the communication.
All Versions
Unknown random number generator (RNG) strength for challenge-response The strength of the RNG used to create challenge-response values for Bluetooth authentication is unknown. Weaknesses in this RNG could compromise the effectiveness of Bluetooth authentication and overall security.
Negotiable encryption key length The Bluetooth specification allows the negotiation of the encryption key down to a size as small as one byte.
Shared master key The encryption key used to key encrypted broadcast communications in a Bluetooth piconet is shared among all piconet members.
Weak E0 stream cipher A theoretical known-plaintext attack has been discovered that may allow recovery of an encryption key much faster than a brute-force attack.
NOTE
For more on this attack, see “The Conditional Correlation Attack: A Practical Attack on Bluetooth Encryption,” by Yi Lu, Willi Meier, and Serge Vaudenay (http://lasecwww.epfl.ch/pub/lasec/doc/LMV05.pdf).
Limited security services As mentioned previously, Bluetooth offers a limited set of security services, with services such as integrity protection and nonrepudiation excluded.
Recommendations
Do not rely on Bluetooth’s native security mechanisms for sensitive applications. Because Bluetooth provides only device-level security services (versus user level), Bluetooth’s security controls cannot be relied upon to limit access to sensitive data and applications to authorized users. As such, it is important that mobile application developers provide appropriate security controls that offer identity-level security features (that is, user authentication and user authorization) for applications that require security above and beyond what Bluetooth is able to natively supply.
The following is a list of technical recommendations concerning Bluetooth security:
Use complex PINs for Bluetooth devices.
In sensitive and high-security environments, configure Bluetooth devices to limit the power used by the Bluetooth radio.
Avoid using the “Just Works” association model for v2.1 + EDR devices.
Limit the services and profiles available on Bluetooth devices to only those required.
Configure Bluetooth devices as non-discoverable except during pairing.
Avoid use of Security Mode 1.
Enable mutual authentication for all Bluetooth communications.
Configure the maximum allowable size for encryption keys.
In sensitive and high-security environments, perform pairing in secure areas to limit the possibility of PIN disclosure.
Unpair devices that had previously paired with a device if a Bluetooth device is lost or stolen.
See the National Institute of Standards and Technology’s “Guide to Bluetooth Security” for additional recommendations for using and configuring Bluetooth securely.