NIST SP 800-121 Rev. 2 日本語訳

NIST Special Publication 800-121

Revision 2

John Padgette John Bahr Mayank Batra Marcel Holtmann Rhonda Smithbey Lily Chen Karen Scarfone

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-121r2-upd1

NIST Special Publication 800-121

Revision 2

John Padgette

Accenture Federal Services

Arlington, VA

John Bahr

Bahr Engineering

Superior, CO

Mayank Batra Qualcomm Tech. Intl., Ltd.

Cambridge, United Kingdom

Marcel Holtmann Intel Corporation Munich, Germany

Rhonda Smithbey

Spanalytics

Richmond, VA

Lily Chen

Computer Security Division Information

Technology Laboratory

Karen Scarfone

Scarfone Cybersecurity

Clifton, VA

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-121r2-upd1

May 2017

INCLUDES UPDATES AS OF 1-19-2022; SEE IX

U.S. Department of Commerce Wilbur L. Ross, Jr., Secretary

National Institute of Standards and Technology

Kent Rochford, Acting NIST Director and Under Secretary of Commerce for Standards and Technology

Authority

This publication has been developed by NIST in accordance with its statutory responsibilities under the Federal Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3551 et seq., Public Law (P.L.) 113-283. NIST is responsible for developing information security standards and guidelines, including minimum requirements for federal information systems, but such standards and guidelines shall not apply to national security systems without the express approval of appropriate federal officials exercising policy authority over such systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130.

Nothing in this publication should be taken to contradict the 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. This publication may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright in the United States. Attribution would, however, be appreciated by NIST.

National Institute of Standards and Technology Special Publication 800-121 Revision 2 Natl. Inst. Stand. Technol. Spec. Publ. 800-121 Rev. 2, 68 pages (May 2017) CODEN: NSPUE2

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-121r2-upd1

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 NIST, nor is it intended to imply that the entities, materials, or equipment are necessarily the best available for the purpose.

There may be references in this publication to other publications currently under development by NIST in accordance with its assigned statutory responsibilities. The information in this publication, including concepts and methodologies, may be used by federal agencies even before the completion of such companion publications. Thus, until each publication is completed, current requirements, guidelines, and procedures, where they exist, remain operative. For planning and transition purposes, federal agencies may wish to closely follow the development of these new publications by NIST.

Organizations are encouraged to review all draft publications during public comment periods and provide feedback to NIST. Many NIST cybersecurity publications, other than the ones noted above, are available at http://csrc.nist.gov/publications.

Comments on this publication may be submitted to: National Institute of Standards and Technology Attn: Computer Security Division, Information Technology Laboratory 100 Bureau Drive (Mail Stop 8930) Gaithersburg, MD 20899-8930 Email: 800-121r2comments@nist.gov

All comments are subject to release under the Freedom of Information Act (FOIA).

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 analyses to advance the development and productive use of information technology. ITL’s responsibilities include the development of management, administrative, technical, and physical standards and guidelines for the cost-effective security and privacy of other than national security-related information in federal information systems. The Special Publication 800-series reports on ITL’s research, guidelines, and outreach efforts in information system security, and its collaborative activities with industry, government, and academic organizations.

Bluetooth wireless technology is an open standard for short-range radio frequency communication used primarily to establish wireless personal area networks (WPANs), and has been integrated into many types of business and consumer devices. This publication provides information on the security capabilities of Bluetooth and gives recommendations to organizations employing Bluetooth wireless 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), 4.0, 4.1, and 4.2. Versions 4.0 and later support the low energy feature of Bluetooth.

Bluetooth; information security; network security; wireless networking; wireless personal area networks.

The authors, John Padgette of Accenture, John Bahr of Bahr Engineering (representing Philips Healthtech), Mayank Batra of Qualcomm, Marcel Holtmann of Intel, Rhonda Smithbey of Spanalytics, Lily Chen of the National Institute of Standards and Technology (NIST), and Karen Scarfone of Scarfone Cybersecurity, wish to thank their colleagues in the Bluetooth Security Experts Group (SEG) who contributed technical content and reviewed drafts of this document. The authors greatly appreciate the comments and feedback provided by Mark Nichols of Spanalytics, and the contributions of Alan Kozlay of Biometric Associates, LP. The authors would also like to acknowledge Catherine Brooks of the Bluetooth SIG technical staff for providing the new graphics. Lily Chen would like to acknowledge her NIST colleague Noah Waller for the help in drafting the errata.

Note to Readers

This document is the second revision to NIST SP 800-121, Guide to Bluetooth Security. Updates in this revision include an introduction to and discussion of Bluetooth 4.1 and 4.2 security mechanisms and recommendations, including Secure Connections for BR/EDR and low energy.

Bluetooth is an open standard for short-range radio frequency (RF) communication. Bluetooth wireless technology is used primarily to establish wireless personal area networks (WPANs). Bluetooth has been integrated into many types of business and consumer devices, including cell phones, laptops, automobiles, medical devices, printers, keyboards, mice, headsets, and, more recently, medical devices and personal devices (such as smart watches, music speakers, home appliances, fitness monitors, and trackers). 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 wireless technology and discusses related security concerns.

Several Bluetooth versions are currently in use in commercial devices, while the most current version can be found at bluetooth.com. At the time of writing, Bluetooth 4.0 (adopted June 2010) is the most prevalent. The most recent versions include Bluetooth 4.1 and Bluetooth 4.2. Bluetooth 4.1 (adopted December 2013) improved the strengths of the Basic Rate/Enhanced Data Rate (BR/EDR) technology cryptographic key, device authentication, and encryption by making use of Federal Information Processing Standard (FIPS)-approved algorithms. Bluetooth 4.2 (adopted December 2014) improved the strength of the low energy technology cryptographic key by making use of FIPS-approved algorithms, and provided means to convert BR/EDR technology keys to low energy technology keys and vice versa. This publication addresses the security of all versions of Bluetooth.

Bluetooth wireless 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 attacks related to Bluetooth wireless technology 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 that is 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. Some security modes have configurable security level settings which affect the security of the connections.

For Bluetooth 4.1 devices that have BR, EDR, and High Speed (HS) features, Security Mode 4, Level 4 is recommended because it requires Secure Connections, which uses authenticated pairing and encryption using 128-bit strength keys generated using FIPS-approved Advanced Encryption Standard (AES) encryption. For Bluetooth 2.1 through 4.0 devices, Security Mode 4, Level 3 is the most secure, and for Bluetooth 2.0 and older devices Security Mode 3 is recommended. 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 the low energy feature of Bluetooth (introduced in Version 4.0 and updated in 4.1 and 4.2), Security Mode 1 Level 4 is the strongest mode because it requires authenticated low energy Secure Connections pairing with Elliptic Curve Diffie-Hellman (ECDH) based encryption. Security Mode 1 Level 3 requires authenticated pairing and encryption but does not use ECDH-based cryptography and thus provides limited eavesdropping protection due to weak encryption. Other security modes/levels allow unauthenticated pairing (meaning no MITM 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.

Organizations should address Bluetooth wireless technology 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, if they are used, requirements for selecting and using Bluetooth personal identification numbers (PINs).¹ A baseline configuration for Bluetooth default settings should accompany the security policy. The checklist in Table 4-2 provides a “Technical Recommendations” section which may be used as a guide. 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.

Annual required security awareness programs should be updated to include Bluetooth security policy guidelines. 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.

Errata

This table contains changes that have been incorporated into NIST Special Publication (SP) 800-121 Revision 1. Errata updates can include corrections, clarifications, or other minor changes in the publication that are either editorial or substantive. Any potential updates for this document that are not yet published in a formal errata update or revision—including additional issues and potential corrections—will be posted as they are identified (see SP 800-121, Revision 2 publication details).

The purpose of this document is to provide information to organizations on the security capabilities of Bluetooth and provide recommendations to organizations employing Bluetooth wireless 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), 4.0, 4.1, and 4.2. Bluetooth with low energy functionality is present in 4.0 and later. Bluetooth 5.0 is not in the scope of this document.

This document discusses Bluetooth wireless 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:

The remainder of this document is composed of the following sections and appendices:

Bluetooth is an open standard for short-range radio frequency (RF) communication. Bluetooth is used primarily to establish wireless personal area networks (WPANs). Bluetooth has been integrated into many types of business and consumer devices, including cell phones, laptops, automobiles, printers, keyboards, mice, headsets, and, more recently, medical devices and personal devices (such as smart watches, music speakers, home appliances, fitness monitors, and trackers). 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.² 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 connection between a cell phone and a headset using Bluetooth wireless technology.

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 are—

Bluetooth 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.³ Bluetooth is standardized within the IEEE 802.15 Working Group for Wireless Personal Area Networks that formed in 1999 as IEEE 802.15.1-2002.4

This section provides an overview of Bluetooth, including frequency and data rates, range, and architecture.

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/n 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 transmissions. FHSS reduces interference and transmission errors but provides minimal transmission security.

With FHSS technology, communications between Bluetooth Basic Rate (BR)/EDR devices use 79 different 1 megahertz (MHz) radio channels by hopping (i.e., changing) frequencies about 1600 times per second for data/voice links and 3200 times per second during page and inquiry scanning. A channel is used for a very short period (e.g., 625 μs 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 low energy communication uses the same frequency range as BR/EDR devices but splits it instead into 40 channels of 2 MHz width. Three of these channels are used for advertising (broadcasting data and for connection setup) and the other 37 are data channels. These 40 channels, combined with a time division multiple access (TDMA) scheme, provide the two multiple access schemes for the low energy feature of Bluetooth. A polling scheme is used in which the first device sends a packet at a predetermined time and a corresponding device responds after a predetermined interval. These exchanges of data are known as either Advertising or Connection Events.

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.

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 frequency-hopping 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 fixed-frequency technologies, like those used in IEEE 802.11b/g. Research has shown that the Bluetooth frequency hopping sequence for an active piconet can be determined using relatively inexpensive hardware and free open source software.⁵

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).⁶ Most small, battery-powered 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. Many Bluetooth low energy devices are designed to run on very small batteries for a long period of time.

Table 2-1. Bluetooth Device Classes of Power Management

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 (counter) value, 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 channel for a device are based on its Bluetooth address. Therefore, knowing a device’s address and local clock⁸ is important for paging and subsequently connecting to the device.

The following sections cover Bluetooth BR/EDR/HS data rates, low energy technology, and dual mode devices.

Bluetooth devices can support multiple data rates using native Bluetooth and alternate Media Access Control (MAC) and Physical (PHY) Layers. 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.

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 payload throughput of approximately

720 kilobits per second (kbps). Introduced in Bluetooth version 2.0, 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.

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 technology.

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.

Bluetooth low energy was introduced in the Bluetooth 4.0 specification and updated in 4.1 and 4.2. Formerly known as “Wibree” and “Ultra Low Power Bluetooth,” low energy is primarily designed to bring Bluetooth to coin cell battery-powered devices such as medical devices and other sensors. The key technology goals of Bluetooth low energy (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 low energy.

Table 2-2. Key Differences Between Bluetooth BR/EDR and Low Energy

A Bluetooth 4.0 or later device may support both BR/EDR/HS and low energy as a “dual mode” Bluetooth device. An example is a cell phone that uses an EDR link to a Bluetooth headset and a concurrent low energy link to a sensor that unlocks and starts the user’s automobile. Figure 2-1 shows the device architecture for Bluetooth 4.x devices, and includes BR/EDR, HS, and low energy technologies. New terms included in the figure related to security are discussed in subsequent sections.

Figure 2-1. Bluetooth 4.x Device 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.

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. Bluetooth low energy (see Section 2.1.2) allows an unlimited number of slaves, which is known as the low energy Peripheral role, with the master being the low energy Central role. The other two low energy device roles, Broadcaster and Observer, are discussed below in this section.

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.¹² 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.

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 phone in Piconet 3 cannot communicate with User B’s phones in Piconet 2 without establishing an additional piconet between them.

Scatternets are supported by both BR/EDR and low energy technologies.

Low energy functionality also supports a connectionless broadcast architecture where Broadcasters (low energy device role) periodically send data, and Observers (low energy device role) listen and consume that data. This allows a device to transmit data to more than one peer at a time. The broadcasting function is a subset of the Advertising capability used in the low energy connection architecture.

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 access point (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

Five basic security services are specified in the Bluetooth standard:

The 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.

Bluetooth BR/EDR/HS defines authentication and encryption security procedures that can be enforced during different stages of communication setup between peer devices. Link-level enforced refers to authentication and encryption setup procedures which occur before the Bluetooth physical link is completely established. Service-level enforced refers to authentication and encryption setup procedures which occur after the Bluetooth physical link has already been fully established and logical channels partially established.

Until Bluetooth 2.0, three modes were defined which specified whether authentication and encryption would be link-level enforced or service-level enforced and that enforcement was configurable.

In Bluetooth 2.1, a fourth mode was added which redefined the user experience during pairing, and required that if both devices are Bluetooth 2.1 or later, they are required to use the fourth mode.

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.

Table 3-1. BR/EDR/HS Security Modes

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 2.0 and earlier devices can support Security Mode 1, and 2.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. Typically, Bluetooth service discovery can be performed prior to any security challenges (i.e., authentication, encryption, and/or authorization). However, all other Bluetooth services should require all of those security mechanisms.

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 2.0 and earlier devices can support Security Mode 2, but 2.1 and later devices can only support it for backward compatibility with 2.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. Therefore, even service discovery cannot be performed until after authentication, encryption, and authorization have been performed. Once a device has been authenticated, service-level authorization is not typically performed by a Security Mode 3 device. However, NIST recommends that service-level authorization should be performed to prevent “authentication abuse”—that is, an authenticated remote device using a Bluetooth service without the local device owner’s knowledge.

All 2.0 and earlier devices can support Security Mode 3, but 2.1 and later devices can only support it for backward compatibility purposes.

Similar to Security Mode 2, Security Mode 4 (introduced in Bluetooth 2.1 + EDR) is a service-level-enforced security mode in which security procedures are initiated after physical and logical link setup. Security Mode 4 uses Secure Simple Pairing (SSP), in which ECDH key agreement is utilized for link key generation (see Section 3.1.1). Until Bluetooth 4.0, the P-192 Elliptic Curve was used for the link key generation, and the device authentication and encryption algorithms were identical to the algorithms in Bluetooth 2.0 + EDR and earlier versions. Bluetooth 4.1 introduced the Secure Connections feature, which allowed the use of the P-256 Elliptic Curve for link key generation. In Bluetooth 4.1 the device authentication algorithm was upgraded to the FIPS-approved Hash Message Authentication Code Secure Hash Algorithm 256-bit (HMAC-SHA-256). The encryption algorithm was upgraded to the FIPS-approved AES-Counter with CBC-MAC (AES-CCM), which also provides message integrity. Security requirements for services protected by Security Mode 4 must be classified as one of the following:

Whether or not a link key is authenticated depends on the SSP association model used (see Section 3.1.1.2). When both the local and remote device support the Secure Connections feature, the link key is said to be generated using Secure Connections, which is the NIST recommended security. Security Mode 4 requires encryption for all services (except Service Discovery) and is mandatory for communication between 2.1 and later BR/EDR devices. However, for backward compatibility, a Security Mode 4 device can fall back to any of the other three security modes when communicating with Bluetooth 2.0 and earlier devices that do not support Security Mode 4. In this case, NIST recommends using Security Mode 3.

Table 3-2. BR/EDR/HS Security Mode 4 Levels Summary

A device can be in Secure Connections Only Mode when all services (except Service Discovery) require an Authenticated link key using Secure Connections. In this mode, the device will refuse service level connections from devices that do not support the Secure Connections feature. As a result, backwards compatibility with older devices will not be maintained. If a device must operate using only FIPS-approved algorithms, except for Service Discovery, then it should enter Secure Connections Only Mode.

Table 3-3 summarizes the most secure Mode which can be achieved, depending on the Bluetooth version of the two peers, assuming that the 4.1 and later devices support the BR/EDR Secure Connections Feature.

Table 3-3. Most Secure Mode for a Pair of Bluetooth Devices

Table 3-4 summarizes the most secure Level which can be achieved in Mode 4, depending on the Bluetooth version of the two peers.

Table 3-4. Most Secure Level in Mode 4 for a Pair of Bluetooth Devices

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

Essential to the authentication and encryption mechanisms provided by Bluetooth is the generation of a secret symmetric key. In Bluetooth BR/EDR this key is called the Link Key and in Bluetooth low energy this key is called the Long Term Key. In legacy low energy pairing, a Short Term Key is generated, which is used to distribute the Slave and/or Master Long Term Key, while in low energy Secure Connections, the Long Term Key is generated by each device and not distributed. 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 in Sections 3.1.1.1 and 3.1.1.2 below.

In Bluetooth version 4.0 and 4.1, pairing is performed using authenticated or unauthenticated procedures. In Bluetooth 4.2, Secure Connections can be used during pairing to authenticate devices. These methods (also known as security modes and levels) are described in Section 3.2.2 below.

For PIN/legacy 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 Ex 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.

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 of binary or, more commonly, 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.¹³

SSP was first introduced in Bluetooth 2.1 + EDR for use with Security Mode 4, and then improved in Bluetooth 4.1. When compared to PIN/Legacy Pairing, 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 (MITM) attacks during pairing. The Elliptic Curve used during the pairing process can be one of two types: P-192 or P-25614 (Secure Connections).

The four association models offered in SSP are as follows:¹⁵

Security Mode 4 requires Bluetooth services to mandate an authenticated link key using Secure Connections (Level 4), an authenticated link key (Level 3), an unauthenticated link key (Level 2), or no security at all (Level 1). 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.

Figure 3-3. Link Key Establishment for Secure Simple Pairing

Each device generates its own ECDH public-private key pair. When both devices support Secure Connections, P-256 elliptic curves are used, else P-192 curves are used. Each device sends the public key to the other device. The devices then perform stage 1 authentication which is dependent on the association model, as described above. After this the first device computes a confirmation value E1 and sends it to the second device which checks the value. If this succeeds, the second device does the same and sends its confirmation value E2 to the first device. Assuming the E2 confirmation value checks out correctly, both devices compute the Link Key.

For AMP link security (e.g., IEEE 802.11, as introduced in Bluetooth 3.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 an 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.¹⁶

Figure 3-4. AMP Link Key Derivation

The Bluetooth device authentication procedure is in the form of a challenge–response scheme. Each device interacting in an authentication procedure can take the role of either the claimant or the verifier or both. 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.

The authentication procedure is of two types: Legacy Authentication (Section 3.1.2.1) and Secure Authentication (Section 3.1.2.2). Legacy Authentication is performed when at least one device does not support Secure Connections. If both devices support Secure Connections, Secure Authentication is performed.

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 controller.

This procedure is used when the link key has been generated using PIN/Legacy Pairing or Secure Simple Pairing using the P-192 Elliptic Curve. Each device interacting in an authentication procedure is referred to as either the claimant or the verifier. Figure 3-5 conceptually depicts the Legacy Authentication scheme.

Figure 3-5. Bluetooth Legacy Authentication

The steps in the authentication process are as follows:

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.

This procedure is used when the link key has been generated using Secure Simple Pairing with the P-256 Elliptic Curve. Each device interacting in an authentication procedure acts as both the claimant and the verifier. Figure 3-6 conceptually depicts the Secure Authentication scheme.

Figure 3-6. Bluetooth Secure Authentication

When the master initiates this authentication process, the steps are as follows:

When the slave initiates the authentication process, the steps followed are identical to the steps above except that the order of Step 1 and Step 2 is swapped.

Note that Secure Authentication is always mutual in nature irrespective of whether the master or slave initiates it.

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:

The encryption mechanism used in Encryption Modes 2 and 3 can be based on either the E0 stream cipher (Section 3.1.3.1) or AES-CCM (Section 3.1.3.2).

The encryption key (\(K_C\)) derived using either mechanism may vary in length 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.

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-7, 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-5. The COF is the 96-bit Ciphering Offset Number and is a concatenation of the Master and Slave BD_ADDR for Master Link Keys, and is the ACO for other Link Keys.

The Bluetooth E0 encryption procedure is based on a stream cipher, \(E_0\). A key stream output is exclusive-OR-ed 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).¹⁹ 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.

Figure 3-7. Bluetooth E0 Encryption Procedure

As shown in Figure 3-8, the encryption key provided to the encryption algorithm is produced using the h3 function. The h3 function produces stream cipher keys based on the 128-bit link key, which is a secret that is held in the Bluetooth devices; the unique 48-bit Bluetooth device address of the master; the unique 48-bit Bluetooth device address of the slave; a fixed key ID “btak”; and the 96-bit ACO value. The ACO is produced during the authentication procedure, as shown in Figure 3-6. The encryption key is shortened by taking the 128 most significant bits of the original encryption key.

The Bluetooth AES-CCM encryption procedure is based on Request for Comment (RFC) 3610, Advanced Encryption Standard - Counter with Cipher Block Chaining-Message Authentication Code. The AES-CCM encryption function takes the following as inputs: the encryption key, the encryption nonce, and the payload bits. The nonce format is of two types: the payload counter format which is used for Asynchronous Connection-Less (ACL) packets, and the clock format (which also includes an 11-bit day counter) which is used for enhanced Synchronous Connection Oriented (eSCO) packets. When AES-CCM encryption is enabled, ACL packets include a 4-octet Message Integrity Check (MIC). eSCO packets do not include a MIC.

Figure 3-8. Bluetooth AES-CCM Encryption Procedure

In addition to the four security modes, Bluetooth allows different levels of trust and 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.

Available service security levels depend on the security mode being used. For Security Modes 1 and 3, no service security levels are specified. For Security Mode 2, the following security requirements can be enforced:

Thus, the available service security levels include any combination of the above, including the lack of security (typically only used for service discovery). Note that BR/EDR encryption cannot be performed without authentication, because the encryption key is derived from an artifact of the authentication process (see Section 3.1.3).

For Security Mode 4, the Bluetooth specification defines five levels of security for Bluetooth services for use during SSP. The service security levels are as follows:

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 at which Bluetooth-specific security controls operate 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.

Because of the intent for Bluetooth low energy to support computationally and storage-constrained devices, and because Bluetooth low energy did not evolve from BR/EDR/HS²¹, low energy security is different from Bluetooth BR/EDR/HS. However, with the Bluetooth 4.1 and 4.2 releases, the differences have been minimized.

One remaining difference is that low energy 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. In low energy Legacy Pairing, the LTK is generated and then distributed using a key transport protocol rather than key agreement as with BR/EDR. That is, one device determines the LTK and securely sends it over to the other device during pairing—instead of both devices generating the same key individually.²² In low energy Secure

Connections the key is generated at each device as a result of a key agreement and thus does not need to be distributed over the link.

Bluetooth specification 4.0 with low energy functionality introduced 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 paved the way for native FIPS-140 validation of Bluetooth low energy devices. 4.2 added the low energy Secure Connections feature which upgraded low energy pairing to utilize FIPS-approved algorithms (AES-CMAC and P-256 elliptic curve). 4.2 also renamed low energy pairing to low energy Legacy Pairing.

Also new in 4.2 is the ability to reuse keys generated via Secure Connections on either physical transport (low energy or BR/EDR) to be used on the other physical transport – alleviating the need for the user to pair on both low energy and BR/EDR. The low energy LTK Key can be derived from the BR/EDR Link Key (using the h6 AES-CMAC-128 function), and the BR/EDR Link Key can likewise be derived from the low energy LTK (using the same h6 function). See Sections 3.2.6 and 3.2.7 for details.

4.0 also introduced features such as low energy 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. These features remained unchanged in 4.1 and 4.2.

With low energy’s privacy feature enabled, the IRK is used to map a Resolvable Private Address (RPA) to an Identity Address. The Identity Address can be either a static random address or a public address. This allows a trusted device to determine another device’s Identity Address from a periodically-changing RPA. Previously, a device would be assigned a static “public” address that would be made available during discovery. If that device remained discoverable, its location could easily be tracked by an adversary. The use of a periodically-changing random address (a hashed and randomized address created with the IRK) mitigates this threat. Since a discoverable low energy device transmits (“advertises”) identity information, this privacy feature is especially useful. Even without low energy privacy the device will get assigned an Identity Address (either a public BD_ADDR or static random address). But with low energy Privacy the RPA is transmitted over the air instead of the Identity Address.

The CSRK is used to verify cryptographically-signed Attribute Protocol (ATT) data frames from a particular device over unencrypted links. 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). If a link is encrypted, the usage of ATT Signed Write is not allowed.²³

In low energy Legacy Pairing all of these cryptographic keys (i.e., LTK, IRK, CSRK) are generated and securely distributed during low energy pairing. For low energy Secure Connections the LTK is generated while the IRK and CSRK are generated and securely distributed. See Section 3.2.2 for details.

Low energy 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 low energy 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.

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 4 requires low energy Secure Connections authenticated pairing and Encryption, using AES-CMAC and P-256 elliptic curve for pairing and AES-CCM for encryption, NIST considers this the most secure of these modes/levels and strongly recommends its use for all low energy connections in 4.2. For 4.0 and 4.1 low energy connections, NIST strongly recommends using Security Mode 1 Level 3 as it requires authenticated pairing and encryption although not as strong (not using P-256 elliptical curve) encryption as Level 4. 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 4 and 3 are strongly preferred over Security Mode 2.

原本PDFの抜粋画像

Low energy 4.2 added a Secure Connections Only Mode which requires that only low energy Security Mode 1 Level 4 may be used for all services except for those that only require Security Mode 1 Level 1. This will ensure that only FIPS-approved algorithms are used on the low energy physical transport. Secure Connections Only Mode is not backwards compatible with 4.0 or 4.1 low energy devices as they do not support P-256 elliptic curve.

4.2 added the low energy Secure Connection pairing which upgraded low energy pairing to utilize FIPS-approved algorithms (AES-CMAC and P-256 elliptic curve). 4.0 and 4.1 low energy pairing was renamed to low energy Legacy Pairing in 4.2.

Although low energy Legacy Pairing uses similar pairing method names to BR/EDR SSP, it does not use ECDH-based cryptography and provides no eavesdropping protection. Therefore, for all pairing methods except OOB with a 128-bit TK, the low energy Legacy Pairing should be considered broken because if an attacker can capture the pairing frames, he or she can determine the resulting LTK. For this reason, low energy Secure Connection pairing should be used when eavesdropping protection is required.

Low energy Legacy pairing uses key transport rather than key agreement for all keys (LTK, IRK, and CSRK), thus a key distribution step is required during low energy Legacy pairing. In low energy Secure Connection pairing, each device independently generates the LTK, therefore an optional key distribution step allows for the exchange of the IRK and CSRK keys in low energy Secure Connection pairing.

As shown in Figure 3-9, low energy Legacy Pairing begins with the two devices agreeing on a Temporary Key (TK) during pairing, 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 distribution of the LTK, IRK, and CSRK.

Figure 3-9. Bluetooth Low Energy Legacy Pairing

As shown in Figure 3-10, low energy Secure Connections pairing begins with the two devices sharing their I/O capabilities and security requirements. After that, public keys are shared. Note that low energy Secure Connections pairing only generates the low energy LTK. The Link is encrypted with the LTK which allows secure distribution of the IRK and CSRK.

Figure 3-10. Bluetooth Low Energy Secure Connections Pairing

The following subsections describe the low energy pairing association models, both Legacy Pairing and Secure Connections. 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.

4.0 and 4.1 allow three low energy pairing methods: Out of Band, Passkey Entry, and Just Works. 4.2 adds Numeric Comparison as a low energy pairing method which is available only for low energy Secure Connections. It is important to note that while the low energy pairing association model names are similar to those from BR/EDR Simple Secure Pairing models, for low energy Secure Connection, the security provided is functionally equivalent to that of the BR/EDR SSP models, but for low energy Legacy Pairing the security provided is different.

If both devices support a common OOB technology, such as NFC or tethering, they will use the OOB method to pair. In low energy Legacy Pairing, the TK is passed over the OOB technology from one device to the other. The TK must be a unique, random, 128-bit number. NIST strongly recommends use of a full 128-bit random binary (non-alphanumeric) value when practical.

Because OOB pairing results in an authenticated LTK, it should provide about 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 if low energy Legacy Pairing is used. 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. In OOB low energy Secure Connection pairing, the device address is passed OOB²⁴, which, even if discovered by an OOB eavesdropper, provides no value towards decrypting the encoded data.

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.

Low energy 4.2 adapted the BR/EDR/HS numeric comparison pairing method to be used by low energy in Secure Connections pairing. There is no numeric comparison method with low energy Legacy Pairing.

If both devices are capable of displaying a six-digit number and both are capable of having the user enter “yes” or “no”, then numeric comparison can be used.

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. An important 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.

Numeric comparison provides MITM protection as well as provides confirmation to the user that they are pairing the intended two devices.

If, at a minimum, one device supports keyboard input and the other a display output (or keyboard input as well), then the Passkey Entry pairing method is used to pair.

In this model for low energy Legacy Pairing, the TK is generated from the passkey generated and/or entered in each device. The specification requires the passkey size to be 6 numeric digits; therefore, a maximum of 20 bits of entropy can be provided.

For low energy Secure Connections pairing, after the public keys have been exchanged, the passkey (6 numeric digits) is generated and/or entered into each device. The devices then take turns sending a hash of each bit of the passkey, the nonce, and both public keys (repeated 20 times for each of the 20 bits of the passkey) until the entire passkey has been sent and agreed upon.

Passkey Entry pairing also results in an authenticated LTK. Because a six-digit passkey is used, an attacker would have a one-in-a-million chance of guessing the correct passkey to perform a MITM attack. NIST recommends using a unique, random passkey for each pairing to provide this level of protection across multiple pairings.

If none of the OOB, Numeric Comparison, or Passkey Entry association models are possible because of device input/output limitations, then the Just Works pairing method is used.

As with SSP in BR/EDR/HS, the Just Works pairing method for low energy is the weakest of the pairing options from a security perspective. In this model for low energy Legacy Pairing, the TK is set to all zeros (0x00). Therefore, an eavesdropper or MITM attacker does not need to guess the TK to generate the STK.

For low energy Secure Connections pairing, after the public keys have been exchanged, the Numeric Comparison procedure is used, but the user is not shown the 6-digit values and the final commitment checks are not performed.

The Just Works pairing method results in an unauthenticated LTK because no MITM protection is provided during pairing.

Once the link is encrypted using the STK, the two devices distribute secret keys such as LTK, IRK, and CSRK. Two options are specified for key generation prior to distribution. A device may simply generate random 128-bit values and store them in a local database (called “Database Lookup” in the specification). The other option is to use a single 128-bit static but random value called Encryption Root (ER) along with a 16-bit Diversifier (DIV) unique to each trusted device to generate the keys. This option is called “Key Hierarchy” in the specification. For example, the keys can be derived from ER, DIV, and the Identity Root (IR) using the following formulas:

The d1 function is a called a Diversifying Function and is based on AES-128 encryption. However, the specification allows the use of other key derivation functions.²⁵

Using this Key Hierarchy method,²⁶ the device does not need to store multiple 128-bit keys for each trusted device; rather, it only needs to store its ER and the unique DIVs for each device. During reconnection, the remote device sends its EDIV, which is a masked version of DIV.²⁷ The local device can then regenerate the LTK and/or CSRK from its ER and the passed EDIV. If data encryption or signing is set up successfully, it is verified that the remote device had the correct LTK or CSRK. If unsuccessful, the link is dropped.

Note in the above example that the IRK is static and device-specific, and therefore could be generated prior to pairing (e.g., during manufacturing).

Low energy Secure Connections security introduced in Bluetooth 4.2 improves low energy security through the addition of ECDH public key cryptography (using the P-256 Elliptic Curve) for protection against passive eavesdropping and MITM during pairing.

Unlike Legacy low energy Pairing, low energy Secure Connections pairing does not involve generation of an STK. Instead, the LTK is directly generated during the pairing.

Low energy Secure Connections pairing begins with the two devices exchanging their pairing features: I/O capabilities, authentication requirements, and maximum encryption key size requirements. The devices then exchange their public keys.

The LTK is generated using the f5 function (which is an AES-CMAC-128 based function) using the following inputs:

After independent generation in each device, the LTK is stored locally by each device - the LTKs do not need to be distributed in Secure Connections mode. Once the LTK has been generated, the link is encrypted using an encryption key derived from the LTK. Thereafter keys such as the IRK and the CSRK can be distributed by both the devices, similar to the key distribution step of Legacy low energy Pairing (see Figure 3-9).

AES-CCM is used in Bluetooth low energy to provide confidentiality as well as per-packet authentication and integrity. There is no separate authentication challenge/response step as with BR/EDR/HS to verify that they both have the same LTK or CSRK.

Because the LTK is used as input for the encryption key, successful encryption setup provides implicit authentication. Similarly, data signing provides implicit authentication that the remote device holds the correct CSRK—although confidentiality is not provided.

The low energy LTK can be derived from the Bluetooth BR/EDR Link Key. As shown in Figure 3-11, the Intermediate LTK (ILTK) is generated using the Bluetooth link key and an extended ASCII key identifier (keyID) of “tmp2” as inputs to an AES-CMAC function h7. Subsequently, the LTK is derived using ILTK and keyID of “brle” as inputs to h6.28

Figure 3-11. Low Energy Long Term Key Derivation from Bluetooth Link Key

The Bluetooth BR/EDR Link Key can also be derived from the low energy Long Term Key. As shown in Figure 3-12, the Intermediate Link Key (ILK) is generated using the low energy LTK and an extended ASCII key identifier (keyID) of “tmp1” as inputs to an AES-CMAC function h7. Subsequently, the Bluetooth Link Key is derived using ILK and keyID of “lebr” as inputs to h6.29

Figure 3-12. Bluetooth Link Key Derivation from Low Energy Long Term Key

This section describes vulnerabilities in Bluetooth and threats against those vulnerabilities. Based on these identified common vulnerabilities and threats, as well as the Bluetooth security features described in Section 3, this section also recommends possible countermeasures that can be used to improve Bluetooth security.

Organizations that are planning to use products that use the Bluetooth 4.0, 4.1, or 4.2 technologies should carefully consider the security implications. The 4.0 specification was released in mid-2010, and the 4.2 specification was released in December 2014. At the time of this writing, one significant security vulnerability related to 4.0 has been discovered (see Table 4-1 below). Additionally, few products that support the 4.2 specification are currently available for evaluation. As more compliant products become available, additional vulnerabilities will possibly be discovered, and additional recommendations will be needed for effectively securing Bluetooth low energy devices. Organizations planning to deploy Bluetooth low energy devices should carefully monitor developments involving new vulnerabilities, threats, and additional security control recommendations.

Table 4-1 provides an overview of a number of known security vulnerabilities associated with Bluetooth. The Bluetooth security checklist in Section 4.4 addresses these vulnerabilities.

NOTE: As mentioned previously, depending on the Bluetooth hardware of a device, it may be able to perform both BR/EDR/HS and low energy functionalities (dual-mode) or only low energy functionalities.

Table 4-1. Key Problems with Native Bluetooth Security

Bluetooth offers several benefits and advantages, but the benefits are not provided without risk. Bluetooth and associated devices are susceptible to general wireless networking threats, such as denial of service attacks, eavesdropping, MITM attacks, message modification, and resource misappropriation,³¹ and are also threatened by more specific Bluetooth related attacks, such as the following:

Organizations should mitigate risks to their Bluetooth implementations by applying countermeasures to address specific threats and vulnerabilities. Some of these countermeasures cannot be achieved through security features built into the Bluetooth specifications. The countermeasures recommended in the checklist in Section 4.4 do not guarantee a secure Bluetooth environment and cannot prevent all adversary penetrations. In addition, security comes at a cost—expenses related to security equipment, inconvenience, maintenance, and operation. Each organization should evaluate the acceptable level of risk based on numerous factors, which will affect the level of security implemented by that organization. To be effective, Bluetooth security should be incorporated throughout the entire lifecycle of Bluetooth solutions.³⁵

FIPS Publication (PUB) 199 establishes three security categories—low, moderate, and high—based on the potential impact of a security breach involving a particular system. NIST SP 800-53 provides recommendations for minimum security controls for information systems based on the FIPS PUB 199 impact categories.³⁶ The recommendations in NIST SP 800-53 should be helpful to organizations in identifying the controls needed to protect Bluetooth implementations in general, which should be used in addition to the specific recommendations for Bluetooth implementations listed in this document.

The first line of defense is to provide an adequate level of knowledge and understanding for those who will deal with Bluetooth-enabled devices. Organizations using Bluetooth should establish and document security policies that address the use of Bluetooth-enabled devices and users’ responsibilities. Organizations should include awareness-based education to support staff understanding and knowledge of Bluetooth. Policy documents should include a list of approved uses for Bluetooth and the type of information that may be transferred over Bluetooth networks. The security policy should also specify a proper password usage scheme. When feasible, a centralized security policy management approach should be used in coordination with an endpoint security product installed on the Bluetooth devices to ensure that the policy is locally and universally enforced.

The general nature and mobility of Bluetooth-enabled devices increases the difficulty of employing traditional security measures across the enterprise. Nevertheless, a number of countermeasures can be enacted to secure Bluetooth devices and communications, ranging from distance and power output to general operation practices. Several countermeasures that could be employed are provided in the checklist in Section 4.4.

Table 4-2 provides a Bluetooth security checklist with guidelines and recommendations for creating and maintaining secure Bluetooth piconets.

For each recommendation or guideline in the checklist, a justification column lists areas of concern for Bluetooth devices, the security threats and vulnerabilities associated with those areas, risk mitigations for securing the devices from these threats, and vulnerabilities. In addition, for each recommendation three checklist columns are provided.

Table 4-2. Bluetooth Piconet Security Checklist

Table 4-3 lists the security controls from NIST Special Publication (SP) 800-53 Revision 4, Security and Privacy Controls for Federal Information Systems and Organizations,³⁷ that map to the recommendations in Table 4-2. The left column gives the number and name of the control from NIST SP 800-53, and the right column provides the Table 4-2 recommendation numbers that correspond to the NIST SP 800-53 control.

The list of controls in Table 4-3 is not intended to be fully comprehensive or authoritative. Rather, it lists those controls that are most directly supported by the Table 4-2 recommendations.

Table 4-3. Recommendation Mappings to NIST SP 800-53 Security Controls

Selected terms used in the publication are defined below.

Access Point (AP) — A device that logically connects wireless client devices operating in infrastructure to one another and provides access to a distribution system, if connected, which is typically an organization’s enterprise wired network.

Ad Hoc Network — A wireless network that allows easy connection establishment between wireless client devices in the same physical area without the use of an infrastructure device, such as an access point or a base station.

Claimant — The Bluetooth device attempting to prove its identity to the verifier during the Bluetooth connection process.

Media Access Control (MAC) — A unique 48-bit value that is assigned to a particular wireless network interface by the manufacturer.

Piconet — A small Bluetooth network created on an ad hoc basis that includes two or more devices.

Range — The maximum possible distance for communicating with a wireless network infrastructure or wireless client.

Scatternet — A chain of piconets created by allowing one or more Bluetooth devices to each be a slave in one piconet and act as the master for another piconet simultaneously. A scatternet allows several devices to be networked over an extended distance.

Verifier — The Bluetooth device that validates the identity of the claimant during the Bluetooth connection process.

Wireless Local Area Network (WLAN) — A group of wireless access points and associated infrastructure within a limited geographic area, such as an office building or building campus, that is capable of radio communications. WLANs are usually implemented as extensions of existing wired LANs to provide enhanced user mobility.

Wireless Personal Area Network (WPAN) — A small-scale wireless network that requires little or no infrastructure and operates within a short range. A WPAN is typically used by a few devices in a single room instead of connecting the devices with cables.

Selected acronyms and abbreviations used in the publication are defined below.

8DPSK — 8 Phase Differential Phase Shift Keying

ACL — Asynchronous Connection-Less

ACO — Authenticated Ciphering Offset

AES — Advanced Encryption Standard

AES-CCM — Advanced Encryption Standard–Counter with CBC-MAC

AES-CMAC — Advanced Encryption Standard-Cipher-based Message Authentication Code

AMP — Alternate MAC/PHY

AP — Access Point

ATT — Attribute Protocol

BR — Basic Rate

CBC-MAC — Cipher Block Chaining - Message Authentication Code (CMAC)

COF — Ciphering Offset Number

CSA — Core Specification Addendum

CSA5 — Core Specification Addendum 5

CSRK — Connection Signature Resolving Key

CTIA — Cellular Telecommunications and Internet Association

dBm — Decibels referenced to one milliwatt

DHK — Diversifier Hiding Key

DHkey — Diffie-Hellman Key

DISA — Defense Information Systems Agency

DIV — Diversifier

DoD — Department of Defense

DoS — Denial of Service

DQPSK — Differential Quaternary Phase Shift Keying

ECDH — Elliptic Curve Diffie-Hellman

EDIV — Encrypted Diversifier

EDR — Enhanced Data Rate

ER — Encryption Root

eSCO — Enhanced Synchronous Connection Oriented

FHSS — Frequency Hopping Spread Spectrum

FIPS — Federal Information Processing Standard

FISMA — Federal Information Security Modernization Act

GFSK — Gaussian Frequency-Shift Keying

GHz — Gigahertz

HCI — Host Controller Interface

HMAC — Hash Message Authentication Code

HS — High Speed

IBC — Iterated Block Cipher

IEEE — Institute of Electrical and Electronics Engineers

ILK — Intermediate Link Key

ILTK — Intermediate Long Term Key

IMEI — International Mobile Equipment Identity

Identity Root

Identity Resolving Key

Industrial, Scientific, and Medical

Information Technology Laboratory

Kilobits per second

kbps

Key Generator

Key Stream Generator

Logical Link Control and Adaptation Protocol

Local Area Network

Link Control Protocol

Linear Feedback Shift Register

Link Layer Protocol

Long-Term Key

Meter

m

Media Access Control

Megabits per second

Mbps

Megahertz

MHz

Message Integrity Check

Man-in-the-Middle

Milliwatt

mW

Near Field Communication

National Institute of Standards and Technology

National Vulnerability Database

Orthogonal Frequency-Division Multiplexing

Office of Management and Budget

Out of Band

Personal Computer

Physical Layer

Personal Identification Number

Public Key Infrastructure

Pseudo-Random Number Generator

Publication

Random Number

Rand

Radio Frequency

Request for Comment

Random Number Generator

Resolvable Private Address

Received Signal Strength Indication

Secure And Fast Encryption Routine

Service Discovery Protocol

Security Experts Group

Secure Hash Algorithm

Special Interest Group

Special Publication

Signed Response

Secure Simple Pairing

Short Term Key

Time Division Multiplexing

Time Division Multiple Access

Temporary Key

Universal Serial Bus

Wireless Local Area Network

Wireless Personal Area Network

d1() — Diversifying function based on AES-128 encryption, used in Legacy Low Energy key generation.

dm() — DIV mask generation function, used in EDIV Generation and DIV Recovery

E0() — Stream cipher used to encrypt Bluetooth packet payloads.

E1() — Bluetooth legacy authentication function based.

E3() — Bluetooth key generation function.

E21() — Link key generator function, used when generating a key from the 48-bit address

E22() — Link key generator function, used when generating a key from the user PIN

f2() — BR/EDR and AMP Link key generator function

f3() — Simple Pairing check function, used to compute confirmation values

f5() — Low Energy Secure Connections key generation function

f6() — Low Energy Secure Connections DHKey check generation function

h4() — Secure Connections Device Authentication Key generation function

h5() — Secure Connections Device Confirmation function

h6() — Second Link Key Conversion function, used to create the Low Energy long term key derivation from a Bluetooth BR/EDR key

h7() — First Link Key Conversion function, used to create the Low Energy long term key derivation from a Bluetooth BR/EDR key

The list below provides references for the publication.

Bluetooth Special Interest Group, Bluetooth specifications. https://www.bluetooth.com/specifications/adopted-specifications

C. Gehrmann, J. Persson, and B. Smeets, Bluetooth Security, Artech House, 2004.

Y. Shaked and A. Wool, Cracking the Bluetooth PIN, In Proc. 3rd USENIX/ACM Conf. Mobile Systems, Applications, and Services (MobiSys), pages 39–50, Seattle, WA, June 2005. https://www.usenix.org/event/mobisys05/tech/full_papers/shaked/shaked.pdf

D. Spill and A. Bittau, BlueSniff: Eve meets Alice and Bluetooth, 2007. https://www.usenix.org/event/woot07/tech/full_papers/spill/spill.pdf

Bluetooth SIG, The Bluetooth Security White Paper, 2002. http://grouper.ieee.org/groups/1451/5/Comparison%20of%20PHY/Bluetooth_24Security_Paper. pdf

Y. Lu, W. Meier, and S. Vaudenay. The Conditional Correlation Attack: A Practical Attack on Bluetooth Encryption, https://lasec.epfl.ch/pub/lasec/doc/LMV05.pdf

The lists below provide examples of resources related to Bluetooth that may be helpful to readers.

Documents

Resource Sites