BLE Security: Where to Begin When Creating a Connected System

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 for a fitness tracker?  What about a wireless door lock or implanted medical device?  How secure is “secure enough?” 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.

To most people who don’t delve into security concepts regularly, the terms encryption and security may be one in 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¹²⁸) 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?!

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, or somebody with a case of “Minnesota Nice” lets an intruder tailgate them into a restricted area.  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 first attempt to exploit other avenues such as flaws in implementation (bugs), poor operational security (accidentally leaked keys), or social engineering (phishing). Therefore, a claim that a system is secure based on encryption strength alone – or any other single aspect, for that matter– 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?

Designing a secure system requires a holistic analysis of threats and mitigations.  The STRIDE model outlined below divides threats into six categories and can be a useful tool for answering the basic question “what could go wrong in our system?”  A deep dive into threat modeling is beyond the scope here, but a quick walkthrough of the list with your application in mind can help reveal high-level blindspots.  At a minimum, this short list can provide the basic language and concepts for a more comprehensive security discussion, especially for those who’ve never heard of it.

Is built-in BLE security good enough?

When properly configured and implemented, modern BLE security offers protections against many of these threats in the form of LE Secure Connections (available with BLE 4.2 and later).  To achieve the highest level of security, one that is resistant to both passive and active attacks (more on that later), data must be exchanged between devices by some means other than BLE (aka “out of band”).  This requirement can often be overlooked when designing a system, but ultimately determines the level of protection provided by off-the-shelf BLE security. Here’s why:

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…. Do 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 that have 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.  If that doesn’t sound like a big deal, take a moment to let this sink in: even if an attacker can see all of the traffic during the key exchange, they still have no practical way of figuring out a secret that both sides now know.  This mind bending algorithm is the backbone to most modern cryptosystems.

In a BLE system, the key exchange happens during pairing, which makes pairing the most vulnerable phase of a secure connection.  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-Kellman key exchange, which provides protection against so-called passive (aka eavesdropping) attacks.

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

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.  First of all, 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.  Furthermore, by exchanging a passkey, the key itself remains securely stored in both devices and is never exposed to the outside world.  Finally, 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.

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.

Other things to consider

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.