中文 Chinese
With billions of Bluetooth enabled devices being shipped every year, today’s enterprises need to protect sensitive data and mitigate ongoing security threats. While Bluetooth Low Energy brings a lot of potential for the IoT, as many other wireless technologies, it’s not immune from security threats such as device tracking, eavesdropping, and man in the middle attacks. BLE devices are designed to broadcast MAC, UUID and service information at a predefined interval. Due to continuous advertisement, hackers can easily track the device and decode the broadcasting information.
The main security issues with the pairing process and BLE, in general, are passive eavesdropping, man in the middle (MITM) attacks and identity tracking. Let’s explore these in a little more detail.
Passive eavesdropping is the process by which a third device “listens in” to the data being exchanged between the two paired devices. The way that BLE overcomes this threat is by encrypting the data being transferred using AES-CCM cryptography. Bluetooth Low Energy was designed with AES-128 encryption for security and is considered one of the most robust encryption types.
A security issue worth mentioning is man in the middle attack (MITM). In general terms, this refers to a hacker positioning themselves in a conversation between a user and an application to eavesdrop or to mimic one of the parties making it appear as if the exchange of information is normal. Think of it as a mailman opening up your bank statement or other personal mail containing sensitive information, writing down this information, resealing the envelope and placing it into your mailbox. To avoid such an attack, developers should use a combination of encryption and verification methods to secure their IoT applications.
A third security issue is identity tracking which occurs when an attacker can associate the address of a BLE device with a specific user and then physically track that user based upon the presence of the BLE device. One way BLE overcomes this issue is by periodically changing the device address.
What is a pairing process?
The pairing process can be defined as how two BLE devices exchange device information so that a secure link can be established. The process does vary between the BLE 4.2 devices and older 4.0 and 4.1 BLE devices. Below is a quick overview:
The pairing process for 4.0 and 4.1 devices, also known as LE Legacy Pairing, uses a custom key exchange protocol unique to the BLE standard. BLE 4.2 devices are fully backward compatible with BLE 4.0 and 4.1 devices which means that 4.2 devices are capable of performing the same pairing process as 4.0 and 4.1 devices. However, BLE 4.2 devices are also capable of creating what are known as LE Secure Connections. The security of this process depends greatly on the pairing method used to exchange a Temporary Key (TK) which we’ll describe below. The pairing process involves three phases (see Figure 1 below):
Phase one begins when the initiating device sends a “pairing request” to the other device. Essentially, this phase involves how two devices determine how they will set up a secure connection. All of the data exchanged during this phase is encrypted.
Phase two involves the devices exchanging and/or generating the TK using one of the pairing methods below.
Phase three is optional and typically used only when bonding requirements are exchanged in phase 1.
In LE Secure Connections, both phase one and phase three of the pairing process are the same as they are in LE Legacy connections, but there are slight differences in phase two of the pairing process. In phase two, both devices generate an Elliptic Curve Diffie-Hellman (ECDH) public-private key pair. The two devices will then exchange their public keys and then start computing the Diffie-Hellman key. One of the pairing methods is then used to authenticate the connection. Once the connection is authenticated, the long-term key (LTK) is generated and the connection is encrypted.
Now that we’ve covered the basics of the pairing process, let’s discuss the four common pairing methods for BLE 4.0, 4.1 and 4.2 devices.
Just WorksTM:
This method is the default pairing method for most BLE networks. In BLE Legacy connections, the TK value that devices exchange during the second phase of pairing is set to 0, and devices generate the Short Term Key value based on that. However, this method is known to be highly insecure and offers little to no protection against attacks nor does it offer MITM protection. Ideally, Just Works can be used in cases where high levels of security are not required.
Out of Band (OOB) Pairing:
This method allows for some data packages to be transferred through a different wireless protocol. OOB pairing can be implemented during phase 2 of pairing so that any keys exchanged between devices are not transferred through a less secure BLE protocol. The main advantage of this method is that a very large TK can be used, up to 128 bits, greatly enhancing the security of the connection. As long as the OOB channel is immune to eavesdropping during the pairing process, then the BLE connection will also be immune from passive eavesdropping as well as from MITM attacks.
Passkey:
When one or more of the devices has an output and an input device, they can use Bluetooth Passkey Entry to pair. The TK in this method is a 6 digit number that is then passed between the devices by the user. The user must then enter the same number into the responding device. The ‘master’ and ‘slave’ device each create a 128-bit random number. Once the values have been exchanged and confirmed, then an encrypted channel is created between the two devices. Once successfully authenticated, the passkey method is generally considered to be secure from MITM attacks and can also offer good protection from passive eavesdropping.
Numeric Comparison:
This method is not available for Bluetooth LE Legacy pairing, only LE Secure Connections (Bluetooth 4.2 and above). Numeric Comparison requires that a display is available on both devices, for example pairing between a mobile phone and a laptop. A 6 digit key will appear on both devices which the user must manually check and verify. Once the key is confirmed and verified, this method protects from MITM attacks.
Over the years, Bluetooth technology has made considerable advancements and introduced new security methods to protect users. As developers look to implement BLE into their designs, they must understand the specific security threats facing BLE and how BLE’s security methods can mitigate these threats.
For today’s enterprises looking for a secure wireless connectivity solution, Cassia’s X1000, E1000 and S2000 provide enterprise-level security features such as Bluetooth 4.1 security standards as well as advanced 128-bit AES encryption to ensure data is safeguarded at all times. For a full comparison of Cassia’s gateways, check out the guide here.
Interested in a free demo? Book a call with our team here.
