Fall 04 — SKRED Messenger

Ein Schlüssel
für alle Geräte.

SKRED ist ein quelloffener Messenger mit Ende-zu-Ende-Anspruch. Beim Lesen seiner offenen Schlüsselverwaltung fand ich einen Ersatzschlüssel, der auf jedem Gerät derselbe war. Gemeldet über das BSI CERT-Bund — und der Hersteller reagierte so, wie man es sich wünscht: offen, technisch fundiert und zügig behoben.

Von Abbas Hoseiny· Koordiniert über BSI CERT-Bund & CERT/CC· Hersteller: SKRED SAS / Twinlife

Nicht jede Lücke ist ein Drama, und nicht jeder gute Fall braucht einen spektakulären Fund. Dieser hier ist die Geschichte eines kleinen, konkreten Fehlers in einem quelloffenen Messenger — und vor allem einer Reaktion, die zeigt, wie koordinierte Offenlegung laufen soll.

Ein einziger Schlüssel, der auf viele identische Telefone passt derselbe Schlüssel auf jedem Gerät
Abb. 1 — ein Schlüssel für alle

SKRED legt sensible Einstellungen auf dem Gerät verschlüsselt ab. Dafür erzeugt es normalerweise einen eigenen Schlüssel im gesicherten Speicher des Telefons (Android-Keystore). Schlägt das fehl — ein auf manchen älteren Geräten bekanntes Problem — griff ein fest einprogrammierter Ersatzschlüssel. Dieser Ersatz war auf jeder Installation derselbe.

Warum es ihn gab. Der Gedanke dahinter war gutartig: Daten auch dann noch schützen, wenn der Keystore des Geräts versagt. Nur war der Ersatzschlüssel nicht geräteindividuell, sondern deterministisch aus zwei fest hinterlegten Werten berechnet — also überall gleich und aus dem offenen Quellcode rekonstruierbar.

Was das bedeutet — ehrlich eingeordnet. Das war ein Ersatzpfad, nicht der normale Verschlüsselungsweg, und er betraf lokal abgelegte Einstellungen, nicht die Inhalte aller Nachrichten. Ausnutzen ließ sich das nur mit Zugriff auf das Gerät selbst — kein Angriff aus der Ferne. Die Schwere liegt im lokalen, gerätegebundenen Fall. Genau diese nüchterne Einordnung ist der Punkt: ein echter, aber klar begrenzter Fehler.

Der Ersatzschlüssel wird weggeschlossen und dient nur noch dem Lesen alter Daten neu: kontrollierter Abbruch Ersatzschlüssel nur noch zum Lesen von Altdaten
Abb. 2 — wie der Hersteller es behoben hat

Im neuen Stand wird der Ersatzschlüssel nicht mehr zum Verschlüsseln verwendet. Schlägt der Keystore fehl, bricht die App kontrolliert ab, statt mit einem bekannten Schlüssel weiterzumachen. Der alte Schlüssel bleibt nur noch, um bereits vorhandene Daten bei der Migration zu entschlüsseln.

Die Reaktion

Ein Mensch antwortet — und behebt.

Nachdem das BSI den Bericht weitergeleitet hatte, meldete sich der technische Leiter des Herstellers persönlich. Keine Textbaustein-Antwort, sondern Punkt für Punkt, technisch fundiert. Er stellte zusätzliche Architektur-Dokumentation bereit, verwies auf die quelloffene Codebasis und begann unmittelbar mit den Korrekturen. Neben dem Ersatzschlüssel wurde auch die fehlende Zertifikatsbindung (Certificate Pinning) ergänzt — nachvollziehbar im offenen Repository.

Was ich daraus mitnehme

So soll es laufen.

Koordinierte Offenlegung lebt nicht von spektakulären Lücken, sondern von dem, was danach passiert. SKRED hat gezeigt, wie es gehen soll: Offenheit (quelloffen), Erreichbarkeit (ein Mensch antwortet), fachliche Auseinandersetzung statt Abwehr und zügige, nachprüfbare Korrekturen. Dass die Apps offen liegen, ist dabei kein Zufall, sondern Teil derselben Haltung.

Technischer Bericht

SKRED Messenger — Analyse & Behebung

Inhalt
  1. Zusammenfassung
  2. Fund 1 — eingebauter AES-Ersatzschlüssel
  3. Fund 2 — fehlende Zertifikatsbindung
  4. Zur Bewertung
  5. Koordination & Offenlegung

Zusammenfassung

SKRED Messenger (SKRED SAS / Twinlife, Frankreich) ist auf Android und iOS quelloffen (AGPL). Analysiert wurde die veröffentlichte App zusammen mit dem offenen Quellcode. Dieser Bericht behandelt zwei behobene Punkte: einen fest eingebauten AES-Ersatzschlüssel in der Schlüsselverwaltung und eine fehlende Zertifikatsbindung. Beide wurden im Rahmen einer über das BSI CERT-Bund (und CERT/CC, VU#629507) koordinierten Offenlegung gemeldet und vom Hersteller behoben; der Stand ist in den öffentlichen Quellen nachvollziehbar.

Fund 1 · Schlüsselverwaltung

Deterministischer AES-Ersatzschlüssel, auf allen Geräten identisch

Was passiert

Die Schlüsselverwaltung (KeyChain) schützt lokal abgelegte, „gesicherte" Einstellungen mit einem Schlüssel aus dem Android-Keystore. Scheitert dessen Erzeugung (bekanntes Problem auf manchen älteren Geräten/ROMs), fiel die App früher auf einen fest einprogrammierten Ersatzschlüssel zurück. Dieser wurde deterministisch aus zwei im Code hinterlegten Byte-Feldern per XOR berechnet — und war damit auf jeder Installation gleich:

// vereinfacht aus der quelloffenen KeyChain-Implementierung
static Key getDefaultSecretKey() {
    int n = Math.min(UUID1.length, UUID2.length);
    byte[] key = new byte[n];
    for (int i = 0; i < n; i++)
        key[i] = (byte) (UUID1[i] ^ UUID2[n - 1 - i]);
    return new SecretKeySpec(key, "AES");   // 128-bit, auf jedem Gerät gleich
}

Auswirkung

Auf einem Gerät, dessen Keystore versagte, wurden lokale „gesicherte" Einstellungen mit einem allgemein bekannten Schlüssel geschützt. Wer lokalen Zugriff auf ein solches Gerät hatte, konnte diese Daten entschlüsseln. Es handelt sich um einen Ersatzpfad (nicht den Normalfall) und einen lokalen, gerätegebundenen Zugriff — kein Fernangriff und keine Offenlegung von Nachrichteninhalten aller Nutzer.

Behebung durch den Hersteller

Der Ersatzschlüssel wird nicht mehr zum Verschlüsseln verwendet. Schlägt die Keystore-Erzeugung fehl, bricht die App kontrolliert ab (Fehlerzustand), statt mit dem bekannten Schlüssel zu verschlüsseln. Der Schlüssel dient nur noch dazu, bereits vorhandene Daten bei der Migration zu entschlüsseln; die Unterstützung für Android 5.0/5.1 (die Hauptquelle des defekten Keystores) wurde entfernt. Verifiziert in den offenen Quellen.

Fund 2 · Netzwerksicherheit

Fehlende Zertifikatsbindung (Certificate Pinning)

Was passiert

Der App fehlte eine Netzwerk-Sicherheitskonfiguration. Ein auf dem Gerät installiertes zusätzliches Zertifikat — etwa in verwalteten Umgebungen — hätte das Mitlesen der TLS-Verbindungen der App ermöglicht.

Behebung durch den Hersteller

Die App bringt eine Netzwerk-Sicherheitskonfiguration mit, die ausschließlich System-Zertifikate vertraut, Klartext-Verkehr unterbindet und ein echtes Pin-Set für die eigene Domain hinterlegt. Bereits früh im Verlauf umgesetzt und von mir in der veröffentlichten App bestätigt.

Zur Bewertung

Warum hier keine dramatischen Schweregrade stehen Der Ersatzschlüssel war ein Ersatzpfad für defekte Keystores und erforderte lokalen Zugriff auf das Gerät; die fehlende Zertifikatsbindung setzte ein auf dem Gerät installiertes Fremdzertifikat voraus. Beide sind reale, aber klar begrenzte Punkte — und beide sind behoben. Statt einer überhöhten Note steht hier die ehrliche Einordnung: lokaler, gerätegebundener Zugang, kein Fernangriff.

Koordination & Offenlegung

Koordinierte Offenlegung über das BSI CERT-Bund und CERT/CC. Herstellerbehebung in den öffentlichen Quellen nachvollziehbar. Zu Abwehr- und Forschungszwecken.