BLEKeeper: MITM Detection for BLE Devices

• BLEKeeper is a MITM attack detection system for BLE devices that leverages the inherent regularity of response times during ATT read/write operations.
• It combines continuous passive monitoring with targeted active probing using lightweight sniffers and statistical profiling to identify adversarial tampering.
• Experiments demonstrate BLEKeeper achieves ~98% detection accuracy with minimal added latency (<20 ms), making it effective in enclosed indoor environments.

Bluetooth Low Energy (BLE) devices are increasingly targeted in man-in-the-middle (MITM) attacks due to a combination of protocol limitations and resource-constrained endpoint implementations. BLEKeeper is a response time behavior-based MITM attack detection system designed for these environments. It leverages the high regularity of response times exhibited by BLE devices during Attribute Protocol (ATT) read and write operations to detect adversarial tampering. BLEKeeper is notable for its rapid, high-accuracy, and low-cost detection, requiring only sniffed packet timing and simple lightweight modeling. Its architecture, operational methodology, performance evaluation, and security considerations are detailed below (Yurdagul et al., 2021).

1. System Architecture and Deployment Environment

BLEKeeper is architected for deployment in enclosed indoor spaces, such as homes, offices, or hospitals, where all BLE advertising and data traffic can be reliably captured. The system employs one or more BLEKeeper appliances, each consisting of Raspberry Pi 4 hosts running Linux, equipped with commodity BLE radios and Ubertooth One sniffers. Ubertooth sniffers are configured such that three are constantly tuned to BLE advertising channels (37, 38, 39) to capture all advertising (ADV) packets, while a fourth is dynamically retuned to the data-channel frequencies active during any newly established BLE connection. This arrangement ensures comprehensive passive monitoring of local BLE communications, allowing for high-fidelity timestamping of link-layer communication events.

The functional workflow of BLEKeeper is organized into two principal modules:

• Traffic Analyzer: Responsible for sniffing, demultiplexing, and timestamping all relevant BLE packets. Each BLE ATT request (read or write) and corresponding ATT response is timestamped based on the last byte sent and the first byte received, respectively, producing accurate per-operation response times ($Tr$).
• Attack Detector: Manages profiling, suspicion marking, and statistical anomaly detection. The Attack Detector consists of three subcomponents:
  • Device Profiler: Constructs a per-device response time profile for select representative GATT characteristics.
  • Device Selector: Flags as suspicious any device initiating a connection, reflecting the precondition of a MITM attack.
  • Change Detector: Actively probes suspected devices with $k$ read/write operations, compares timing to baseline distributions, and raises alerts if deviations exceed statistical thresholds.

This division allows BLEKeeper to seamlessly interleave passive monitoring with targeted active probing, achieving both low overhead and rapid detection.

2. Response Time Acquisition and Profiling Methodology

BLEKeeper’s detection capability fundamentally relies on accurately measuring and modeling the response time ($Tr$) for ATT operations. For each BLE ATT Read or Write Request, the system obtains $Tr = t_{rsp} - t_{req}$, where $t_{req}$ is the timestamp of the outgoing request's final radio byte and $t_{rsp}$ is the timestamp of the incoming response's first radio byte.

Profiling is performed over 20 connections per device, with each session providing 10 reads and 10 writes, resulting in approximately 400 response-time samples for each target device. This substantial sample size allows BLEKeeper to characterize statistical behavior with high confidence.

• Timestamping Accuracy: BLEKeeper utilizes sniffer-side timestamps, which bypass OS-induced and USB transmission delays inherent to host-side measurement. This produces a precise baseline of the device’s response-time regularity, which is central to distinguishing normal from adversarial (MITM) behavior.
• Profiling Strategy: BLEKeeper selects one or two GATT characteristics per device—one readable, one writable—representative of the device’s typical use and response patterns.

3. Statistical Modeling, Thresholds, and Detection Mechanism

The device-specific response time profile is modeled according to empirically observed variance in the baseline samples. BLEKeeper implements two principal statistical models:

• Single-mode (Low-variance) Devices:
  • $Tr$ is treated as a univariate Gaussian: $Tr \sim \mathcal{N}(\mu_i,\sigma_i^2)$, with empirical mean $\mu_i = \mathrm{E}[Tr]$ and standard deviation $\sigma_i$ (often near zero).
• Multi-mode (Higher-variance) Devices:
  • The distribution of $\{Tr\}$ is clustered into $j$ tight modes, with per-mode parameters $(m_{i,r}, \sigma_{i,r})$ and weights $w_{i,r}$: $$p_i(Tr) = \sum_{r=1}^j w_{i,r}\,\mathcal{N}(Tr\mid m_{i,r},\sigma_{i,r}^2)$$.

For detection, BLEKeeper defines confidence intervals ($L_{i,r}, U_{i,r}$) for each mode:

• $L_{i,r} = m_{i,r} - k\sigma_{i,r}$
• $U_{i,r} = m_{i,r} + T_{\mathit{MITM}}$

Here, $k$ (typically 3) corresponds to the 99.7% confidence level, and $T_{\mathit{MITM}} = t_1 + t_2$ represents the minimal observed attacker-induced delay (empirically, $T_{\mathit{MITM}}\geq2.2~\mathrm{ms}$ in Mirage-based attacks).

Detection proceeds as follows:

• For each probe, if $Tr_i \notin \bigcup_{r=1}^j [L_{i,r},\,U_{i,r}]$, it is counted as an anomaly.
• An MITM alert is raised if the number of anomalies in one probe session meets or exceeds a preset threshold (generally 1 for low-variance devices), after which the connection is terminated.

Alternatively, BLEKeeper can employ likelihood ratio tests:

$$\Lambda(Tr) = \ln\frac{f^{i}(Tr)}{f^{i}(Tr - T_{\mathit{MITM}})}$$

and declare an “attack” if $\Lambda(Tr)<\tau$ for some $\tau<0$.

A z-score approach is also formalized:

$z = \frac{Tr - m_{i,r}}{\sigma_{i,r}}$

flagging anomalies if $z>k$ or $Tr > m_{i,r} + T_{\mathit{MITM}}$.

4. Active Detection Protocol and Operational Workflow

The BLEKeeper active detection protocol consists of the following steps:

1. Continuous ADV Monitoring: Record name and MAC for each advertising device.
2. Suspicion Marking: Upon observing a device that initiates a connection (necessary for MITM), mark it as “suspicious.”
3. Active Probe: Initiate a short-lived connection to the suspicious device, performing $k$ GATT operations (commonly 1 read and 1 write) on the profiled characteristics.
4. Anomaly Scoring: For each operation, compare response time to the baseline intervals.
5. Decision Logic: If the number of anomalies reaches the threshold, issue a MITM alert and disconnect. Otherwise, terminate the connection without escalation and revert to passive monitoring.

This protocol enables BLEKeeper to detect MITM-induced response time inflation rapidly—typically within one or two ATT exchanges, adding less than 20 ms to normal response latency.

5. Experimental Evaluation and Performance Analysis

BLEKeeper was evaluated using a dedicated testbed comprising Raspberry Pi 4 appliances (2 GB RAM), three Ubertooth One sniffers, and native CYW43455 BLE radio; attack scenarios employed an Ubuntu 16.04 laptop with two CSR 4.0 dongles. Seven BLE devices were profiled:

Device	Device Type
LEDBLE	smart bulb
LYWSD03MMC	thermometer
My Oximeter	health sensor
Medical Oximeter	health sensor
MS1020	smart bracelet
iTag	smart tag
Samsung Smart TV	smart TV

MITM attacks were emulated using two major tools:

• Mirage: Single-machine proxy.
  • Minimum attack-induced delay: $t_1$=1.2 ms (forward), $t_2$=1.0 ms (response), $T_{\mathit{MITM}}\geq2.2$ ms.
• BtleJuice: Two-machine TCP/IP proxy, with minimal delays ≈8 ms due to higher network overhead.

For each scenario, 50 read and 50 write requests were issued under attack and clean conditions (200 samples per case). Key results:

• Accuracy: Average MITM detection accuracy ≈98% across all devices and attack tools.
• False-Positive Rate: ≈1.1%, predominantly on multi-mode (higher-variance) devices.
• False-Negative Rate: ≈2.3%, nearly zero for low-variance devices, higher for Samsung Smart TV due to mode overlap.
• Detection Latency: Typically <20 ms extra (over 1–2 ATT operation times).
• Comparative Simplicity: BLEKeeper requires only 1–2 simple ATT probes and a single scalar statistic, in contrast to alternative learning approaches requiring higher-complexity features (such as interarrival times, RSSI, or CFO).

6. Limitations, Adversary Model, and Enhancement Prospects

An adaptive MITM attacker could attempt to evade BLEKeeper by adding constant artificial delay ($T_{\mathit{MITM}}$ or specific multiples) to all proxied responses, mimicking the variance or multimodal behavior of the authentic device. This evasion, however, tends to inflate the response-time empirical variance over time, especially when BLEKeeper mandates extended probe sessions ($k\gg1$). BLEKeeper’s profiling is also extensible to additional or randomized GATT operations, increasing the adversary’s modeling burden.

Scalability is achieved by increasing the number of sniffers and BLE radios, facilitating simultaneous tracking and active probing for tens to hundreds of devices. Future enhancements indicated include adoption of non-Gaussian and multivariate timing features (e.g., inter-packet spacing) and integration into policy enforcement or intrusion prevention systems for centralized mitigation.

7. Significance and Practical Implications

BLEKeeper demonstrates that the inherent response-time regularity of commodity BLE servers, especially in low-power IoT devices, constitutes a robust and rapidly applicable fingerprint for MITM tampering. Its brief profiling phase (≈20 seconds) and minimal computational requirements favor retrofitting to legacy deployments lacking firmware upgrade pathways. The empirical performance substantially exceeds that of competing feature-based or machine-learning detection mechanisms, achieving high accuracy with low latency and operational simplicity (Yurdagul et al., 2021).