Grundsätze für den Entwurf sicherer Protokolle

Beim Entwurf sicherer Protokolle wird von einem Angreifer ausgegangen, der das Netzwerk vollständig kontrolliert. Das Dolev-Yao-Modell (1983) legt fest: Der Angreifer kann jede übertragene Nachricht abfangen, lesen, verzögern, wiedergeben, löschen und verändern. Er kann Nachrichten erzeugen, die von denen legitimer Parteien nicht zu unterscheiden sind. Er kann aus bekannten Nachrichtenbestandteilen neue Nachrichten zusammensetzen. Kryptografische Primitive kann der Angreifer nicht brechen (ohne den Schlüssel entschlüsseln oder Signaturen fälschen). Entscheidend ist, dass der Angreifer rechnerisch beschränkt ist und in polynomieller Zeit arbeitet, aber alle Kommunikationskanäle kontrolliert. Protokollsicherheit bedeutet, Authentifizierungs- und Geheimhaltungsziele selbst gegenüber diesem mächtigen Angreifer zu erreichen und sich dabei ausschließlich auf die rechnerische Schwierigkeit der zugrunde liegenden Primitive zu stützen.

Abadi und Needham (1994) fassten praktische Lehren für den Protokollentwurf in einer Reihe von Prinzipien zusammen. (1) Jede Nachricht sollte erkennen lassen, was sie bedeutet: Die Interpretation einer Nachricht sollte in sich geschlossen sein und nicht vom Kontext abhängen. (2) Bedingungen, unter denen ein Prinzipal eine Aktion ausführt, sollten im Protokoll ausdrücklich angegeben werden. (3) Wenn die Identität eines Prinzipals wichtig ist, sollte sie in der Nachricht ausdrücklich angegeben werden. (4) Machen Sie klar, warum Verschlüsselung verwendet wird: Verschlüsselung bietet Vertraulichkeit, Signieren bietet Authentifizierung – verwenden Sie Verschlüsselung nicht als Ersatz für das Signieren. (5) Eine Nachricht sollte auf der Protokollebene verschlüsselt werden, auf der ihre Geheimhaltung erforderlich ist. Diese Prinzipien verhinderten viele Schwachstellen vom NS-Typ.

Wiedergabeangriffe gehören zu den häufigsten Schwachstellen von Protokollen. Mechanismen zur Sicherstellung der Aktualität gewährleisten, dass eine empfangene Nachricht erst kürzlich erzeugt und nicht aus einer alten Sitzung wiedergegeben wurde. Es gibt zwei Ansätze: (1) Nonces (nur einmal verwendete Zahlen) – ein Challenge-Response-Verfahren, bei dem der Empfänger einen zufälligen Wert sendet und erwartet, dass dieser in der Antwort zurückgesendet wird. Die Antwort muss die Nonce verschlüsselt oder signiert enthalten, damit eine alte Aufzeichnung die Herausforderung nicht erfüllen kann. (2) Zeitstempel – beide Parteien fügen die aktuelle Zeit ein; eine Nachricht mit einem veralteten Zeitstempel wird abgelehnt. Zeitstempel erfordern synchronisierte Uhren (Kerberos erlaubt eine Abweichung von 5 Minuten). Nonces werden bevorzugt, wenn keine Uhrensynchronisierung verfügbar ist; Zeitstempel vereinfachen die zustandslose Prüfung.

Die Verwendung desselben kryptografischen Schlüssels für mehrere Zwecke führt zu gefährlichen Wechselwirkungen. Wenn ein Schlüssel K sowohl zur Verschlüsselung als auch zur Authentifizierung verwendet wird, kann ein Angreifer gezielt konstruierte Chiffrate in den Authentifizierungsmechanismus einspeisen, um Informationen zu gewinnen. TLS 1.3 vermeidet dies konsequent durch HKDF-Expand-Label mit unterschiedlichen Labels für jeden abgeleiteten Schlüssel: "c hs traffic" (Client-Handshake), "s hs traffic" (Server-Handshake), "c ap traffic" (Client-Anwendung). Selbst wenn der Handshake-Schlüssel kompromittiert wird, bleiben die aus einem anderen HKDF-Zweig abgeleiteten Anwendungsschlüssel sicher. Protokollentwürfe müssen jeden Schlüssel auf Risiken durch Mehrfachverwendung prüfen und für unterschiedliche Zwecke separate Schlüssel ableiten.

Authentifizierungsnachweise müssen an die konkrete Sitzung gebunden sein, in der sie verwendet werden. Ohne diese Bindung kann ein in einer Sitzung erlangter Nachweis in einer anderen erneut abgespielt werden. Techniken: (1) Sitzungsbezeichner in signierte oder mit einem MAC versehene Daten aufnehmen. (2) Das DH-Transkript in die Signatur aufnehmen (STS-Ansatz). (3) Den über HKDF abgeleiteten Sitzungsschlüssel für einen MAC über die Identität verwenden (SIGMA-Ansatz). TLS 1.3 Finished-Nachricht: MAC(server_finished_key, transcript_hash) — der MAC deckt das vollständige Transkript ab, sodass das erneute Abspielen einer Finished-Nachricht aus einer anderen Sitzung fehlschlägt. Diese Bindung verhindert die sitzungsübergreifenden Angriffe, die in frühen Kerberos- und NS-Varianten auftraten.

Protokolle sollten nur die für ihre Funktion unbedingt erforderlichen Informationen preisgeben. Identitäten sollten nur denjenigen offengelegt werden, die sie benötigen. Zertifikatsseriennummern oder Bezeichner, die eine Verknüpfung von Sitzungen mit Identitäten ermöglichen, sollten nicht aufgenommen werden, sofern dies nicht erforderlich ist. TLS 1.3 verschlüsselt das Serverzertifikat — anders als TLS 1.2, bei dem es im Klartext übertragen wird — und verringert dadurch die Informationen, die ein passiver Lauscher sammeln kann. ESNI (Encrypted SNI, inzwischen ECH — Encrypted Client Hello) verschlüsselt die Servernamenanzeige, um zu verbergen, mit welchem Server der Client eine Verbindung herstellt. Die minimale Informationspreisgabe ist auch ein Prinzip beim Token-Design: JWT-Claims sollten nur die für die Autorisierung erforderlichen Angaben enthalten, nicht vollständige Identitätsdatensätze.

Die Versionsaushandlung ist eine häufige Angriffsfläche: Ein Angreifer entfernt oder verändert das ClientHello, um beide Parteien zur Verwendung einer älteren, schwächeren Protokollversion zu zwingen. Schutzmaßnahmen: (1) Authentifizierte Versionsaushandlung — die ausgehandelte Version wird in das signierte Transkript aufgenommen (Finished in TLS deckt das ClientHello einschließlich der Version ab). (2) Downgrade-Sentinels — TLS 1.3 setzt beim Downgrade auf TLS 1.2 spezielle Bytefolgen in ServerHello.Random, damit der Client das Downgrade erkennen kann. (3) Vermeidung von Versionsintoleranz — Server müssen fehlerhafte ClientHellos ablehnen, ohne stillschweigend auf eine andere Version zurückzufallen. (4) SCSV — TLS_FALLBACK_SCSV signalisiert dem Server, dass der Client einen erneuten Versuch mit einer niedrigeren Version unternimmt, sodass der Server unzulässige Rückstufungen ablehnen kann.

Protokollnachrichten sollten bereits ab dem ersten Austausch festgeschrieben sein. Nicht-Malleabilität bedeutet, dass ein Angreifer einen Chiffretext oder eine Signatur nicht so verändern kann, dass sie in einem anderen Kontext gültig ist. AEAD gewährleistet die Nicht-Malleabilität von Chiffretexten — jede Änderung macht das Authentifizierungs-Tag ungültig. Auf Protokollebene stellt das Hashing des Transkripts sicher, dass der Finished-Austausch am Ende eines Handshakes jede gesendete Nachricht festschreibt. Dadurch werden Cut-and-Paste-Angriffe verhindert: Das Zusammenfügen von Nachrichten aus zwei verschiedenen Sitzungen kann keinen gültigen Finished-Wert für eine der beiden Sitzungen erzeugen. Commitment-Schemata (Hash-Commitments) erweitern dieses Prinzip auf Protokollabläufe, die vor der Offenlegung eine Vorabfestlegung erfordern.

Komplexe Protokolle scheitern häufig an den Grenzen ihrer Zustandsmaschinen. Wenn ein Zustandsübergang nicht eindeutig ist — was geschieht, wenn Nachricht 3 vor Nachricht 2 eintrifft? Was geschieht, wenn ein unerwarteter Nachrichtentyp eintrifft? — können Implementierungen voneinander abweichen und dadurch Inkonsistenzen erzeugen, die ein Angreifer ausnutzen kann. Protokollspezifikationen müssen Folgendes definieren: die vollständige Zustandsmaschine (alle Zustände und gültigen Übergänge), das Verhalten bei unerwarteten Eingaben (Ablehnung mit einem bestimmten Fehler oder stilles Ignorieren), Zeitüberschreitungen und Grenzen für erneute Übertragungen sowie die Bereinigung von Sitzungen. SSL/TLS litt historisch unter voneinander abweichenden Zustandsmaschinen in Implementierungen — CVE-2014-0160 (Heartbleed) war im Wesentlichen ein Fehler der Zustandsmaschine, bei dem eine Heartbeat-Anfrage in einem Zustand verarbeitet wurde, in dem der Speicher nicht ordnungsgemäß begrenzt war.

Kryptografische Protokolle werden nur selten isoliert eingesetzt. Ein AKE-Protokoll richtet einen Sitzungsschlüssel ein, der anschließend von einem Protokoll der Anwendungsschicht verwendet wird. Wenn das AKE- und das Anwendungsprotokoll unabhängig voneinander und ohne Blick auf die Komponierbarkeit entworfen werden, können Wechselwirkungen die Sicherheit beeinträchtigen. Das Universal-Composability-Framework (UC) (Canetti, 2001) bietet ein rigoroses Modell für die Protokollkomposition: Ein Protokoll ist UC-sicher, wenn es sicher bleibt, sobald es beliebig mit anderen UC-sicheren Protokollen zusammengesetzt wird. TLS 1.3, Signal und Noise zielen auf komponierbare Sicherheit. Praktisch bedeutet dies: Verwenden Sie Channel Binding (exportieren Sie den Transkript-Hash), um die AKE-Sitzung mit der nachfolgenden Anwendungsauthentifizierung zu verknüpfen und so die Weiterleitung von Zugangsdaten zwischen Sitzungen zu verhindern, die über dasselbe AKE-Protokoll eingerichtet wurden.

Protokolldesigner machen wiederholt dieselben Arten von Fehlern. (1) Eigenbau-Kryptografie: Implementieren eigener Blockchiffren, MACs oder Schlüsselableitungen ohne Begutachtung durch andere Fachleute. (2) Implizites Vertrauen: Annehmen einer Nachrichtenquelle aufgrund des Netzwerkkontexts statt aufgrund eines kryptografischen Nachweises. (3) Optionale Sicherheit: Verschlüsselung oder Authentifizierung konfigurierbar machen, was unweigerlich zu Downgrades führt. (4) Lang lebende Tokens ohne Widerruf: JWTs oder Sitzungsschlüssel mit langer Gültigkeitsdauer und ohne Widerrufsmechanismus ausgeben. (5) Den Fehlerkanal ignorieren: Werden Fehlermeldungen nicht authentifiziert, kann ein Angreifer Fehler einschleusen und dadurch das Protokollverhalten beeinflussen. (6) Verschlüsselung zur Authentifizierung verwenden: Die Verschlüsselung von Daten authentifiziert deren Quelle nicht ohne MAC oder Signatur.

Sicheres Protokolldesign wendet etablierte Prinzipien an: das Dolev-Yao-Angreifermodell (Angreifer mit Kontrolle über das Netzwerk), die Abadi-Needham-Prinzipien (explizite Identität, in sich geschlossene Nachrichten), Frische durch Nonces oder Zeitstempel, Schlüsseltrennung durch HKDF mit unterschiedlichen Labels, die Bindung von Authentifizierungsnachweisen an Sitzungen, minimale Informationspreisgabe, die Verhinderung von Downgrades durch Transkriptauthentifizierung, Nicht-Malleabilität durch AEAD und Transkript-Hashing, klare Zustandsmaschinen mit definiertem Fehlerverhalten sowie Komponierbarkeit durch Sicherheitsbeweise im UC-Modell. Verstöße gegen diese Prinzipien sind die Ursache fast aller bekannten kryptografischen Schwachstellen auf Protokollebene.