A few days ago, I stumbled upon BLEUnlock, a project that used BLE (Bluetooth Low Energy) to unlock Mac devices based on the proximity of a secondary device, like an iPhone or Apple Watch. After roughly looking through the repository, it became apparent that the software lacked encrypted communications to facilitate authentication. Instead, it merely relied on the secondary device’s MAC address as enough trust to unlock the system, which is a major security flaw.

This got me thinking about how encryption could be implemented with BLE, and so in this article, we’ll be exploring the different options provided by the standard, as well as a system I devised that should provide ample protection between devices.

BLE Standard

There are four “levels” of encryption that come with the BLE standard, each providing better security than the last.

Level 1

Level 1 is the simplest version of the protocol, with no encryption or authentication. It is mainly used with low security systems like beaconing. This is what BLEUnlock uses, which as you know by now makes it very vulnerable.

Level 2

Level 2 steps up the protection with real encryption between the messages sent. The system works by having the two devices agree on an encryption key during the pairing process, before encrypting the rest of the data. No human intervention is needed during this process, however, which makes it vulnerable to man in the middle attacks. There are two MITM methods for level 2, passive and active, each with its pros and cons.

Passive listening of the BLE transaction between two devices requires the attacker to know the key being used. This can be found during the key exchange phase (pairing) or by cracking the code (usually zero for BLE legacy).

Active attacks have the assailant device act as both target devices, becoming a relay for BLE messages. This allows for things like replay attacks, on the fly modification, or the reverse engineering of commands.

Level 3

Level 3 fixes some of the MITM problems found in level 2 by requiring manual input from the user during the pairing process. Usually, a six digit code is given from one device and entered into the second device making it much harder to intercept the key.

However, since the code is only six digits (padded to 128 bits), the opponent can brute force the key as long as they capture data from the initial pairing process. Tools such as Crackle make this extremely easy, and once the key is found, passive sniffing can be used to capture further information to be decrypted later.

Level 4

Level 4 leverages a full 128 bit key instead of padding a six digit one. As you can probably guess by now, it’s much more secure than the other levels as brute forcing the key is exponentially more difficult. However, with technological improvements, it may soon be possible to break the keys relatively easily. GPUs are becoming especially powerful thanks to the AI boom and with a large GPU farm it’s feasible to crack 128 bit keys.

Custom Solution

⚠️Warning⚠️: I am not an expert/professional in the field of securing communications. I am not responsible for any issues should you try to implement this yourself.

BLE is a communication technology that facilitates the exchange of data. So even if a low level of encryption is used, the system can still be secure so long as the data gets encrypted with a higher standard beforehand.

My idea is to have both devices also exchange RSA public keys during the pairing process. The devices will encrypt data being sent with the other’s public key and decrypt any received data with their private key, making it impossible (currently) to crack. A challenge response system could also be implemented to prevent replay attacks.

There are still a few issues though, mainly during the pairing process, where unless the keys are exchanged through a different method, an active MITM attack would still be possible. Some low power devices may also have a harder time keeping up as the majority of their processing would be taken up doing other things.

Conclusion

BLE is not an extremely secure form of communication, but for what it’s used for it doesn’t need to be. The majority of BLE enabled devices are sensors or microcontrollers which don’t require extensive security. It’s a tradeoff between protection and convenience. For applications that need better safeguarding, it may be better to look at more battle proven technologies like WiFi.