Bluetooth security by NIST

Currently, Bluetooth is undergoing a rebirth. This is facilitated by the development of IoT, the lack of a headphone jack in modern smartphones, as well as popular bluetooth speakers, wireless mice / keyboards, headsets, and more. We decided to see what security recommendations are presented in the NIST standard for Bluetooth.


Why the "blue tooth"? The name Bluetooth came from the nickname of the Viking King Harald I of Sine-Teeth, who ruled Denmark in the 10th century and part of Norway. During his reign, he united the hostile Danish tribes into a single kingdom. By analogy, Bluetooth also unites, but not the land, but communication protocols.

The first Bluetooth specification was developed by the Bluetooth Special Interest Group (Bluetooth SIG) in 1998 and published as part of the IEEE 802.15.1 standard on June 14, 2002.

The following specifications currently exist:

• 1998-1999: Bluetooth 1.0 and 1.0B ( specification ) - decommissioned since 2006;
• 2001: Bluetooth 1.1 ( specification ) - decommissioned since 2006;
• 2003: Bluetooth 1.2 ( specification ) - decommissioned since 2009;
• 2004: Bluetooth 2.0 + EDR ( specification ) - obsolete in 2014, will be decommissioned in 2019;
• 2008: Bluetooth 2.1 + EDR ( specification ) - will be considered obsolete in 2019, will be decommissioned in 2020;
• 2009: Bluetooth 3.0 + HS ( specification ) - will be considered obsolete in 2019, will be decommissioned in 2020;
• 2010: Bluetooth 4.0 ( specification ) - will be considered obsolete in 2019, will be decommissioned in 2020;
• 2013: Bluetooth 4.1 ( specification ) - will be considered obsolete in 2019, will be decommissioned in 2020;
• 2014: Bluetooth 4.2 ( specification )
• 2016: Bluetooth 5.0 ( specification )

To understand the recommendations of NIST on the construction of protected Bluetooth networks, first we need to consider the implemented functions and security modes in order to understand what is at stake in the recommendations themselves.

Bluetooth security features

Device pairing methods

• Numeric Comparison. From the name, I think, the technology is clear - on both devices a six-digit number is shown, which allows identifying devices. This method does not protect against MITM attacks.
• Just Works. Since not all devices have a screen, such a mode was invented. In fact, it is similar to "Numeric Comparison", but the number is always "000000".
• Passkey Entry. On one device shows the password that must be entered on the other.
• Out Of Band (OOB). The most interesting method is to use additional protocols when pairing. Illustrative examples:

Apple Watch shows a cloud of dots when pairing, which you need to scan with an iPhone camera.



Use NFC between the headphones and the paired device.



Depending on the type of Bluetooth device, the standard assumes various security modes (Security Mode).

Bluetooth BR / EDR / HS

• Security Mode 1 - lack of any protection. Most often used only as part of testing. NIST recommends that you never use this mode. It still exists to maintain backward compatibility with older devices.
• Security Mode 2 — Security functions can be initiated after a connection is established, but before a logical channel is established. Security features control access to services. In this mode, the concept of authorization is introduced - the process of determining whether a particular device is allowed to have access to a particular service.
• Security Mode 3 is a security mode whose functions operate at the channel level. In this Bluetooth mode, the device initiates security procedures before the connection is fully established. Bluetooth devices operating in security mode 3 authenticate and encrypt all connections to and from the device.
• Security Mode 4 is essentially an improvement in security mode 2. Security features are implemented after the connection is established. ECDH (Diffie-Hellman protocol on elliptic curves) is used to generate the link key. This mode also has 5 levels of requirements (from 0 to 4) for implementation:

NIST, which is logical, recommends using Security Mode 4 Level 4 for all its specifications for this class of devices.

Details of the mechanisms for key generation, pairing devices, authentication, etc. go beyond the article. If you wish, you can read them in the guide.

Bluetooth Low Energy

Low Energy Security Mode 1 is a security mode that can be associated with the word “encryption”. It has several levels:

• Level 1 - lack of any security. No authentication, no encryption. The saddest level in terms of security.
• Level 2 - allows pairing without device authentication, but with mandatory encryption.
• Level 3 - requires pairing with authentication and encryption.
• Level 4 - requires pairing with “low energy Secure Connections” authentication (using FIPS-approved algorithms - AES-CMAC and P-256 elliptic curve) and encryption.

Low energy Security Mode 2 is a security mode that can be associated with the phrase “data signature”. Also has several levels:

• Level 1 - pairing without authentication with data signature.
• Level 2 - data authentication pairing.

Before proceeding to the recommendations, consider the types of attacks on Bluetooth, to understand what we are defending.

Types of Bluetooth attacks

• Bluesnarfing is an attack that results in an attacker gaining access to data (often used to access IMEI) via Bluetooth devices that are not only turned on, but also put into “accessible to all” mode. To implement this attack using flaws in the firmware devices.
• Bluejacking is a kind of Bluetooth spam (sometimes phishing). The attacker could send messages to devices that have Bluetooth turned on.
• Carwhisperer - an attack on hands-free devices and other Bluetooth equipment without a display and keyboard (initially - handsfree in cars), reduced to the brutus of standard passwords. In the case of a successful attack, the attacker can not only transmit their audio to the device, but also to eavesdrop.
• Denial of Service - like other wireless technologies, Bluetooth is susceptible to DoS attacks. Impacts include the inability to use a Bluetooth device and the rapid discharge of the battery. These types of attacks are not critical due to the short range of Bluetooth, and they can be easily prevented simply by stepping out of the range of the attacking transmitter.
• Pairing Eavesdropping - sniffing a Bluetooth broadcast to intercept frames sent during pairing devices. An attacker, having these frames, can quickly figure out the secret key. Only Bluetooth versions 2.0 and below are in PIN / Legacy pairing mode and Low Energy Bluetooth in Legacy pairing mode.
• Secure Simple Pairing Attacks - MITM attack on Bluetooth low energy devices operating in “Just Works” pairing mode.

* NIST also marks out an attack on Bluetooth, such as fuzzing, but it seems to us that this makes no sense, since any protocol can be fuzzy.

Bluetooth Piconet Security Checklist

NIST offers a convenient table in which all recommendations are divided into two categories: “Recommended for implementation” and “Should be taken into account”. The first category means that this recommendation is relevant for all organizations, and the second - depending on the capabilities of the organization, since the requirements for operation and costs increase.
There is also a third column “Status”, left blank for the auditors, so that they can check the items performed during the check.

No	Recommendation	Justification
Organizational recommendations
one	Develop a Bluetooth wireless security organization policy.	Security policy is the basis for all other countermeasures.	+
2	Make sure that all Bluetooth users are familiar with the safety rules for using Bluetooth.	A security awareness program helps users follow a practice that helps prevent security incidents.	+
3	Regularly conduct comprehensive Bluetooth security assessments.	Security assessments help identify the Bluetooth devices used in the organization, as well as help ensure compliance with the wireless security policy.	+
four	Ensure that the Bluetooth wireless devices being used are fully architecturally understood and documented accordingly.	Bluetooth-enabled devices can contain various network technologies and interfaces that allow you to connect to local and global networks. The organization must understand the overall connectivity of each device to identify possible risks and vulnerabilities. These risks and vulnerabilities can then be leveled out in a wireless network security policy.	+
five	Provide users with a list of precautions they need to take to better protect Bluetooth-enabled handheld devices from theft.	The organization and its employees are responsible for their Bluetooth-enabled devices, because stealing these devices could lead to information security incidents.	+
6	Keep a complete inventory of all wireless devices and Bluetooth addresses (BD_ADDRs).	A complete inventory of Bluetooth devices can be provided as part of an audit to identify unauthorized devices.	+
Technical recommendations
7	Change the default Bluetooth settings to match your organization’s security policy.	Since the default settings are generally not secure, you must carefully examine these settings to ensure that they comply with the organization’s security policy. For example, it is usually necessary to change the device name (i.e. so that it does not display the type of platform).	+
eight	Set Bluetooth devices to the lowest necessary and sufficient power level so that the radius of the signal remains within the organization’s protected perimeter.	Installing Bluetooth devices with the minimum necessary and sufficient power level provides secure access to authorized users. Class 1 devices should be avoided, as well as external amplifiers or high gain antennas due to their extended range.	+
9	Choose PINs that are reasonably random, long and private. Avoid static and weak PIN codes, for example, 000000.	PIN codes must be random so that attackers cannot easily guess them. Longer PIN codes are more resistant to brute-force attacks. For Bluetooth 2.0 devices (or earlier versions), use an eight-letter alphanumeric PIN if possible. Using a single PIN is unacceptable.	+
ten	Make sure the connection keys (session keys / link keys) are not based on device keys.	The use of “shared link keys” has been deprecated since Bluetooth 1.2.	+
eleven	Do not use the “Just Works” pairing mode for Bluetooth 2.1 and higher devices using SSP .	“Just Works” pairing mode does not provide protection against MITM. NIST does not even recommend purchasing them.	+
12	For devices with Bluetooth 2.1 and later versions using the SSP, random and unique access keys based on the Passkey Entry association model should be used for each pairing .	If the same access key is used for multiple pairings, the protection against MITM attacks provided for in the Passkey Entry pairing model is significantly reduced.	+
13	If a device with Bluetooth versions 2.1 and later using Security Mode 4 needs to connect to older Bluetooth versions that do not support Security Mode 4, then this device should be rolled back to Security Mode 3.	Bluetooth specifications allow the 2.1 device to revert to any Security Mode for backward compatibility. This allows you to return to protection modes 1-3. As previously discussed, security mode 3 provides better security.	+
14	Low energy Bluetooth devices with versions 4.0 and 4.1 should use Security Mode 1 Level 3 when possible	The remaining modes are unsafe.	+
15	Low energy Bluetooth devices with version 4.2 and above should use Security Mode 1 Level 4 if possible.	This mode allows you to provide the maximum level of security for such devices.	+
sixteen	Bluetooth BR / EDR devices with versions 4.0 and 4.1 should use Security Mode 4 Level 4 if possible.	If Security Mode 4 Level 4 is not supported, then you should use Security Mode 4 Level 3 instead.	+
17	Unapproved services and profiles should be disabled.	Most Bluetooth stack implementations support multiple profiles and related services. It is recommended to allow only the necessary profiles and services.	+
18	Bluetooth devices should be configured as “undetectable” by default , unless necessary for pairing.	This setting will hide the Bluetooth device from other devices.	+
nineteen	You must use connection encryption.	Without using connection encryption, data transmission is vulnerable to listening to the broadcast.	+
20	If you are using a multi-beam wireless connection, make sure that encryption is enabled on each connection in the chain.	One unsecured connection leads to a compromise of the entire communication chain.	+
21	Ensure that all connections are mutually authenticating the device.	Mutual authentication is required to ensure authentication of all devices on the network.	+
22	Enable encryption for all broadcasts (encryption mode 3).	Broadcast transmissions that are protected by encrypting connections provide a level of security that protects these transmissions from interception.	+
23	Adjust the size of the encryption keys as long as your device allows.	Using the maximum allowable key sizes provides protection against brute force attacks.	+
24	Bluetooth devices must request the user to authorize all incoming Bluetooth connection requests before allowing all incoming connection requests.	Users should also not accept connections, files, or other objects from unknown or unreliable sources.	+
25	Use application-level authentication and encryption over the Bluetooth stack for sensitive data transfer.	Since devices can automatically connect to previously connected devices, it is advisable to use applications that additionally implement encryption and authentication functions.		+
26	Add layers to authenticate users, such as biometrics, smart cards, two-factor authentication, or PKI.	Implementing powerful authentication mechanisms can minimize password and PIN-related vulnerabilities.		+
27	If you are using Mobile Device Management (MDM) solutions, make sure that your organization’s Bluetooth security policy is properly enforced using the technical tools you use.	Security policies can be applied by MDM solutions. The default settings are generally unsafe. You must carefully study these parameters to ensure that they comply with the organization’s security policy.		+
Operational requirements
28	Make sure the Bluetooth features are disabled when not in use.	Bluetooth should be turned off on all devices, unless the user explicitly allows Bluetooth to establish a connection. This minimizes the impact of potential malicious acts. For devices that do not support turning off Bluetooth (for example, a headset), the entire device should be turned off if it is not used.	+
29	Perform pairing as seldom as possible, ideally in a secure area where attackers cannot intercept frames with access key exchange during pairing. (Note: “safe area” is defined as a non-public area located indoors away from windows in places with physical access control.) Users should not respond to any messages requesting a PIN code unless the user has initiated pairing and is not sure that PIN request is sent by one of the user's devices.	Pairing is an important security feature and requires users to be aware of possible listening devices. If an attacker can capture transmitted frames associated with pairing, the definition of the link key is simple for Bluetooth devices with all versions up to 2.1 and another 4.0, since security depends solely on the entropy and the length of the PIN code.	+
thirty	Bluetooth BR / EDR in Security Mode 2 or 4 must be used in a controlled area.	NIST strongly recommends that Bluetooth BR / EDR devices use security mode 3.	+
31	Make sure that portable devices with Bluetooth interfaces are configured to use a password.	This helps prevent unauthorized access if the device is lost or stolen.	+
32	If a Bluetooth device is lost or stolen, users must immediately remove the missing device from the list of paired devices in all other Bluetooth devices.	This policy will prevent an intruder from using a lost or stolen device to access another Bluetooth device owned by the user.	+
33	Install antivirus software on Bluetooth-enabled hosts that support such software.	Antivirus software helps prevent malware from appearing on your Bluetooth network.	+
34	Regularly deploy Bluetooth software updates and firmware updates.	Patches must be fully tested before deployment to confirm that they are effective.	+
35	Users should not accept transmissions of messages, files and images from unknown or suspicious devices.	With the increase in the number of Bluetooth enabled devices, it is important that users only establish connections with other trusted devices and only accept content from these trusted devices.	+
36	It is necessary to fully analyze the implications of deploying any security features or product before deployment.	To ensure successful deployment, an organization must fully understand the technical, protective, operational, and personnel requirements prior to implementation.	+
37	You must select a person to track the release of new versions of Bluetooth, as well as security standards (for example, via Bluetooth SIG), the emergence of new vulnerabilities and attacks.	A person assigned to track the latest technologies, standards and risks will help ensure the continued safe use of Bluetooth.		+

Unfortunately, NIST gives only recommendations, but does not tell how to implement them. And if it is quite realistic to perform some recommendations on smartphones (for example, switching the device to the “invisible mode” - No. 18), then on other devices their implementation may not be provided in principle. Thus, the only way is the correct selection of devices based on the specification and subsequent verification of the device for compliance with it.

Software and useful links after:

• Project Ubertooth (http://ubertooth.sourceforge.net/) is a platform for analyzing Bluetooth connections. Based on it, 2 devices are made: Ubertooth Zero and Ubertooth One
• Bluetooth Special Interest Group (https://www.bluetooth.com/)
• Trifinite Group (https://trifinite.org/) - Bluetooth security research team (we can only open via TOR)