Der Einsatz von Bluetooth-Beacons in Produktionsumgebungen eröffnet Angriffsflächen, die viele BLE-Protokoll-Tutorials übersehen. Dieser Artikel analysiert praktische Bedrohungen – Adress-Spoofing, Abhören von ADV-Paketen und Replay-Angriffe – und bietet technische Gegenmaßnahmen mit quantitativen Sicherheitsmargen. Die Zielgruppe sind RF-Ingenieure und Embedded-Security-Praktiker, die Beacons in Einzelhandel, Industrie und Asset-Tracking-Szenarien einsetzen.

Bedrohungsmodell: Was ein Angreifer tatsächlich tun kann

BLE ist für komfortablen Niedrigenergiebetrieb konzipiert, nicht für kryptografische Befestigungen. Das Verständnis der realistischen Bedrohungslandschaft ist der Ausgangspunkt für jede Bereitstellung:

AngriffstypSchichtErforderliche AusrüstungSchwierigkeitAuswirkung
MAC-Adress-SpoofingLink-LayerUSB-Dongle (20 $) + hcitoolGeringFalsche Präsenzmeldungen
ADV-Paket-SniffingLink-LayerUbertooth / nRF-Sniffer (50 $)Gering bis MittelStandortverfolgung, Leckage von Asset-IDs
Replay-AngriffAnwendungsschichtAufzeichnen + erneut sendenMittelUnbefugtes Betreten einer Zone
MitM (Verbindung)L2CAP2× Dongles + BT-VS-HCI-BefehleHochDatenabfang
StörsendungPHYSDR (300 $+) oder modifizierte FirmwareMittelDoS des Beacons

MAC-Adress-Spoofing: Erkennung und Minderung

BLE-Adressen gibt es in vier Typen (Public, Random Static, Random Private Resolvable (RPA), Random Private Non-Resolvable). Die meisten Produktions-Beacons verwenden Public- oder Random-Static-Adressen – beide lassen sich trivial spoofen. Ein Angreifer mit einem 20-$-USB-Dongle kann die MAC eines Beacons klonen und gefälschte ADV-Pakete einspeisen:

# Attacker: spoofing a beacon's MAC

sudo hciconfig hci0 down

sudo hciconfig hci0 leadrand # or set static BD_ADDR

sudo hciconfig hci0 up

hcitool -i hci0 cmd 0x08 0x0008 # set ADV data

hcitool -i hci0 cmd 0x08 0x000a # enable ADV

Erkennungsstrategie: Querverweis auf RSSI-Fingerprinting. Wenn dieselbe MAC innerhalb von 3 Sekunden bei -45 dBm in Zone A und bei -82 dBm in Zone B auftritt, handelt es sich um ein Spoofing. Server-seitige Implementierung:

MAX_SPEED_MS = 30  # m/s (human running)

MIN_RSSI_DELTA = 25 # dBm for physically distinct positions

def detect_spoofing(mac, rssi, gateway_id, timestamp):

prev = db.get_last_seen(mac)

if prev:

time_delta = timestamp - prev['ts']

rssi_delta = abs(rssi - prev['rssi'])

# Physical impossibilty: RSSI jump >25dBm in <2s

if time_delta < 2.0 and rssi_delta > MIN_RSSI_DELTA:

return "SPOOF_DETECTED"

return "OK"

ADV-Paket-Abhören: Analyse von Informationslecks

ADV-Pakete werden im Klartext übertragen. Jeder passive Listener im Empfangsbereich erfasst:

  • Beacon-MAC-Adresse (Geräteidentität)
  • ADV-Daten-Payload (einschließlich benutzerdefinierter Herstellerdaten)
  • RSSI (implizit, beim Empfänger)

Risikquantifizierung: Ein nRF52840-Sniffer erfasst 100 % der ADV-Pakete von Beacons innerhalb von 40 Metern (Freifeld, 0 dBm Sendeleistung). Der Angreifer extrahiert Asset-IDs, Firmware-Versionen und – falls vorhanden – unverschlüsselte Standort-Tags.

Gegenmaßnahme 1: Entfernen von Kennungen aus dem ADV-Payload. Verwenden Sie flüchtige IDs (EID), die täglich über ein gemeinsames Geheimnis rotiert werden:

# Beacon: daily EID rotation

import hmac, hashlib, time

DAILY_KEY = hmac.new(SECRET, str(int(time.time())//86400).encode(), hashlib.sha256).digest()[:8]

# ADV manufacturer data = DAILY_KEY[:4] + rotating_counter[:4]

# Server resolves: lookup table of EID -> asset_id

Gegenmaßnahme 2: ADV-Payload minimieren. Fügen Sie keine Asset-Seriennummern, Firmware-Versionen oder menschenlesbare Zeichenfolgen in ADV-Daten ein. Verwenden Sie eine kompakte Binärcodierung mit einem rotierenden Nonce.

Replay-Angriffe: Verhindern des unbefugten Betretens von Zonen

Bei entfernungsbasierter Zugriffskontrolle (z. B. „Tür entriegeln, wenn Beacon mit ID X innerhalb von 1 Meter ist“) zeichnet ein Angreifer ein gültiges ADV-Paket auf und spielt es später erneut ab. Ohne eine zeitbegrenzte Challenge-Response gewährt das System Zugriff.

Minderung: Signierte Challenge-Response. Anstelle einer rein passiven ADV-Erkennung initiiert das Gateway eine Verbindung und fordert eine signierte Antwort an:

MethodeSicherheitsstufeEnergiekosten (zusätzliche μAh/Ereignis)Latenz
ADV-only (keine Auth)Keine (spoofbar)00 ms
ADV + Verbindung + signiertes Char lesenMittel (ECDSA P-256)~180 μAh~120 ms
Verschlüsseltes ADV (LE Secure Connections OOB)Hoch~60 μAh (keine Verbindung nötig)~15 ms

LE Secure Connections mit Out-of-Band (OOB)-Pairing verteilt ein gemeinsames Geheimnis über NFC oder einen vorab geteilten Schlüssel. Das Beacon verschlüsselt ADV mit AES-CCM und einem rollierenden IV. Das Gateway entschlüsselt und validiert den Zeitstempel innerhalb von ±500 ms, um Replay zu verhindern.

Verschlüsselte Werbung: LE Secure Connections und darüber hinaus

Bluetooth 5.4 führte Encrypted Advertising Data (EAD) ein. Beacon und Gateway teilen sich einen geheimen Schlüssel (über GATT nach sicherem Pairing verteilt). ADV-Pakete übertragen mit AES-128-CCM verschlüsselte Payloads. Selbst wenn sie mitgeschnitten werden, sind die Payloads ohne den Schlüssel nicht entschlüsselbar.

Implementierung auf nRF52 (SoftDevice S140):

// Configure EAD in SoftDevice

ble_ead_config_t ead_config = {

.p_key = pre_shared_key_16byte,

.key_id = 1,

.nonce_mode = BLE_EAD_NONCE_INCREMENTING

};

sd_ble_ead_enable(&ead_config);

// ADV data now encrypted

ble_advdata_t advdata = { .p_ead_data = &encrypted_payload };

Leistungsauswirkung: EAD fügt pro ADV-Paket etwa 8 Byte Overhead hinzu. Bei einem ADV-Limit von 31 Byte verbleiben so 23 Byte für den eigentlichen Payload. Planen Sie eine Nachrichtenfragmentierung, falls Ihr Payload dies überschreitet.

Physische Sicherheit: Manipulationserkennung

Neben RF-Angriffen ist die physische Manipulation von Beacons in Einzelhandels- und Lagerbereitstellungen eine reale Bedrohung. Gegenmaßnahmen:

  • Gehäuse-Öffnungsschalter: Magnetischer Reed-Kontakt löst einen MCU-Löschvorgang aus (GPIO-Interrupt → BLE-Schlüssel im Flash löschen)
  • UV-löschbares Epoxidharz: Kapseln Sie die PCB ein; bei physischer Entfernung wird der Chip UV-Strahlung ausgesetzt, wodurch die gespeicherten Schlüssel korrumpiert werden
  • Aktiver Heartbeat: Das Beacon sendet alle 15 Minuten eine signierte „alive“-Nachricht; das Fehlen von 3 aufeinanderfolgenden Heartbeats löst einen Alarm aus

Sicherheit vs. Energie: Quantitativer Trade-off

SicherheitsstufeADV-IntervallSendeleistungBatterielebensdauer (CR2477)Spoofbar?
Keine (Klartext-ADV)100 ms0 dBm14 MonateJa
Basis (EID-Rotation)500 ms0 dBm28 MonateSchwierig (erfordert Kompromittierung des Schlüssels)
Mittel (ECDSA-signierte Verbindung)1000 ms0 dBm18 MonateNein (erfordert privaten Schlüssel)
Hoch (EAD + sicheres Pairing)500 ms-8 dBm36 MonateNein (AES-CCM verschlüsselt)

Die optimale Produktionsbalance: EID-Rotation + EAD-Verschlüsselung, mit einem ADV-Intervall von 500 ms. Dies erreicht eine starke Sicherheit bei einer Batterielebensdauer von über 28 Monaten mit CR2477.

Bereitstellungs-Checkliste

  • ✅ EID-Schlüssel täglich über OTA rotieren (oder 90-Tage-Schlüsselfenster vorab bereitstellen)
  • ✅ EAD (Bluetooth 5.4+) für sensible Payloads aktivieren
  • ✅ RSSI-Konsistenz server-seitig validieren, um MAC-Spoofing zu erkennen
  • ✅ Zufällige MAC-Adressen (resolvable private address) mit 15-Minuten-Rotation verwenden
  • ✅ Für Zugriffskontrolle: signierte Challenge-Response erfordern (nicht nur ADV-Präsenz)
  • ✅ Beacon physisch sichern (Manipulationsschalter + UV-löschbares Epoxidharz)

Sicherheit für Bluetooth Beacon-Bereitstellungen ist 2026 keine Option – sie ist eine Designanforderung. Die oben genannten Techniken (EID-Rotation, EAD-Verschlüsselung, RSSI-Fingerprinting und signierte Challenge-Response) bieten Verteidigung in der Tiefe gegen die häufigsten Angriffsvektoren. Unser Engineering-Team kann bei der sicheren Beacon-Firmware-Implementierung und der Sicherheitsüberprüfung Ihrer Bereitstellungsarchitektur helfen. Kontaktieren Sie uns für einen technischen Deep-Dive in Ihren Anwendungsfall mit Bluetooth Beacon.