Whether it’s your run-of-the-mill email phishing attack from a Nigerian prince, or a corporate-scale data breach that leaks millions of people’s identifying information, all of us can probably recall a time where we’ve been the target of a cybersecurity attack in one form or another.
By now, most people are well aware of the need for taking proper security precautions while online and have probably even developed a pretty good spidey sense for shady activity. If you’re developing a BLE-connected, or other embedded device that handles sensitive data or interacts with critical hardware or infrastructure, chances are good that security has crossed your mind at least once or twice.
Despite the fact that we routinely interact with secure systems in our daily lives, knowing how to apply our security knowledge and intuition in the embedded world can be a daunting task for any developer, and understandably so.
Is Built-in BLE Security Sufficient?
Is built-in BLE security sufficient for a fitness tracker? What about a wireless door lock or implanted medical device? How secure is “secure enough?” BLE is used in everything from casual consumer gadgets to regulated medical devices, and the security stakes vary dramatically across that spectrum.
While there is no “one-size-fits-all” solution, knowing a few basic concepts can go a long way towards helping identify what tradeoffs exist for a particular application.
Encryption Strength Isn’t Everything
To most people who don’t delve into security concepts regularly, the terms encryption and security may be one and the same. Need more security? Why not just crank up the encryption strength by using a longer key?
Maybe you’ve heard of Advanced Encryption Standard (AES), the encryption specification that is used to secure the vast majority of modern communication. A little math shows that simply doubling the length of an AES key from 128 to 256 bits increases the resistance to a brute force attack by a whopping 340,282,366,920,938,463,463,374,607,431,768,211,456 (2^128) times!
With this level of encryption, it would take all of the computing resources on the planet literally trillions of trillions of times longer than the age of the universe to randomly guess the correct key. Problem solved, right?!
The System Is Only as Strong as Its Weakest Link
Unfortunately, the reality is that a system’s security is only as good as its weakest link.
Adding more deadbolts to the front door doesn’t do much to improve security if you leave the back window open.
That may be a cheesy low-tech analogy, but the point is that an attacker will always go for the low hanging fruit, which almost never means brute-forcing NIST-certified cryptographic algorithms.
It’s much more likely that an attacker will exploit:
- Flaws in implementation (bugs)
- Poor operational security (accidentally leaked keys)
- Social engineering (phishing)
Therefore, a claim that a system is secure based on encryption strength alone—or any other single aspect—is certainly naive, and possibly even misleading. So, let’s take a look at the common security threats and how they relate to BLE communication.
What Could Go Wrong? Use STRIDE to Identify Threats
Designing a secure system means thinking beyond just encryption strength, it requires examining where things can break down across the entire interaction surface. That’s where the STRIDE model comes in.
STRIDE offers a structured way to identify and categorize threats early in the design process. It helps teams move past vague concerns (“Is this secure?”) to specific risks they can evaluate and address. Even a quick pass through the model can uncover blind spots and assumptions that might otherwise go unchecked.
| Threat | Desired Property | What It Means in BLE Context |
|---|---|---|
| Spoofing | Authenticity | A rogue device pretends to be a trusted peripheral (e.g., a fake glucose sensor or fitness tracker). |
| Tampering | Integrity | An attacker modifies GATT characteristics or intercepts and alters communication mid-stream. |
| Repudiation | Non-reputability | Lack of audit logging means you can’t prove which device took an action (e.g., door unlock command). |
| Information disclosure | Confidentiality | An attacker captures unencrypted BLE packets (e.g., leaking user credentials or personal data). |
| Denial of Service | Availability | Repeated pairing requests or malicious advertising floods the device, rendering it unusable. |
| Elevation of Privilege | Authorization | An unauthorized device gains access to restricted functions by exploiting weak pairing or bonding logic. |
STRIDE helps teams move beyond surface-level assumptions and spot security risks that aren’t always obvious. Asking what could go wrong? early gives you a clearer view of your system and the decisions that matter most.
How Secure Is BLE Pairing?
When properly configured, modern BLE security can protect against many common wireless threats, especially when using LE Secure Connections introduced in Bluetooth 4.2.
But BLE security is not automatic. Many developers assume it is handled by the stack, when in fact, several key features must be intentionally supported, configured, and tested. To make informed design decisions, it’s important to understand which security capabilities exist and which Bluetooth versions introduced them.
BLE Security Feature Reference
| Feature | Introduced | What it does |
|---|---|---|
| LE Legacy Pairing | Bluetooth 4.0 | Basic pairing with Just Works, Passkey Entry, or OOB. Susceptible to MITM. |
| LE Secure Connections | Bluetooth 4.2 | Uses Elliptic Curve Diffie-Hellman (ECDH) for stronger key exchange. Supports MITM protection. |
| LE Privacy | Bluetooth 4.0¹ | Masks device MAC address with a random address to prevent passive tracking. |
| LE Secure Advertising | Bluetooth 5.0 | Enables authenticated, encrypted advertising payloads to prevent spoofing. |
| Numeric Comparison | Bluetooth 4.2 | MITM-resistant pairing method using user-verified numeric value. |
| LE Credit-Based Flow Control (L2CAP) | Bluetooth 4.1 | Secure, connection-oriented channels for higher-throughput data transfers. |
| Signed Writes | Bluetooth 4.0 | Protects data integrity for unencrypted connections using signed data packets. |
¹ Enhanced LE Privacy with improved address resolution was refined in Bluetooth 4.2. It’s also worth noting that LE Privacy protects the device address but does not secure the actual communication payload.
Securing the Most Vulnerable Part of BLE Pairing
To achieve the highest level of BLE security, especially protection from passive eavesdropping and active MITM attacks, devices must exchange authentication data using a second communication channel, referred to as out-of-band (OOB). This step is often overlooked but has a direct impact on how secure your pairing process truly is.
If your product handles sensitive data, supports safety-critical features, or must meet regulatory expectations, start with LE Secure Connections and choose an authenticated pairing method, ideally with OOB. From there, align your Bluetooth version, pairing configuration, and threat model to the specific risks your system needs to manage.
The Key Exchange Dilemma
When communicating with someone for the first time, you have a chicken-and-egg dilemma that goes like this: I need to send you a secret message. To do this, I’ll create a key, use it to encrypt my message, and send you the ciphertext. Of course, you’ll need the key to decrypt the ciphertext. I can send it to you, but I need to keep it secret. So, first I’ll need a way to send you a secret message… You see the predicament.
Fortunately, this problem was solved some years ago by what’s called the Diffie-Hellman key exchange. There are plenty of resources to explain how it works in detail. For now, let’s just say that it’s a method that allows two parties with no prior knowledge of each other to establish a shared secret key over an insecure channel, meaning a communication medium that is susceptible to eavesdropping.
Even if an attacker can see all of the traffic during the key exchange, they still have no practical way of figuring out the secret that both sides now know. This algorithm forms the backbone of most modern cryptosystems, including BLE Secure Connections, where it’s used during the pairing process.
Pairing: The Most Vulnerable Phase
In a BLE system, the key exchange happens during pairing, which makes pairing the most vulnerable phase of a secure connection. Pairing establishes a secure connection, while bonding saves that relationship for future use. Both need to be considered when evaluating security.
A handful of pairing methods exist so that different tradeoffs between security risk, user convenience, and hardware capabilities can be made. All LE Secure connections use a form of the Diffie-Hellman key exchange, which provides protection against so-called passive (aka eavesdropping) attacks.
What Is a MITM Attack?
The man-in-the-middle (MITM) attack is an active spoofing attack where an attacker inserts themselves between two parties who believe they are communicating directly with each other, in order to manipulate or snoop on their conversation.
From a security perspective, the BLE pairing methods can be broken down into two groups:
- Those that are resistant to a MITM attack
- Those that aren’t
The goal of this attack is to trick the participants into exchanging keys with the “man in the middle,” rather than with each other. Doing so requires an attacker to participate in the pairing process and impersonate both devices simultaneously. This of course requires a bit of sophistication on the attacker’s end. In reality, however, it can be done with any laptop or mobile device that’s within range of both devices.
What makes the MITM attack possible is that the Diffie-Hellman key exchange itself doesn’t provide any way to ensure that the exchange is happening with the intended participant. It doesn’t provide a means to verify a message’s authenticity. Anyone who can manipulate the messages between two parties could potentially spoof (impersonate) another device. To overcome this limitation, both parties need to authenticate themselves to each other to ensure they aren’t being spoofed, at some point before the key exchange is finalized.
Why Use a Passkey Instead of Sending the Key?
There are several ways to perform this authentication, with varying levels of sophistication. BLE employs a relatively simple method that relies on exchanging information outside of the BLE communication channel, in a way that the attacker presumably doesn’t have access to.
When using a pairing method with MITM protection, each side must provide knowledge of this “out of band” information to prove they were the intended recipient. In practice, this requires some level of physical access to one or both of the devices.
For example:
- A short passkey can be displayed on one device and then manually entered into the other device using a keypad
- Alternatively, this “out of band” information could be transferred over NFC, which ensures physical proximity due to its limited communication range of a few centimeters
Both methods provide authenticity to the communication by requiring physical access to the devices during pairing.
You might be wondering, if we have this out of band channel, why not just use that to send the key itself rather than complicating things with the passkey exchange step?
In fact, there are a handful of advantages to going the passkey route:
- The passkey is only used as an input to generate a secret key during pairing
- After that, the passkey is discarded and the key is used to encrypt and authenticate further communication
- If an attacker had gained knowledge of the passkey, it would only be useful to them during this pairing attempt
- Conversely, gaining access to the key itself would grant an attacker full access until a new key is created during the next pairing attempt
- Encryption keys are typically at least 16 bytes, whereas a BLE passkey is only 6 (decimal) digits
This presents a practical user experience concern for devices with limited display or data entry capabilities.
Weighing Tradeoffs: Simplicity vs. Protection
Something to consider is that both of these attacks are only possible during the pairing phase, which typically takes less than a minute to complete. Once both devices have been securely paired, it becomes much more difficult for a malicious third party to obtain the secrets necessary to listen in on the encrypted traffic.
You may decide that ease of use or design simplicity outweighs the added security benefit and accept the risk. Alternatively, you may decide that none of the options for providing MITM protection are practical for your application, but you still need that level of security. In that case, it may be worth exploring additional security features at the application level. A public key infrastructure, for example, can provide the necessary authentication mechanism, but is no doubt a more complex solution with its own set of challenges and tradeoffs.
BLE Security Ends at the BLE Stack
Another thing to consider is that BLE security only applies to the BLE connection itself. This sufficiently protects against most over-the-air attacks, but that protection ends with whatever is interfacing with the BLE stack on the software or firmware side.
On a mobile device, for example, BLE security is handled by the OS, which can leave the door open to unauthorized access by third party applications. If a secure connection is needed all the way to a specific application, additional measures may be necessary to prevent other applications from eavesdropping or spoofing the target app.
In other situations, an end BLE device may want to communicate with the cloud through an intermediary mobile device without revealing the contents to the mobile device. In this case, an additional layer of security on top of BLE would be necessary to authenticate the endpoints and encrypt the communication end-to-end.
Important Note: BLE security is necessary, but not sufficient alone. Application-level protections are just as critical, especially when your device connects to mobile apps or cloud services.
Design Security Around the Real Risks
Built-in BLE security is powerful, but only when applied with clear intent. Understanding the pairing process, the limits of the stack, and the real-world attack surface is what enables the right tradeoffs for your system.
Start by asking: What are we protecting, and from whom? Then build out from there.
And if you’re navigating high-stakes decisions around pairing, authentication, or connectivity architecture, having the right development partner can make the difference between assumptions and assurance.
