Since many of these wireless devices rely on Bluetooth technology, Bluetooth SIG (the authority for Bluetooth technology) added a variety of security protocols while maintaining convenience and reliability.
What makes Bluetooth security possible is its clever encryption methods and algorithms. Keep on reading if you are interested in how Bluetooth security is designed and uses encryption.
Latest Bluetooth Versions and Low Energy Privacy
Bluetooth security aims to provide standard protocols for Bluetooth-capable devices concerning authentication, integrity, confidentiality, and privacy, all of which use encryption. It’s has been in use since 1998 and has already had several iterations.
In 2010, with the rising need for better short-range wireless technology, Bluetooth SIG developed a newer version of Bluetooth—Bluetooth 4.0. The most significant difference between the older generations of Bluetooth and Bluetooth 4.0 is the addition of BLE (Bluetooth Low Energy).
Do note that “Low Energy” in BLE doesn’t mean it necessarily uses less energy; it just means that it works well with low energy devices such as wireless earphones, which have minimal battery capacity.
Since most devices run on Bluetooth 4.0 and up, we will specifically discuss the design stack of these newer versions. Furthermore, this version solved many of the security problems of previous Bluetooth generations.
The current versions of Bluetooth are currently using the BLE stack shown below:
We are interested in a piece of the fourth layer of the stack known as the Security Manager, which handles everything concerning authentication, security, confidentiality, and privacy. The Security Manager implements its protocols through the pairing and bonding of devices.
BLE Pairing Methods
Pairing is an integral part of Bluetooth’s Security Manager. It authenticates the device you are connecting to if it is the intended device and then generates an encryption key for both devices to use throughout the session.
Your devices can use several authentication methods to ensure you are connected to the intended device. These methods would include the following:
Just Works: The fastest but less secure method of passing encryption keys for both devices OOB (Out of Band): Uses other authentication methods (besides Bluetooth) to send encryption keys. An example would include connecting through NFC or using your device’s camera to scan a QR code on the other device’s display Passkey: Users authenticate themselves by giving the correct passkey when prompted Numeric Comparison: Works just like Passkey, but the devices automatically send passkeys. The users only need to confirm if both devices have the same passkeys
BLE Encryption Key Algorithms
Now that your devices have authenticated the identity of the connecting device. They would then send encryption keys which your devices will use to encrypt and decrypt data throughout the session.
Bluetooth’s Security Manager has different phases in which it utilizes various encryption key algorithms to work correctly. The most common encryption key algorithms used by the latest version of Bluetooth (4.0 and up) would be the following:
Symmetric-Key Ciphers: this type of encryption uses a single key to decrypt hashes or ciphers Asymmetric-Key Ciphers: this encryption type utilizes what is known as a public key and a private key. A public key is used to encrypt data, while a private key decrypts the encrypted data Elliptical Curve Cryptography (ECC): uses an elliptic curve equation to create keys that are much shorter than symmetric or asymmetric keys but equally secure Advanced Encryption Standard (AES): is a symmetric block cipher spanning 128 bits in size
The Security Manager’s Pairing and Bonding Process
The Security Manager Layer is designed to handle all things security within Bluetooth through what is known as pairing and bonding processes. There will always be a master device and a slave device in a Bluetooth connection.
The master device is the device that scans for broadcasting Bluetooth-capable devices. In contrast, a slave is a device that broadcasts its location for the world to know.
An example of a master and slave relationship would be your phone and a wireless earphone. Your phone is the master device because it scans for Bluetooth devices, while your wireless earphone is the slave because it is the one broadcasting its signals for your phone to find.
The pairing process consists of the first two of the three phases of the Security Manager’s security phases. The pairing process involves the initial connection of devices attempting to connect.
For the initial pairing, both the master and slave devices would share a list of capabilities each device features and the version of Bluetooth they are running. These capabilities would include whether or not the device has a screen, a keypad, a camera, and NFC.
After letting each other know their capabilities, the slave and master devices would decide which security protocol and encryption algorithms to use.
The shared encryption for the initial pairing of both devices is known as an STK (Short-Term Key). As the name suggests, an STK would be the encryption key that both master and slave devices would use until the session ends.
When both devices have successfully paired, they use the STK to encrypt every packet of data they would share. And with the data encrypted, anyone who tries to monitor your session won’t have an STK to decrypt data.
The problem with an STK is that it is only suitable for one session. Both devices will have to keep pairing to generate a new STK for every session. For this reason, an extra optional stage called bonding has been developed. The bonding stage is the third phase of Bluetooth’s Security Manager. It is the optional prompt you get on your device asking if you trust the paired device and would like to connect to it whenever it sees the device broadcasting. Since both devices are already paired (have a secured connection through an STK), the bonding process won’t require further security checks. What this stage would do would be to generate an LTK (Long-Term Key) and an IRK (Identity Resolve Key). Both devices will then use these keys to decrypt data and automatically identify your device whenever Bluetooth is on.
An LTK is an encryption key similar to an STK in that devices use it to encrypt and decrypt data. The difference is that an LTK is generated through ECC instead of AES-120 and is used for the long term.
To understand an IRK, let’s briefly talk about Bluetooth MAC address. All Bluetooth-capable devices come equipped with a NIC (Network Interface Controller). Each NIC comes with a unique MAC address (Media Access Control). You cannot change these MAC addresses as the given addresses are hardcoded into the physical hardware of the NIC.
Although you can spoof a MAC address through software, it is not a viable option when you want your device to be identified by bonded devices. With this in mind, Bluetooth SIG added an IRK system that allows your device to be recognized by bonded devices and be unidentifiable to unknown Bluetooth devices.
Digging Deep
Bluetooth is a complex mix of technologies that provides a wide range of device compatibilities, convenience, and reliability. The nature of Bluetooth makes Bluetooth security a somewhat tricky topic.
The points stated above are simplified and are meant to give a general idea of how Bluetooth encryption and security work. Hopefully, this serves as a gateway for people who are interested in security to look deeper into the topic and learn more about the inner workings of Bluetooth. To those interested, welcome to the rabbit hole!
