Deep Dive into Bluetooth LE Security

Alexis Duque
Mar 3, 2018 · 7 min read

Bluetooth Low Energy (BLE) is becoming one of the most common wireless standards used today in IoT devices. Likewise, it is also becoming more commonly used in applications where sensitive information is being transferred. As a consequence, IoT devices makers looking to integrate BLE into their products should be aware of the security features and limitations of this technology. In this post, I will try to provide a basic overview of BLE security features. If you are not already familiar with BLE, I suggest you to watch this nice webinar by Nordic Semiconductor before.


When two devices, which initially do not have security, wish to do something that requires security, the devices must first pair. This process is triggered by a Central device (e.g. a smartphone) that is attempting to access a data value (a “characteristic”) on a Peripheral device that requires authenticated access. Pairing involves authenticating the identity of two devices, encrypting the link using a short-term key (STK) and then distributing long-term keys (LTK) used for encryption. The LTK is saved for faster reconnection in the future, that is termed Bonding.

This process is shown the following figure:

Bluetooth paring process

The new security level of the connection is based on the method of pairing performed and its selection is based on the I/O capabilities of each device. The security level of any subsequent reconnections is based on the level achieved during the initial pairing.

The role each device plays is defined in the Security Manager (SM) portion of the BLE stack. They are the Initiator (the central), and the Responder (the peripheral).

Encryption and Authentication

Authentication is provided in Bluetooth (LE) by digitally signing the data using the connection Signature Resolving Key (CSRK). The sending device places a signature after the Data PDU. The receiver verifies the signature using the CSRK.

Security Modes and Levels of a Connection

Security Mode 1

  • Security Level 1: No Security (No authentication and no encryption)
  • Security Level 2: Unauthenticated pairing with encryption
  • Security Level 3: Authenticated pairing with AES-CCM encryption
  • Security Level 4: Authenticated LE Secure Connections pairing with encryption. Level 4 uses Elliptic Curve Diffie-Hellman P-256 (ECDH) and AES-CCM encryption.

Security Mode 2

  • Security Level 1: Unauthenticated pairing with data signing
  • Security Level 2: Authenticated pairing with data signing

Mixed Security Mode

Each connection starts its lifetime in Security Mode 1, level 1 and can later be upgraded to any security level by means of an authentication procedure discussed below. When pairing, the method/algorithm chosen determines if the pairing performed a strong authentication or not. Unauthenticated pairings occur in situations where the device could not authenticate itself (for example, if it has no input/output capabilities).

Further details are provided in Vol. 3, Part C, Section 10 of the BLE v4.2 Core Specification.

Pairing Modes

Phase 1

Phase 2

Phase 3

The pairing flowchart which applies to both legacy pairing and secure connections.

Pairing Procedures

Just Works: The STK is generated on both sides, based on the packets exchanged in plain text. This method provides no security against man-in-the-middle (MITM) attacks.

Passkey Display: One of the peers displays a randomly generated 6-digit passkey and the other side has asked to enter it. In some cases, both sides enter the key if no display is available. This method provides protection against MITM attacks.

Out of Band (OOB): In this method, the additional data can be transferred by other means than the BLE radio (such as another wireless technology like NFC). This method also provides protection against MITM attacks.

Numeric Comparison (LE Secure Connections Pairing) and only with BLE 4.2: This method uses an algorithm called Elliptic curve Diffie–Hellman (ECDH) for key generation and a new pairing procedure for the key exchange. The link is encrypted using LTK from Phase 2

The table below is a reference to determine/for determining the pairing method based on the two devices I/O capabilities and the role each device plays in the process.

Pairing procedure and I/O capabilities

Bonding Modes and Procedure

  • Non-Bondable Mode: this is the default bondable mode for devices. This means the device will not accept bonding. No keys will be exchanged or stored by the device.
  • Bondable Mode: to accept a bonding request, the Peripheral must set the bonding bit in the authentication requirements of the Pairing Request message during pairing. The device exchanges security keys and stores them.

If a Central wants to bond with a Peripheral device it believes is bondable, it uses the bondable procedure. It initiates pairing with the same bonding bit set in the authentication requirements of the Pairing Request message. If the Peripheral device is bondable, it will respond with the bonding bit set. If all this happens, the keys will be distributed after the link is encrypted and then the keys are stored. Once the keys have been distributed and stored, the pair of devices are said to be Bonded.


As IoT devices makers, we take care of implementing BLE features into their designs. We are aware of the specific security threats facing BLE and make our best effort to leverage BLE’s security features to mitigate them.

Annexe 1: Summary of 4.0 and 4.2 differences

Using LE Secure Connections with the ECDH algorithms to generate public/private key pairs, the Security Manager protects the communication from passive eavesdropping regardless of the I/O capabilities and pairing methods (Numeric Comparison, Just Works, Passkey Entry, and Out Of Band). It will provide protection from Man-In-The-Middle (MITM) attacks if the application uses Numeric Comparison, Passkey Entry, and Out Of Band as the pairing method.


Bluetooth Core Specification, ver. 4.2, Bluetooth SIG, December 2014

Bluetooth Pairing August 2016

Rosa, T. (2013, May 23). Bypassing Passkey Authentication in Bluetooth Low Energy. Retrieved August 01, 2016, from

Ryan, M. (2013). Bluetooth: With Low Energy Comes Low Security. Retrieved August 01, 2016, from

This post has been posted on Rtone blog. I would like to thanks Jenny Baur for the review.

Rtone IoT Security

Blog about IoT security by Rtone IoT Makers

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store