Discovering BLE Security through an internship

This article has been written by François Sevaux, student in his first year of Master at Université de Bretagne Sud, France, during his internship in our group.

Internet of Things (IoT) have been growing fast over the past years, mainly due to a major price cut of dozens of electronic devices and physical components. Smart sensors are integrated in all areas, from consumers’ home to critical infrastructures like smart grids or water utilities. The medical industry is no exception to this global trend and is getting more and more digitally connected to help increase the quality of the care and ease patients’ life. It is also common those days for people to wear low-cost IoT devices that can track their vitals, from heart beats to blood sugar level.

The integration of IoT to the so-called Wireless Body Area Network (WBAN) comes with several concerns related to the security of this ecosystem. How secure are the devices? What information is collected? How is this information secured on the device and during its transfer? These are only some examples of questions that can be raised.

Internship subject’s presentation

The goal of my internship at SINTEF was to study the communication link between an eHealth IoT device and an arbitrary gateway. The general idea is for the patient to allow some professional (physicians or researchers for instance) to have access to the data according to the permissions he would have defined. To do so, one must ensure that there is no security flaw in the system, and that starting from the IoT sensor.

For our study, we will consider a heartbeat sensor sending its data to a smartphone (also called the gateway). Then, this gateway sends the data to a secure server where it can be analyzed. Such a connection between the sensor and the smartphone is established with Bluetooth Low Energy (BLE). What happens to the data once on the smartphone was not considered here. The smartphone can indeed be used to send data securely to a server using standardized and well-known protocols.

My work was included in a bigger ongoing project SINTEF is part of: “Health Democratization”. This project aims to enable sharing health data in a secured and controlled way to benefit of the immense scientific, societal and commercial values of those data.

Figure 1: Project’s scope

Internship’s outcomes

Bluetooth Low Energy (BLE) is a low power wireless technology used to connect devices with each other. It is targeted towards applications (perfect for smartphones) that need to consume less power and may need to run on batteries for long periods of months, and even years. As a mean of comparison, BLE could be seen as the intelligent and power-friendly version of the Bluetooth wireless technology. Its power efficiency makes it perfect for IoT devices, which need to run on a tiny battery for long periods.

The main perk of BLE in the medical field is that it can be adapted on small objects that can monitor many human body parameters. It uses little battery and last for long time periods. It is simple to use for patients (they have often nothing to do) and it is as efficient as any other communication protocol (Wi-Fi, LoRa, ZigBee, …).

However, the Bluetooth/BLE Core Specification is very hard to understand for unaccustomed developers (over 3000 pages!). That might unfortunately lead to ambiguity or errors in the implementation and to vulnerabilities discovered afterwards. More countermeasures exist and have to be included into the code of the running application (like build flags). Other common attacks are Man-In-The-Middle (MITM) or passive eavesdropping. They can be avoided by applying the different levels of security during the establishment of the connection. The best practice is for security is to use the Out-Of-Band (OOB) association model, Secure Simple Pairing Mode 1 Level 4. See Core Specification and BLE security guide for more detail.

In order to better apprehend BLE security, some practice was required. This allowed me to use my skills developed at University and to put in action some knowledge acquired earlier.

The most interesting part in experiments was that I had to set up a completely new development environment for me. I had never worked with Nordic Semiconductor hardware. More precisely, I had to get familiar with the nRF52840 dongle and with Nordic software to program the dongle.

Figure 2: the Nrf52840 Dongle

This dongle is a small and low-cost USB dongle that is mainly used for its ability to work with BLE. It was decided to use the Nordic nRF52840 soc because it supports Bluetooth 5, is built around an ARM Cortex M4 and the documentation makes it easy to get started with this hardware. In addition, it can be used either with the nrf5 SDK, or the more recent nrf Connect SDK that integrates Zephyr, an open source RTOS. The nrf52840 dongle is programmable with either ‘nRF Connect for Desktop’ under Windows or with the command line tool ‘nrfutil’ for Unix users.

I setup several scenarios, with different goals and security levels. The main one was a heart rate sensor (simulated by the dongle), sending its data to my smartphone using BLE, and visualized via the Nordic nRF Connect app. The goal was to try to listen to the communication with various methods. I used Wireshark and a second dongle to capture the BLE flow and then analyze it. It was also possible to activate HCI packets capture on the phone directly to simulate a capture with more privileges, and to later study it on a computer. Finally, it is also possible to use specialized hardware to capture the BLE traffic. After my hacking experiments, I tried to make the heart rate program as secure as possible by following the best BLE security practices previously identified during the documentation phase.

BLE is relevant for a health monitoring sensor for sure. The main perk of this protocol is that it is widely used across the world and especially for embedded sensors like this. This means that BLE is followed by many researchers who are testing it and looking for improvements.

The main disadvantage is the complexity of the BLE stack which makes it really hard for manufacturers to implement it. It is up to them to make sure they follow an up-to-date Core Specification to have secure device.

The security of BLE lies in the hands of its implementers. It is important to keep in mind that countermeasures cost time and money to the company developing a device. Depending on how sensitive or critical transferred data will be, it is sometimes necessary to make a compromise between security measures and a fast device with low energy consumption.

Conclusion

This internship allowed me to learn a lot more on embedded systems, which is the main topic of my studies. It was a great way to apply the learnings from my years of academic training. The fact that I worked on a Nordic dongle is a real perk. Those devices use state-of-the art and constantly evolving technologies. A technological watch allows me to stay up to date with the scientific progress in the field of embedded systems.

Working with a research institute as important as SINTEF was a great experience. I have been in contact with the research community and embedded systems professionals. Despite the COVID-19 situation, I have been well integrated (virtually) in the cybersecurity research group and learned a lot on research techniques and personal improvements.

Author: François Sevaux