Introduced in 2009, Bluetooth 4.0 or Bluetooth Low Energy (BLE) has fast become one of the most popular communication methods around. This is largely due to the exponential growth of “Internet of things” (IoT) devices which, by their nature, demand low power consumption. However, low power consumption appears to go hand-in-hand with low security when it comes to early versions of BLE.

Fast forward to 2020 and the introduction - or lack of - Contact-tracing apps, there has been a resurgence interest in the security issues surrounding Bluetooth and it’s various different versions. Most smartphones run Bluetooth Versions 4.2 onwards (not all - more on that in future posts), but that doesn’t mean that there aren’t still lots of heart-rate monitors, blood-glucose counters and various other healthcare devices kicking about still running on the very vulnerable versions of 4.0 and 4.1!

This post explains how a weakness in the pairing process in these versions can be exploited to decrypt communications between devices. It makes use of Crackle available on Github, developed by researcher Mike Ryan, to do the maths involved in breaking the encryption.

Ryan’s work talks about a vulnerability established during the paring process – where two Bluetooth devices initially make contact, recognise each other and agree on how future communications will proceed.

NIST (National Institute of Standards and Technology) have a useful diagram for explaining this vulnerable pairing process. Each phase involves the generation of a key to be used in the rest of the communication process – Temporary Key, Short-Term Key and then Long-Term Key.

Phase One - Temporary Key (TK):

This initial communication involves creation of the TK using one of three methods:

• Pass Key When pairing Bluetooth devices for the first time, you may be asked to enter four or six digit passcode displayed on device one, into device two. This is known as Pass Key pairing. You will have seen this when connecting your phone to your car etc.

• JustWorks Here the initial value of the TK is automatically set to zero. This method is really common when the pairing devices do not have any input/output capabilities such as a keypad or display.

• Out-of Band (OOB) The most secure method is Out-of Band (OBB), as code is transmitted via another medium, perhaps Near Field Communication. This is how the Apple watch manages initial BLE pairing requests.

The result of any of these pairing methods becomes the value of the TK. If JustWorks and its standard value of zero was used – you’ve just practically been handed all communications in plaintext!  

Phase Two – Short-term Key (STK):

Now that the TK has been created and each device has confirmed its value, phase two takes the TK and produces a STK using AES and incorporating a random value generated by both the Slave (MRand) and Master (SRand). This value is used to encrypt a communication channel between the master and slave devices in order to facilitate phase three.

Phase Three – Long-term Key (LTK):

The final phase involves production of the LTK which is the key will be used to encrypt all further communications between master and slave. The LTK can either be a completely random 128-bit number or the result of a function (d1) with an Encryption Root (ER) - a random 128-bit number, and a DIV (Diversifier) - a 16-bit value unique to each device. The NIST diagram also references IRK (Identity Resolving Key) and CSRK (Connection Signature Resolving Key). However, these values are not required for the operation of Crackle.

The practical part…

These above mentioned pairing process is integral to Crackle’s operation. Crackle is programmed with the ability to either guess or brute force the TK, which can be used to calculate the STK. Once these have been obtained, Crackle can ‘crack’ LTK ultimately leading to the ability to decrypt communications.

If you want to do some eavesdropping on BLE communications, unfortunately you need some kind of sniffing device which can capture Bluetooth packets (see Ubertooth). One (efficient) security measure of Bluetooth is that devices engage in ‘channel hopping’ as frequent as 1600 times a second, making it extremely difficult to follow communications without more specialist hardware like the Ubertooth.

Fortunately for us, Crackle’s Github repository provides some pre-captured PCAP files that we can use to simulate breaking the encryption and getting access to device communications.

The first PCAP file shows an example of a pairing process with all packets intact and present. The first 515 packets of this example are simply broadcast packets of the Slave device advertising itself as available. Packet No.516 is a connection request from what will become the Master device. In this packet, the Master also outlines important information such as which channels the connection will use as well as the hop interval. This is critical information for both devices, as it allows them to follow the everchanging path of communication.

The next few packets are exchanging of the TK and set up of the STK before finally passing the LTK to encrypt all future communications. However, as everything after the initial exchange of the TK is encrypted in some form, this information cannot be seen in packets without the use of Crackle.

The following example shows Crackle run with the flags -i and -o which specify an input PCAP and a filename for the decrypted version of the PCAP file that Crackle will create.

crackle -i tests/01_crack/pairing_and_ltk_exchange.pcap -o outputs/01_out.pcap

The output shows that 3 packets have been decrypted. These are the packets which contain the following data:

• Opcode: LL_START_ENC_RSP (Found at packet: 585) This packet is the Master’s response to the Slave’s request to encrypt communications using the recently calculated STK. This will facilitate the ‘encrypted’ disclosure of the LTK in the next significant communication. However Crackle does not to include the value of the STK in the terminal output.

• Opcode: ENCRYPTION INFORMATION (Found at packet: 589) This is the transfer of the LTK. For example, on examination of the output PCAP file, the LTK can now be seen in packet No.589. It is displayed in little endian, because this is the format BLE chooses to send keys. However, this will be converted to big endian in order to decrypt the AES cipher.

• Opcode: LL_TERMINATE_IND (Found at packet: 713) Serves as an example for all future communications. Opcodes are instructions for either the slave or master device. In this instance, it is just the Opcode to share the LTK. However, if the devices were to exchange any further information such as the current heart rate from a medical device, these packets would also be decrypted be decrypted by Crackle.

If we did want to manipulate the function of a BLE device, Control opcodes and their subsequent data are what we are looking for – these are known as Services, and Characteristics. These are identified by 16 or 128 bit UUIDs. Most of these have been standardised by Bluetooth SIG and explained as part of their specifications. However, some devices have very specific operations and as a result will use their own custom Services. These are explained in individual device manufacturer documentation and often this has found its way onto the web for wannabe hackers to utilise. Alternatively, if you have access to both the master and slave devices, you can work these out by changing inputs/outputs from the master and slave and sniffing traffic to see what UUIDs fly past.

If you can spare £100+ for an Ubertooth to successfully capture traffic and you manage to obtain some of the Service codes, then a BLE device could be under your control in a matter of minutes. All you need to do now is use your own device, such as a laptop, to pair (or spoof pairing) and send over your Service codes. Although his method was slightly different, Mike Ryan actually got CVE-2015-2247 for managing to send service codes which modified the movements of a BLE enabled electric skateboard!

In conclusion, any devices running BLE versions 4.0 and 4.1 are vulnerable to having their encryption keys exposed with tools like Crackle. Once exposed, communications between master and slave devices can be uncovered – these include not only data which may be classed as sensitive such as healthcare information, but also opcodes and instructions which can be used to manipulate the device’s operation.

It took them a few years, but Bluetooth SIG removed this symmetric encryption vulnerability in the next Bluetooth release (version 4.2) by introducing Elliptic-Curve Diffie-Helman (ECDH) key exchange. It’s also important to point out that this certainly wasn’t the end of BLE vulnerabilities… but more on this in future posts.

Disclaimer – Don’t do bad things with your newfound BLE knowledge. Also please do let me know if I’ve got something not quite right or, if you have a question, I can be found at the end of the Twitter handle @sudoKathryn.