BLE-Grundlagen

Lernziel

Nach dieser Seite weißt du, wie BLE intern aufgebaut ist — vom Funksignal bis zum Anwendungsbefehl. Du kennst die Schichten des Protokollstapels, verstehst die GATT-Hierarchie und weißt, welche Sicherheitsstufen BLE bietet. Dieses Wissen ist das Fundament für alle folgenden Kapitel.

Der Protokollstapel — das Stockwerk-Modell

Stell dir BLE wie ein Hochhaus vor. Jedes Stockwerk hat eine klare Aufgabe und kommuniziert nur mit dem Stockwerk direkt darüber und darunter. Gemeinsam ermöglichen sie, dass dein Smartphone einer smarten LED-Lampe sagt: "Werde rot."

BLE wurde 2010 mit der Bluetooth-4.0-Spezifikation eingeführt und ist vollständig von Classic Bluetooth (dem Audio-Bluetooth) getrennt. Der Stapel teilt sich in zwei Subsysteme: den Controller für alles Hardwarenahe und den Host für die Anwendungslogik.

Physical Layer (PHY) — das Erdgeschoss

Der Physical Layer ist das unterste Stockwerk: das eigentliche Funksignal. BLE nutzt das lizenzfreie 2,4-GHz-ISM-Band (dasselbe wie WLAN und Mikrowellen). Um Störungen zu vermeiden, wechselt BLE ständig die Frequenz — ein Verfahren namens Frequency Hopping.

BLE teilt das Band in 40 Kanäle auf, je 2 MHz breit:

• 3 Advertising-Kanäle (Kanäle 37, 38, 39): Für Ankündigungen und Verbindungsaufbau
• 37 Datenkanäle: Für die eigentliche Kommunikation nach dem Verbindungsaufbau

Die Datenrate beträgt 1 Mbit/s oder 2 Mbit/s — deutlich langsamer als WLAN, aber völlig ausreichend für Sensorwerte und Steuerbefehle.

Link Layer (LL) — der Hausmeister

Der Link Layer verwaltet den Zustand jeder Verbindung. Er kennt nur wenige Zustände: Standby, Advertising, Scanning, Initiating und Connected. Er ist verantwortlich für:

• Adressierung: Jedes BLE-Gerät hat eine 48-Bit-Adresse (öffentlich oder zufällig)
• Paketformatierung: Aufbau und Prüfung der Datenpakete
• Timing: Synchronisation zwischen Sender und Empfänger
• Verschlüsselung: AES-128-CCM für gesicherte Verbindungen

HCI — die Telefonzentrale

Das Host Controller Interface (HCI) ist die standardisierte Schnittstelle zwischen Controller und Host. Es definiert einen Befehlssatz, über den der Host den Controller steuert. Wichtig für die Sicherheitsanalyse: Über HCI lassen sich Rohdaten mitlesen — Tools wie Wireshark nutzen genau das.

L2CAP — der Paketverteiler

Das Logical Link Control and Adaptation Protocol (L2CAP) löst ein praktisches Problem: BLE-Pakete dürfen maximal 27 Byte Nutzdaten tragen. L2CAP zerschneidet größere Nachrichten in passende Stücke (Fragmentierung) und setzt sie beim Empfänger wieder zusammen (Reassemblierung).

SMP — der Sicherheitsbeauftragte

Das Security Manager Protocol (SMP) regelt alles rund um Authentifizierung und Verschlüsselung:

• Aushandlung der Pairing-Methode
• Erzeugung und Verteilung kryptografischer Schlüssel
• Verwaltung von drei Schlüsseltypen: LTK (Long Term Key für Verschlüsselung), IRK (Identity Resolving Key für Adressen-Datenschutz), CSRK (Connection Signature Resolving Key für Datensignierung)

ATT — das Datenbankprotokoll

Das Attribute Protocol (ATT) funktioniert nach dem Client-Server-Prinzip. Das Gerät (z.B. ein Sensor) ist der Server und stellt Daten bereit. Die App ist der Client und fragt Daten ab oder sendet Befehle. Jeder Datenpunkt hat einen eindeutigen 16-Bit-Handle — eine Art Hausnummer in der Gerätedatenbank.

GATT — das Anwendungs-Framework

Das Generic Attribute Profile (GATT) baut auf ATT auf und bringt Struktur in die rohen Handles. GATT definiert, wie Daten in Services und Characteristics organisiert werden — mehr dazu im nächsten Abschnitt.

GAP — der Reiseführer

Das Generic Access Profile (GAP) regelt, wie Geräte sich ankündigen und finden. Es steuert:

• Advertising: Gerät sendet Pakete, um gefunden zu werden
• Scanning: Gerät sucht nach Advertising-Paketen
• Verbindungsaufbau: Wer initiiert die Verbindung, wer akzeptiert sie
• Sicherheitsinitiierung: Wann wird Pairing gestartet

GATT-Hierarchie — das Dateiverzeichnis des Geräts

GATT organisiert die Daten eines BLE-Geräts in einer klaren Dreistufenhierarchie. Stell es dir wie ein gut strukturiertes Bürogebäude vor:

Gerät
└── Service "Herzfrequenz" (UUID: 0x180D)
    ├── Characteristic "Herzfrequenz-Messung" (UUID: 0x2A37)
    │   ├── Value: [0x06, 0x4B]  ← der eigentliche Wert
    │   └── Descriptor CCCD (UUID: 0x2902)  ← Benachrichtigungen an/aus
    └── Characteristic "Sensor-Position" (UUID: 0x2A38)
        └── Value: [0x01]  ← "Brust"

Services — die Abteilungen

Ein Service fasst zusammengehörige Funktionen unter einer UUID (Universally Unique Identifier) zusammen. Es gibt zwei Arten:

• 16-Bit-UUIDs für von der Bluetooth SIG standardisierte Services, z.B.:

  • 0x180D — Heart Rate Service
  • 0x180F — Battery Service
  • 0x1800 — Generic Access Service

• 128-Bit-UUIDs für herstellerspezifische Services, z.B.:

  • 0000FFF0-0000-1000-8000-00805F9B34FB — proprietärer Steuerservice einer LED-Brille

Characteristics — die Akten

Eine Characteristic ist der eigentliche Datenpunkt. Sie besteht aus:

1. Declaration: Enthält Properties (Zugriffsrechte) und den Handle
2. Value: Der rohe Datenwert (bis zu 512 Byte)
3. Descriptors: Optionale Metadaten

Die Properties bestimmen, was ein Client mit der Characteristic tun darf:

Descriptors — die Post-its

Descriptors liefern Metadaten zu einer Characteristic. Der wichtigste ist der Client Characteristic Configuration Descriptor (CCCD) mit der UUID 0x2902. Über ihn aktiviert der Client Notifications oder Indications — also: "Sag mir Bescheid, wenn sich dieser Wert ändert."

GATT-Operationen

Die fünf zentralen Operationen sind:

• Read: Client fragt einen Wert ab — Gerät antwortet
• Write: Client sendet einen Wert — Gerät bestätigt den Empfang
• Write Without Response: Client sendet, keine Bestätigung
• Notify: Gerät sendet selbstständig neue Werte — Client bestätigt nicht
• Indicate: Gerät sendet — Client muss bestätigen

BLE-Sicherheitsmechanismen

Jetzt wo du die Architektur kennst, schauen wir uns an, wie BLE Sicherheit implementiert — und wo die Schwachstellen liegen.

Security Modes und Levels

Die Bluetooth-Spezifikation definiert zwei Security Modes:

Security Mode 1 (verschlüsselungsbasiert) hat vier Stufen:

Security Mode 2 ergänzt signaturbasierte Zugriffskontrolle auf Datenschicht — wird in der Praxis selten eingesetzt.

Pairing — der Schlüsselaustausch

Pairing ist der Prozess, bei dem zwei Geräte kryptografische Schlüssel austauschen, um eine sichere Verbindung aufzubauen. Er läuft in drei Phasen ab:

1. Feature Exchange: Geräte tauschen Fähigkeiten aus (Display vorhanden? Tastatur? NFC?)
2. Schlüsselerzeugung: Je nach Fähigkeiten wird ein Verfahren gewählt
3. Schlüsselverteilung: LTK, IRK und CSRK werden verteilt

Es gibt vier Association Models (Pairing-Methoden):

Just Works Kein Benutzereingriff nötig. Der Temporary Key (TK) wird auf 0 gesetzt. Das klingt praktisch — ist aber das unsicherste Verfahren: bietet keinen Schutz gegen Man-in-the-Middle-Angriffe (MITM). Jeder kann passiv mithören und die Schlüssel ableiten.

Passkey Entry Eine 6-stellige PIN wird auf einem Gerät angezeigt und auf dem anderen eingegeben. Bietet MITM-Schutz, da ein Angreifer die PIN kennen müsste. Schwachstelle: 10^6 = 1.000.000 mögliche PINs — bei einem Offline-Angriff mit schneller Hardware in Minuten geknackt.

Numeric Comparison Beide Geräte zeigen dieselbe 6-stellige Zahl an und der Nutzer bestätigt. Verwendet ECDH für den eigentlichen Schlüsselaustausch. Deutlich sicherer als Passkey Entry.

Out of Band (OOB) Der Schlüsselaustausch erfolgt über einen externen Kanal, z.B. NFC oder QR-Code. Sehr sicher, aber selten in günstigen IoT-Geräten implementiert.

Bonding — das Gedächtnis

Bonding bedeutet, dass die ausgetauschten Schlüssel dauerhaft gespeichert werden. Bei der nächsten Verbindung müssen die Geräte nicht erneut pairen — sie erkennen sich anhand des gespeicherten LTK. Das ist der Unterschied zwischen "pairen" (einmalig) und "gebondet sein" (dauerhaft gespeichert).

Zusammenfassung

• BLE nutzt das 2,4-GHz-ISM-Band mit 40 Kanälen (3 Advertising, 37 Daten)
• Der Protokollstapel besteht aus PHY, Link Layer, HCI, L2CAP, SMP, ATT, GATT und GAP
• GATT organisiert Gerätedaten in der Hierarchie: Services → Characteristics → Descriptors
• 16-Bit-UUIDs sind standardisiert; 128-Bit-UUIDs sind herstellerspezifisch
• Security Mode 1 hat vier Stufen — Level 1 bietet keine Sicherheit
• Just Works ist das unsicherste Pairing-Verfahren, LE Secure Connections das sicherste
• Bonding speichert Schlüssel dauerhaft für spätere Verbindungen