Übersicht
5-Phasen-Framework zur systematischen BLE-Sicherheitsanalyse
Lernziel
Nach dieser Seite verstehst du, wie das 5-Phasen-Framework für BLE-Sicherheitsanalysen aufgebaut ist, welche Werkzeuge du brauchst und wie viel Zeit du einplanen solltest.
Was ist dieses Framework?
Stell dir vor, du willst herausfinden, ob ein Schloss sicher ist. Du würdest nicht einfach drauflosschrauben — du würdest systematisch vorgehen: erst von außen beobachten, dann die Mechanik verstehen, dann testen, ob das Schloss sich auch ohne Schlüssel öffnen lässt. Genauso funktioniert eine BLE-Sicherheitsanalyse.
Das 5-Phasen-Framework dieser Anleitung basiert auf dem OWASP IoT Security Testing Guide, NIST SP 800-115 und dem Penetration Testing Execution Standard (PTES). Es wurde speziell für BLE-basierte Consumer-Geräte adaptiert — von Fitness-Trackern über smarte LED-Strips bis hin zu Körperwaagen.
Zielgruppen
Dieser Guide richtet sich an drei Zielgruppen:
- Security-Researcher erhalten eine systematische Methodik für Responsible-Disclosure-Prozesse.
- Penetrationstester gewinnen reproduzierbare Workflows für BLE-Assessments im Rahmen von Red-Team-Engagements.
- IoT-Entwickler erhalten ein Self-Assessment-Toolkit zur Schwachstellenidentifikation vor Produktlaunch.
Scope und Abgrenzung
Der Guide deckt Consumer-IoT-Geräte mit BLE 4.0 bis 6.0 und Android-Companion-Apps ab. Nicht erfasst sind:
- Proprietäre Protokoll-Stacks mit Hardware-Security-Modulen
- iOS-only-Apps (kein JADX-Pendant für Swift/Objective-C)
- Automotive-BLE-Systeme mit ISO/SAE 21434-Zertifizierung
- Hardware-Angriffe (Seitenkanalanalyse, Fault-Injection)
- Firmware-Extraktion direkt vom Gerätechip
- Cloud-Backend-Analyse
Ausblick: BLE 6.0 Channel Sounding
BLE 6.0 führt mit Channel Sounding eine native Lösung gegen Relay-Angriffe ein: Durch präzise Distanzmessung auf PHY-Ebene kann ein Gerät verifizieren, ob sich der Kommunikationspartner tatsächlich in der erwarteten Nähe befindet. Für Consumer-IoT wird das die Sicherheitslandschaft mittelfristig verändern.
Jede Phase baut auf den Ergebnissen der vorherigen auf:
| Phase | Aufgabe | Werkzeug | Ergebnis |
|---|---|---|---|
| 1: APK-Analyse | App dekompilieren, Geheimnisse suchen | JADX-GUI | UUIDs, Kryptoschlüssel |
| 2: Traffic-Capture | BLE-Funkverkehr aufzeichnen | nRF52840, Wireshark | Paketmitschnitte |
| 3: Reverse Engineering | Native Bibliotheken analysieren | Ghidra | Hardcodierte Schlüssel |
| 4: Protokollrekonstruktion | Kommunikationsprotokoll verstehen | Python-Skripte | Protokollspezifikation |
| 5: PoC-Entwicklung | Angriff beweisen | blatann, Python | Funktionsfähiger Exploit |
Was ist ein PoC?
PoC steht für Proof of Concept — ein Nachweis, dass eine Schwachstelle tatsächlich ausnutzbar ist. Ein PoC ist kein fertiger Angriff, sondern zeigt kontrolliert, dass das Problem real ist.
Geräteauswahl: Was analysiert werden sollte
Das Framework wurde an drei echten Geräten entwickelt und erprobt. Die Auswahl folgte fünf Kriterien, die du beim Wählen eigener Analysekandidaten beachten solltest:
- Verschiedene IoT-Kategorien (Wearable, Smart Home, Health) — damit die Erkenntnisse auf viele Geräteklassen übertragbar sind
- Reproduzierbar kaufbar unter 100 EUR — damit jeder die Analyse nachvollziehen kann
- Unterschiedliche CIA-Gewichtung — Verfügbarkeit, Vertraulichkeit und Integrität sind je nach Gerät unterschiedlich wichtig
- Nur Standard-BLE — keine proprietären Hardware-Dongles notwendig
- Marktrelevant — in Amazon-Bestseller-Listen gelistet, also weit verbreitet
CIA-Triade kurz erklärt
CIA steht für Confidentiality (Vertraulichkeit), Integrity (Integrität) und Availability (Verfügbarkeit). Bei einer Körperwaage ist Vertraulichkeit kritisch — niemand soll deine Gesundheitsdaten mitlesen. Bei einer LED-Brille ist Integrität wichtiger — niemand soll unautorisiert Text ändern.
Die drei untersuchten Geräte im Überblick:
| Gerät | Kategorie | BLE-Version | Preis |
|---|---|---|---|
| Sonhomay LED Glasses | Wearable | 4.0 | ca. 30 EUR |
| Smart-LED-Strip | Smart Home | 4.0 | ca. 20 EUR |
| Lebenlang Digital Smart Scale | Health | 4.0/5.0 | ca. 35 EUR |
Bedrohungsmodell: Wer greift an?
Das Framework geht von einem realistischen Angreifer aus — dem sogenannten "Low-Skilled-Attacker":
- Position: Innerhalb der BLE-Reichweite (ca. 20–30 m in Innenräumen, ggf. mehr mit Richtantenne)
- Kein physischer Gerätezugang notwendig — der Angreifer muss das Gerät nicht in der Hand halten
- Werkzeugkenntnisse: JADX, Wireshark, GATT-Explorer — alles Open-Source-Standardwerkzeuge
- Motivation: Reicht von Vandalismus (LED-Brille) bis zu gezieltem Stalking oder Datenerfassung (Körperwaage)
Angreifermodell ist nicht dasselbe wie Angreiferexpertise
Das Modell bewertet Schwachstellen so, wie sie nach einer einmaligen Analyse reproduzierbar ausnutzbar sind. CVSS-Scores werden nach dem Attack Vector "Adjacent" (AV:A) bewertet, da BLE physische Nähe erfordert.
Benötigte Werkzeuge (Toolchain)
Alle Werkzeuge sind kostenlos. Die einzige Hardwareausgabe ist der nRF52840-Dongle:
| Kategorie | Werkzeug | Version | Zweck |
|---|---|---|---|
| APK-Analyse | JADX-GUI | 1.5.3+ | Java-Dekompilierung |
| APK-Analyse | apktool | 2.9.3+ | APK-Disassembly |
| Traffic-Capture | Wireshark | 4.6.1+ | Paketanalyse |
| Traffic-Capture | nRF-Sniffer | 4.1.1+ | BLE-Capture-Plugin |
| Reverse Engineering | Ghidra | 11.4.3+ | Native-Library-Analyse |
| Reverse Engineering | FindCrypt | 3.x | Kryptokonstanten erkennen |
| PoC-Entwicklung | Python | 3.7+ | Skripting |
| PoC-Entwicklung | blatann | 0.3.0+ | BLE-Bibliothek (nRF52840) |
| PoC-Entwicklung | PyCryptodome | 3.20.0+ | Krypto-Operationen |
| Hardware | nRF52840 Dongle | — | Sniffer + Interaktion |
Gesamtkosten Hardware: ca. 10–15 EUR (nRF52840-Dongle, PCA10059).
Warum blatann statt Bleak?
blatann gibt dir direkte Kontrolle über den nRF52840-Chip und erlaubt sowohl Sniffer- als auch Interaktionsmodus mit demselben Dongle. Bleak ist einfacher zu verwenden, bietet aber keinen Zugriff auf Link-Layer-Parameter — das macht es für echte Sicherheitsanalysen weniger geeignet.
Zeitschätzung nach Gerätekomplexität
Als Orientierung: Ein einfaches Gerät (kein Obfuscator, einfaches XOR) benötigt 10–18 Stunden. Ein mittleres Gerät (ProGuard, AES-ECB) 18–27 Stunden. Ein komplexes Gerät (DexGuard, AES-CCM/GCM) 29–44 Stunden.
| Phase | Einfach | Mittel | Komplex |
|---|---|---|---|
| APK-Analyse | 2–4 h | 4–6 h | 8–12 h |
| Traffic-Capture | 1–2 h | 2–3 h | 3–4 h |
| Native-Library-RE | 2–4 h | 4–6 h | 6–10 h |
| Protokollrekonstruktion | 2–3 h | 3–4 h | 4–6 h |
| PoC-Entwicklung | 3–5 h | 5–8 h | 8–12 h |
| Gesamt | 10–18 h | 18–27 h | 29–44 h |
Wie es weitergeht
Die folgenden Seiten beschreiben jede Phase im Detail — mit konkreten Befehlen, Wireshark-Filtern, Ghidra-Schritten und Python-Code. Die Fallstudien zeigen, wie das Framework an echten Geräten angewendet wurde.
Nur eigene Geräte testen
Alle Analysen dürfen ausschließlich an eigenen, legal erworbenen Geräten durchgeführt werden. Das Abfangen fremder BLE-Kommunikation ist nach §202b StGB strafbar. Mehr dazu im Abschnitt Rechtlicher Rahmen.
Zusammenfassung
- Das 5-Phasen-Framework deckt die vollständige BLE-Sicherheitsanalyse ab: APK → Traffic → RE → Protokoll → PoC
- Alle Software-Werkzeuge sind kostenlos; die Hardware (nRF52840-Dongle) kostet ca. 10–15 EUR
- Das Bedrohungsmodell geht von einem Low-Skilled-Attacker in BLE-Reichweite aus
- Einfache Geräte brauchen 10–18 Stunden, komplexe bis zu 44 Stunden
- Analyse nur an eigenen Geräten — unautorisiertes Testen ist strafbar