Nowadays, the Bluetooth technology is widely used for general mobile phone and wireless IoT solutions, this last one thanks to the implementation of the Bluetooth Low Energy (BLE) standard suitable for battery-powered IoT sensors.
Bluetooth was originally conceived by Dr. Jaap Haartsen at Ericsson in 1994. It was named after a renowned Viking ruler who united Denmark and Norway in the 10th century.
It operates in the 2.400 GHz to 2.4835 GHz frequency range, and although it occupies very similar frequencies to WiFi, it was designed for much shorter range and lower power consumption.
There are several Bluetooth versions released, from 1.0 to 5.0. In this article, I will focus on the most recent ones, from 4.0 to 5. Let us start.
Currently, several Bluetooth versions are in use in commercial devices and all of them support backward compatibility with the “classic” one. Earlier versions implement different methods to pair devices and implement different security mechanisms. If we are connecting a device with an older Bluetooth version with a device with a newer one, you have to be aware that the security implementation of the oldest one is going to be used for communication.
There are two main security factors to consider when connecting with another device: how they pair and which security methods they use in the communication.
For Bluetooth BR/EDR, after the version 4.0, there were some changes regarding the Pairing Algorithm and Encryption Algorithm. In the case of the Pairing Algorithm, Elliptic Curve P-192 was upgraded to Elliptic Curve P-256. The Encryption algorithm was changed from E1/SAFER+ to AES-CCM, providing better encryption.
For BLE, the main change was in the efficiency of the Pairing Algorithm, which was changed from AES-128 in version 4.1 to Elliptic Curve P-256 in version 4.2.
These are things to keep in mind when acquiring devices for your project, especially when working with devices using the 2.1 or older standard, where the algorithms and security mechanisms have changed even more.
Secure Simple Pairing (SSP) is the mechanism used by devices implementing version 2.1 and onwards. This mechanism simplifies the PIN pairing process used previously. There are four different association models, making it more flexible.
Most of the devices use Just Works, even though it is possible to use another kind of association. Just Works doesn't prevent attacks like Man-In-The-Middle. Moreover, some values are passed between the devices in plaintext during the STK (Short Term Key) generation, which can later lead to the LTK (Long Term Key) that will be used to encrypt all future communication.
Unfortunately, most BLE devices are not capable of using another method because of the lack of screens, as well as the fact that adding more circuitry will make them more expensive.
As I mentioned before, Bluetooth Low Energy devices implement an encryption algorithm defined in the AES-128 block cipher protocol. Data within the payload can be encrypted, ensuring confidentiality. The packets also include a Message Integrity Check to validate the integrity of the messages and a package counter to avoid replay attacks.
After two devices have entered the Connection State, the host should initiate encryption. The slave can send a Security Request command to ask about this, but only the Host can start it.
We should always be sure that our devices are using link-layer encryption to avoid sending messages in plain text during communication.
If you need a high level of security for communication between devices, you can implement encryption at the application level. The data is first encrypted, and then is transferred using Bluetooth. When it is completely received, it should be decrypted on the other end.
The transmission of the data will take longer than without encryption, and this time will vary according to the algorithm used to encrypt. If DES, AES and Triple DES algorithms are considered, the DES will perform the best time-wise, but is not considered truly secure. On the other hand, AES and Triple DES will perform similarly when transmitting, but Triple DES will take longer to encrypt the data. Is advisable to use AES or DES depending on the level of security needed.
A re-authentication can be required every time a user wants to access secure information or services. This can be implemented in the application very easily, for example by using a fingerprint scanner to avoid annoying the user by asking him for a username and a password every time there is an interaction with a secure information or service.
This kind of mechanism can avoid attacks such as BlueBugging and BTVoiceBugging effectively.
There are several ways of improving the security of the Bluetooth connection used in our application, but it is also necessary to instruct to the user in using the best practices to interact with our Bluetooth products.
For example, one thing that should be done is explaining to the user that the first pairing should be done, if possible, in a secure environment to avoid MITM attacks, etc.
It is always important to bring the best and most secure experience possible to the users.
Have a nice code.