Skip to content

BlueMaster: Bypassing and Fixing Bluetooth-based Proximity Authentication

Engineers explore architecture and security mechanisms for BlueMaster: Bypassing and Fixing Bluetooth-based Proximity Authentication.

Summary

## Overview

Jim Bong Shane (Samsung Research) and Young Min (Oregon State University) presented BlueMaster—new attacks against Bluetooth Low Energy proximity authentication in Android and Windows systems. Proximity-based authentication extends the concept of "something you have" (trusted Bluetooth wearables, car audio, keyboards) to enable automatic device unlock or lock based on proximity. Android's Smart Lock (introduced 2014, available from Lollipop 5.0) automatically unlocks smartphones when a trusted Bluetooth device connects; Windows Dynamic Lock (introduced 2017, Windows 10) automatically locks screens when trusted Bluetooth phones move out of proximity. Both systems assume that if a trusted device is Bluetooth-connected, the owner is present and authenticated access is appropriate. However, researchers demonstrate that Bluetooth RSSI signal strength measurement (the basis for proximity checking) is unreliable and can be defeated via relay attacks, spoofing, and signal manipulation. Android Smart Lock vulnerabilities were previously discovered and patched in 2015 (fixed in Android 5.1); Windows Dynamic Lock remains unpatched with no prior public security research.

## Bluetooth Proximity Authentication Architecture

**Android Smart Lock Design**: Users register trusted Bluetooth devices (smartwatches, fitness bands, car audio, keyboards). When a registered device connects, the phone automatically skips PIN/biometric authentication and unlocks directly. The system assumes physical proximity—if you carry your smartwatch or Bluetooth keyboard, you're present. Different device types have different trust assumptions: smartwatches/fitness bands (always-carried devices) represent high-confidence proximity; car audio (car-specific devices) represents private space and owner presence; keyboards (carried or desk-mounted) represent workspace presence.

**Windows Dynamic Lock Design**: Users pair smartphones with Windows laptops. When the paired phone moves far from the laptop, Windows automatically locks the screen after a timeout period. The implementation improves upon Basic Bluetooth signal strength detection by measuring RSSI (Received Signal Strength Indicator) across multiple signals (Bluetooth and Wi-Fi) to estimate actual distance between devices more accurately than single-point RSSI. Microsoft recommends RSSI-based distance checking due to natural signal attenuation with distance.

**Bluetooth Pairing and Security Model**: Successful Bluetooth pairing establishes a "link key" (shared secret) between devices. After pairing, every connection authenticates using this link key and encrypts subsequent messages. Bluetooth security is considered adequate when properly used; however, the design assumes the authenticated peer is truly the original trusted device. Service Discovery Protocol (SDP) used for Bluetooth device discovery is explicitly NOT secured—anyone can discover device names, addresses, and capabilities.

## RSSI-Based Proximity Checking and Attack Surface

**RSSI Signal Strength Characteristics**: Signal strength decreases predictably with distance, providing a basic distance proxy. However, RSSI is affected by environmental factors (walls, obstructions), multi-path propagation, and antenna orientation. Bluetooth specification allows RSSI to work reliably up to ~100 meters in open space—problematic for authentication assuming "proximity" means <1-3 meters. Windows Dynamic Lock attempts to address this by requiring consistent RSSI measurements below a threshold; however, the approach remains vulnerable to signal manipulation.

**Authentication Weaknesses**: Both Android and Windows implementations rely on RSSI for proximity validation but do not use Bluetooth's native security mechanisms (pairing, authentication, encryption) in the proximity-checking layer. Instead, they re-establish connection and check RSSI independently. This separation means an attacker can: (1) relay Bluetooth signals from a compromised device to a target via amplifiers or protocol relays, (2) forge RSSI measurements, (3) replay old pairing credentials, or (4) intercept and manipulate proximity authentication messages.

**Windows-Specific Vulnerability**: Windows Dynamic Lock's RSSI-based distance estimation can be defeated by signal amplification (relay attacks extending Bluetooth range) or environmental spoofing (manipulating signal propagation to appear closer than actual distance). The system lacks cryptographic verification that proximity-checking messages originate from the legitimate paired phone rather than a relay or spoofed source.

## Attack Techniques and Mitigations

**Relay Attacks**: An attacker in proximity to a locked laptop captures Bluetooth advertisements from the paired phone at distance, relays them to the laptop via Bluetooth extenders or software-defined radio, causing the laptop to believe the phone is nearby when it is not. The locked screen remains unlocked even though the actual phone owner is absent.

**Prior Research and Fixes**: Android Smart Lock vulnerabilities (discovered 2015) leveraged SDP unsecured device discovery to enumerate trusted devices and spoof their Bluetooth presence. Google patched this in Android 5.1 by implementing additional cryptographic verification in the proximity authentication layer, making spoofing attacks much harder.

**Mitigation Recommendations**: Proper Bluetooth proximity authentication requires: (1) using Bluetooth's existing security mechanisms (pairing authentication) for proximity claims, (2) implementing cryptographic protocols (e.g., secure channel with ECDH) for distance-bounding instead of relying on RSSI alone, (3) validating that proximity-checking messages are signed by the paired device's link key, (4) implementing distance-bounding protocols that prove the legitimate device is actually close (versus just forwarding relay messages). Windows Dynamic Lock requires OS-level patches; users can temporarily mitigate by disabling Dynamic Lock or relying on manual unlock authentication.

Related talks