Guide to Bluetooth Security

Special Publication 800-121 Revision 1 (Draft) Guide to Bluetooth Security (Draft) Recommendations of the National Institute of Standards and Technology John Padgette Karen Scarfone

NIST Special Publication 800-121 Revision 1 (Draft) Guide to Bluetooth Security (Draft) Recommendations of the National Institute of Standards and Technology John Padgette Karen Scarfone C O M P U T E R S E C U R I T Y Computer Security Division Information Technology Laboratory National Institute of Standards and Technology Gaithersburg, MD 20899-8930 September 2011 DRAFT U.S. Department of Commerce Rebecca M. Blank, Acting Secretary National Institute of Standards and Technology Patrick D. Gallagher, Under Secretary for Standards and Technology and Director

Reports on Computer Systems Technology The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the nation s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analysis to advance the development and productive use of information technology. ITL s responsibilities include the development of technical, physical, administrative, and management standards and guidelines for the cost-effective security and privacy of sensitive unclassified information in Federal computer systems. This Special Publication (SP) 800-series reports on ITL s research, guidance, and outreach efforts in computer security and its collaborative activities with industry, government, and academic organizations. National Institute of Standards and Technology Special Publication 800-121 Revision 1 (Draft) Natl. Inst. Stand. Technol. Spec. Publ. 800-121 Revision 1, 49 pages (Sep. 2011) Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately. Such identification is not intended to imply recommendation or endorsement by the National Institute of Standards and Technology, nor is it intended to imply that the entities, materials, or equipment are necessarily the best available for the purpose. ii

Acknowledgments for Revision 1 The authors John Padgette of Accenture and Karen Scarfone of Scarfone Cybersecurity wish to thank their colleagues Lily Chen, Murugiah Souppaya, and Meltem Turan who reviewed drafts of this first revision of this document and contributed to its technical content. The authors greatly appreciate the feedback provided by Matthew Sexton of pureintegration and Kaisa Nyberg of Nokia. The authors would also like to thank Joe Jamaldinian of Booz Allen Hamilton for providing the new graphics. Acknowledgments for Original Version The authors, Karen Scarfone of the National Institute of Standards and Technology (NIST) and John Padgette of Booz Allen Hamilton, wish to thank their colleagues who reviewed drafts of the original version of this document and contributed to its technical content. The authors would like to acknowledge Sheila Frankel, Tim Grance, and Tom Karygiannis of NIST, and Derrick Dicoi, Matthew Sexton, and Michael Bang of Booz Allen Hamilton, for their keen and insightful assistance throughout the development of the document. The authors also greatly appreciate the feedback provided by representatives from the Department of State, Gerry Barsczewski (Social Security Administration), Alex Froede (Defense Information Systems Agency [DISA]), and Dave Wallace and Mark Nichols (Spanalytics). Note to Readers This document is the first revision to NIST SP 800-121, Guide to Bluetooth Security. Updates in this revision include the latest vulnerability mitigation information for Secure Simple Pairing, introduced in Bluetooth v2.1 + Enhanced Data Rate (EDR), as well as an introduction to and discussion of Bluetooth v3.0 + High Speed and Bluetooth v4.0 Low Energy security mechanisms and recommendations. iii

Table of Contents Executive Summary... 1 1. Introduction... 1-1 1.1 Authority...1-1 1.2 Purpose and Scope...1-1 1.3 Audience and Assumptions...1-1 1.4 Document Organization...1-2 2. Overview of Bluetooth Technology... 2-1 2.1 Bluetooth Technology Characteristics...2-1 2.1.1 Basic, Enhanced and High Speed Data Rates... 2-3 2.1.2 Low Energy... 2-3 2.1.3 Dual Mode Devices (Concurrent LE & BR/EDR/HS Support)... 2-4 2.2 Bluetooth Architecture...2-5 3. Bluetooth Security Features... 3-1 3.1 Security Features of Bluetooth BR/EDR/HS...3-2 3.1.1 Pairing and Link Key Generation... 3-3 3.1.2 Authentication... 3-7 3.1.3 Confidentiality... 3-8 3.1.4 Trust Levels, Service Levels, and Authorization... 3-11 3.2 Security Features of Bluetooth LE... 3-11 3.2.1 LE Security Modes and Levels... 3-12 3.2.2 LE Pairing Methods... 3-12 3.2.3 LE Key Generation and Distribution... 3-14 3.2.4 Confidentiality, Authentication, and Integrity... 3-15 4. Bluetooth Vulnerabilities, Threats, and Countermeasures... 4-1 4.1 Bluetooth Vulnerabilities...4-1 4.2 Bluetooth Threats...4-3 4.3 Risk Mitigation and Countermeasures...4-4 4.4 Bluetooth Security Checklists...4-5 List of Appendices Appendix A Glossary of Terms... A-1 Appendix B Acronyms and Abbreviations... B-1 Appendix C References... C-1 Appendix D Online Resources... D-1 iv

List of Figures Figure 2-1. Bluetooth v4.0 Device Architecture... 2-5 Figure 2-2. Bluetooth Ad Hoc Topology... 2-6 Figure 2-3. Bluetooth Networks (Multiple Scatternets)... 2-7 Figure 3-1. Bluetooth Air-Interface Security... 3-1 Figure 3-2. Link Key Generation from PIN... 3-4 Figure 3-3. Link Key Establishment for Secure Simple Pairing... 3-6 Figure 3-4. AMP Link Key Derivation... 3-7 Figure 3-5. Bluetooth Authentication... 3-7 Figure 3-6. Bluetooth Encryption Procedure... 3-10 Figure 3-7. Bluetooth Low Energy Pairing... 3-13 List of Tables Table 2-1. Bluetooth Device Classes of Power Management... 2-2 Table 2-2. Key Differences Between Bluetooth BR/EDR and LE... 2-4 Table 4-1. Key Problems with Native Bluetooth Security... 4-1 Table 4-2. Bluetooth Piconet Security Checklist... 4-6 v

Executive Summary Bluetooth is an open standard for short-range radio frequency (RF) communication. Bluetooth technology is used primarily to establish wireless personal area networks (WPAN), commonly referred to as ad hoc or peer-to-peer (P2P) networks. Bluetooth technology has been integrated into many types of business and consumer devices, including cell phones, laptops, automobiles, printers, keyboards, mice, and headsets. This allows users to form ad hoc networks between a wide variety of devices to transfer voice and data. This document provides an overview of Bluetooth technology and discusses related security concerns. Several Bluetooth versions are currently in use in commercial devices. At the time of writing, Bluetooth 1.2 (adopted November 2003) and 2.0 + Enhanced Data Rate (EDR, adopted November 2004) are the most prevalent. Bluetooth 2.1 + EDR (adopted July 2007), which is quickly becoming the standard, provides significant security improvements for cryptographic key establishment in the form of Secure Simple Pairing (SSP). The most recent versions include Bluetooth 3.0 + High Speed (HS, adopted April 2009), which provides significant data rate improvements, and Bluetooth 4.0 Low Energy (LE, adopted June 2010), which supports smaller, resource-constrained devices and associated applications. This publication addresses the security of all these versions of Bluetooth. Bluetooth technology and associated devices are susceptible to general wireless networking threats, such as denial of service (DoS) attacks, eavesdropping, man-in-the-middle (MITM) attacks, message modification, and resource misappropriation. They are also threatened by more specific Bluetooth-related attacks that target known vulnerabilities in Bluetooth implementations and specifications. Attacks against improperly secured Bluetooth implementations can provide attackers with unauthorized access to sensitive information and unauthorized use of Bluetooth devices and other systems or networks to which the devices are connected. To improve the security of Bluetooth implementations, organizations should implement the following recommendations: Organizations should use the strongest Bluetooth security mode available for their Bluetooth devices. The Bluetooth specifications define several security modes, and each version of Bluetooth supports some, but not all, of these modes. The modes differ primarily by the point at which the device initiates security; hence, these modes define how well they protect Bluetooth communications and devices from potential attack. For Bluetooth Basic Rate (BR), EDR, and HS, Security Mode 3 is the strongest mode because it requires establishment of authentication and encryption before the Bluetooth physical link is completely established. Security Modes 2 and 4 can also use authentication and encryption, but do not initiate them until after the Bluetooth physical link has already been fully established and logical channels partially established. Security Mode 1 devices never initiate security and therefore should never be used. For Bluetooth LE (introduced in Version 4.0), Security Mode 1 Level 3 is considered the strongest mode because it requires authenticated pairing and encryption. Other security modes/levels allow unauthenticated pairing (meaning no man-in-the-middle protection is provided during cryptographic key establishment), and some do not require any security at all. The available modes vary based on the Bluetooth specification version supported by the device, so organizations should choose the most secure mode available for each case. ES-1

Organizations should address Bluetooth technology it in their security policies and change default settings of Bluetooth devices to reflect the policies. A security policy that defines requirements for Bluetooth security is the foundation for all other Bluetooth-related countermeasures. The policy should include a list of approved uses for Bluetooth, a list of the types of information that may be transferred over Bluetooth networks, and requirements for selecting and using Bluetooth personal identification numbers (PINs), where applicable. After establishing a Bluetooth security policy, organizations should ensure that Bluetooth devices default settings are reviewed and changed as needed so that they comply with the security policy requirements. For example, a typical requirement is to disable unneeded Bluetooth profiles and services to reduce the number of vulnerabilities that attackers could attempt to exploit. When available, a centralized security policy management approach should be used to ensure device configurations are compliant. Organizations should ensure that their Bluetooth users are made aware of their security-related responsibilities regarding Bluetooth use. A security awareness program helps educate and train users to follow security practices that protect the assets of an organization and prevent security incidents. For example, users should be provided with a list of precautionary measures they should take to better protect handheld Bluetooth devices from theft. Users should also be made aware of other actions to take regarding Bluetooth device security, such as ensuring that Bluetooth devices are turned off when they are not needed to minimize exposure to malicious activities, and performing Bluetooth device pairing as infrequently as possible and ideally in a physically secure area where attackers cannot observe passkey entry and eavesdrop on Bluetooth pairing-related communications. ES-2

1. Introduction 1.1 Authority The National Institute of Standards and Technology (NIST) developed this document in furtherance of its statutory responsibilities under the Federal Information Security Management Act (FISMA) of 2002, Public Law 107-347. NIST is responsible for developing standards and guidelines, including minimum requirements, for providing adequate information security for all agency operations and assets; however, such standards and guidelines shall not apply to national security systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130, Section 8b (3), Securing Agency Information Systems, as analyzed in A-130, Appendix IV: Analysis of Key Sections. Supplemental information is provided in A-130, Appendix III. This guideline has been prepared for use by Federal agencies. It may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright, although attribution is requested. Nothing in this document should be taken to contradict standards and guidelines made mandatory and binding on Federal agencies by the Secretary of Commerce under statutory authority nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, Director of the OMB, or any other Federal official. 1.2 Purpose and Scope The purpose of this document is to provide information to organizations on the security capabilities of Bluetooth and provide recommendations to organizations employing Bluetooth technologies on securing them effectively. The Bluetooth versions within the scope of this publication are versions 1.1, 1.2, 2.0 + Enhanced Data Rate (EDR), 2.1 + EDR, 3.0 + High Speed (HS), and 4.0 Low Energy (LE). 1.3 Audience and Assumptions This document discusses Bluetooth technologies and security capabilities in technical detail. This document assumes that the readers have at least some operating system, wireless networking, and security knowledge. Because of the constantly changing nature of the wireless security industry and the threats and vulnerabilities to the technologies, readers are strongly encouraged to take advantage of other resources (including those listed in this document) for more current and detailed information. The following list highlights people with differing roles and responsibilities that might use this document: Government managers (e.g., chief information officers and senior managers) who oversee the use and security of Bluetooth technologies within their organizations Systems engineers and architects who design and implement Bluetooth technologies Auditors, security consultants, and others who perform security assessments of wireless environments Researchers and analysts who are trying to understand the underlying wireless technologies. 1-1

1.4 Document Organization The remainder of this document is composed of the following sections and appendices: Section 2 provides an overview of Bluetooth technology, including its benefits, technical characteristics, and architecture. Section 3 discusses the security features defined in the Bluetooth specifications and highlights their limitations. Section 4 examines common vulnerabilities and threats involving Bluetooth technologies and makes recommendations for countermeasures to improve Bluetooth security. Appendix A provides a glossary of terms. Appendix B provides a list of acronyms and abbreviations used in this document. Appendix C lists Bluetooth references. Appendix D lists Bluetooth online resources. 1-2

2. Overview of Bluetooth Technology Bluetooth is an open standard for short-range radio frequency (RF) communication. Bluetooth technology is used primarily to establish wireless personal area networks (WPAN), commonly referred to as ad hoc or peer-to-peer (P2P) networks. Bluetooth technology has been integrated into many types of business and consumer devices, including cell phones, laptops, automobiles, printers, keyboards, mice, and headsets. This allows users to form ad hoc networks between a wide variety of devices to transfer voice and data. Bluetooth is a low-cost, low-power technology that provides a mechanism for creating small wireless networks on an ad hoc basis, known as piconets. 1 A piconet is composed of two or more Bluetooth devices in close physical proximity that operate on the same channel using the same frequency hopping sequence. An example of a piconet is a Bluetooth-based connection between a cell phone and a headset. Bluetooth piconets are often established on a temporary and changing basis, which offers communications flexibility and scalability between mobile devices. Some key benefits of Bluetooth technology are Cable replacement. Bluetooth technology replaces a variety of cables, such as those traditionally used for peripheral devices (e.g., mouse and keyboard connections), printers, and wireless headsets and earbuds that interface with desktops, laptops, cell phones, etc. Ease of file sharing. A Bluetooth-enabled device can form a piconet to support file sharing capabilities with other Bluetooth devices, such as laptops. Wireless synchronization. Bluetooth provides automatic synchronization between Bluetoothenabled devices. For example, Bluetooth allows synchronization of contact information contained in electronic address books and calendars. Internet connectivity. A Bluetooth device with Internet connectivity can share that access with other Bluetooth devices. For example, a laptop can use a Bluetooth connection to direct a cell phone to establish a dial-up connection so that the laptop can access the Internet through the phone. Bluetooth technology was originally conceived by Ericsson in 1994. Ericsson, IBM, Intel, Nokia, and Toshiba formed the Bluetooth Special Interest Group (SIG), a not-for-profit trade association developed to drive development of Bluetooth products and serve as the governing body for Bluetooth specifications. 2 Bluetooth is standardized within the IEEE 802.15 Working Group for Wireless Personal Area Networks that formed in early 1999 as IEEE 802.15.1-2002. 3 This section provides an overview of Bluetooth technology, including frequency and data rates, range, and architecture. 2.1 Bluetooth Technology Characteristics Bluetooth operates in the unlicensed 2.4000 gigahertz (GHz) to 2.4835 GHz Industrial, Scientific, and Medical (ISM) frequency band. Numerous technologies operate in this band, including the IEEE 802.11b/g wireless local area network (WLAN) standard, making it somewhat crowded from the standpoint of the volume of wireless transmissions. Bluetooth employs frequency hopping spread spectrum (FHSS) technology for all transmissions. FHSS reduces interference and transmission errors and provides a limited level of transmission security. With FHSS technology, communications between 1 2 3 As discussed in Section 2.2, the term piconet applies to both ad hoc and infrastructure Bluetooth networks. The Bluetooth SIG website (http://www.bluetooth.com/) is a resource for Bluetooth-related information and provides numerous links to other sources of information. For more information, see the IEEE website at http://grouper.ieee.org/groups/802/15/. 2-1

Bluetooth BR/EDR devices use 79 different 1 megahertz (MHz) radio channels by hopping (i.e., changing) frequencies about 1,600 times per second for data/voice links and 3,200 times per second during page and inquiry scanning. A channel is used for a very short period (e.g., 625 microseconds for data/voice links), followed by a hop to another channel designated by a pre-determined pseudo-random sequence; this process is repeated continuously in the frequency hopping sequence. Bluetooth also provides for radio link power control, which allows devices to negotiate and adjust their radio power according to signal strength measurements. Each device in a Bluetooth network can determine its received signal strength indication (RSSI) and request that the other network device adjust its relative radio power level (i.e., incrementally increase or decrease the transmission power). This is performed to conserve power and/or to keep the received signal characteristics within a preferred range. If the Bluetooth power control feature is used appropriately, any potential adversary is forced to be in relatively close proximity to pose a threat to a Bluetooth piconet, especially if the Bluetooth devices are very close to each other. The combination of a frequency hopping scheme and radio link power control provides Bluetooth with some additional, albeit limited, protection from eavesdropping and malicious access. The frequencyhopping scheme, primarily a technique to avoid interference, makes it slightly more difficult for an adversary to locate and capture Bluetooth transmissions than to capture transmissions from fixedfrequency technologies, like those used in IEEE 802.11b/g. Research published in 2007 has shown that the Bluetooth frequency hopping sequence for an active piconet can be determined using relatively inexpensive hardware and free open source software. 4 The range of Bluetooth BR/EDR devices is characterized by three classes that define power management. Table 2-1 summarizes the classes, including their power levels in milliwatts (mw) and decibels referenced to one milliwatt (dbm), and their operating ranges in meters (m). 5 Most small, batterypowered devices are Class 2, while Class 1 devices are typically universal serial bus (USB) adapters for desktops and laptops, as well as access points and other mains powered devices. Table 2-1. Bluetooth Device Classes of Power Management Type Power Max Power Level Designed Operating Range Sample Devices Class 1 High 100 mw (20 dbm) Up to 100 meters (328 feet) USB adapters, access points Class 2 Medium 2.5 mw (4 dbm) Up to 10 meters (33 feet) Mobile devices, Bluetooth adapters, smart card readers Class 3 Low 1 mw (0 dbm) Up to 1 meter (3 feet) Bluetooth adapters To allow Bluetooth devices to find and establish communication with each other, discoverable and connectable modes are specified. A device in discoverable mode periodically monitors an inquiry scan physical channel (based on a specific set of frequencies) and responds to an inquiry on that channel with its device address, local clock, and other characteristics needed to page and subsequently connect to it. A device in connectable mode periodically monitors its page scan physical channel and responds to a page on that channel to initiate a network connection. The frequencies associated with the page scan physical 4 5 For more information, see Dominic Spill and Andrea Bittau s 2007 research paper: http://www.usenix.org/event/woot07/tech/full_papers/spill/spill.pdf The ranges listed in Table 2-1 are the designed operating ranges. Attackers may be able to intercept communications at significantly larger distances, especially if they use high-gain antennas and high-sensitivity receivers. 2-2

channel for a device are based on its Bluetooth device address. Therefore, knowing a device s address and local clock 6 is important for paging and subsequently connecting to the device. The following sections cover Bluetooth BR/EDR/HS data rates, LE technology, and dual-mode devices. 2.1.1 Basic, Enhanced and High Speed Data Rates Bluetooth devices can support multiple data rates using native Bluetooth and alternate Medium Access Controls (MAC) and Physical Layers (PHY). Because Bluetooth specifications are designed to be backward-compatible, a later specification device that supports higher data rates also supports the lower data rates supported by earlier specification devices (e.g., an EDR device also supports rates specified for BR devices). The following sections provide an overview for Bluetooth and alternate MAC/PHYs, as well as associated data rates and modulation schemes. 2.1.1.1 Basic Rate/Enhanced Data Rate Bluetooth versions 1.1 and 1.2 only support transmission speeds of up to 1 megabit per second (Mbps), which is known as Basic Rate (BR), and can achieve throughput of approximately 720 kilobits per second (kbps). Introduced in Bluetooth version 2.0, Enhanced Data Rate (EDR) specifies data rates up to 3 Mbps and throughput of approximately 2.1 Mbps. BR uses Gaussian Frequency-Shift Keying (GFSK) modulation to achieve a 1 Mbps data rate. EDR uses π/4 rotated Differential Quaternary Phase Shift Keying (DQPSK) modulation to achieve a 2 Mbps data rate, and 8 phase Differential Phase Shift Keying (8DPSK) to achieve a 3 Mbps data rate. Note that EDR support is not required for devices compliant with the Bluetooth 2.0 specification or later. Therefore, there are devices on the market that are Bluetooth 2.0 compliant versus Bluetooth 2.0 + EDR compliant. The former are devices that support required version 2.0 features but only provide the BR data rate. 2.1.1.2 High Speed with Alternate MAC/PHY Introduced in the Bluetooth 3.0 + HS specification, devices can support faster data rates by using Alternate MAC/PHYs (AMP). This is known as Bluetooth High Speed (HS). In the Bluetooth 3.0 + HS specification, IEEE 802.11-2007 was introduced as the first supported AMP. IEEE 802.11-2007 is a rollup of the amendments IEEE 802.11a through 802.11j. For the 802.11 AMP, IEEE 802.11g PHY support is mandatory, while IEEE 802.11a PHY support is optional. The 802.11 AMP is designed to provide data rates up to 24 Mbps using Orthogonal Frequency-Division Multiplexing (OFDM) modulation. Note that this AMP is IEEE 802.11 compliant but not Wi-Fi compliant. Therefore, Wi-Fi Alliance specification compliance is not required for Bluetooth 3.0 + HS devices. 2.1.2 Low Energy Bluetooth LE was introduced in the Bluetooth 4.0 specification. Formerly known as Wibree and Ultra Low Power Bluetooth, LE is primarily designed to bring Bluetooth technology to coin cell batterypowered devices such as medical devices and other sensors. The key technology goals of Bluetooth LE 6 Having a remote device s clock information is not needed to make a connection, but it will speed up the connection process. 2-3

(compared with Bluetooth BR/EDR) include lower power consumption, reduced memory requirements, efficient discovery and connection procedures, short packet lengths, and simple protocols and services. Table 2-2 provides the key technical differences between BR/EDR and LE. Table 2-2. Key Differences Between Bluetooth BR/EDR and LE Characteristic Bluetooth BR/EDR Bluetooth LE RF Physical Channels 79 channels with 1 MHz channel spacing 40 channels with 2 MHz channel spacing Discovery/Connect Inquiry/Paging Advertising Number of Piconet Slaves 7 (active)/255 (total) Unlimited Device Address Privacy None Private device addressing available Max Data Rate 1 3 Mbps 1 Mbps via GFSK modulation Encryption Algorithm E0/SAFER+ AES-CCM Typical Range 30 meters 50 meters Max Output Power 100 mw (20 dbm) 10 mw (10 dbm) 2.1.3 Dual Mode Devices (Concurrent LE & BR/EDR/HS Support) A Bluetooth v4.0 device may support both BR/EDR/HS and LE as a dual mode Bluetooth device. An example is a cell phone that uses an EDR link to a Bluetooth headset and a concurrent LE link to a sensor that unlocks and starts the user s automobile. Figure 2-1 shows the device architecture for Bluetooth v4.0 devices, and includes BR/EDR, HS and LE technologies. New terms included in the figure related to security are discussed in subsequent sections. 2-4

Figure 2-1. Bluetooth v4.0 Device Architecture 2.2 Bluetooth Architecture Bluetooth permits devices to establish ad hoc networks. Ad hoc networks allow easy connection establishment between devices in the same physical area (e.g., the same room) without the use of any infrastructure devices. A Bluetooth client is simply a device with a Bluetooth radio and software incorporating the Bluetooth protocol stack and interfaces. The Bluetooth specification provides separation of duties for performing stack functions between a host and a controller. The host is responsible for the higher layer protocols, such as Logical Link Control and Adaptation Protocol (L2CAP) and Service Discovery Protocol (SDP). The host functions are performed by a computing device like a laptop or smartphone. The controller is responsible for the lower layers, including the Radio, Baseband, and Link Control/Management. The controller functions are performed by an integrated or external (e.g., USB) Bluetooth adapter. The host and controller send information to each other using standardized communications over the Host Controller Interface (HCI). This standardized HCI allows hosts and controllers from different product vendors to interoperate. In some cases, the host and controller functions are integrated into a single device; Bluetooth headsets are a prime example. 2-5

Figure 2-2 depicts the basic Bluetooth network topology. In a piconet one device serves as the master, with all other devices in the piconet acting as slaves. BR/EDR piconets can scale to include up to 7 active slave devices and up to 255 inactive slave devices. The new Bluetooth LE technology (see Section 2.1.2) allows an unlimited number of slaves. Figure 2-2. Bluetooth Ad Hoc Topology The master device controls and establishes the network, including defining the network s frequency hopping scheme. Although only one device can serve as the master for each piconet, time division multiplexing (TDM) allows a slave in one piconet to act as the master for another piconet simultaneously, thus creating a chain of networks. 7 This chain, called a scatternet, allows networking of several devices over an extended distance in a dynamic topology that can change during any given session. As a device moves toward or away from the master device the topology may change, along with the relationships of the devices in the immediate network. Figure 2-3 depicts a scatternet that involves three piconets. 7 Note that a particular device can only be the master of one piconet at any given time. 2-6

Figure 2-3. Bluetooth Networks (Multiple Scatternets) The Bluetooth core protocols provide no multi-hop network routing capabilities for devices involved in scatternets. For example in Figure 2-3, User C s PDA in Piconet 3 cannot communicate with User B s PDA or Mobile Phone in Piconet 2 without establishing an additional piconet between them. Scatternets are only available to BR/EDR devices, because Bluetooth LE technology does not support that feature. 2-7

3. Bluetooth Security Features This section provides an overview of the security mechanisms included in the Bluetooth specifications to illustrate their limitations and provide a foundation for the security recommendations in Section 4. A high-level example of the scope of the security for the Bluetooth radio path is depicted in Figure 3-1. In this example, Bluetooth security is provided between the phone and the laptop, while IEEE 802.11 security protects the WLAN link between the laptop and the IEEE 802.11 AP. Communications on the wired network are not protected by Bluetooth or IEEE 802.11 security capabilities. Therefore, end-to-end security is not possible without using higher-layer security solutions atop the security features included in Bluetooth and IEEE 802.11. Figure 3-1. Bluetooth Air-Interface Security Three basic security services are specified in the Bluetooth standard: Authentication: verifying the identity of communicating devices based on their Bluetooth device address. Bluetooth does not provide native user authentication. Confidentiality: preventing information compromise caused by eavesdropping by ensuring that only authorized devices can access and view transmitted data. Authorization: allowing the control of resources by ensuring that a device is authorized to use a service before permitting it to do so. The three security services offered by Bluetooth and details about the modes of security are described below. Bluetooth does not address other security services such as audit and non-repudiation; if such services are needed, they should be provided through additional means. 3-1

3.1 Security Features of Bluetooth BR/EDR/HS Cumulatively, the family of Bluetooth BR/EDR/HS specifications defines four security modes. Each Bluetooth device must operate in one of these modes, called Security Modes 1 through 4. These modes dictate when a Bluetooth device initiates security, not whether it supports security features. Security Mode 1 devices are considered non-secure. Security functionality (authentication and encryption) is never initiated, leaving the device and connections susceptible to attackers. In effect, Bluetooth devices in this mode are indiscriminate and do not employ any mechanisms to prevent other Bluetooth-enabled devices from establishing connections. However, if a remote device initiates security such as a pairing, authentication, or encryption request a Security Mode 1 device will participate. Per their respective Bluetooth specification versions, all v2.0 and earlier devices can support Security Mode 1, and v2.1 and later devices can use Security Mode 1 for backward compatibility with older devices. However, NIST recommends never using Security Mode 1. In Security Mode 2, a service level-enforced security mode, security procedures may be initiated after link establishment but before logical channel establishment. For this security mode, a local security manager (as specified in the Bluetooth architecture) controls access to specific services. The centralized security manager maintains policies for access control and interfaces with other protocols and device users. Varying security policies and trust levels to restrict access can be defined for applications with different security requirements operating in parallel. It is possible to grant access to some services without providing access to other services. In this mode, the notion of authorization the process of deciding whether a specific device is allowed to have access to a specific service is introduced. It is important to note that the authentication and encryption mechanisms used for Security Mode 2 are implemented in the controller, as with Security Mode 3 described below. All v2.0 and earlier devices can support Security Mode 2, but v2.1 and later devices can only support it for backward compatibility with v2.0 or earlier devices. Security Mode 3 is the link level-enforced security mode, in which a Bluetooth device initiates security procedures before the physical link is fully established. Bluetooth devices operating in Security Mode 3 mandate authentication and encryption for all connections to and from the device. All v2.0 and earlier devices can support Security Mode 3, but v2.1 devices can only support it for backward compatibility purposes. Similar to Security Mode 2, Security Mode 4 (introduced in Bluetooth v2.1 + EDR) is a service-levelenforced security mode in which security procedures are initiated after physical and logical link setup. Security Mode 4 uses Secure Simple Pairing (SSP), in which Elliptic Curve Diffie-Hellman (ECDH) replaces legacy key agreement for link key generation (see Section 3.1.1). However, the device authentication and encryption algorithms are identical to the algorithms in Bluetooth v2.0 + EDR and earlier versions. Security requirements for services protected by Security Mode 4 must be classified as one of the following: Authenticated link key required Unauthenticated link key required No security required. Whether or not a link key is authenticated depends on the SSP association model used (see Section 3.1.1.2). Security Mode 4 requires encryption for all services (except Service Discovery) and is mandatory for communication between v2.1 and later BR/EDR devices. However, for backward 3-2

compatibility, a Security Mode 4 device can fall back to any of the other three Security Modes when communicating with Bluetooth v2.0 and earlier devices that do not support Security Mode 4. In this case, NIST recommends using Security Mode 3. The remainder of this section discusses specific Bluetooth security components in more detail pairing and link key generation, authentication, confidentiality, and other Bluetooth security features. 3.1.1 Pairing and Link Key Generation Essential to the authentication and encryption mechanisms provided by Bluetooth is the generation of a secret symmetric key, called the link key. As mentioned in Section 3.1, Bluetooth BR/EDR performs pairing (i.e., link key generation) in one of two ways. Security Modes 2 and 3 initiate link key establishment via a method called Personal Identification Number (PIN) Pairing (i.e., Legacy or Classic Pairing), while Security Mode 4 uses SSP. Both methods are described below. 3.1.1.1 PIN Pairing For PIN pairing, two Bluetooth devices simultaneously derive link keys when the user(s) enter an identical secret PIN into one or both devices, depending on the configuration and device type. The PIN entry and key derivation are depicted conceptually in Figure 3-2. Note that if the PIN is less than 16 bytes, the initiating device s address (BD_ADDR) supplements the PIN value to generate the initialization key. The E x boxes represent encryption algorithms that are used during the Bluetooth link key derivation processes. More details on the Bluetooth authentication and encryption procedures are outlined in Sections 3.1.2 and 3.1.3, respectively. 3-3

Figure 3-2. Link Key Generation from PIN After link key generation is complete, the devices complete pairing by mutually authenticating each other to verify they have the same link key. The PIN code used in Bluetooth pairing can vary between 1 and 16 bytes or alphanumeric characters. The typical four-digit PIN may be sufficient for low-risk situations; a longer PIN (e.g., 8-character alphanumeric) should be used for devices that require a higher level of security. 8 8 The Bluetooth Security White Paper from the Bluetooth Special Interest Group is available at http://grouper.ieee.org/groups/1451/5/comparison%20of%20phy/bluetooth_24security_paper.pdf. 3-4

3.1.1.2 Secure Simple Pairing SSP was introduced in Bluetooth v2.1 + EDR for use with Security Mode 4. SSP simplifies the pairing process by providing a number of association models that are flexible in terms of device input/output capability. SSP also improves security through the addition of ECDH public key cryptography for protection against passive eavesdropping and man-in-the-middle attacks (MITM) during pairing. The four association models offered in SSP are as follows: 9 Numeric Comparison was designed for the situation where both Bluetooth devices are capable of displaying a six-digit number and allowing a user to enter a yes or no response. During pairing, a user is shown a six-digit number on each display and provides a yes response on each device if the numbers match. Otherwise, the user responds no and pairing fails. A key difference between this operation and the use of PINs in legacy pairing is that the displayed number is not used as input for link key generation. Therefore, an eavesdropper who is able to view (or otherwise capture) the displayed value could not use it to determine the resulting link or encryption key. Passkey Entry was designed for the situation where one Bluetooth device has input capability (e.g., keyboard), while the other device has a display but no input capability. In this model, the device with only a display shows a six-digit number that the user then enters on the device with input capability. As with the Numeric Comparison model, the six-digit number used in this transaction is not incorporated into link key generation and is of no use to an eavesdropper. Just Works was designed for the situation where at least one of the pairing devices has neither a display nor a keyboard for entering digits (e.g., headset). It performs Authentication Stage 1 (see Figure 3-3) in the same manner as the Numeric Comparison model, except that a display is not available. The user is required to accept a connection without verifying the calculated value on both devices, so Just Works provides no MITM protection. Out of Band (OOB) was designed for devices that support a common additional wireless/wired technology (e.g., Near Field Communication or NFC) for the purposes of device discovery and cryptographic value exchange. In the case of NFC, the OOB model allows devices to pair by simply tapping one device against the other, followed by the user accepting the pairing via a single button push. It is important to note that to keep the pairing process as secure as possible, the OOB technology should be designed and configured to mitigate eavesdropping and MITM attacks. Security Mode 4 requires Bluetooth services to mandate an authenticated link key, an unauthenticated link key, or no security at all. Of the association models described above, all but the Just Works model provide authenticated link keys. Figure 3-3 shows how the link key is established for SSP. Note how this technique uses ECDH public/ private key pairs rather than generating a symmetric key via a PIN. 9 This information is derived from the Bluetooth 2.1 specification, which is available at https://www.bluetooth.org/technical/specifications/adopted.htm. 3-5

Figure 3-3. Link Key Establishment for Secure Simple Pairing 3.1.1.3 AMP Link Key Derivation from Bluetooth Link Key For AMP link security (e.g., IEEE 802.11, as introduced in Bluetooth v3.0), an AMP link key is derived from the Bluetooth link key. A Generic AMP Link Key (GAMP_LK) is generated by the AMP Manager in the host stack whenever a Bluetooth link key is created or changed. As shown in Figure 3-4, the GAMP_LK is generated using the Bluetooth link key (concatenated with itself) and an extended ASCII key identifier (keyid) of gamp as inputs to a HMAC-SHA-256 function. Subsequently, a Dedicated AMP Link Key (for a specific AMP and Trusted Device combination) is derived from the Generic AMP Link Key and keyid. For the 802.11 AMP Link Key, the keyid is 802b. For IEEE 802.11 AMPs, the Dedicated AMP Link Key is used as the 802.11 Pairwise Master Key. See NIST Special Publication 800-97, Establishing Wireless Robust Security Networks: A Guide to IEEE 802.11i 10, for more information about IEEE 802.11 security. 10 Download a copy of NIST SP 800-97 here: http://csrc.nist.gov/publications/nistpubs/800-97/sp800-97.pdf 3-6

Figure 3-4. AMP Link Key Derivation 3.1.2 Authentication The Bluetooth device authentication procedure is in the form of a challenge response scheme. Each device interacting in an authentication procedure is referred to as either the claimant or the verifier. The claimant is the device attempting to prove its identity, and the verifier is the device validating the identity of the claimant. The challenge response protocol validates devices by verifying the knowledge of a secret key the Bluetooth link key. Figure 3-5 conceptually depicts the challenge response verification scheme. Figure 3-5. Bluetooth Authentication 3-7

The steps in the authentication process are as follows: Step 1. The verifier transmits a 128-bit random challenge (AU_RAND) to the claimant. Step 2. The claimant uses the E 1 algorithm 11 to compute an authentication response using his or her unique 48-bit Bluetooth device address (BD_ADDR), the link key, and AU_RAND as inputs. The verifier performs the same computation. Only the 32 most significant bits of the E 1 output are used for authentication purposes. The remaining 96 bits of the 128-bit output are known as the Authenticated Ciphering Offset (ACO) value, which will be used later as input to create the Bluetooth encryption key. Step 3. The claimant returns the most significant 32 bits of the E 1 output as the computed response, the Signed Response (SRES), to the verifier. Step 4. The verifier compares the SRES from the claimant with the value that it computed. Step 5. If the two 32-bit values are equal, the authentication is considered successful. If the two 32-bit values are not equal, the authentication fails. Performing these steps once accomplishes one-way authentication. The Bluetooth standard allows both one-way and mutual authentication to be performed. For mutual authentication, the above process is repeated with the verifier and claimant switching roles. If authentication fails, a Bluetooth device waits an interval of time before making a new attempt. This time interval increases exponentially to prevent an adversary from attempting to gain access by defeating the authentication scheme through trial-and-error with different link keys. It is important to note that this technique does not provide security against offline attacks to determine the link key using eavesdropped pairing frames and exhaustively guessing PINs. Note that the security associated with authentication is solely based on the secrecy of the link key. While the Bluetooth device addresses and random challenge value are considered public parameters, the link key is not. The link key is derived during pairing and should never be disclosed outside the Bluetooth device or transmitted over wireless links. However, the link key is passed in the clear from the host to the controller (e.g., PC to USB adapter) and the reverse when the host is used for key storage. The challenge value, which is a public parameter associated with the authentication process, must be random and unique for every transaction. The challenge value is derived from a pseudo-random generator within the Bluetooth silicon. 3.1.3 Confidentiality In addition to the Security Modes for pairing and authentication, Bluetooth provides a separate confidentiality service to thwart attempts to eavesdrop on the payloads of the packets exchanged between Bluetooth devices. Bluetooth has three Encryption Modes, but only two of them actually provide confidentiality. The modes are as follows: Encryption Mode 1 No encryption is performed on any traffic. Encryption Mode 2 Individually addressed traffic is encrypted using encryption keys based on individual link keys; broadcast traffic is not encrypted. 11 The E 1 authentication function is based on the SAFER+ algorithm. SAFER stands for Secure And Fast Encryption Routine. The SAFER algorithms are iterated block ciphers (IBCs). In an IBC, the same cryptographic function is applied for a specified number of rounds. 3-8

Encryption Mode 3 All traffic is encrypted using an encryption key based on the master link key. Encryption Modes 2 and 3 use the same encryption mechanism. Security Mode 4 introduced in Bluetooth 2.1 + EDR requires that encryption be used for all data traffic, except for service discovery. As shown in Figure 3-6, the encryption key provided to the encryption algorithm is produced using an internal key generator (KG). The KG produces stream cipher keys based on the 128-bit link key, which is a secret that is held in the Bluetooth devices; a 128-bit random number (EN_RAND); and the 96-bit ACO value. The ACO is produced during the authentication procedure, as shown in Figure 3-4. The Bluetooth encryption procedure is based on a stream cipher, E 0. A key stream output is exclusive-ored with the payload bits and sent to the receiving device. This key stream is produced using a cryptographic algorithm based on linear feedback shift registers (LFSRs). 12 The encryption function takes the following as inputs: the master device address (BD_ADDR), the 128-bit random number (EN_RAND), a slot number based on the piconet clock, and an encryption key, which when combined initialize the LFSRs before the transmission of each packet, if encryption is enabled. The slot number used in the stream cipher changes with each packet; the ciphering engine is also reinitialized with each packet while the other variables remain static. 12 LFSRs are used in coding (error control coding) theory and cryptography. LFSR-based key stream generators (KSG), composed of exclusive-or gates and shift registers, are common in stream ciphers and are very fast in hardware. 3-9

Figure 3-6. Bluetooth Encryption Procedure The encryption key (K C ) is derived from the current link key and may vary in single byte increments from 1 byte to 16 bytes in length, as set during a negotiation process that occurs between the master and slave devices. During this negotiation, a master device makes a key size suggestion for the slave. The initial key size suggested by the master is programmed into the controller by the manufacturer and is not always 16 bytes. In product implementations, a minimum acceptable key size parameter can be set to prevent a malicious user from driving the key size down to the minimum of 1 byte, which would make the link less secure. It is important to note that E 0 is not a Federal Information Processing Standards (FIPS) approved algorithm and has come under scrutiny in terms of algorithmic strength. 13 A published theoretical knownplaintext attack can recover the encryption key in 2 38 computations, compared with a brute force attack, which would require testing 2 128 possible keys. If communications require FIPS-approved cryptographic 13 Y. Lu, W. Meier, and S. Vaudenay. The Conditional Correlation Attack: A Practical Attack on Bluetooth Encryption. http://lasecwww.epfl.ch/pub/lasec/doc/lmv05.pdf 3-10

protection (e.g., to protect sensitive information transmitted by Federal agencies), this protection can be achieved by layering application-level FIPS-approved encryption over the native Bluetooth encryption. 3.1.4 Trust Levels, Service Levels, and Authorization In addition to the four security modes, Bluetooth allows two levels of trust and three levels of service security. The two Bluetooth levels of trust are trusted and untrusted. A trusted device has a fixed relationship with another device and has full access to all services. An untrusted device does not have an established relationship with another Bluetooth device, which results in the untrusted device receiving restricted access to services. The Bluetooth specification specifies three levels of security for Bluetooth services. These levels allow independent configuration and alteration of the requirements for authorization, authentication, and encryption. The service security levels are as follows: Service Level 1 Requires authorization and authentication. Automatic access is granted only to trusted devices; untrusted devices need manual authorization. Service Level 2 Requires authentication only; authorization is not necessary. Access to an application is allowed only after an authentication procedure. Service Level 3 Open to all devices, with no authentication required. Access is granted automatically. The Bluetooth architecture allows for defining security policies that can set trust relationships in such a way that even trusted devices could gain access only to specific services. Although Bluetooth core protocols can only authenticate devices and not users, user-based authentication is still possible. The Bluetooth security architecture (through the security manager) allows applications to enforce more granular security policies. The link layer which Bluetooth-specific security controls operate at is transparent to the security controls imposed by the application layers. Thus, user-based authentication and fine-grained access control within the Bluetooth security framework are possible through the application layers, although doing so is beyond the scope of the Bluetooth specification. 3.2 Security Features of Bluetooth LE Because of the intent for Bluetooth LE to support computationally and storage-constrained devices, LE security is different from Bluetooth BR/EDR/HS. One difference is that LE pairing results in the generation of a Long-Term Key (LTK) rather than a Link Key. While fundamentally performing the same secret key function as the Link Key, the LTK is established in a different manner. The LTK is generated using a key transport protocol rather than key agreement as with BR/EDR. That is, one device determines the LTK and sends it over to the other device during pairing instead of both devices generating the same key individually. LE introduces the use of Advanced Encryption Standard Counter with CBC-MAC (AES-CCM) encryption for the first time in a Bluetooth specification. In addition to providing strong, standards-based encryption, the inclusion of AES-CCM paves the way for native FIPS-140 validation of Bluetooth LE devices in the future. LE also introduces features such as private device addresses and data signing. New cryptographic keys called the Identity Resolving Key (IRK) and Connection Signature Resolving Key (CSRK) support these features, respectively. The IRK is used to resolve public to private device address mapping. This allows a trusted device to determine another device s private device address from a public (random) device 3-11

address. This new security feature provides privacy for a particular device. Previously, a device would be assigned a static address that would be made available during discovery. If that device remained discoverable, its location could be tracked by an adversary. The CSRK is used to verify cryptographically signed data frames from a particular device. This allows a Bluetooth connection to use data signing (providing integrity and authentication) to protect the connection instead of data encryption (which, in the case of AES-CCM, provides confidentiality, integrity, and authentication). All of these cryptographic keys (i.e., LTK, IRK, CSRK) are generated and securely distributed during LE pairing. See Section 3.2.2 for details. 3.2.1 LE Security Modes and Levels LE security modes are similar to BR/EDR service-level security modes (i.e., Security Modes 2 and 4) in that each service can have its own security requirements. However, Bluetooth LE also specifies that each service request can have its own security requirements as well. A device enforces the service-related security requirements by following the appropriate security mode and level. LE Security Mode 1 has multiple levels associated with encryption. Level 1 specifies no security, meaning no authentication and no encryption will be initiated. Level 2 requires unauthenticated pairing with encryption. Level 3 requires authenticated pairing with encryption. LE Security Mode 2 has multiple levels associated with data signing. Data signing provides strong data integrity but not confidentiality. Level 1 requires unauthenticated pairing with data signing. Level 2 requires authenticated pairing with data signing. If a particular service request and the associated service have different security modes and/or levels, the stronger security requirements prevail. For example, if either requires Security Mode 1 Level 3, then the requirements for Security Mode 1 Level 3 are enforced. Because Security Mode 1 Level 3 requires authenticated pairing and encryption, NIST considers this the most secure of these modes/levels and strongly recommends its use for all connections. Security Mode 1 Level 1 is the least secure and should never be used. Also, because Security Mode 2 does not provide encryption, Security Mode 1 Level 3 is strongly preferred over Security Mode 2. 3.2.2 LE Pairing Methods Although LE uses similar pairing method names to BR/EDR SSP, LE pairing does not use ECDH-based cryptography and provides no eavesdropping protection. Therefore, if an attacker can capture the LE pairing frames, he/she may be able to determine the resulting LTK. Because key transport is used rather than key agreement for LE pairing, a key distribution step is required during LE pairing. As shown in Figure 3-7, LE pairing begins with the two devices agreeing on a Temporary Key (TK), whose value depends on the pairing method being used. The devices then exchange random values and generate a Short Term Key (STK) based on these values and the TK. The link is then encrypted using the STK, which allows secure key distribution of the LTK, IRK, and CSRK. 3-12

Figure 3-7. Bluetooth Low Energy Pairing The following subsections describe the LE pairing association models. As with BR/EDR SSP, the association model that is used for a particular connection is based on the input/output capabilities of both devices. It is important to note that the LE pairing association model names are similar to those from BR/EDR SSP association models, but the security the models provide are very different. 3.2.2.1 Out of Band If both devices support a common OOB technology, such as NFC or tethering, they will use the OOB method to pair. In this model, the TK is passed over the OOB technology from one device to the other. The TK should be unique, random, and equivalent to six decimal digits (i.e., in the hexadecimal range 0x0 0xF423F) at a minimum. NIST strongly recommends use of a full 128-bit random value when practical. Because OOB pairing results in an authenticated LTK, it should provide at least one-in-a-million protection against MITM attacks based on the premise that an attacker would have to successfully guess the six-digit TK value. However, the actual protection provided by OOB pairing depends on the MITM protection provided by the OOB technology itself because a successful OOB eavesdropper would know the TK value instead of having to guess it. 3.2.2.2 Passkey Entry If the devices do not support a common OOB technology, the pairing method to be used is determined based on the input/output capabilities of both devices. 3-13