By Emma Lubes
This project aims to analyze communications over Bluetooth Low Energy (BLE) protocols between hearing aids and phones. The relationship between Internet of Things (IoT) medical devices and cybersecurity is under-researched, particularly research of network traffic being communicated from Internet-connected medical devices . A study of BLE network traffic is performed by using a BLE packet sniffer to capture traffic between two hearing aids paired to the phone as a single device and analysis of this traffic is performed to establish a generic traffic pattern.
2. Materials and Dependencies
|Opn 3 miniRITE – Right||Oticon||Hardware||6.0 (Firmware)|
|Opn 3 miniRITE – Left||Oticon||Hardware||6.0 (Firmware)|
|Bluetooth Low Energy Sniffer||Adafruit||Hardware||3.0 (Black)|
|iPhone 11||Apple||Hardware||iOS 14.4.2|
|CP210x Universal Windows Driver||Silicon Labs||Software||10.1.10|
|NRF Sniffer for Bluetooth LE||Nordic Semiconductor||Software||3.1.0|
Table 1: The materials and software dependencies that were used for this project.
2.1 Product Descriptions
- Opn 3 miniRITE: Hearing aid with built-in Bluetooth Low Energy capabilities.
- Bluetooth Low Energy Sniffer: USB packet sniffer for capturing BLE traffic.
- CP210x Universal Windows Driver: USB to UART bridge VCP driver for the packet sniffer.
- NRF Sniffer for Bluetooth LE: Firmware that bridges the sniffer with Wireshark.
- Wireshark: A packet capture and analysis tool.
3.1 Setting Up the Sniffer
The majority of the Sniffer setup can be performed by following the steps for “USB Driver Install” and “Using with Sniffer V2” included within Source 1. However, further setup not outlined within the source is necessary. Within Wireshark, the “nRF Sniffer for Bluetooth LE” interface toolbar must be activated. This can be done within View àInterface Toolbars à nRF Sniffer for Bluetooth LE. This toolbar allows the BLE packets being viewed to be changed on a per-device basis.
Figure 1: How to activate the nRF Sniffer interface in Wireshark.
Once the toolbar has been toggled on, there are specific settings required to view the hearing aid traffic. The interface selected, COM5, is the nRF Sniffer Interface (and was also the only option). The interface name may be slightly different per nRF Sniffer installation, but it will follow the pattern COM#.
The device name is mode-dependent. “Emma -67 dBm” refers to the name of the hearing aid pair being used and selecting this device shows all the packets that involves the hearing aid pair, either as the source or the destination. The option “All advertising devices” allows the user to show all the advertisement packets for all devices within range that are advertisting, instead of looking at a specific device.
Figure 2: Interface Toolbar settings specific to the pair of hearing aids.
3.2 nRF Sniffer Modes
There are three relevant Adafruit + nRF Sniffer modes for the project.
- To sniff all network device advertisements, start Wireshark using the nRF Sniffer interface and choose “all advertising devices” as the device in the interface toolbar.
- To sniff all advertisements from a single device, start Wireshark using the nRF Sniffer interface and chose the device name in the interface toolbar. Do NOT pair the hearing aid(s) to the phone.
- To sniff all BLE traffic, including advertisements, from a single device, start Wireshark using the nRF Sniffer interface and chose the device name in the interface toolbar. Next, pair the hearing aid(s) with the phone. The connection must not occur until after you have chosen the device in the toolbar, or else you will not be able to see packets passed in the connection.
Note: There were 3 different devices listed in the drop-down menu, one for the left hearing aid, one for the right hearing aid, and one for the hearing aid pair. You must have selected the correct device. The left and right hearing aid individual listings both showed -71 dBm for the RSSI power measure, while the pair listing showed -67 dBm. You must ensure you have chosen the correct device for analysis, and that if only looking at an individual hearing aid, the other hearing aid in the pair is turned off. It may take some trial and error to associate the device name with the physical hearing aid.
Figure 3: The device listing for the hearing aid pair.
Figure 4: The device listing for the left hearing aid.
Figure 5: The device listing for the right hearing aid.
For any sniffer or Wireshark related set-up problems not covered in the previous link or the above write-up, check the nRF Sniffer User Guide (Source 2).
3.3 Introduction to BLE Traffic
The hearing aids being studied use BLE, as opposed to Bluetooth. BLE originally came out in 2011 as Bluetooth 4.0 (Source 3). The main difference between BLE and Bluetooth is the BLE consumes much less power than Bluetooth does, allowing it to be integrated into small devices with much less power generation to spare, such as hearing aids. Bluetooth and BLE are not compatible; a BLE device cannot connect to a Bluetooth device, and vice versa.
There are four main protocols involved in BLE traffic: Bluetooth Low Energy Link Layer (LE LL), Bluetooth Attribute Protocol (ATT), Bluetooth Security Manager Protocol (SMP), and L2CAP. ATT and SMP both run on top of L2CAP. In this section, the LE LL PDU types and ATT opcodes relevant to the analysis of the traffic are explored. Since the L2CAP commands and SMP opcodes are given well-explanatory names, they will be explored when relevant in the Analysis section of the paper.
3.3.1 LE LL PDU Types
|PDU Type||Control Opcode||Usage|
Table 2: PDU and usage information for relevant LE LL packets.
126.96.36.199 Advertising PDUs
- ADV_IND: Advertising packet to which any central BLE device can connect (Source 4).
- SCAN_REQ: Advertising packet sent from a central BLE device that requests more advertising data from a specific device (Source 4).
- SCAN_RSP: Contains additional advertising data that is from a peripheral BLE device to a central BLE device upon request (Source 4).
188.8.131.52 Device Connection PDUs
- CONNECT_REQ: Contains a connection request sent from a central BLE device to a specific peripheral BLE device (Source 4).
- LL_VERSION_IND: Control type that indicates the LE LL version number.
- LL_CONNECTION_UPDATE_REQ: Control type that indicates that a connection is starting or being updated.
- LL_FEATURE_REQ: Control type that indicates that the master is requesting a list of compatible features from the slave.
- LL_FEATURE_RSP: Control type that indicates that the slave is resolving the compatible features with the master.
- LL_TERMINATE_IND: Control type that indicates that the master-slave connections is being closed.
184.108.40.206 Device Communication PDUs
- LL_ENC_REQ: Control type that indicates that encryption is being requested.
- LL_ENC_RSP: Control type that indicates that encryption is being established.
- LL_START_ENC_REQ and LL_START_ENC_RSP: Control types that are used in-conjunction to perform the 3-Way handshake for beginning encryption (Source 5).
3.3.2 ATT Opcodes
|Sent Read By Group Type Request||0x10|
|Recv Read By Group Type Response||0x11|
|Sent Read By Type Request||0x08|
|Recv Read By Type Response||0x09|
Table 3: PDU types and opcodes for relevant ATT packets.
- Sent Read By Group Type Request: Request for an attribute to be sent from the device’s group attribute array (Source 6).
- Recv Read By Group Type Request: Response with the attribute from the group attribute array (Source 6).
- Sent Read By Type Request: Request for an attribute to be sent from the device’s local individual attribute array (Source 6).
- Recv Read By Type Request: Response with the attribute from the individual attribute array (Source 6).
Note: A “Usage” section of the table is not included since all four packet types are mainly used for device connection.
Generic Attribute Profile (GATT) is the method for exchanging profile and user data between devices over a BLE connection. GATT-based profiles that devices from different vendors can still operate with each other over BLE (Source 7). During analysis, several portions of the GATT exchange will be seen.
For the purposes of this project, the traffic from the hearing aid pair (right and left hearing aids together) were studied. The hearing aids were paired to the phone together so as to be recognized as a pair. For ease of reading the remainder of the writeup and included figures, a table of addresses, Wireshark identifiers, and the devices associated with these identifiers. Pre-connection, device connection, data transmission, and connection termination phases of traffic will be considered. Furthermore, the analysis is completed with both the left and the right hearing aids on and connected to the phone. This is done so as to force the central device to consider the peripheral devices as one peripheral device and observe how this is done over BLE protocols; when a person wears two hearing aids, sound must stream to both hearing aids synchronously, so that the hearing aids remain in-sync.
|MAC Address||Associated Device||Wireshark Identifier|
|74:0F:CA:63:61:FA||Hearing Aid Pair/Peripheral Device||Slave_0xaf9a92d1|
Table 4: Identification information for the devices included in analysis.
Figure 6: Advertisements between the phone and the hearing aid, prior to connection.
Before attempting to pair with the phone, the hearing aid pair sends periodic broadcast messages to other devices within range, looking for a central device with which to connect. After receiving this broadcast message from a peripheral device, a central device requests to scan the peripheral device (Figure 6). This process continues until a connection request is made.
4.2 Device Connection
Figure 7: Connection request from phone to hearing aid pair.
Figure 8: Version and connection updates occur between the master and slave.
The phone sends a connection request (Figure 7), and after being accepted, version and connection information is communicated between the phone and the pair of hearing aids (Figure 8).
Figure 9: The master requests features that it offers from the slave.
Figure 10: The slave responds with its’ available features.
The next part of the connection process is resolving the connection features that can be used between the phone and the hearing aids. The phone, now known as master since a connection has been initiated, requests the features that it offers from the hearing aids. Since the master device is a phone, it has quite a few feature available for use (Figure 9). The hearing aid pair, now know as the slave, responds with the features it has available. Since the hearing aids do not have much spare processing power, the only extra feature it offers is data encryption (Figure 10). From this response, the master knows not to attempt to use any of the excess features that the slave is unable to use.
Figure 11: ATT slave acknowledgment and GATT information exchange begins.
Once version, communication, and feature information have been resolved, the slave acknowledges that it is ready to communicate, and the master the slave for GATT information (Figure 11). Here, the majority of communication switches from LE LL to ATT.
Figure 12: The slave sends its primary service handles.
Figure 13: The master asks for characteristic declaration for prior-received handles.
Figure 14: The slave sends back the Manufacturer Name String, the Model Number String, the Hardware Revision String, the Firmware Revision String, and the Software Revision String, as well as the properties the master is allotted to these characteristics.
Several things occur during the transfer of GATT information. First, the slave sends its primary service handles (Figure 12). This communicates the hearing aid pair’s primary functionality to the phone. The master then asks the slave for to declare characteristics for each of the handles it received (Figure 13). The characteristics often are undefined within the ATT protocol, but responses include the handle, characteristic properties (i.e, what permissions the master has with this handle, such as read/write), and the characteristic value handle. Figure 14 shows the slave responding with defined characteristics that Wireshark is able to translate: the Manufacturer Name String, the Model Number String, the Hardware Revision String, the Firmware Revision String, and the Software Revision String.
Figure 15: SMP Sent Pairing Request packet sent from the master to the slave.
Figure 16: SMP Recv Pairing Response packet sent from the slave to the master.
Once the exchange of GATT information has concluded, the master sends a pairing request to the slave over SMP. This request includes the maximum encryption key size, the Initiator Key Distribution, and the Responder Key Distribution (Figure 15). The slave sends a pairing response to accept the pairing request and resolve the encryption keys to be used throughout data transmission.
4.3 Data Transmission
Figure 17: The LE LL/SMP encryption exchange between the master and the slave.
Since the slave has accepted the request to pair from the master, data transmission begins with a series of messages to begin data encryption (Figure 17).
Figure 18: An ATT/L2CAP write exchange between the master and the slave.
Because the data is encrypted, the plaintext write values cannot be viewed. However, ATT Write Requests and L2CAP Update Responses can still be viewed (Figure 18). While connected, the phone sent multiple requests to the hearing aids to increase and decrease the volume, so this traffic is presumed to be volume modification of the hearing aid pair.
4.4 Connection Termination
Figure 19: The LE LL termination packet sent from the master to the slave.
To terminate the connection, one hearing is turned off. When the hearing aid is turned off, the master attempts to formally terminate the connection using an LE LL LL_TERMINATE_IND packet, but the packet is malformed due to the hearing aid pair now being 2 standalone hearing aids, and not paired under the device name.
Figure 20: Broadcast advertisements from the hearing aid “pair” after connection termination.
Figure 21: The final, malformed advertisement packet that is attempted to send from the slave to the master.
Once the connection is terminated, the hearing aid pair (but really, the stand-alone hearing aid) goes back to advertising, waiting for the other hearing aid to come back online so the pair can reconnect to the phone (Figure 20). When the other hearing aid is turned off, there is one last broadcast from the slave to the master, which is also malformed since there is no longer actually a slave to advertise from, and packet stop (Figure 21). The slave and master are missing their identification strings, as the slave in question is no longer made up of both hearing aids and the hearing aids do not need to be identified together. Since both hearing aids are turned off, no more advertisements are seen from the device, and no scan requests are made from the phone.
Optimally, some reverse engineering of the hearing aid BLE messages could have been performed after analysis of the BLE traffic. Since the data is encrypted, this is impossible at the current time, as the OOB encryption algorithm used to encrypt the data would need to be cracked in order to access the plaintext values within the ATT Write Requests. However, a in-depth look at the pairing and termination process for BLE hearing aids was performed, which had not been done previously.
This model of hearing aids does not have an on/off switch. Instead, the hearing aids are turned on/off by opening and closing the battery door, so that the circuit is broken/completed. This means that the model of hearing aid being studied experiences a force-quit instead of a graceful close.
6. Future Work
As established previously, the hearing aid model in use uses OOB authentication to encrypt the data being used within data transmission. In order to reverse engineer the hearing aid traffic, either the hearing aids will need to be convinced not to use encryption, or the OOB authentication process or encryption keys being used will need to be cracked. These are all potential routes for future research into hearing aid BLE communications.
This model of hearing aids does not have an on/off switch. Instead, the hearing aids are turned off by closing the battery door, so that the circuit is broken. This means that the model of hearing aid being studied experiences a force-quit instead of a graceful close. In the future, work can be done to identify potential traffic differences between hearing aids that use a graceful close method instead of a force-quit method to terminate the connection.
In this project, connection termination was only studied by turning the hearing aids off. Another method of terminating the connection would be to have the phone forget the devices during the connection or to turn off BLE during the connection. Further research can be done to identify potential traffic differences between turning the hearing aids off during the connection and turning BLE off during the connection. It should be kept in mind that many hearing aids are considered “Made for iPhone” devices by Apple and connect slightly differently within iOS than other Bluetooth/BLE devices do, and in these cases, the option to turn off BLE may not exists. The option to have the phone forget the device still withstands, regardless of the hearing aid model’s classification within iOS.