1. Why is security necessary in BLE?
2. Security mode & Security Procedure in BLE
3. Authentication, encryption and delegation
4. Example – BLESA Attacks
5. Project on nRF52/nRF5340
6. Conclusion
1. Why is security necessary in BLE?
The widespread adoption of Bluetooth Low Energy (BLE) has played a key role in driving the development of IoT devices, wearables, and smart healthcare systems, bringing unprecedented levels of convenience and connectivity to modern life. With its advantages of low power consumption, reasonable deployment costs, and support across most popular platforms, BLE has quickly become the default choice for billions of connected devices globally. However, alongside this rapid growth are increasingly serious concerns about security and privacy.
Notably, most security risks associated with BLE do not stem from inherent weaknesses in the protocol itself, but rather primarily from how it is implemented in practice. The pressure to shorten time to market, coupled with the complexity of a Bluetooth specification spanning thousands of pages, sometimes forces developers and manufacturers to compromise between convenience, cost, and security. As a result, many critical security mechanisms are either inadequately configured or even omitted, creating subtle but potentially exploitable vulnerabilities.
In the context of Bluetooth Low Energy becoming an increasingly fundamental infrastructure in digital life—from personal devices and healthcare systems to industrial applications and smart infrastructures—understanding, implementing, and comprehensively evaluating BLE security mechanisms is no longer an option, but a necessity. Only when security is properly addressed from the design stage can BLE fully fulfill its role as a secure, reliable, and sustainable connectivity technology for the modern IoT ecosystem.
2. Security mode & Security Procedure in BLE
BLE security is built on two core concepts:
- Security Mode: defines the overall security strategy, i.e., the level of protection a connection or data requires.
- Security Procedure: the specific technical mechanisms used to implement that strategy.
In other words, the security mode determines “how much protection is needed,” while the security procedure answers “how to protect it.”
Security Mode 1 focuses on securing BLE connections through pairing and encryption. This mode includes four levels of security:
- Level 1: No authentication, no encryption – convenient but not secure.
- Level 2: Unauthenticated pairing with encryption (Just Works) – common but not MITM-protected.
- Level 3: Authentically authenticated pairing with encryption – MITM-protected through password entry or OOB.
- Level 4: LE Secure Connections – uses ECDH and a 128-bit key, the highest level of security.
Imagine an attacker being able to secretly modify the on/off switch of a communication device. This represents a potential Man-in-the-Middle (MITM) attack. Authentication helps protect against MITM by ensuring that each participating party can verify the other party’s identity cryptographically. In the BLE world, when you connect your smartphone to an IoT device for the first time, you might encounter a “pairing” pop-up window. Once the two devices are paired, they permanently save the settings and become “linked,” eliminating the need to re-pair each time they attempt to connect.
Passive eavesdropping and Man-in-the-Middle attacks are two of the most common types of cyberattacks involving hacking BLE modules. BLE networks can be attacked through passive eavesdropping, allowing an outside device to intercept data exchanged between devices. For example, an attacker could eavesdrop on data provided by industrial peripheral sensors to a central controller to discover new security vulnerabilities in the system. BLE modules using BLE Secure connections are, by default, protected against passive eavesdropping.
In MITM attacks, an alien device simultaneously assumes both central and peripheral roles, tricking other devices on the network into connecting to it. This can become a problem in large manufacturing complexes because the alien device can inject forged data into the data stream and disrupt the entire production chain. BLE Secure connections offer security against passive eavesdropping, but man-in-the-middle attacks can only be prevented with the right pairing techniques.
The level of security achieved largely depends on the device’s I/O capabilities and the trade-off between user experience and system security. Beyond connection security, BLE also supports data protection in specific contexts:
- Security Mode 2: uses connection-based data signing to ensure data integrity and authenticity, even without link encryption. This mechanism relies on CSRK and MAC keys to detect spoofing and replay attacks.
- Security Mode 3: applies to broadcast data, enabling broadcast data encryption using Broadcast_Code, particularly important for modern BLE broadcast applications (Bluetooth 5.4+).
3. Authentication, encryption and delegation
Bluetooth Low Energy security is built on three core mechanisms: authentication, encryption, and authorization. These three layers of protection work closely together to ensure that only legitimate devices can connect, that transmitted data is not exposed or modified, and that resource access is properly controlled.
Authentication in BLE verifies the identity of the connected devices, thereby preventing spoofing and MITM attacks. Authentication is performed during the pairing phase and may require user interaction through mechanisms such as password entry, number comparison, or Out-of-Band (OOB). Specifically, from BLE 4.2 onwards, the LE Secure Connections mechanism utilizes Elliptic Curve Diffie-Hellman (ECDH), enhancing MITM resistance and becoming the recommended authentication platform for modern BLE devices.
Encryption plays a crucial role in protecting data throughout wireless communication. After successful pairing, BLE devices generate secret keys and use the AES-CCM algorithm to encrypt the link, ensuring that data cannot be eavesdropped on or modified by third parties. Encryption helps protect not only application data but also the security keys exchanged during the connection, which is especially important for IoT and medical devices transmitting sensitive data.
Authorization is the next layer of protection after authentication and encryption, focusing on controlling resource access. In BLE, authorization is typically implemented at the GATT layer, where each service or characteristic may require a different level of security, such as only allowing read or write access when the connection is encrypted or authenticated. This mechanism ensures that even if a device has successfully connected, it can only access the resources it has been authorized to access.
The effective combination of authentication, encryption, and authorization determines the true security level of a BLE system. In practice, many security incidents stem not from a lack of these mechanisms, but from misconfiguration or inadequate use, highlighting the importance of thoroughly understanding and correctly implementing BLE security principles from the design stage.
4. Example – BLESA Attacks
A prime example demonstrating the serious weaknesses of Bluetooth Low Energy, even with standard encryption mechanisms, is the BLESA (Bluetooth Low Energy Spoofing Attack) vulnerability, disclosed at the USENIX WOOT 2020 conference. According to the authors from Purdue University and EPFL, BLESA exploits the BLE reconnection mechanism – a feature designed to reduce latency and save energy for previously paired devices. In this scenario, the BLE standard does not require re-authentication of device identity during reconnection, allowing an attacker to impersonate a legitimate peripheral device and send forged data to the central device.
It is noteworthy that BLESA does not require encryption, does not require retrieval of the secret key, and does not rely on hardware errors. Instead, the attack exploits ambiguities in the BLE specification, allowing BLE stacks to implement reconnection mechanisms in various ways, some of which are insecure. Research indicates that BLESA can be successfully implemented on popular BLE implementations, including Linux BlueZ, as well as BLE stacks on Android and iOS, where the research team discovered logic flaws that allow the central device to accept connections from spoofed devices. These findings have been officially confirmed by Google and Apple, demonstrating the actual impact of the vulnerability.
transmission mechanism
According to the article, BLESA is particularly dangerous in common IoT scenarios such as wearables, medical sensors, and smart devices, where reconnection occurs frequently and completely automatically. Given that BLE is being used on billions of devices globally (estimated to reach over 5 billion BLE devices by 2023), BLESA demonstrates that secure initial pairing is insufficient. Without additional measures such as GATT access control, application-layer authentication, or reconnection limitations, a BLE device can still be compromised without the user’s knowledge.
The BLESA case highlights a crucial fact: BLE security depends not only on the encryption algorithm but also heavily on how the standard is implemented and configured in practice. This clearly demonstrates that serious vulnerabilities in BLE can stem from protocol design and connection logic, rather than from cryptographic algorithms, and further underscores the need for comprehensive BLE security assessments, especially in large-scale IoT ecosystems.
5. Project on nRF52 / nRF5340
Pairing & Bonding (Zephyr / nRF SDK)
- Turn on LE Secure Connections
- Require MITM protection
Protect GATT characteristic
Bluetooth Security Manager Protocol
On nRF5340, CPUAPP handles the entire BLE security stack, allowing the combination of BLE + Secure DFU + TrustZone to build a multi-layered security system.
6. Conclusion
Only when properly implemented is Bluetooth Low Energy truly a secure wireless communication standard. Throughout the entire BLE connection lifecycle, the pairing phase remains the most sensitive point in terms of security, but it can be effectively protected if the correct pairing model and authentication mechanism are applied. Common threats such as man-in-the-middle attacks or passive eavesdropping mainly stem from weak security configurations, rather than from the BLE protocol itself.
In the development of IoT applications, the choice of hardware and software platforms plays a crucial role in the system’s security. SoCs like the nRF52 and nRF5340 provide all the necessary hardware security features for modern BLE, including LE Secure Connections, accelerated AES encryption, ECDH support, secure memory, and secure boot. When combined with properly deployed BLE stacks and tight coupling processes, these platforms enable the construction of energy-efficient and highly secure IoT systems in fields such as wearables, healthcare, industry, and smart homes.
For businesses considering deploying an IoT ecosystem, understanding and correctly applying security principles from the foundational level is essential. A secure IoT architecture must be built on reliable hardware and correctly configured protocols from the outset. In fact, it is common design and implementation vulnerabilities – not complex encryption algorithms – that cause the majority of serious security incidents and commercial losses.
