Kryptoagilität ist die Fähigkeit, ein Protokoll von einer kryptografischen Suite auf eine andere umzustellen, ohne klare Sicherheitszusagen zu verlieren. Beim Messaging bedeutet das mehr, als einen neuen Algorithmusnamen hinzuzufügen. Alte Clients, Offline-Empfänger, gespeicherte Nachrichten und verknüpfte Geräte müssen sich während des Übergangs vorhersehbar verhalten.
Die RFC 7696 der IETF beschreibt Algorithmusagilität als Migrationsproblem, das Kennungen, Implementierungen und betriebliche Veränderungen umfasst. Eine Versionsnummer hilft zu erkennen, was verwendet wird; sie macht eine Migration nicht von selbst sicher.
Drei leicht zu verwechselnde Versionen
Ein Messenger kann eine App-Version, eine Version des Übertragungsprotokolls und eine Kennung der kryptografischen Suite haben. Sie beantworten unterschiedliche Fragen:
| Kennung | Was sie einer prüfenden Person sagt | Was sie nicht belegt |
|---|---|---|
| App-Release | Welcher Software-Build installiert ist | Dass jedes Gespräch das neueste Protokoll verwendet |
| Protokollversion | Welches Nachrichtenformat und welche Zustandsregeln gelten | Dass die Implementierung diese Regeln korrekt befolgt |
| Algorithmus- oder Suite-Kennung | Welche kryptografischen Komponenten ausgewählt sind | Dass die Aushandlung nicht auf eine schwächere Variante herabgestuft werden kann |
Versionshinweise sollten diesen Zusammenhang ausdrücklich erklären. „Neue Verschlüsselung ausgeliefert“ ist mehrdeutig, wenn nur neu angelegte Gespräche sie nutzen oder ein älterer verknüpfter Client einen Rückfall auslöst.
Was eine sichere Migration festlegen muss
Beginnen Sie mit einem konkreten Szenario: Alice aktualisiert heute; Bob bleibt mit einem älteren Telefon offline. Alice sendet eine Nachricht und fügt später ein zweites Gerät hinzu. Was soll jedes Gerät annehmen, speichern und anzeigen?
Ein überprüfbarer Entwurf beantwortet mindestens diese Fragen:
- Wie erfährt jede Seite, welche Versionen die andere unterstützt?
- Wird die ausgewählte Version als Teil der Sitzung authentifiziert?
- Was passiert, wenn es keine gemeinsam unterstützte akzeptable Version gibt?
- Kann ein bösartiger Vermittlungsserver eine Fähigkeit entfernen und einen schwächeren Modus erzwingen?
- Bleiben alte Nachrichten lesbar, und welche alten Schlüssel werden weiterhin benötigt?
- Stellt das Wiederherstellen eines Backups veralteten Protokollzustand wieder her?
- Wann werden abgekündigte Algorithmen deaktiviert, statt lediglich von ihrer Verwendung abzuraten?
Ein sichtbarer Fehler ist oft sicherer als ein unbemerkter Wechsel in einen Modus, den der Nutzer nicht beabsichtigt hat. Das genaue Fehler- und Wiederherstellungsverhalten sollte jedoch dokumentiert werden, damit Menschen es nicht durch den Wechsel zu einem ungeschützten Kanal umgehen.
Eine praktische Testmatrix für Upgrades
Ein Sicherheits-Upgrade braucht mehr als einen erfolgreichen Chat zwischen zwei frischen Installationen. Testen Sie diese Fälle mit nicht sensiblen Daten:
| Test | Aufzuzeichnende Belege |
|---|---|
| Neuer Client zu altem Client | Ausgewähltes Protokoll oder eindeutiges Inkompatibilitätsergebnis |
| Empfänger während des Upgrades offline | Zustell- und Entschlüsselungsverhalten nach erneuter Verbindung |
| Altes verknüpftes Gerät kehrt zurück | Ob es lesen, senden oder einen unerwarteten Modus erzwingen kann |
| Gruppe nimmt inkompatibles Mitglied auf | Ausdrückliche Gruppenrichtlinie und für Nutzer sichtbarer Zustand |
| Backup nach Abschaltung veralteter Verfahren wiederhergestellt | Ob nicht unterstützter Zustand abgewiesen oder migriert wird |
| Manipulierte Versionsmetadaten | Authentifizierungsfehler statt unbemerkter Herabstufung |
Dies sind Bewertungskriterien, keine Behauptungen, dass ein genanntes Produkt die Tests bestanden hat. Bewahren Sie Build-Kennungen und beobachtete Ergebnisse auf, damit sich eine spätere Regression von einer Dokumentationsänderung unterscheiden lässt.
Wie Livaras Protokollnamen zu verstehen sind
Livara nennt in seiner Sicherheitsdokumentation LVR1 für direkte Chats und LGS1 für private Gruppen. Diese Namen unterscheiden Zuständigkeiten; sie sollten nicht als Beleg für eine unabhängige Standardisierung oder Prüfung verstanden werden. Die Seite erläutert auch das Verhalten bei Clients oder Gruppen, die die Voraussetzungen des verschlüsselten Modus nicht erfüllen können.
Die nächsten hilfreichen Belege wären eine versionierte Spezifikation, Testvektoren, Kompatibilitätsregeln und an eine bestimmte Veröffentlichung gebundene Prüfergebnisse. Das Proof Lab benennt den engeren Umfang seiner Demonstration ausdrücklich. Kryptografische Grundbausteine in einem Browser auszuführen ist nicht dasselbe, wie jeden Migrationspfad in der App zu testen.
Was Nutzer während eines Verschlüsselungs-Upgrades tun sollten
Halten Sie unterstützte Clients aktuell, lesen Sie Sicherheitshinweise zur Gerätekompatibilität und achten Sie auf veränderte Identitäts- oder Verschlüsselungsstatusanzeigen. Gehen Sie nicht davon aus, dass ein neues App-Symbol bedeutet, jede alte Gruppe und jedes Backup habe neuen Schutz erhalten. Wenn das Produkt nicht erklären kann, bei welchen Daten sich der Schutz geändert hat, fragen Sie nach, bevor Sie sensible Inhalte teilen.
Gute Kryptoagilität macht Veränderungen überprüfbar. Sie benennt, was sich geändert hat, wie Kommunikationspartner sich darauf einigen, was schiefgehen kann und wann das alte Verfahren nicht mehr akzeptiert wird.
