Kryptografische Grundlagen

Lernziel

Nach dieser Seite verstehst du, welche kryptografischen Verfahren BLE-Geräte verwenden, warum manche davon gefährlich schwach sind, und wie du mit Shannon-Entropie auf einen Blick erkennst, ob ein BLE-Payload verschlüsselt ist oder nicht.

Was ist Kryptografie und warum ist sie wichtig?

Stell dir vor, du schickst deinem Freund eine Postkarte. Jeder, der sie in die Hände bekommt, kann sie lesen. Eine verschlüsselte Nachricht ist wie ein versiegelter Brief in einem Safe — selbst wer den Brief abfängt, kann ohne den richtigen Schlüssel nichts damit anfangen.

BLE-Geräte senden ihre Daten über Funk. Ohne Verschlüsselung kann jeder in Reichweite den Datenverkehr mitlesen — ob es sich um Steuerbefehle für eine LED-Brille handelt oder um Körpergewicht und Impedanzwerte einer smarten Waage.

Das Problem: Viele Hersteller setzen zwar irgendeine Form von Kryptografie ein, wählen aber den falschen Modus — oder keine echte Kryptografie, sondern nur eine XOR-Operation.

AES: Der Goldstandard der symmetrischen Verschlüsselung

AES (Advanced Encryption Standard, NIST FIPS 197) ist ein symmetrischer Blockchiffre — beide Seiten nutzen denselben Schlüssel zum Ver- und Entschlüsseln. Das Wort "symmetrisch" ist dabei entscheidend: Wer den Schlüssel kennt, kann alles lesen.

AES arbeitet immer mit 128-Bit-Blöcken (16 Byte). Das bedeutet, der Klartext wird in 16-Byte-Stücke aufgeteilt und Block für Block verarbeitet. Die Schlüssellänge bestimmt die Anzahl der Verarbeitungsrunden:

In jeder Runde werden vier mathematische Transformationen angewendet:

1. SubBytes — Jedes Byte wird durch eine nichtlineare Substitutionstabelle (S-Box) ersetzt. Das sorgt für Konfusion — die Beziehung zwischen Schlüssel und Chiffretext wird unübersichtlich.
2. ShiftRows — Die Zeilen der 4×4-Byte-Matrix werden zyklisch verschoben.
3. MixColumns — Die Spalten werden mathematisch gemischt. Das sorgt für Diffusion — eine kleine Änderung im Klartext verändert viele Bits im Chiffretext.
4. AddRoundKey — Der aktuelle Block wird per XOR mit dem Rundenschlüssel verknüpft.

BLE verwendet AES mit 128-Bit-Schlüsseln. Der eigentliche Schutz hängt aber nicht nur von AES selbst ab, sondern davon, wie AES verwendet wird — dem sogenannten Betriebsmodus.

AES-Betriebsmodi: Dieselbe Krypto, völlig anderes Sicherheitsniveau

AES allein verschlüsselt nur einen einzelnen 16-Byte-Block. Was passiert mit längeren Nachrichten? Dafür gibt es Betriebsmodi — und die Wahl des Modus ist entscheidend für die Sicherheit.

ECB-Modus: Das Pinguinproblem

Der ECB-Modus (Electronic Codebook) ist der naivste Ansatz: Jeder 16-Byte-Block wird unabhängig von den anderen verschlüsselt.

Das klingt harmlos, hat aber eine fatale Schwäche: Identische Klartextblöcke erzeugen identische Chiffretextblöcke. Stell dir ein Bitmapbild vor, das mit ECB verschlüsselt wurde — die Umrisse des Bildes bleiben im Chiffretext erkennbar, weil gleiche Pixel-Blöcke immer gleiche verschlüsselte Blöcke ergeben. Dieses Phänomen wurde am berühmten "ECB-Penguin" (dem Linux-Maskottchen Tux) demonstriert: Auch nach der Verschlüsselung ist der Pinguin noch erkennbar.

In der Praxis bedeutet das: Wenn ein Gerät immer denselben Befehl sendet (z. B. "LED an"), ist der Chiffretext jedes Mal identisch. Ein Angreifer muss den Befehl gar nicht entschlüsseln — er kann ihn einfach wiederholen (Replay-Angriff).

In der BLE-Analyse begegnet uns ECB real: Die LED-Brille, die in dieser Analyse untersucht wurde, verwendet AES-128 im ECB-Modus — mit einem hartkodiertem Schlüssel in der nativen Bibliothek der App.

GCM-Modus: State of the Art

Der GCM-Modus (Galois/Counter Mode) löst die ECB-Probleme auf elegante Weise. Er kombiniert zwei Mechanismen:

• CTR-Modus (Counter): Ein Zähler wird verschlüsselt und dann per XOR mit dem Klartext verknüpft. Jeder Block bekommt einen einzigartigen Zählerwert — identische Klartextblöcke erzeugen dadurch unterschiedliche Chiffretextblöcke.
• GHASH: Eine keyed Hash-Funktion berechnet einen Authentifizierungstag über den Chiffretext.

Das Ergebnis ist AEAD (Authenticated Encryption with Associated Data): Vertraulichkeit, Integrität und Authentizität in einem. Wer den Chiffretext manipuliert, zerstört den Authentifizierungstag — der Empfänger erkennt die Manipulation.

CCM-Modus: Was BLE intern verwendet

Der CCM-Modus (Counter with CBC-MAC) kombiniert ebenfalls Verschlüsselung (CTR) mit einem Authentifizierungscode (CBC-MAC). BLE verwendet CCM für die Link-Layer-Verschlüsselung — also für die Sicherheit auf Protokollebene, wenn LE Secure Connections aktiviert ist.

CCM ist wie GCM ein AEAD-Verfahren und bietet guten Schutz, sofern korrekt implementiert. Das Problem in der Praxis: Viele BLE-Geräte aktivieren die Link-Layer-Verschlüsselung gar nicht, oder setzen zusätzlich eine eigene Applikations-Layer-Verschlüsselung ein — manchmal mit deutlich schwächeren Verfahren wie ECB.

ECDH: Schlüsselaustausch über einen unsicheren Kanal

AES ist symmetrisch — beide Seiten brauchen denselben Schlüssel. Wie einigen sich zwei Geräte auf einen gemeinsamen Schlüssel, wenn sie nur über Funk kommunizieren und jeder den Funk abhören kann?

Die Antwort lautet ECDH (Elliptic Curve Diffie-Hellman). Das Verfahren ist elegant und lässt sich mit einer Analogie erklären:

Stell dir vor, du und dein Gesprächspartner einigt euch öffentlich auf eine Farbe — zum Beispiel Gelb. Dann mischt jeder von euch geheim eine eigene Privatfarbe darunter. Das Ergebnis tauscht ihr öffentlich aus. Jetzt mischt jeder die private Farbe des anderen unter das, was er bekommen hat. Das Endergebnis ist auf beiden Seiten identisch — aber ein Beobachter, der nur die öffentlichen Mischungen gesehen hat, kann die Privatfarben nicht rekonstruieren.

In der Mathematik arbeitet ECDH mit Punkten auf einer elliptischen Kurve. BLE verwendet die P-256-Kurve (NIST-Standard). Der Ablauf:

1. Beide Seiten erzeugen ein zufälliges privates Schlüsselpaar.
2. Die öffentlichen Schlüssel werden über Funk ausgetauscht.
3. Aus dem eigenen privaten und dem öffentlichen Schlüssel der Gegenseite berechnet jede Seite dasselbe Shared Secret.
4. Das Shared Secret verlässt niemals den Funk — nur die öffentlichen Schlüssel werden übertragen.

Das macht ECDH resistent gegen passives Eavesdropping: Selbst wenn jemand den gesamten Funk mitschneidet, kann er das Shared Secret nicht berechnen (das würde den diskreten Logarithmus auf elliptischen Kurven erfordern — ein mathematisch unlösbares Problem).

BLE verwendet ECDH für LE Secure Connections (Security Mode 1, Level 4) — die höchste Sicherheitsstufe. Geräte, die nur "Just Works" ohne ECDH verwenden, setzen den Temporary Key auf 0 und bieten keinen Schutz gegen passives Sniffing.

XOR: Warum das keine Verschlüsselung ist

XOR (exklusives Oder, Symbol: ⊕) ist eine bitweise Operation: Zwei Bits ergeben 1, wenn sie verschieden sind, und 0, wenn sie gleich sind. Die "Verschlüsselung" sieht so aus:

Chiffretext C = Klartext P ⊕ Schlüssel K

Und die "Entschlüsselung":

Klartext P = Chiffretext C ⊕ Schlüssel K

Das funktioniert — aber es ist nur dann sicher, wenn drei Bedingungen erfüllt sind:

1. Der Schlüssel ist mindestens so lang wie die Nachricht
2. Der Schlüssel ist echt zufällig (nicht aus einem Passwort abgeleitet)
3. Der Schlüssel wird genau einmal verwendet

Das ist das theoretisch sichere One-Time-Pad — praktisch aber nicht einsetzbar, weil der Schlüssel sicher übertragen werden müsste (und wenn man einen sicheren Kanal hätte, bräuchte man die Verschlüsselung nicht).

In der Analyse des Smart-LED-Strips aus dieser Arbeit wurde genau das gefunden: 19-Byte-Nachrichten, die scheinbar "verschlüsselt" waren, entpuppten sich als XOR mit einem einzelnen Byte (0x66). Die gesamte "Verschlüsselung" kollabierte auf einen einzigen Byte-Schlüssel — und ließ sich in Sekunden brechen.

Shannon-Entropie: Ist dieser Payload verschlüsselt?

Wenn du einen BLE-Payload vor dir hast — ein paar Dutzend Bytes aus einem Wireshark-Mitschnitt — wie erkennst du auf Anhieb, ob er verschlüsselt ist?

Die Shannon-Entropie ist ein Maß aus der Informationstheorie, das die "Zufälligkeit" einer Bytesequenz misst. Die Formel:

H = -Σ p(x) · log₂(p(x))

Dabei ist p(x) die Häufigkeit jedes Byte-Wertes in der Sequenz. Das Maximum liegt bei 8 bits/byte — das entspräche einer perfekt gleichmäßigen Verteilung aller 256 möglichen Byte-Werte.

Daumenregel aus der Praxis:

In der Analyse der Körperwaage aus dieser Arbeit lag die Entropie bei ~4,5 bits/byte — ein klares Signal für unverschlüsselte Daten, bestätigt durch die anschließende Code-Analyse.

Hier kannst du selbst experimentieren — füge beliebige Hex-Werte ein und sieh, was die Entropie sagt:

Zusammenfassung

• AES ist ein symmetrischer Blockchiffre mit 128-Bit-Blöcken. Die Sicherheit hängt nicht nur von AES selbst ab, sondern vom gewählten Betriebsmodus.
• ECB ist gefährlich: Gleiche Klartextblöcke erzeugen gleiche Chiffretextblöcke. Muster im Klartext bleiben erkennbar, Replay-Angriffe werden trivial.
• GCM und CCM sind sichere AEAD-Modi, die zusätzlich zur Vertraulichkeit auch Integrität und Authentizität garantieren. BLE verwendet CCM auf Link-Layer-Ebene.
• ECDH ermöglicht Schlüsselaustausch über einen unsicheren Kanal. Das Shared Secret verlässt niemals den Funk und ist damit resistent gegen passives Eavesdropping.
• XOR mit kurzem Schlüssel ist keine Kryptografie: Bei Schlüsselwiederverwendung fällt der Schlüssel heraus, bei bekanntem Klartext lässt er sich trivial berechnen.
• Shannon-Entropie (> 7,5 = verschlüsselt, < 6,0 = Klartext) ist ein nützliches Vorab-Screening — aber kein Ersatz für Code-Analyse.

Weiter zu: BLE-Grundlagen | Reverse Engineering