BLE-Berry Project

From Embedded Lab Vienna for IoT & Security
Jump to navigation Jump to search


This Project is the result of a master’s thesis that created a Threat Model of the Bluetooth Low Energy (BLE) Standard and developing a tool called BLE Berry to enable easier BLE Development and to perform basic pentesting operations.

Threat Model

The Threat Model was performed by analyzing the BLE portion of the BLE Standard and gathering further information's from numerous white papers and scientific papers. The gathered Threats and Vulnerabilities got mapped to the Layer/Protocol they are performed on, as shown in the figure below.

BLE Berry Project Threat Model.png

Some of the Threats use other Threats as an entry vector, e.g., a machine-in-the-middle attack relies on address spoofing and can benefit from Radio Jamming. The dependencies of the Threat is shown in the figure below.

BLE Berry Project Threat Dependencies.png

The STRIDE method was used to categorize the discovered Threats, as shown in the following table. STRIDE separates the Threats in the following six categories:

  • Spoofing
  • Tampering
  • Repudiation
  • Information disclosure
  • Denial of Service
  • Elevation of Privilege

BLE Berry Project STRIDE3.png

Threat Vectors

Sniffing / Eavesdropping

Sniffing or eavesdropping is performed with BLE by scanning the Radio for messages. This results in an information disclosure, but can be countered if encryption is used to provide confidentiality. The BLE standard itself provides AES-CCM encryption with message authentication by a key created with the usage of P256 ECDH. The commercial market provides some affordable USB Sniffing Accessories, which output pacap files that can be analyzed with wireshark:

Radio Jamming

Radio jamming aims to perform a Denial of Service (DoS) by disrupting sent data with interfering signals. Radio jamming can be performed on all channels at the same time (called full band jamming) or selective on a single channel. Furthermore, can be differentiated into persistent and reactive jamming. Persistent full band jamming can be detected easily because it interferes with all sent messages for a long time period. Selective reactive jamming on the other hand is hard to detect because it only jams specific messages.


Spoofing is the process of changing the Bluetooth address to impersonate the other device. BLE Spoofing cannot be prevented and is one of the biggest vulnerabilities of the communication protocol. Furthermore, many BLE chip manufacturer provide the functionality to change the address with manufacturer specific host controller interface (HCI) commands, which is abused for spoofing.

IRK Stealing

The BLE provides a function to hide the address of and device by using private address. This security feature aims to prevent tracking of devices because they change their address periodically. The devices still can establish a connection by resolving the private address by calculating a hash with the usage of the Identity Resolving Key. This key gets distributed after a legit connection establishment. Therefore, can an adversary spoof another device and tell the target that it lost the long term key and initiate a new pairing process and gathers the IRK.

Battery Draining Attacks

Battery drain attacks aim to preform a Denial of Service by draining the devices' battery. This can be either achieved by flooding a device by many pairing requests that then don't get performed, or by connecting to the device and using its services and denying it to sleep. Many devices achieve a long battery life by using long deep sleep phases and short awake times, which is prevented by an adversary in this case.

DoS due to Spoofed Connection

Older versions of BLE only allowed a peripheral device to only serve one connection at a time. This is used by an adversary to prevent the legit central device from discovering the peripheral by connecting it and keeping the connection open. This restriction was lifted, but the ability to serve multiple connections must be configured by the device manufacturer and therefore is not used by most devices.


Fuzzing is the act of sending arbitrary data or message with mutated lengths of fields. This can cause device failures and deadlocks resulting in denial of service.

Downgrade Attacks

Downgrade attacks downgrade either the used paring algorithm or the key size of the encryption key. This attack require a machine in the middle attack during the connection establishment and altering the input output capabilities, secure connections or key size field in connection request.

Brute-forcing Legacy Pairing Encryption Key

The Legacy Pairing algorithm relied on a six-digit temporal key (TK) as the only secret parameter for the derivation of the short term key and link key. The six-digit passcode only provides an entropy of 20 bits and is therefore brute-forceable. Any device that use any BLE version after 4.2 relies on a secure paring authentication algorithm and is therefore not prone to this threat anymore.

Cross Transport Key Derivation

Cross Transport Key Derivation (CTKD) is a protocol to cross derive a key from Bluetooth Classic and BLE used by devices that implement both communication protocols (dual-mode devices), e.g., smartphones. The problem is that dual-mode devices can only turn on both protocols in conjunction and even when one of them is in use, is the other one able to be connected to. This is abused by adversaries by connecting to the unused protocol and performing the CTKD. This results in a disconnect between the two legit device because the key is overwritten, and the connection overtaken by the adversary.

Machine in the Middle

A machine in the middle attack creates a spoofed connection with both targets and tries to downgrade the connection to plain text to cause information disclosure.

BLE Berry

The BLE Berry takes a distributed three layer multi-user approach. At the lowest layer are the BLE Nodes. BLE Nodes are raspberry pis (3, 4 or Zero) that run a script to perform BLE operations, like interacting with a device, deploying a BLE server. The nodes can have a Sniffing USB accessory attached to perform sniffing operations (The current version only supports the Ubertooth One other ones are WIP). The Nodes interact with the frontend via MQTT messages. The frontend is a QT application that displays the collected data and lets the users command the BLE Nodes. Multiple frontend session can run at the same time, and they are only restricted by the amount of available BLE Nodes. The backend consists of three Docker containers. The database and MQTT Broker use the official Mosquitto and MySQL images, and the database agent is a python script running in an alpine container. The agent stores all gathered information in the database and provides the stored data to the front end when a session is reopened.

BLE Berry Project Architecture.png

The following figure the how the MQTT topics look like for the BLE Berry Tool. BLE Berry Project MQTT.png

The MySQL database is shown in the figure below. BLE Berry Project Database.png

Source Code and Thesis

Sadly, the source code as well as the thesis can not made public the due to legal reasons until I finish my studies by passing my final exam, but you can contact this email address to get informed when the project gets accessible.