Vergleichende Analyse

Lernziel

Nach dieser Seite kannst du die 13 gefundenen Schwachstellen aller drei Geräte strukturiert vergleichen. Du erkennst wiederkehrende Muster — Probleme, die nicht zufällig, sondern systematisch entstehen — und verstehst die Ursachen hinter ihnen: von "Cargo Cult Security" bis zum regulatorischen Vakuum.

Überblick: 13 Schwachstellen, 3 Geräte

Die Analyse von LED-Brille, LED-Strip und Körperwaage ergab zusammen 13 dokumentierte Schwachstellen. Die folgende Tabelle gibt dir den vollständigen Überblick:

Zusammenfassung nach Gerät:

Muster 1: Fehlende Authentifizierung (3/3 Geräten)

Das auffälligste Ergebnis: Kein einziges der drei Geräte authentifiziert den Absender von Befehlen. Jeder in BLE-Reichweite kann Befehle senden oder Daten empfangen — ohne sich zu identifizieren.

BLE bietet dafür mehrere Mechanismen:

Das "Just Works"-Pairing der LED-Brille ist dabei fast schlimmer als kein Pairing: Es suggeriert Sicherheit (der Nutzer sieht eine Pairing-Anfrage), bietet aber keinen Schutz gegen passive Eavesdropper oder aktive Man-in-the-Middle-Angriffe, da der Temporary Key auf 0 gesetzt ist.

Stell dir vor, jeder könnte ohne Schlüssel in dein Haus — und der Türsteher fragt zwar nach dem Namen, schreibt ihn aber nie auf. Das ist "Just Works".

Muster 2: Verschlüsselungsversagen als Spektrum (3/3 Geräten)

Alle drei Geräte scheitern an der Verschlüsselung — aber auf unterschiedliche Arten. Das Ergebnis ist ein Spektrum vom "falschen Sicherheitsgefühl" bis zum vollständigen Verzicht:

LED-Brille:   AES-128 vorhanden, aber...
              └── Schlüssel hardcodiert (.data:0x113020)
              └── ECB-Modus → semantische Sicherheit verletzt

LED-Strip:    GATT-Traffic vollständig im Klartext
              └── XOR nur auf Advertisements (Obfuskation, keine Krypto)
              └── XOR-Schlüssel als ASCII im Code

Körperwaage:  Keine Verschlüsselung
              └── Keine Verschlüsselungsebene vorgesehen
              └── Broadcast im Klartext

Das ist besonders lehrreich: Die LED-Brille hat den meisten Krypto-Code, aber die Implementierung ist so fehlerhaft, dass der Schutz illusorisch ist. Der LED-Strip täuscht mit XOR-"Verschlüsselung" zumindest in den Advertisement-Daten eine Verschlüsselung vor — bei näherer Betrachtung ist es nichts weiter als eine Caesar-Chiffre im 21. Jahrhundert. Die Waage ist wenigstens ehrlich: Es gibt keine Verschlüsselung, und das ist sofort erkennbar.

Muster 3: Hardcodierte Geheimnisse (2/3 Geräten)

Zwei der drei Geräte enthielten geheime Schlüssel, die direkt im ausgelieferten Code eingebettet waren:

LED-Brille:

AES-128-Schlüssel: 8 Byte (Hex) gefunden in .data:0x113020
Methode: Ghidra + statische Speicheranalyse
Bestätigung: PoC entschlüsselt Live-Traffic erfolgreich

LED-Strip:

XOR-Schlüssel: "YLZK51!)>H@vdbQD^D?" (19 ASCII-Zeichen)
Methode: JADX, String-Suche in Bytecode
Kontext: Als Konstante in Verschlüsselungsfunktion

Ein hardcodierter Schlüssel ist das Sicherheitsäquivalent eines Schlüssels unter der Fußmatte: Jeder, der einmal nachschaut, hat dauerhaften Zugang — und der Schlüssel kann nicht ohne ein App-Update geändert werden. Bei Millionen ausgelieferter Geräte ist ein Software-Update nie garantiert.

Muster 4: Proprietäre statt Standardprotokolle (3/3 Geräten)

Alle drei Geräte verwenden eigene, nicht dokumentierte GATT-Service-UUIDs und proprietäre Payload-Formate:

Das ist kein technisches Versagen, aber ein symptomatisches Muster: Proprietäre Protokolle werden ohne Security Review implementiert. Standardprotokolle (wie das GATT Body Composition Profile 0x181B) haben zumindest eine öffentliche Spezifikation, die geprüft werden kann.

Vergleich mit Industriestandards

Die Ergebnisse dieser Studie sind kein Einzelfall. Vergleiche mit größeren Studien zur IoT-Sicherheit zeigen eine bedrückende Übereinstimmung:

Die Stichprobengröße von drei Geräten erlaubt keine statistischen Schlüsse über den Gesamtmarkt — aber die vollständige Übereinstimmung mit dem Branchentrend legt nahe, dass die gefundenen Muster systema­tisch sind, nicht zufällig.

Ursachenanalyse: Warum passiert das immer wieder?

Die Schwachstellen sind bekannt. Die Angriffe sind dokumentiert. Warum werden dieselben Fehler trotzdem gemacht?

Ursache 1: „Cargo Cult Security"

Der Begriff „Cargo Cult" kommt aus der Anthropologie: Isolierte Völker imitierten nach dem Zweiten Weltkrieg das äußere Erscheinungsbild von Militärstützpunkten (Landebahnen, Kontrolltürme aus Holz), ohne zu verstehen, was diese Dinge eigentlich bewirkten — in der Hoffnung, die Flugzeuge kämen zurück.

In der IoT-Sicherheit sieht das so aus: Entwickler importieren Krypto-Bibliotheken, instanziieren AES, rufen encrypt() auf — und glauben, das Gerät sei sicher. Dass AES im ECB-Modus mit einem hardcodierten Schlüssel keinen echten Schutz bietet, bleibt unerkannt. Der Code sieht aus wie Krypto. Er ist keine.

Ursache 2: Zeit- und Kostendruck

Typische IoT-Produktentwicklungszyklen dauern 6–12 Monate. In dieser Zeit konkurrieren Sicherheitsfeatures mit funktionalen Features, Stabilitätsproblemen und Markteinführungsterminen. Sicherheit ist nicht sichtbar — sie ist kein Feature, das auf der Verpackung steht. Im Zweifel wird sie zurückgestellt.

Ursache 3: Skill-Gap im IoT-Engineering

Ein Embedded-Systems-Ingenieur muss heute gleichzeitig Hardware-Design, RTOS-Programmierung, BLE-Stack-Konfiguration, App-Entwicklung und Sicherheitsanalyse beherrschen. Kryptographisches Wissen ist nicht standardmäßig Teil von Embedded-Ausbildungen. Das Ergebnis: Entwickler kopieren Code-Snippets aus Stack Overflow oder Hersteller-Beispielprojekten — oft ohne die Sicherheitsimplikationen zu verstehen.

Ursache 4: Fehlende Sicherheits-Frameworks

Web-Frameworks wie Django oder Rails haben Sicherheitsfeatures eingebaut: CSRF-Schutz, sichere Session-Cookies, SQL-Injection-Prävention. Ein Web-Entwickler, der Django richtig benutzt, macht viele Fehler gar nicht erst.

Im IoT-Ökosystem gibt es kein Äquivalent. BLE-Stacks wie NimBLE oder das Nordic SDK bieten Krypto-Primitiven an, aber keine sichere Standardkonfiguration. Der Entwickler muss bewusst entscheiden, Verschlüsselung zu aktivieren, ein sicheres Pairing zu konfigurieren, Replay-Schutz zu implementieren. Wer das nicht weiß, tut es nicht.

Ursache 5: Fehlendes regulatorisches Enforcement

Bis 2027 fehlte in der EU ein verbindliches Sicherheitsgesetz für IoT-Geräte. Der Cyber Resilience Act (CRA) tritt schrittweise in Kraft: Ab September 2026 gelten Meldepflichten für Sicherheitsvorfälle, ab Dezember 2027 müssen alle neuen Geräte die Sicherheitsanforderungen erfüllen.

Vor dem CRA gab es keinen finanziellen Anreiz für Hersteller, Sicherheit zu investieren. Niemand prüfte es, niemand sanktionierte es — außer der DSGVO bei Gesundheitsdaten.

Was gute Sicherheit ausgesehen hätte

Zum Abschluss ein kurzer Blick darauf, was die Hersteller hätten tun können — ohne fundamentale Architekturänderungen:

Nichts davon ist exotisch. Alles davon ist in BLE-Chips wie dem nRF52840 bereits implementiert und dokumentiert. Es war eine Frage des Wissens und der Priorität — nicht der technischen Möglichkeiten.

Zusammenfassung

• Alle drei Geräte teilen vier systemische Muster: fehlende Authentifizierung, Verschlüsselungsversagen, hardcodierte Geheimnisse und proprietäre Protokolle ohne Security Review.
• Die Ergebnisse decken sich mit Branchenstudien: > 80% aller IoT-BLE-Geräte haben keine Authentifizierung, > 72% schwache oder keine Verschlüsselung.
• Die Ursachen sind nicht technischer Natur, sondern organisatorisch: Zeitdruck, Skill-Gap, fehlende Frameworks und fehlendes Enforcement.
• Der Cyber Resilience Act wird ab 2027 erstmals verbindliche Standards setzen — bis dahin bleibt Sicherheitsforschung wie diese der wichtigste Mechanismus, um Hersteller zur Verbesserung zu bewegen.
• Responsible Disclosure ist deshalb keine optionale Tugend, sondern ein notwendiger Teil des Prozesses: Nur wenn Hersteller von Schwachstellen erfahren, können sie handeln.