Bluetooth Security 101: A perspective on Bluetooth Security

Given the proliferation of Bluetooth wireless technology, there are a lot of questions and discussions about Bluetooth security. One of the most common questions asked at Cassia Networks involving Bluetooth security is “How secure is Bluetooth Low Energy (BLE)?”

The answer touches on specifics about BLE, and several general Bluetooth security issues.  Moreover, the answer involves three aspects of BLE security. We will review the operating concepts behind each of these aspects of BLE security.

Firstly, in all BLE versions of the past several years, there are two types of BLE security. These two types are included in Bluetooth LE specifications 4.0 first introduced in 2009, 4.1 introduced in 2013, 4.2 introduced in 2014, and 5.0 specified in 2016.

Public key legacy security

The first Bluetooth legacy security or legacy pairing involves an exchange of “public keys.” However, public keys are at security risk as a passive eavesdrop can intercept the public keys. The reason is there is only a public key exchange. A sniffer, for example, is a passive eavesdrop which can conduct passive eves-dropping in a public-key only situation.

Notably, in a circumstance where the initial Bluetooth legacy security is not enough, a 3rd party proprietary solution (NFC, bar codes etc…) aka a “low out of band (OOB)” type of pairing helps in addressing security.

OOB security procedures

Cassia Networks has implemented an OOB pairing security procedure.  Cassia’s OOB works as follows: If there are two BLE devices within the range of a Cassia router, then the Cassia router remotely sets up this OOB security feature between the two BLE devices. This occurs at the Cassia gateway/router via remote pairing of the devices using Cassia’s OOB proprietary method.

In other words, there is a two-level operation (involving conceptual/logic layers) to change the connection to a more secure connection.

The reason for this is the data exchange and operational procedures for authentication using a “public” key only process is a bit like a person getting a license to drive. Most people can get a license to drive, or public key. However, to drive safely on the information highway, an additional layer of “private” key data exchange needs to occur (kind of like wearing a safety belt while driving.) As a security layer between two devices, the Cassia hub sets up an encrypted exchange between two devices.

When the connection between the devices occurs via Cassia’s software development kit (SDK) encryption, then the connection does not need to happen on premise. A developer uses the SDK to create a secure channel between device A and B. The Cassia router acts as a secure channel, so devices A and B can have a secure router-mediated secure pathway. The Cassia security in the SDK is an advanced encryption standard, 128-bit algorithm (AES-128).

LE Secure Connection

The next type of BLE legacy security is the LE Secure Connection, which is a bank-level, military level security standard started in 4.2. It uses a public key infrastructure (PKI), with Elliptic curve Diffie–Hellman (ECDH), which reduces the risk of risky of key exchange behavior. ECDH is an anonymous key agreement protocol to share a public-private key secret over an insecure channel.

First, there is an exchange of public keys and device A uses a public key to encrypt the public key for device B. Device A needs a private key to decrypt the public key’s encryption. The private key never leaves device A. In short, this is how the 4.2 LE security connection works.

Bluetooth Security behavior

In addition, there are a few basic Bluetooth security behaviors, which can serve as guides for approaching Bluetooth security. For example, in an end-to-end Bluetooth security system, the oldest Bluetooth protocol (4.1 for example) sets the “default” security for the rest of the Bluetooth connected components. In other words, a Bluetooth 5 security protocol does not extend to an older Bluetooth protocol like 4.2 or 4.1.

Also, note the following Bluetooth security behavior:

  1. The default setting is “off” or non-secure, for all Bluetooth protocol versions, such as 4.0, 4.1, 4.2 and 5.0.
  2. To ensure the most recent updates of Bluetooth security carries through an entire environment, use the latest Bluetooth technology, such as Bluetooth 5.
  3. An end-to-end security perspective, with layers of security at separate points in the network, such as user security, protocol security (MQTT, https, proprietary methods etc…), access security, physical security, algorithm security etc…is important for security.

Cassia Networks Bluetooth Security

In describing the basics of Bluetooth security, Cassia Networks is providing a general overview and not a definitive solution or guidance for specific circumstances. Given the varied nature of Bluetooth implementations Cassia Networks always works with organizations and users to ensure security receives the attention it deserves and is developed appropriately. Cassia will always work with customers to ensure information is protected.