Cybersecurity Assessment of the Polar Bluetooth Low Energy Heart-rate Sensor
Smone Soderi




Cybersecurity Assessment of the Polar BLE Heart-rate Sensor





S. Soderi



IEEE Senior Member 

soderi@ieee.com

Cybersecurity Assessment of the Polar Bluetooth Low Energy Heart-rate Sensor
    S. Soderi1
    
============================================================================





Wireless communications among wearable and implantable devices implement the information exchange around the human body. Wireless body area network (WBAN) technology enables non-invasive applications in our daily lives. Wireless connected devices improve the quality of many services, and they make procedures easier. On the other hand, they open up large attack surfaces and introduces potential security vulnerabilities. Bluetooth low energy (BLE) is a low-power protocol widely used in wireless personal area networks (WPANs).
This paper analyzes the security vulnerabilities of a BLE heart-rate sensor. By observing the received signal strength indicator (RSSI) variations, it is possible to detect anomalies in the BLE connection. The case-study shows that an attacker can easily intercept and manipulate the data transmitted between the mobile app and the BLE device. With this research, the author would raise awareness about the security of the heart-rate information that we can receive from our wireless body sensors.




8.4cm1pt

Please cite this version of the paper:


Soderi, S. Cybersecurity assessment of the polar bluetooth low energy heart-rate sensor. In Body Area Networks: Smart IoT and Big Data for Intelligent Health Management: 14th EAI International Conference, BODYNETS 2019, Florence, Italy, October 2-3, 2019, Proceedings 14 (pp. 252-265). Springer International Publishing. https://doi.org/10.1007/978-3-030-34833-5_20



You may use the following bibtex entry:

8.4cm1pt






§ INTRODUCTION


In the last two decades, Bluetooth became very popular in the short-range communications. Every smartphone, tablet and personal computer embeds this technology. At the same time, many wireless sensors such as fitness sensors, smartwatches, headsets, wireless medical devices (WMDs) rely on Bluetooth to exchange data with the user's smartphone or tablet. Today, wireless body area networks (WBANs) collect humans' information through Bluetooth low energy (BLE) sensors nodes. BLE is thus becoming de-facto a key wireless technology and users leave that interface always enabled on their devices. BLE was introduced as Wibree by Nokia in 2006 <cit.>. Today, BLE is the dominant technology to convey efficiently data in body networks using coin cell battery-powered devices.

Though the advantages offered by any WBAN are substantial, it makes one of the prime targets for security threats and more particularly for users' privacy.  WBANs are commonly used to track health and fitness data and it raises the interest of cyber-criminals to this kind of information.



Fitness wearable devices collect human`s information, and they are designed to be worn all day. The user reads these data through his smartphone, tablet or even by his smartwatch. Historically,  these fitness trackers have numerous security vulnerabilities and the wireless sensor or even the software application may disclose users' data. It is clear that it might have important privacy implications <cit.>. 
In the literature, there are several contributions that deals with security aspects in WBAN health-care applications. Indeed, the security weaknesses of WMDs can lead to a high risk for the patient's safety <cit.>. On the other hand,  standardization bodies have already adopted security solutions. The IEEE802.15.6 defines different levels of security throughout the encryption and authentication of the data <cit.>. Moreover,  the European Telecommunications Standard Institute (ETSI) takes into account the security in the smart body area networks (SmartBANs) <cit.>. SmartBANs are used for the collection, processing, and transmission of patient's data. It is crucial that the information must be securely treated <cit.>.
The rapid proliferation of wireless implantable medical devices (WIMDs) coupled with their increasing features is raising the risk for patients <cit.>. 

The utilization of wireless technology  makes the data prone to being eavesdropped, modified and injected. This increases concerns about the privacy of the information managed in WBANs. In this paper, the author is considering man-in-the-middle (MitM) attack in a BLE WBAN fitness scenario. Observing the received signal strength indicator (RSSI) variations, this study proposes a mechanism to detect MitM attacks.

The rest of this paper is organized as follows. Section <ref> overviews the BLE specifications. Section <ref> describes the security vulnerabilities of a BLE heart-rate sensor and the results of a MitM attack. Then, the paper proposes security countermeasures. Finally, conclusions are presented in Section <ref>.





§ BLUETOOTH LOW ENERGY (BLE)





 §.§ BLE Core Specifications

Bluetooth is an open standard used for short-range communications. This wireless technology operates in the 2.4 GHz ISM band and it is primarily used for consumer, medical and personal devices <cit.>. With Bluetooth users can create personal ad-hoc networks to transfer any kind of data. Above 5 billion Bluetooth devices are expected to be shipped within 2022 <cit.>. At the time of writing, Bluetooth 5.0 is the most recent version and it is rapidly adopted in smartphones. Despite the Bluetooth Special Interest Group (SIG) releases newer versions, even older ones are currently in use and is common to find Bluetooth 4.1 and 4.2 in commercial devices <cit.>. The Bluetooth architecture specifies two forms: basic rate/enhanced data rate (BR/EDR) and low energy (LE) <cit.>. This paper refers to the BLE standard.

Table <ref> shows a comparison of the lower layers between BLE and Bluetooth BR/EDR. This comparison indicates a different usage of the radio spectrum. BLE splits spectrum into 40 channels: 3 advertising channels to establish connections and 37 channels to transmit data. Furthermore, BLE devices are designed to send short bursts of data rather than a continuous data stream. It makes BLE ideal for sensor applications. BLE devices consume very low energy in comparison to other wireless technologies. 
 







BLE is a full protocol stack. It is a combination of hardware parts and software layers <cit.>. As shown in Figure <ref>,  BLE architecture is organized in three major blocks: applications, host and controller. The user application defines the interface with the Bluetooth stack. Host block consists of the upper layers, whereas controller includes lower layers. Host and controller communicate through the host controller interface (HCI). This division makes possible to interface many hosts with a single controller by using the HCI.

The generic access profile (GAP) layer controls the role and connection of a BLE device. BLE  specifications define GAP roles as follows <cit.>

	
  * Broadcaster: a device that only sends advertising events;
	
  * Observer: a device that only receives advertising events;
	
  * Peripheral: a device that accepts the establishment of a LE physical link using the connection establishment procedure;
	
  * Central: a device that initiates the establishment of a physical connection.



 

The logical link control and adaptation protocol (L2CAP) layer plays a central role in Bluetooth stack.  It takes multiple protocols from the upper layers and encapsulates them into the standard BLE packet format and vice-versa. L2CAP layer is in charge or routing two main protocols: the attribute protocol (ATTP) and the security manager (SM).

Figure <ref> shows the connections flow between master and slave  BLE devices. In a fitness scenario, the central device, e.g. a smartphone, scans the frequencies for connectable advertising packets. The peripheral devices, e.g. the heart-rate sensor sends connectable advertising packets periodically and accepts incoming connections. Once a connection is established master and slave use generic attribute (GATT) profiles to exchange data. GATT is a simple structured list. Indeed, the data in GATT is organized in services and each service contains one or more characteristics.
Each characteristic consists of a universally unique identifier (UUID), a value and a set of properties. Bluetooth SIG defined UUIDs to identify BLE manufacturers as well <cit.>. By reading UUIDs data, the hacker might gather useful information to plan his attack.



 §.§ BLE Security

In the BLE architecture (Figure <ref>) SM is responsible for paring, integrity, authentication, and encryption <cit.>. SM distributes security keys between peers and provides cryptographic functionalities. 

NIST 800-121-R2 details the security capabilities of Bluetooth and makes recommendations to effectively secure these devices. BLE security is different from Bluetooth BR/EDR. Since the introduction of the BLE 4.0, the protocol supports a 128-bit advanced encryption standard–counter with CBC-MAC (AES-CCM) <cit.>. Although AES is considered one of the most secure forms of encryption, the key exchange protocol is exploitable. Indeed, during the pairing process devices in BLE 4.0 and 4.1 versions exchange a temporary key (TK) and use it to create a short-term key (STK). These keys are used to encrypt the communication. In this case, an attacker can eavesdrop the keys and then decrypt the connection. This is not the case for BLE version 4.2 and beyond due to the introduction of a long-term key (LTK) which uses the  elliptic curve Diffie Hellman (ECDH) key exchange, which is proved to be secure under this type of attack <cit.>.

BLE 4.0 and 4.1 devices use the secure simple pairing  (SSP) model, in which devices based on their input/output (I/O) capabilities, choose one method from 

	
  ∙ Just Works: TK is all zeros;
	
  ∙ Passkey: TK is a six-digit number combination inserted by the user;
	
  ∙ Out-of-Band (OOB): TK is exchanged through a different medium.


The SM can protect the connection from MitM when the operating system (OS) selects Passkey or OOB as paring method. On the other hand, Just Works method does not provide any protection against MitM, that can be exploited by potential hackers.





§ CYBERSECURITY IN A WBAN FITNESS SCENARIO


Despite the Bluetooth SIG released the new  Bluetooth 5.0, there is still a huge number of devices in use that utilizes older versions of Bluetooth, such as version 4.1 and 4.2 <cit.>. Based on a recent estimation last year there were 4 billion BLE enabled devices using version 4.0 or 4.1 <cit.>. Based on this information, the paper addresses security issues in BLE 4.1 devices.




As shown in Figure <ref>,  the scenario investigated in this paper includes a Polar H7 heart-rate BLE sensor worn at appropriate positions on the body <cit.>. The device communicates a person's activity data through the BLE protocol to the smartphone. Due to their nature, WBAN might experience eavesdropping attacks. In this scenario, security and privacy are among major areas of concerns.

Once the author described the BLE protocol in the previous sections, the system analysis must be completed by describing the interfaces present in each device. Figure <ref> shows the interfaces between the person, the Polar heart-rate sensor and the smartphone which runs the app to perform the synchronization. In particular, by using a SysML internal block diagram (IBD) <cit.>, the author highlighted only those interfaces that might have a key role in this analysis. 


 




The author has already discussed herein how the pairing procedure in BLE 4.1 makes these devices prone to eavesdropping attacks.
The use of each association model is based on the I/O capabilities of the device. Considering that the smartphone, i.e. the initiator, is equipped with a display and a keyboard display that can be used for pairing by the user. Whereas, the heart-rate sensor, i.e. the responder, does not have any I/O capability.  Thus, in the scenario under investigation and by analyzing the available interfaces, Table <ref> represents all possible pairing options. Accordingly, with the SSP model in this scenario, only the Just Works method can be used. The user is required to accept a connection without verifying TK value on both devices, so Just Works provides no MitM protection because it is an unauthenticated pairing.

The common type of attacks against BLE communications are

	
  ∙ MitM in which an attacker has the ability to both monitor and alter or inject messages into a communication channel;
	
  ∙ Passive Eavesdropping in which  the attacker is secretly listening (by using a sniffing device) to the private communication of others without consent.





 §.§ BLE 4.1 Assessment


This section describes the cybersecurity assessment of BLE 4.1 devices in a fitness scenario as shown in Figure <ref>. The assessment combined multiple methodologies to best fit the investigation needs.





The author selected NIST 800 series to evaluate threats and vulnerabilities of BLE sensors <cit.>. Furthermore, the OWASP guideline is adopted to rate the risk associated with each vulnerability <cit.>.

<Ref> report found vulnerabilities for the scenario under investigation. By following the methodology selected each table ties together concepts such as likelihood, technical impact, risk and threat events that could exploit the vulnerability. Moreover, for each vulnerability, the author provides a description and possible mitigation. 
Since these vulnerabilities have a risk mainly rated between high and critical, it should raise some concerns about the security of the heart-rate information transmitted by the sensor.















 §.§ Experiment with MitM Attack

Based on the cybersecurity assessment, in this section, the author proposes an active MitM attack for testing the BLE WBAN in a fitness scenario.

MitM usually involves three actors: Alice, Bob and Eve. In BLE networks this attacks changes its architecture. Indeed, the attacker, i.e. Eve, cannot act simultaneously as a sensor and as a mobile app.
Therefore, a BLE MitM needs to make use of two BLE components capable of acting together: one connects to the mobile app acting as the smartphone, while the other connects to the smartphone acting as the mobile app <cit.>. 

The WBAN experiment setup consisted of a Polar H7 heart-rate sensor, i.e. Alice, and an Apple iPhone SE <cit.>, i.e. Bob.  The synchronization between the sensor and the smartphone is performed over BLE 4.1. The smartphone ran the Polar Beat mobile app for real-time heart-rate monitoring <cit.>.
As shown in Figure <ref>, Eve consists of a laptop that runs Linux Ubuntu 18.10 and two CSR 8510-based USB dongles that support BLE 4.1. These two dongles are connected to the laptop and communicate with each other using the BtleJuice web-based software <cit.>. 



 

BtleJuice is a framework to perform MitM attacks on BLE devices. This framework consists of two parts which run on two virtual machines hosted by the same laptop. These parts named interception core and proxy, and they implement the MitM architecture shown in Figure <ref>. And to do this, each virtual machine manages one USB dongle.




BtleJuice acts as a proxy between the mobile app and the BLE heart-rate sensor. Any command sent to the sensor is captured by BtleJuice and relayed to the sensor. In particular, the interception proxy interacts with BLE peripherals and the interception core generates the fake devices with a fake BLE address. Then, the attacker from the web user interface (UI) can control the interception core. He can select the BLE target and intercept GATT operations. From the UI, it is possible to replay any GATT operation, but it allows also on-the-fly (OTF) data modification.

In WBAN BLE fitness scenario, Polar H7 heart-rate sensor communicates with the Polar Beat. Since the pairing process is completed, the author started  the experiment by attempting to actively sniff BLE traffic.
Figure <ref> shows how Eve, by using BtleJuice, can intercept the BLE information exchanged between the peripheral and the mobile app and manipulate data OTF. 

Once Btlejuice is initialized, the UI allows Eve the selection and the connection of the Polar H7 BLE sensor. In this way, Bob rather than connect to its peripheral, he connects his mobile app to the fake device. As shown in Figure <ref>, the attacker by using the replay function in Btlejuice can modify the heart-rate measurement, i.e. characteristics 0x2A37 <cit.>, inside the heart-rate service, i.e. 0x180D <cit.>. As proof of concept (POC), Eve pushes 255 beats per minute (bpm) in the Polar Beat app.



 §.§ Discussion about Security Countermeasures

As pointed out during the cybersecurity assessment (Section <ref>), BLE specifications do not offer defenses against MitM attacks. Although the experiment is limited to the WBAN fitness scenario described in this paper, these security leaks can give an advantage to the attacker.

On the L2CAP layer, there is the possibility to request an echo from the BLE sensor to measure round trip time (RTT) on the established link by using the l2ping command. It is included in the BlueZ utils<cit.>. The author assumes that the RTT of the MitM connection in Figure <ref> is greater than the one in the BLE original connection. The evaluation of the RTT might offer a mechanism to detect the MitM. Unfortunately, the l2ping command is not supported in most of the BLE peripherals. 




Alternatively, the evaluation of the RSSI might offer another way to detect a MitM attack.
In the literature, there are several contributions to the relationship between the RSSI and the distance. In <cit.>, RSSI is described as follows




    RSSI = - 10 · N · log(d) + a,
 

where N is a constant assumed 1, d is the distance in meters and a is the transmitted power at 1-meter distance.




The author measured the RSSI by using the iPhone and the Bluefruit mobile app <cit.>. Table <ref> shows the average value and the standard deviation of the RSSI over 10 measurements for each distance. These measurements validate the RSSI model in (<ref>). Although the indoor environment and layout settings have a direct effect on the RSSI variability, the author assumes that Eve's RSSI can be greater than Bob's RSSI. Figure <ref> and Table <ref> confirm the assumption. In this scenario, by monitoring the RSSI value Bob can have a mechanism to detect the attack. Indeed, if the RSSI increased unexpectedly then the mobile app might alert the user about a possible attack. 





§ CONCLUSIONS


This paper aims to raise a concern about the need to be aware on the use of BLE devices. The author analyzed the security issues of BLE 4.1. based sensors. Using the NIST classified threats, the author has identified a list of attacks which apply to BLE devices.

The WBAN scenario under test consists of a Polar H7 heart-rate sensor that communicates with the Polar Beat mobile app using the BLE technology. Being Polar Electro a top player in the wearable smart health devices, its BLE-based sensors are spread worldwide. With this research, the author would raise awareness about the security of the heart-rate information that we can receive from our wireless body sensors.

The case study shows that an attacker can easily intercept and manipulate the data transmitted between the mobile app and the BLE device.  Btlejuice was used to implement an active MitM attack, an operation that can result in the OTF modification of the data. The author remarks the importance to detect this kind of attack that might modify sensitive information such as the heart-rate.






splncs04

