Sicherheit in Computernetzen

Eine Nachricht kann vertraulich sein und dennoch verändert werden oder von einem Betrüger stammen. Sichere Kommunikation benötigt daher mehrere Eigenschaften, die jeweils eine andere Frage zum Austausch beantworten.

Benenne die gefährdete Eigenschaft

Alice und Bob sind die Kommunikationspartner; Trudy ist die Angreiferin. Eine passive Angreiferin fängt Verkehr ab, ohne ihn zu verändern. Das Mitlesen eines Passworts ist Abhören. Aus Verbindungszeiten auf einen arbeitsreichen Tagesablauf zu schließen, ist Verkehrsanalyse, selbst wenn die Inhalte verschlüsselt sind. Eine aktive Angreiferin schleust Pakete ein, verändert, löscht oder wiederholt sie. Bei der Identitätsvortäuschung gibt sie eine falsche Quellidentität an; bei einer Übernahme kontrolliert sie einen bestehenden Austausch; durch Überflutung versucht sie, Ressourcen zu erschöpfen.

Internetrouter leiten Pakete im Allgemeinen weiter, ohne die Echtheit ihrer Quelladressen nachzuweisen. Pakete durchqueren außerdem Netze, die keiner der beiden Nutzer kontrolliert. Im WLAN kann ein anderes Funkgerät in Reichweite übertragene Datenrahmen abfangen. Protokolle müssen die Kommunikation auch dann schützen, wenn ein Angreifer den Pfad kontrolliert.

Verfolge eine ungeschützte Anmeldung

Bob verbindet sich mit einem Café-Hotspot und meldet sich über unverschlüsseltes HTTP an. Trudy liest das Passwort: Die Vertraulichkeit ist verletzt. Sie verändert einen Downloadlink in der Antwort: Die Integrität ist verletzt. Betreibt sie einen gefälschten Hotspot mit dem Namen des Cafés, fehlt Bob außerdem eine zuverlässige Prüfung der Identität des Access Points. Nur das Passwort zu verschlüsseln würde nicht alle diese Schwachstellen beheben. Ein Angreifer kann manche verschlüsselte Nachrichten verändern, ohne sie zu verstehen, und eine abgefangene Authentifizierungsnachricht unverändert erneut senden.

Halte den Schlüssel geheim

Das Kerckhoffs-Prinzip besagt, dass die Sicherheit auch dann bestehen muss, wenn der Algorithmus bekannt wird. Das Geheimnis ist der Schlüssel. Ein selbst entwickelter geheimer Algorithmus kann aus Software rekonstruiert werden; außerdem ist es schwieriger, einen ganzen Algorithmus zu ändern und zu verteilen, als einen Schlüssel zu ersetzen. Der Austausch eines offengelegten Schlüssels schützt zukünftigen Verkehr, macht aber Aufzeichnungen unter dem alten Schlüssel nicht sicher.

Auch das Wissen des Angreifers ist wichtig. Ein Angriff mit bekanntem Geheimtext beginnt mit abgefangenen verschlüsselten Nachrichten. Bei einem Angriff mit bekanntem Klartext kommen passende ursprüngliche Nachrichten hinzu, etwa vorhersehbarer HTTP/1.1-Text, der mit „GET /“ beginnt. Bei einem Angriff mit gewähltem Klartext kann die Angreiferin Verschlüsselungen selbst gewählter Nachrichten erhalten. Moderne Verschlüsselung ist so entworfen, dass sie diesen stärkeren Angriffsmöglichkeiten standhält.

Bestimme den geschützten Pfad

WLAN- und Mobilfunksicherheit schützen eine Funkverbindung. TLS schützt die Kommunikation zwischen Anwendungsendpunkten. IPsec schützt ausgewählten IP-Verkehr zwischen Hosts oder Gateways. Schutz auf Nachrichtenebene, etwa bei sicherer E-Mail, kann während der Speicherung bei einer Nachricht bleiben. Eine sichere Funkstrecke schützt nicht den Rest eines Internetpfades: Nachdem ein Access Point den Schutz der Verbindung entfernt hat, muss ein anderer Mechanismus den weiteren Verkehr schützen.

Eine symmetrische Chiffre verwendet an beiden Enden denselben geheimen Schlüssel. Klartext ist die ursprüngliche Nachricht; Geheimtext ist ihre verschlüsselte Form. Schreibe die Verschlüsselung als $c=E_{K_S}(m)$ und die Entschlüsselung als $m=D_{K_S}(c)$: Der Schlüssel wird gemeinsam verwendet, aber die beiden Operationen machen einander rückgängig.

Schlüsselgröße und strukturelle Schwächen

Eine Caesar-Verschiebung um 3 macht aus „HALLO“ das Wort „KDOOR“. Durch Ausprobieren aller 25 nützlichen Verschiebungen lässt sie sich knacken. Eine Substitutionschiffre hat $26!\approx \mathrm{4,03}\times {10}^{26}$ Schlüssel, erhält aber die Buchstabenhäufigkeiten. Ein Angreifer kann wiederholte Buchstaben und häufige Wörter nutzen, um die Zuordnung zu rekonstruieren, ohne jeden Schlüssel auszuprobieren. Die Größe des Schlüsselraums allein beweist keine Sicherheit.

AES ist eine Blockchiffre mit 128-Bit-Blöcken und Schlüsseln mit 128, 192 oder 256 Bit. DES hatte 64-Bit-Blöcke und einen 56-Bit-Schlüssel; 1998 wurde ein DES-Schlüssel durch vollständige Suche gefunden, und DES und Triple DES werden nicht mehr standardmäßig eingesetzt. Jedes zusätzliche Schlüsselbit verdoppelt den Aufwand der vollständigen Suche. Bei ${10}^{12}$ Versuchen pro Sekunde dauert die Suche über alle DES-Schlüssel etwa $2^{56}\mathrm{/}{10}^{12}\approx 72.000$ Sekunden oder 20 Stunden; im Durchschnitt wird der Schlüssel nach der Hälfte der Zeit gefunden. Die Suche über alle AES-128-Schlüssel dauert bei dieser Rate etwa $\mathrm{1,1}\times {10}^{19}$ Jahre.

Der Modus verändert den Schutz der Nachricht

Ein Betriebsmodus verarbeitet mehr als einen Block.

Der erste CBC-Block verwendet anstelle eines vorherigen Geheimtextblocks einen Initialisierungsvektor, kurz IV. Der IV wird offen gesendet; entscheidend sind Unvorhersehbarkeit und Neuheit, nicht Geheimhaltung. Die Zufallsauswahl verbirgt unmittelbar erkennbare Gleichheitsmuster zwischen Nachrichten. Sie erkennt für sich genommen keine Manipulation.

Untersuche die Wiederverwendung eines Schlüsselstroms

Angenommen, zwei Nachrichten verwenden denselben Schlüsselstrom $k$. Ihre Geheimtexte sind $c_1=m_1\oplus k$ und $c_2=m_2\oplus k$. Ihre XOR-Verknüpfung hebt den wiederholten Schlüsselstrom auf:

Kennt man nun einen Klartext, lässt sich der andere ermitteln. Wiederholte IVs verursachten bei WEP diese Art von Fehler. Ein längerer Verschlüsselungsschlüssel behebt einen wiederholten Schlüsselstrom nicht.

AEAD, authentifizierte Verschlüsselung mit zugehörigen Daten, verbindet Vertraulichkeit mit Integrität. AES-GCM und ChaCha20-Poly1305 authentifizieren den Geheimtext und alle zugehörigen Daten. Zugehörige Daten, etwa ein Routingfeld, bleiben lesbar, können aber nicht verändert werden, ohne dass die Prüfung fehlschlägt. TLS 1.3 verwendet AEAD für jeden geschützten Record.

Verteile das Geheimnis

Schnelle Verschlüsselung großer Datenmengen benötigt weiterhin einen gemeinsamen Schlüssel. Benötigt jedes Paar von $n$ Nutzern einen anderen Schlüssel, beträgt die Gesamtzahl $n(n-1)\mathrm{/}2$. Für 100 Nutzer sind das 4.950 Schlüssel. Asymmetrische Verfahren ermöglichen es den Beteiligten, Sitzungsschlüssel zu vereinbaren, ohne vorher für jedes Paar ein separates Geheimnis zu verteilen.

Bob veröffentlicht $K_B^{+}$ und hält $K_B^{-}$ geheim. Alice kann für Bob verschlüsseln, ohne zuvor ein Geheimnis mit ihm zu teilen. Es muss praktisch unmöglich sein, den privaten Schlüssel aus dem öffentlichen Schlüssel zu berechnen.

Berechne einen einfachen RSA-Austausch

RSA beginnt mit den Primzahlen $p$ und $q$. Berechne $n=pq$ und $z=(p-1)(q-1)$. Wähle einen öffentlichen Exponenten $e$, der teilerfremd zu $z$ ist, und finde dann $d$, sodass $ed<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>z=1$ gilt. Der öffentliche Schlüssel ist $(n,e)$; der private Schlüssel ist $(n,d)$. Für eine Nachrichtenzahl kleiner als $n$ gilt:

Verwende die kleinen Beispielprimzahlen 11 und 13. Dann sind $n=143$ und $z=120$. Wähle bei $e=7$ den Wert $d=103$, denn $7\times 103=721=6\times 120+1$. Für $m=9$ ergibt wiederholtes Quadrieren $9^2<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>143=81$ und $9^4<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>143=126$. Die Kombination der Potenzen ergibt $9^7<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>143=48$. Die Entschlüsselung liefert ${48}^{103}<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>143=9$.

Diese Zahlen machen die Rechnung sichtbar; RSA in der Praxis verwendet Moduln mit mindestens 2.048 Bit. Die Zerlegung des Moduls legt die Primzahlen offen und ermöglicht die Rekonstruktion des Schlüssels. Echte RSA-Verschlüsselung verwendet außerdem eine zufallsbasierte OAEP-Auffüllung: RSA in der Lehrbuchform ohne Auffüllung erzeugt bei einer wiederholten Nachricht erneut denselben Geheimtext.

Vereinbare ein Geheimnis mit Diffie-Hellman

Diffie-Hellman stellt ein gemeinsames Geheimnis her, ohne dieses Geheimnis zu senden. Alice und Bob veröffentlichen eine Primzahl $p$ und einen Generator $g$. Alice hält $a$ geheim und sendet $A=g^a<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>p$. Bob hält $b$ geheim und sendet $B=g^b<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>p$. Alice berechnet $B^a<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>p$ und Bob berechnet $A^b<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>p$; beide erhalten $g^{ab}<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>p$.

Für $p=29$, $g=2$, $a=5$ und $b=12$ sendet Alice 3 und Bob 7. Alices Rechnung ergibt $7^5<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>29=16$; die von Bob ergibt $3^{12}<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>29=16$. Ihr kleines Beispiel ist leicht zu knacken; bei großen Gruppen ist die Rekonstruktion der geheimen Exponenten praktisch unmöglich. Verfahren auf elliptischen Kurven wie X25519 erfüllen denselben Zweck mit kürzeren Schlüsseln.

Authentifiziere den Austausch

Diffie-Hellman allein identifiziert keinen der Teilnehmer. Trudy kann ihre eigenen öffentlichen Werte einsetzen und zwei getrennte gemeinsame Geheimnisse erzeugen, eines mit Alice und eines mit Bob. Dann liest sie den Verkehr und verschlüsselt ihn erneut. Ein authentifiziertes Protokoll bindet die ausgetauschten Werte an vertrauenswürdige Identitäten, mithilfe von Signaturen und Zertifikaten oder einem bereits vereinbarten gemeinsamen Geheimnis.

Protokolle verwenden hybride Verschlüsselung: Asymmetrische Verfahren vereinbaren einen Sitzungsschlüssel, und AES oder ChaCha20 verarbeitet die großen Datenmengen. RSA kann einen zufälligen Sitzungsschlüssel übertragen, doch der spätere Diebstahl des privaten RSA-Schlüssels legt aufgezeichnete Austausche offen. Neue kurzlebige Diffie-Hellman-Werte, die nach Gebrauch gelöscht werden, bieten Vorwärtsgeheimnis gegenüber dem späteren Diebstahl langfristiger Authentifizierungsschlüssel.

Ein ausreichend großer Quantencomputer würde RSA und klassisches Diffie-Hellman brechen. ML-KEM, 2024 von NIST in FIPS 203 standardisiert, dient der Post-Quanten-Schlüsselvereinbarung. Ein hybrides Verfahren wie X25519MLKEM768 kombiniert klassische und Post-Quanten-Komponenten. In dieser Verwendung beschreibt „hybrid“ zwei Mechanismen zur Schlüsselvereinbarung; große Datenmengen werden weiterhin symmetrisch verschlüsselt, auch mit 256-Bit-Schlüsseln für eine große Sicherheitsreserve.

Eine Integritätsprüfung muss einem gezielten Angriff standhalten, nicht nur versehentlichen Fehlern. Eine Netzwerkprüfsumme und ein kryptografischer Hashwert dienen unterschiedlichen Zwecken, und keiner von beiden authentifiziert für sich genommen eine Nachricht.

Verstehe die Eigenschaften von Hashfunktionen

Eine kryptografische Hashfunktion bildet eine Nachricht beliebiger Länge auf einen Hashwert fester Größe ab. SHA-256 erzeugt 256 Bit, die gewöhnlich als 64 Hexadezimalziffern geschrieben werden. Gute Hashfunktionen besitzen drei unterschiedliche Resistenzeigenschaften:

Kollisionen existieren, weil eine endliche Anzahl von Hashwerten mehr mögliche Nachrichten abbildet. Sicherheit bedeutet, dass es praktisch unmöglich ist, eine nutzbare Kollision zu finden. Für MD5 und SHA-1 gibt es praktisch durchführbare Kollisionsangriffe; sie eignen sich nicht für Signaturen und Zertifikate. SHA-3 bietet eine weitere moderne Familie von Hashfunktionen.

Kleine Änderungen an einer Nachricht wirken sich über den ganzen Hashwert aus: Das ist der Lawineneffekt. Die Änderung von „Pay Ana 100“ zu „Pay Ana 900“ verändert 124 Bit der SHA-256-Ausgabe; die Hashwerte beginnen mit ECD0D31E und 21736708. Dagegen ist die Internet-Prüfsumme sowohl von „PAY 1290“ als auch von „PAY 9012“ gleich 0xEC3B: Das Vertauschen der betreffenden 16-Bit-Wörter erhält ihre Summe. Eine Prüfsumme, die zufällige Beschädigungen erkennen soll, lässt sich bei einer gezielten Änderung leicht beibehalten.

Ergänze das Geheimnis, das einem Angreifer fehlt

Eine Nachricht und ihren Hashwert offen zu senden, schützt nicht vor aktiver Manipulation. Trudy ersetzt sowohl die Nachricht als auch ihren Hashwert, sodass die Neuberechnung des Empfängers erfolgreich ist. Ein Nachrichtenauthentifizierungscode, kurz MAC, ergänzt einen geheimen Authentifizierungsschlüssel, den Alice und Bob gemeinsam besitzen.

Alice sendet $m$ und $\mathrm{M}\mathrm{A}\mathrm{C}(s,m)$. Bob berechnet aus der empfangenen Nachricht und seiner eigenen Kopie von $s$ einen Authentifizierungswert und vergleicht die Werte. Ändert Trudy „Pay Ana 100“ zu „Pay Ana 900“, berechnet Bob den Wert für den geänderten Text. Trudys kopierter alter Wert besteht den Vergleich nicht. Die Nachricht kann weiterhin lesbar sein: Ein MAC bietet Integrität und authentifiziert einen Schlüsselinhaber, bietet aber keine Vertraulichkeit.

HMAC verwendet eine Hashfunktion in zwei verschachtelten Durchläufen mit Schlüssel. HMAC-SHA256 ist eine Standardwahl. Einfach $H(s\mathrm{\parallel }m)$ mit SHA-256 zu verwenden, ist unsicher: Durch eine Längenerweiterung kann ein Angreifer möglicherweise Bytes anhängen und einen passenden Authentifizierungswert berechnen, ohne den Schlüssel zu erfahren. Die Konstruktion von HMAC vermeidet diesen Fehler.

Unterscheide Authentizität und Aktualität

Eine alte Nachricht mit ihrem ursprünglichen MAC hat weiterhin einen gültigen Authentifizierungswert. Um Wiederholungen zurückzuweisen, authentifiziere zusammen mit der Nachricht eine Sequenznummer oder eine neue Herausforderung und prüfe diesen Aktualitätswert beim Empfänger. Eine nicht authentifizierte Nummer hinzuzufügen genügt nicht, weil Trudy sie verändern könnte.

Beide Inhaber des gemeinsamen Schlüssels können gültige Authentifizierungswerte erzeugen. Ein Dritter kann daher anhand eines MAC nicht entscheiden, welcher Inhaber eine Nachricht geschrieben hat. Digitale Signaturen liefern diesen öffentlich überprüfbaren Nachweis. Wenn du Verschlüsselung mit einem separaten MAC kombinierst, verwende getrennte Schlüssel und berechne den MAC nach der Verschlüsselung über den Geheimtext; eine AEAD-Konstruktion bietet eine integrierte Alternative.

Eine digitale Signatur erlaubt jedem, einen mit einem privaten Schlüssel erstellten Nachweis zu prüfen. Wer prüft, benötigt sowohl eine zuverlässige Signaturprüfung als auch eine vertrauenswürdige Verbindung zwischen dem öffentlichen Schlüssel und der Identität, für die er steht.

Signiere und prüfe eine Nachricht

Der Unterzeichner verwendet einen privaten Schlüssel; wer die Signatur prüft, verwendet den passenden öffentlichen Schlüssel. Signaturen binden ihren Nachweis an die Nachricht, sodass die Prüfung bei einer Veränderung fehlschlägt. Der private Schlüssel muss unter der Kontrolle des Unterzeichners bleiben. Das unterstützt die Nichtabstreitbarkeit: einen unabhängig überprüfbaren Nachweis der Signatur, anders als bei einem MAC, den jeder Inhaber des gemeinsamen Schlüssels erzeugen könnte.

Signaturverfahren verarbeiten einen Hashwert oder eine kodierte Darstellung der Nachricht. In einem vereinfachten RSA-Modell lautet die Signatur $K_B^{-}(H(m))$. Der Empfänger berechnet den Hashwert und vergleicht ihn mit dem Wert, den er mithilfe von Bobs öffentlichem Schlüssel erhält. Tatsächliche RSA-Signaturen ergänzen eine Kodierung wie RSASSA-PSS; ECDSA und Ed25519 verwenden andere Rechenverfahren. Signieren ist kein allgemeines Verfahren, um eine Nachricht mit einem privaten Schlüssel zu verschlüsseln.

Für einen einfachen RSA-Schlüssel mit $n=143$, $e=7$ und $d=103$ sei der Hashwert 20. Bob berechnet $\sigma ={20}^{103}<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>143=58$. Alice erhält ${58}^7<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>143=20$ und vergleicht das Ergebnis mit ihrem eigenen Hashwert. Hat ein veränderter Text den Hashwert 21, stimmt der erhaltene Wert 20 nicht überein. Kollisionsresistenz ist wichtig, weil sonst zwei Nachrichten mit demselben Hashwert dieselbe Eingabe für die Signatur hätten.

Binde einen Schlüssel an einen Namen

Trudy kann ein vollkommen gültiges Schlüsselpaar erzeugen. Bezeichnet sie dessen öffentlichen Schlüssel als „Bob“, deckt eine erfolgreiche Signaturprüfung allein die Vertauschung nicht auf. Ein Zertifikat bindet eine Identität unter der Signatur einer Zertifizierungsstelle an einen öffentlichen Schlüssel.

Ein X.509-Zertifikat für eine Website enthält Domainnamen im Feld Subject Alternative Name, den öffentlichen Schlüssel des Inhabers, einen Aussteller, Gültigkeitsdaten und die Signatur des Ausstellers. Ein Server stellt normalerweise sein Endzertifikat und Zwischenzertifikate bereit. Der Client prüft diese Kette bis zu einem Wurzelzertifikat, dem sein Betriebssystem oder Browser bereits vertraut. Nicht die Selbstsignatur eines Wurzelzertifikats macht es vertrauenswürdig; seine Aufnahme in den Vertrauensspeicher liefert dieses anfängliche Vertrauen.

Bei der Prüfung werden die Signaturen entlang der Kette, die Gültigkeitsdaten, der vorgesehene Name, die erlaubte Verwendung und, soweit verfügbar, Informationen zum Widerruf kontrolliert. Eine Kette, die bei einem unbekannten Wurzelzertifikat endet, wird nicht allein deshalb vertrauenswürdig, weil ihre Signaturen mathematisch gültig sind.

Verlange einen Nachweis des Schlüsselbesitzes

Zertifikate sind öffentlich und können kopiert werden. Ein Server muss außerdem die Kontrolle über den zugehörigen privaten Schlüssel nachweisen, indem er neue Handshake-Daten signiert. Eine gestohlene Zertifikatsdatei allein kann diese Signatur nicht erzeugen. Ein gewöhnliches gültiges Website-Zertifikat bestätigt die Kontrolle über den Domainnamen; es bestätigt nicht, dass die Inhalte oder die Geschäftstätigkeit der Website ehrlich sind.

Endpunktauthentifizierung fragt, wer jetzt teilnimmt. Eine alte gültige Nachricht kann beweisen, dass jemand einmal einen Schlüssel besaß, ohne zu beweisen, dass der gegenwärtige Sender ihn besitzt.

Knacke die schwachen Versionen

Alice sendet zunächst „Ich bin Alice“. Trudy kann dieselben Worte senden. Die Ergänzung von Alices Quell-IP-Adresse schlägt fehl, weil ein Datagramm eine gefälschte Adresse enthalten kann. Das Senden eines Passworts legt es einem Beobachter offen. Die Verschlüsselung eines festen Passworts verbirgt seinen Inhalt, hinterlässt aber einen wiederverwendbaren Nachweis: Trudy zeichnet den Geheimtext auf und sendet ihn bei einer anderen Anmeldung.

Das ist ein Wiederholungsangriff. Die Angreiferin entschlüsselt oder verändert den alten Nachweis nicht. Die Schwäche besteht darin, dass Bob dieselben Bytes in einer neuen Sitzung akzeptiert. Eine stärkere Chiffre würde diesen Protokollfehler nicht beheben.

Binde den Nachweis an diesen Versuch

Bob sendet eine neue, unvorhersehbare Nonce, eine Herausforderung, die in diesem Authentifizierungskontext einmal verwendet wird. Alice gibt einen Wert zurück, für den ihr geheimer Schlüssel nötig ist, etwa einen HMAC der Herausforderung. Bob berechnet die erwartete Antwort mit seiner Kopie des Schlüssels. Eine von einer früheren Herausforderung kopierte Antwort stimmt nicht überein.

Beispielsweise lautet die Herausforderung am Montag 0x7F3A91C2. Trudy fängt die gültige Antwort darauf ab. Am Dienstag sendet Bob 0x0B66E4D9. Die Wiederholung der Antwort vom Montag schlägt fehl, weil der am Dienstag erwartete Authentifizierungswert aus anderen Bytes berechnet wird. Die kurzen Hexadezimalwerte veranschaulichen den Austausch; reale Herausforderungen benötigen genügend zufällige Bits, um brauchbare Vorhersagen oder Wiederholungen zu vermeiden.

Unvorhersehbarkeit verhindert auch das Sammeln im Voraus. Ist Bobs nächste Herausforderung leicht zu erraten, kann Trudy sich als Bob ausgeben, Alice um eine Antwort auf diese zukünftige Herausforderung bitten und die gesammelte Antwort später Bob vorlegen. Eine Herausforderung muss an den aktuellen Protokollaustausch gebunden sein und sich nicht nur von der letzten unterscheiden.

Authentifiziere mit öffentlichen Schlüsseln

Alice kann eine neue Herausforderung mit ihrem privaten Schlüssel signieren. Bob prüft die Signatur mit ihrem echten öffentlichen Schlüssel. Akzeptiert Bob einen von Trudy gelieferten Ersatzschlüssel, kann Trudy Bobs Herausforderung selbst signieren. Zertifikate stellen die Verbindung zwischen Identität und Schlüssel her; die neue Signatur beweist den aktuellen Besitz dieses Schlüssels.

Bei der gegenseitigen Authentifizierung weisen beide Gegenstellen ihre Identität nach. Ein Protokoll muss ihre Rollen unterscheiden und Nachweise an die Sitzung binden, damit die Antwort einer Seite nicht einfach als Antwort der anderen zurückgespiegelt werden kann. Gewöhnliches Web-TLS authentifiziert meist den Server mit einem Zertifikat; der Nutzer authentifiziert sich anschließend innerhalb dieses geschützten Kanals mit einem Passwort oder Passkey. Verbindungen zwischen Diensten und VPNs authentifizieren häufig beide Endpunkte.

Schütze die Kommunikation nach der Anmeldung

Eine erfolgreiche Authentifizierung schützt späteren Klartextverkehr nicht. Trudy könnte warten, bis die Anmeldung abgeschlossen ist, und dann Befehle einschleusen oder die Verbindung übernehmen. Sichere Handshakes vereinbaren Sitzungsschlüssel, und nachfolgende Nachrichten erhalten einen an diese Sitzung gebundenen Integritätsschutz.

Ein Challenge-Response-Verfahren stärkt auch ein schwaches menschliches Passwort nicht automatisch. Kann eine Beobachterin eine abgefangene Antwort für jeden Passwortversuch neu berechnen, kann sie einen Offline-Wörterbuchangriff durchführen. Die Aktualitätsprüfung verhindert Wiederholungen, während ein starkes Geheimnis oder ein geeignetes passwortauthentifiziertes Austauschverfahren dem Erraten begegnet; die beiden Schutzmaßnahmen lösen unterschiedliche Probleme.

TLS bietet zwei Anwendungsprozessen einen vertraulichen, authentifizierten Kanal über einen zuverlässigen Bytestrom. Im häufigen Fall von HTTPS verwendet HTTP TLS über TCP, normalerweise auf Port 443. Eine Anwendungsbibliothek wie OpenSSL oder BoringSSL übernimmt TLS; TCP überträgt dessen Bytes, ohne sie zu interpretieren.

Vereinbare Schlüssel und schütze dann Records

Ein Handshake authentifiziert die Gegenstelle und vereinbart gemeinsames Schlüsselmaterial. Die Schlüsselableitung erzeugt daraus getrennte Geheimnisse für den Handshake-Verkehr und die Anwendungsdaten sowie unterschiedliche Schlüssel für jede Richtung. Alices ausgehender Record kann nicht einfach als Bobs Record zurückgespiegelt werden, weil die Empfangsrichtung einen anderen Schutz verwendet.

TLS teilt Daten in Records, sodass der Empfänger jeweils ein Stück prüfen kann. Ein Klartext-Record enthält höchstens $2^{14}=16.384$ Bytes Inhalt. Sein kurzer Header enthält einen Typ, ein älteres Versionsfeld und die Länge. Verschlüsselung fügt zusätzliche Daten hinzu, sodass ein verschlüsselter Record größer als der ursprüngliche Inhalt ist. In TLS 1.3 verrät der äußere Typ eines geschützten Records nicht unmittelbar den Typ des enthaltenen Anwendungs- oder Handshake-Inhalts.

TLS 1.3 verlangt AEAD. Der Empfänger prüft den Authentifizierungswert eines Records, bevor er dessen Klartext an die Anwendung weitergibt. Verändert Trudy eine geschützte HTTP-Anfrage, schlägt die Prüfung des Werts fehl: Der Empfänger beendet die Verbindung und verwendet bad_record_mac für einen Fehler beim Record-Schutz. TLS erkennt die Manipulation; es verwandelt böswillig veränderte Bytes nicht zurück in eine gültige Anfrage.

Zähle Records in jeder Richtung

Jeder Sender und Empfänger führt eine implizite Record-Sequenznummer. Sie wird nicht im TLS-Record-Header gesendet. TLS 1.3 verknüpft sie durch XOR mit einem IV für die jeweilige Richtung, um die AEAD-Nonce zu erzeugen. Wird ein alter Record an einer neuen Position erneut gesendet, passt die erwartete Nummer nicht und die Authentifizierung schlägt fehl. Das Löschen oder Umordnen geschützter Records stört ebenso die erwartete Reihenfolge, wenn spätere Bytes verarbeitet werden.

Die TCP-Sequenznummern sorgen weiterhin für die gewöhnliche Zustellung und Wiederherstellung der Reihenfolge. Sie authentifizieren die Gegenstelle nicht: Ein Angreifer, der den Pfad kontrolliert, kann TCP-Header fälschen. Die Record-Zählung von TLS ist an den Schutz mit geheimem Schlüssel gebunden, sodass eine erfolgreiche TCP-Zustellung allein keine erfolgreiche TLS-Prüfung bedeutet.

Erkenne ein unvollständiges Ende

Angenommen, Bob erwartet ein Dokument, aber die TCP-Verbindung wird auf halbem Weg geschlossen. Ein gefälschtes FIN oder eine unterbrochene Verbindung kann die Transportzustellung beenden, ohne zu beweisen, dass der TLS-Sender fertig war. TLS verwendet die geschützte Meldung close_notify, um ein ordnungsgemäßes Ende seines Sendestroms zu signalisieren. Ohne sie muss der Empfänger ein mögliches Abschneiden berücksichtigen und die Vollständigkeitsregeln der Anwendung nutzen; ein unerwartetes TCP-EOF ist keine authentifizierte Endmarkierung.

Ein Angreifer kann Pakete jederzeit verwerfen und den Fortschritt stoppen. Vertraulichkeit und Integrität garantieren keine Verfügbarkeit. Eine vollständige HTTP-Nachrichtenlänge kann einer Anwendung helfen zu erkennen, dass eine Nachricht eingetroffen ist, aber das ist eine separate Prüfung neben dem ordnungsgemäßen TLS-Abschluss.

Unterscheide verwandte Protokolle

TLS 1.3 ist in RFC 9846 spezifiziert, der 2026 RFC 8446 ersetzte. TLS 1.2 bleibt im Einsatz; SSL 2.0/3.0 und TLS 1.0/1.1 gelten als veraltet. DTLS passt den Sicherheitsentwurf an Datagramme an. QUIC überträgt den TLS-1.3-Handshake innerhalb seines UDP-basierten Transportprotokolls und schützt anschließend QUIC-Pakete selbst; es sendet keine gewöhnlichen TLS-über-TCP-Records über UDP.

Ein TLS-Handshake muss ein Geheimnis vereinbaren und zeigen, wessen Geheimnis es ist. Bei einem vollständigen zertifikatsbasierten TLS-1.3-Austausch liefert die kurzlebige Schlüsselvereinbarung neues Schlüsselmaterial, und Signaturen binden die Aushandlung an die Identität des Servers.

Verfolge die Nachrichtenfolgen

1. ClientHello bietet Versionen, AEAD-Chiffresuiten, Schlüsselaustauschgruppen, Signaturalgorithmen, Zufallsdaten und einen oder mehrere key_share-Werte an. Üblicherweise nennt es den Server über SNI.
2. ServerHello wählt Parameter aus und liefert den Schlüsselanteil des Servers. Beide Gegenstellen berechnen gemeinsames Schlüsselmaterial und leiten Verkehrsschlüssel für den Handshake ab.
3. Der Server sendet die verschlüsselten Nachrichten EncryptedExtensions, Certificate, CertificateVerify und Finished. CertificateVerify signiert eine strukturierte Eingabe, die den Hashwert des bisherigen Handshake-Verlaufs enthält; Finished authentifiziert den Verlauf mit einem abgeleiteten MAC-Schlüssel.
4. Der Client prüft die Kette, den Servernamen, die Signatur und Finished und sendet dann sein eigenes Finished. Der Anwendungsverkehr verwendet separat abgeleitete Verkehrsgeheimnisse.

Das Zertifikat des Servers ordnet einen Namen einem öffentlichen Schlüssel zu. CertificateVerify weist die Kontrolle über den privaten Schlüssel in diesem Austausch nach. Finished erkennt Eingriffe in den Verlauf der Aushandlung. Das sind getrennte Prüfungen: Die erfolgreiche Ableitung eines gemeinsamen Geheimnisses weist die Serveridentität nicht nach.

Zähle die Umläufe

Bei einer RTT von 40 ms dauert der TCP-Aufbau ohne Verarbeitungs- und Übertragungsverzögerung 40 ms, und ein vollständiger TLS-1.3-Handshake benötigt weitere 40 ms. Der Client sendet seine Anfrage nach 80 ms; eine Antwort kann nach etwa 120 ms zurückkommen. Ein vollständiger TLS-1.2-Handshake benötigt nach TCP zwei RTTs, sodass die entsprechenden Zeiten 120 ms und 160 ms betragen. QUIC kombiniert den Transportaufbau mit dem TLS-Handshake, sodass eine neue Verbindung ihre Anfrage nach einer RTT, also nach 40 ms, senden kann.

Eine HelloRetryRequest fügt einen Umlauf hinzu, wenn der Server einen anderen Schlüsselanteil benötigt. Die gemeinsame Unterstützung einer Gruppe genügt nicht, wenn das erste Angebot keinen akzeptablen Anteil enthielt.

Binde die Aushandlung und trenne Geheimnisse

Entfernt Trudy bei der Übertragung starke Chiffresuiten aus einem ClientHello, zeichnen Client und Server unterschiedliche Verläufe auf. Die Authentifizierung dieser Verläufe schlägt fehl. TLS enthält außerdem ein Signal für die Herabstufung der Version, wenn ein dazu fähiger Server eine ältere Version aushandelt.

Die Schlüsselableitung verwendet das auf HMAC basierende HKDF, um zweckspezifische Geheimnisse abzuleiten. Handshake-Schlüssel schützen Einrichtungsnachrichten; Anwendungsschlüssel schützen spätere Daten. KeyUpdate ersetzt während einer langen Verbindung die Verkehrsschlüssel für Anwendungsdaten. TLS 1.3 hat den statischen RSA-Schlüsseltransport entfernt: Ein RSA-Zertifikat kann weiterhin einen Handshake durch Signieren authentifizieren, während eine kurzlebige Schlüsselvereinbarung Vorwärtsgeheimnis bietet.

Nimm eine Verbindung ohne erneute Zertifikatsauthentifizierung auf

Nach dem Aufbau ermöglicht NewSessionTicket den Gegenstellen, die Wiederaufnahme vorzubereiten. Sie leiten aus dem Wiederaufnahmegeheimnis und der Ticket-Nonce einen Wiederaufnahme-PSK ab; der Client legt später das Ticket als Kennung des PSK vor und weist den Besitz dieses PSK nach. Die Wiederaufnahme kann für Vorwärtsgeheimnis einen neuen Diffie-Hellman-Austausch enthalten.

0-RTT sendet frühe Daten mit der ersten Nachrichtenfolge, aber diese Daten können erneut gesendet werden. Verwende es nur dort, wo die Wiederholung einer Anfrage unbedenklich ist, niemals für eine ungeschützte wiederholbare Zahlungsaktion. Der Schutz des späteren Handshakes macht frühe Daten nicht nachträglich gegen Wiederholung sicher.

Gegenseitiges TLS ergänzt ein angefordertes Clientzertifikat und einen Nachweis des zugehörigen privaten Schlüssels. Hybride Post-Quanten-Gruppen wie X25519MLKEM768, definiert in RFC 10024, kombinieren X25519 und ML-KEM-768, sodass die Geheimhaltung bestehen bleibt, wenn mindestens eine der Komponenten sicher bleibt.

Verschlüsselung ist nur nützlich, wenn sie die beabsichtigte Gegenstelle erreicht. Ein Client muss die Identität hinter den Schlüsseln prüfen, bevor er vertrauliche Anwendungsdaten sendet.

Prüfe die gesamte Identitätsangabe

Ein TLS-Client prüft, ob die Zertifikatskette ein Wurzelzertifikat in seinem Vertrauensspeicher erreicht, ob Signaturen und Gültigkeitszeiträume die Prüfung bestehen, ob der angefragte Name zum Zertifikat passt und ob das Zertifikat die TLS-Serverauthentifizierung erlaubt. Prüft er den Widerruf, muss auch diese Prüfung bestanden werden. CertificateVerify weist anschließend den Besitz des zugehörigen privaten Schlüssels nach.

Beim Namensabgleich geht es um den Host, den der Client kontaktieren wollte, nicht um einen Namen, den der Server nach dem Verbindungsaufbau vorschlägt. Ein Zertifikat für *.example.com deckt www.example.com und mail.example.com ab. Es deckt weder example.com noch a.b.example.com ab: Der Platzhalter ersetzt genau eine Namenskomponente. Ein völlig gültiges Zertifikat für die falsche Domain besteht die Authentifizierung dennoch nicht.

Ein Client fragt beispielsweise shop.example.net an, erhält aber ein vertrauenswürdiges, aktuell gültiges Zertifikat für *.example.com. Die Kette und die Datumsprüfung können erfolgreich sein; der Namensabgleich schlägt fehl. Der Client muss diese Verbindung zurückweisen. Ein Zertifikat berechtigt seinen Inhaber nicht allgemein dazu, sich als beliebiger Server auszugeben.

Verstehe verschlüsseltes Abfangen

Ist die Zertifikatsprüfung deaktiviert, kann Trudy die TLS-Verbindung vom Client beenden und eine zweite TLS-Verbindung zum echten Server aufbauen. Beide Verbindungen sind verschlüsselt, aber Trudy hat dazwischen Zugriff auf den Klartext. Wer nur die Verschlüsselung und nicht die Gegenstelle prüft, übersieht daher den Angriff. Lass die Zertifikatsprüfung aktiviert und behandle eine fehlgeschlagene Identitätsprüfung als fehlgeschlagene Verbindung.

Ein Proxy zur TLS-Untersuchung in einer Organisation folgt gezielt einem verwandten Aufbau. Verwaltete Geräte vertrauen dem Wurzelzertifikat der Organisation, sodass ihr Proxy Zertifikate ausstellen kann, die sie akzeptieren. Der Proxy beendet eine sichere Verbindung und baut eine andere auf. Der Pfad vom Browser zum Server enthält dann einen zusätzlichen vertrauenswürdigen Endpunkt mit Zugriff auf Klartext.

Schütze die erste Anfrage

Beim SSL-Stripping hält ein Angreifer die Seite des Nutzers bei HTTP, während er die Website über HTTPS kontaktiert. Das kann beginnen, wenn ein Browser eine Adresse ohne Protokoll zunächst über HTTP aufruft. HSTS weist einen Browser an, bei späteren Besuchen HTTPS zu verwenden. Ein vorinstallierter Eintrag kann HTTPS schon vor dem ersten Besuch erzwingen; eine erst nach einem erfolgreichen HTTPS-Besuch gelernte Richtlinie kann eine frühere HTTP-Anfrage nicht nachträglich schützen.

Erkenne, was sichtbar bleibt

TLS 1.3 verschlüsselt das Serverzertifikat und die Anwendungsinhalte, aber Beobachter sehen weiterhin Netzwerkadressen, Ports, zeitlichen Ablauf und Record-Größen. Das gewöhnliche SNI im ClientHello legt den angefragten Servernamen offen. Encrypted Client Hello, standardisiert in RFC 9849, schützt diesen Namen, wenn es eingesetzt wird. Auch eine nicht separat geschützte DNS-Abfrage kann den Zielnamen verraten.

TLS schützt Daten während der Übertragung zwischen seinen Endpunkten. Es kann Schadsoftware auf dem Client, einen kompromittierten Server, unsicher gespeicherte Daten oder Anwendungsschwachstellen nicht beheben. Auch das Verwerfen von Paketen kann es nicht verhindern. IPsec hat einen anderen Schutzbereich: Es schützt ausgewählten IP-Verkehr auf der Vermittlungsschicht, ohne dass jede Anwendung TLS aufrufen muss. Werden beide verwendet, können sie unterschiedliche Abschnitte desselben Pfades schützen.

IPsec schützt auf der IP-Schicht und kann dort TCP-, UDP- und ICMP-Verkehr abdecken, ohne deren Anwendungen zu ändern. Seine Endpunkte können einzelne Hosts oder Gateways sein, die ganze Netze verbinden.

Wähle Protokoll und Modus

AH verwendet die IP-Protokollnummer 51; ESP verwendet 50. ESP ist die übliche Wahl für modernen VPN-Verkehr. Der Schutz von AH umfasst Adressfelder, die NAT umschreibt, sodass gewöhnliche Adressübersetzung mit seiner Authentifizierungsprüfung unvereinbar ist. ESP authentifiziert den äußeren IP-Header nicht.

Im Transportmodus liegt der ESP-Header zwischen dem ursprünglichen IP-Header und dem Transportsegment. Router sehen weiterhin die ursprüngliche Quelle und das ursprüngliche Ziel. Im Tunnelmodus adressiert ein neuer IP-Header die beiden Tunnelendpunkte, und das ursprüngliche IP-Datagramm wird darin übertragen. Bei verschlüsseltem ESP im Tunnelmodus können außenstehende Beobachter die Adressen der ursprünglichen Hosts und die Transportports nicht lesen, wohl aber die für die Weiterleitung benötigten Adressen der Gateways. AH im Tunnelmodus bietet weiterhin keine Vertraulichkeit.

IPsec kann Vertraulichkeit, Integrität, Authentifizierung des Ursprungs und Schutz vor Wiederholungsangriffen bieten. Die tatsächlichen Dienste hängen von Protokoll, Algorithmen und Richtlinie ab; die Wahl von AH bietet nicht schon deshalb Verschlüsselung, weil es zu IPsec gehört.

Verwalte Zustandsinformationen für jede Richtung

Eine Sicherheitsassoziation, kurz SA, definiert eine Richtung des geschützten Verkehrs. Sie enthält Algorithmen, Schlüssel, Modus, Endpunkte, Sequenzzustand, Zustand des Anti-Replay-Fensters und eine Lebensdauer. Ein 32-Bit-Security Parameter Index, kurz SPI, hilft dem Empfänger, die richtige SA auszuwählen. Er ist eine Kennung, kein Verschlüsselungsschlüssel, und kann offen im ESP-Header übertragen werden.

Verkehr in beide Richtungen benötigt zwei IPsec-SAs. Ein Gateway der Zentrale, das eine Zweigstelle und 50 reisende Laptops versorgt, hat 51 Gegenstellen. Bei einem ESP-Paar pro Gegenstelle benötigt es $2\times 51=102$ ESP-SAs sowie eine IKE-SA pro Gegenstelle für die Verwaltung. Schlüsselerneuerung oder getrennte Verkehrsklassen können weitere SAs hinzufügen; die Anzahl hier folgt dem angegebenen Aufbau mit einem Paar pro Gegenstelle.

Obwohl IP-Weiterleitung verbindungslos ist, wird dieser kryptografische Zustand an den schützenden Endpunkten verwaltet. Router dazwischen müssen weder die Sitzungsschlüssel kennen noch die IPsec-SA verwalten.

Trenne Richtlinie und aktiven Schutzzustand

Die Security Policy Database (SPD) gleicht Verkehrsmerkmale wie Adressen, Protokolle und Ports ab. Sie entscheidet, ob ausgewählter Verkehr geschützt wird, den Schutz umgeht oder verworfen wird. Die Security Association Database (SAD) speichert die Parameter und den sich ändernden Zustand eingerichteter SAs. Ein Empfänger nutzt den SPI des Pakets und den relevanten Kontext, um diesen Zustand zu finden.

Die SPD beantwortet „Was soll mit diesem Verkehr geschehen?“. Die SAD beantwortet „Welche eingerichteten Schlüssel und Zähler setzen diesen Schutz um?“. Eine VPN-Richtlinie kann Büro-Subnetze schützen und ein anderes Ziel den Schutz umgehen lassen. Aktiviertes IPsec bedeutet nicht, dass jedes von einem Host gesendete Paket in einen Tunnel gelangt.

Ein Standort-VPN verbindet zwei Netze über Gateways; ein Fernzugriffs-VPN verbindet das Gerät eines Nutzers mit einem Gateway. Beide kapseln Verkehr, sodass gewöhnliche Internetrouter ihn zwischen den schützenden Endpunkten übertragen können.

Richte die Assoziationen ein

IKEv2 richtet Schlüssel und SAs ein. IKE_SA_INIT tauscht Algorithmusvorschläge, Diffie-Hellman-Werte und Nonces aus. Die entstehenden Schlüssel schützen IKE_AUTH, wo die Gegenstellen ihre Identitäten authentifizieren und das erste Paar von ESP-SAs erzeugen. Mit Signaturen oder einem vorab geteilten Schlüssel benötigt dies normalerweise vier Nachrichten in zwei Umläufen. EAP-Authentifizierung kann IKE_AUTH-Austausche hinzufügen. Spätere Austausche erzeugen weitere SAs oder ersetzen ablaufende Schlüssel.

IKE verwendet zunächst UDP-Port 500. Wird NAT erkannt, verwenden IKE und in UDP gekapseltes ESP Port 4500. ESP selbst hat keine TCP- oder UDP-Ports; die Kapselung ermöglicht die zuverlässige Übertragung über portbasierte NAT-Zuordnungen, auch für mehrere Clients. Der äußere Transport ändert sich, während ESP weiterhin den inneren Verkehr schützt.

Sende ein Datagramm

Host 10.1.0.5 sendet an 10.2.0.9. Das Gateway der Zweigstelle ist 198.51.100.1; die Zentrale verwendet 203.0.113.1.

1. Die SPD der Zweigstelle wählt den Tunnelschutz für das Zielsubnetz, und das Gateway beschafft die passende SA.
2. Es behandelt das vollständige ursprüngliche Datagramm als innere ESP-Nutzlast und ergänzt einen Trailer mit Auffüllung, Auffüllungslänge und nächstem Header 4 für IPv4.
3. Es verschlüsselt das innere Datagramm und den Trailer und ergänzt den ESP-Header mit dem SPI und der nächsten Sequenznummer. Der Integritätsschutz umfasst den ESP-Header und die geschützte Nutzlast; ein AEAD-Algorithmus verbindet Verschlüsselung und Erzeugung des Authentifizierungswerts.
4. Es ergänzt den äußeren IP-Header, der vom Gateway der Zweigstelle an das Gateway der Zentrale adressiert ist. Natives ESP verwendet Protokoll 50; NAT-Traversal überträgt ESP innerhalb von UDP.

Internetrouter sehen die äußeren Endpunktadressen. Die internen Adressen und Ports befinden sich innerhalb der verschlüsselten Nutzlast.

Empfange und authentifiziere

Die Zentrale wählt anhand des SPI eine SA aus, prüft vorläufig die Sequenznummer, überprüft die Integrität und entschlüsselt. Sie aktualisiert den vertrauenswürdigen Zustand für den Wiederholungsschutz erst nach erfolgreicher Authentifizierung. Sie entfernt den Tunnelschutz und leitet das wiederhergestellte ursprüngliche Datagramm an 10.2.0.9 weiter. Das Feld für den nächsten Header identifiziert die wiederhergestellte Nutzlast: 4 für IPv4, 41 für IPv6 oder 6 für TCP in einem ESP-Beispiel im Transportmodus.

Erlaube Umordnung, aber weise Wiederholungen zurück

Ein Anti-Replay-Fenster für 64 Pakete mit der höchsten authentifizierten Nummer 1000 reicht von 937 bis 1000. Das noch nicht gesehene Paket 990 kann verspätet eintreffen und akzeptiert werden. Seine nächste Kopie wird zurückgewiesen. Paket 930 ist zu alt. Ein gültiges Paket 1005 verschiebt den Bereich auf 942 bis 1005. Ein Angreifer kann das vertrauenswürdige Fenster nicht einfach verschieben, indem er ein nicht authentifiziertes Paket mit einer großen Nummer sendet.

Ein VPN schützt nur den Pfad zwischen seinen Endpunkten. Nach dem Entfernen des Tunnelschutzes benötigt die interne Zustellung bei Bedarf eigenen Schutz. Split-Tunneling sendet einen Teil des Verkehrs außerhalb des VPN. Bei einem kommerziellen VPN wird dessen Anbieter zu einem weiteren Netzbetreiber, dem man vertrauen muss. TLS-/DTLS-basierte VPNs und WireGuard verwenden andere Protokolle zur Umsetzung von Tunneln; „VPN“ bezeichnet die Netzstruktur, nicht ein vorgeschriebenes Verschlüsselungsprotokoll.

Ein WLAN-Datenrahmen ist für Funkgeräte in Reichweite empfangbar. Ein Angreifer in der Nähe kann Verkehr abfangen oder einen Evil Twin bekannt machen, einen gefälschten Access Point mit einem vertrauten Netzwerknamen. WLAN-Sicherheit muss den Zugang authentifizieren und Datenrahmen schützen; es genügt nicht, den Netzwerknamen zu verbergen.

Warum WEP scheiterte

WEP kombinierte ein gemeinsames 40- oder 104-Bit-Geheimnis mit einem öffentlichen 24-Bit-IV, um RC4 zu initialisieren. Seine CRC-32-Prüfung erkannte Fehler, war aber kein Authentifizierungsmechanismus mit Schlüssel. Der IV-Raum hat nur $2^{24}=\mathrm{16.777.216}$ Möglichkeiten; bei zufällig gewählten IVs beträgt die Wahrscheinlichkeit einer Wiederholung nach ungefähr 4.823 Datenrahmen etwa 50 %.

Ein wiederholter IV unter demselben Schlüssel wiederholt den Schlüsselstrom. Die XOR-Verknüpfung zweier Geheimtexte legt dann die XOR-Verknüpfung der Klartexte offen. Die lineare Struktur von CRC-32 erlaubt es einem Angreifer außerdem, Bits zu verändern und die Fehlerprüfung anzupassen. Die schwache Schlüsselinitialisierung von RC4 ermöglichte die Rekonstruktion des Schlüssels aus abgefangenen Datenrahmen. Diese Fehler betreffen die Wiederverwendung von Nonces, nicht authentifizierte Integritätsprüfung und den Aufbau der Chiffre; ein weniger auffälliger Netzwerkname behebt keinen davon.

Ersetze den Schutz der Datenrahmen

WPA2 auf Basis von IEEE 802.11i verwendet CCMP: AES-Verschlüsselung im Zählermodus in Kombination mit CBC-MAC für Integrität. Die Paketnummer hilft dabei, einzigartige Nonces zu bilden und Wiederholungen zurückzuweisen. Das frühere WPA/TKIP war eine Übergangsmaßnahme für alte Hardware und gilt als veraltet.

Die Verbindung durchläuft die Entdeckung, die Authentifizierung zur Einrichtung eines paarweisen Hauptschlüssels (PMK), den Vier-Wege-Handshake und die geschützte Übertragung. Bei WPA2-Personal erzeugen eine Passphrase und der Netzwerkname einen 256-Bit-PMK durch PBKDF2 mit 4.096 HMAC-SHA1-Iterationen. Jeder, der diese Passphrase und SSID verwendet, leitet denselben PMK ab. Die Authentifizierung hat noch keinen neuen Verkehrsschlüssel für die einzelne Assoziation geliefert.

Verfolge den Vier-Wege-Handshake

1. Der Access Point sendet ANonce.
2. Die Station erzeugt SNonce und leitet den PTK aus dem PMK, beiden Nonces und beiden MAC-Adressen ab. Sie sendet SNonce und einen Nachrichtenintegritätscode (MIC).
3. Der Access Point leitet denselben PTK ab und prüft den MIC. Er stellt den Gruppenverkehrsschlüssel (GTK) in einer geschützten Nachricht bereit.
4. Die Station bestätigt Empfang und Installation.

Der PMK wird im Handshake nicht gesendet. Neue Nonces erzeugen aus dem vorhandenen PMK neue Sitzungsschlüssel. Der GTK dient dem Gruppenverkehr, während der paarweise Schlüssel der Kommunikation zwischen dieser Station und dem Access Point dient.

Erkenne, was das Passwort ermöglicht

Ein abgefangener WPA2-Personal-Handshake ermöglicht Passwortversuche offline: Leite einen möglichen PMK und PTK ab, berechne den MIC erneut und vergleiche ihn mit dem abgefangenen Wert. Ein Nutzer, der die Netzwerkpassphrase bereits kennt, kann aus dem abgefangenen Handshake eines anderen Nutzers auch dessen PTK ableiten. KRACK nutzte die erneute Installation von Schlüsseln und die Wiederverwendung von Nonces in Implementierungen aus; Sicherheitsaktualisierungen beheben diesen Fehler.

WPA2-Enterprise verwendet 802.1X. Die Station ist der Supplicant; der Access Point ist der Authenticator und leitet EAP an einen Authentifizierungsserver weiter, meist über RADIUS. EAP-TLS verwendet Clientzertifikate; PEAP und EAP-TTLS übertragen Zugangsdaten innerhalb des TLS-Schutzes. Nutzer erhalten individuelles Schlüsselmaterial, und ihr Zugang kann einzeln widerrufen werden. In beiden Modi endet der WLAN-Schutz am Access Point; TLS kann den Schutz bis zu einem Anwendungsserver fortsetzen.

Eine geschützte Funkverbindung benötigt ein zuverlässiges Verfahren zur Schlüsselvereinbarung. WPA3 verändert die passwortbasierte Schlüsselvereinbarung im WLAN, während Mobilfunknetze mit einem Teilnehmergeheimnis beginnen, das auf der SIM und im Heimatnetz gespeichert ist.

Verbessere passwortbasiertes WLAN

WPA3-Personal verwendet SAE, Simultaneous Authentication of Equals, um den PMK zu vereinbaren. Ein abgefangener SAE-Austausch bietet keinen Offline-Passworttest wie bei WPA2: Jeder Versuch benötigt eine aktive Interaktion. SAE bietet außerdem Vorwärtsgeheimnis, sodass die spätere Kenntnis des Passworts aufgezeichnete vergangene Sitzungen nicht offenlegt. Der Vier-Wege-Handshake leitet dann Verkehrsschlüssel aus dem PMK ab.

WPA3 verlangt geschützte Verwaltungsrahmen (PMF), die robuste Verwaltungsrahmen wie Deauthentifizierungsnachrichten authentifizieren. Das blockiert gefälschte Nachrichten zum Verbindungsabbau; Funkstörungen kann es nicht verhindern. WPA3-Enterprise behält 802.1X bei und bietet einen optionalen Sicherheitsmodus mit 192 Bit und stärkeren Algorithmen wie GCMP-256.

Der Übergangsmodus akzeptiert WPA2 und WPA3 unter einem Netzwerknamen. Seine Kompatibilität kann Geräte dem schwächeren WPA2-Verfahren aussetzen. Beim Betrieb mit 6 GHz ist WPA3 oder Enhanced Open erforderlich, und der WPA2-Übergangsmodus ist nicht erlaubt; WPA3-Personal verwendet die Hash-to-Element-Methode von SAE.

Enhanced Open, das auf OWE basiert, richtet Verschlüsselung ohne Passwort durch Diffie-Hellman ein. Es verhindert, dass passive Mithörer Datenrahmen lesen, authentifiziert aber den Hotspot nicht. Ein Evil Twin kann eine eigene verschlüsselte Verbindung mit dem Nutzer aufbauen.

Authentifiziere einen Mobilfunkteilnehmer

Ein langfristiges Geheimnis $K$ liegt auf der USIM und in der Authentifizierungsinfrastruktur des Heimatnetzes: HSS bei 4G und UDM/ARPF bei 5G. Ein besuchtes Netz erhält Authentifizierungsmaterial, ohne dieses langfristige Geheimnis zu erfahren.

Bei 4G AKA erhält die MME des besuchten Netzes vom HSS des Heimatnetzes einen Vektor mit RAND, AUTN, XRES und Schlüsselmaterial. Das Mobiltelefon empfängt die zufällige Herausforderung RAND und das Authentifizierungstoken AUTN. Seine USIM prüft AUTN, um das Netz und die Aktualität zu authentifizieren, und berechnet dann RES. Das besuchte Netz akzeptiert den Teilnehmer, wenn RES mit XRES übereinstimmt. Abgeleitete Schlüssel schützen die spätere Kommunikation.

Das ist gegenseitige Authentifizierung. Das frühere 2G GSM authentifizierte das Mobiltelefon gegenüber dem Netz, gab dem Mobiltelefon aber keine entsprechende Möglichkeit, das Netz zu prüfen. Das ermöglichte Angriffe mit gefälschten Basisstationen. Gegenseitige Authentifizierung benötigt weiterhin sichere Algorithmen und korrekte Schlüsselverwaltung; das langfristige Geheimnis muss nie an das besuchte Netz gesendet werden.

Verbirg die dauerhafte Identität

Bei 5G trifft das Heimatnetz die endgültige Authentifizierungsentscheidung. Das Mobiltelefon kann außerdem den teilnehmerspezifischen Teil seiner dauerhaften Identität, der SUPI, mithilfe des öffentlichen Schlüssels des Heimatnetzes verbergen und so die SUCI bilden. Routinginformationen bleiben lesbar, damit die Anfrage das richtige Heimatnetz erreichen kann.

Die Verschleierung benötigt ein eingerichtetes Schutzverfahren. Das Nullverfahren lässt die Identität ungeschützt. Eine geschützte SUCI verringert die Offenlegung gegenüber Geräten, die dauerhafte Identitäten anfordern; sie macht nicht jede Funkaktivität anonym. Nach der Registrierung verringern temporäre Kennungen die alltägliche Verwendung der dauerhaften Identität. Die Sicherheit des Mobilfunkzugangs schützt weiterhin nicht den gesamten Pfad zu einem App-Server: TLS bietet diesen separaten Schutz zwischen den Anwendungsendpunkten.

Eine Firewall setzt eine Richtlinie zwischen Netzen oder Netzsegmenten durch. Sie funktioniert nur, wenn der relevante Verkehr sie passiert, und die Firewall selbst muss einer Kompromittierung standhalten. Ein zustandsloser Filter entscheidet für jedes Paket anhand seiner Headerfelder neu.

Lies eine Regel genau

Eine Regel kann Quell- und Ziel-IP-Adressen, Transportprotokoll, Ports, TCP-Flags, ICMP-Typ, Schnittstelle und Richtung abgleichen. Die Regeln werden der Reihe nach geprüft: Die erste zutreffende Regel entscheidet. Ein abschließendes Default Deny verwirft Pakete, auf die keine erlaubende Regel zutraf.

Betrachte für das Netz 203.0.113.0/24 einen Webserver unter 203.0.113.10:

Ein SYN von 198.51.100.7:50000 an Port 443 des Webservers entspricht Regel 1. Ein SYN an seinen Port 22 erreicht Regel 3 und wird verworfen. Eine Antwort von Port 443 des Servers mit gesetztem ACK entspricht Regel 2. Jedes Feld einer Regel ist wichtig: Ein Paket mit UDP-Port 443 entspricht keiner erlaubenden Regel für TCP.

Finde verdeckte Regeln

Angenommen, eine frühere Regel lautet „eingehendes TCP an jeden Host in 203.0.113.0/24 auf jedem Port erlauben“. Eine spätere Regel, die SSH an 203.0.113.10 verbietet, hat keine Wirkung: Die frühere allgemeine Erlaubnis hat bereits entschieden. Prüfe neben dem Wortlaut jeder Regel auch die Reihenfolge. Setze beabsichtigte Ausnahmen vor die allgemeine Regel, die sonst auf sie zutreffen würde.

Default Deny ist nützlich, weil ein neuer Dienst durch seine Einrichtung nicht stillschweigend erreichbar wird. Eine standardmäßige Erlaubnis hat die entgegengesetzte Folge: Jeder Verkehr, der nicht ausdrücklich blockiert ist, wird durchgelassen. Keine der beiden Standardeinstellungen korrigiert eine falsch geordnete Regeltabelle.

Erkenne die ACK-Abkürzung

Eine Richtlinie kann eingehende SYN-Pakete mit nicht gesetztem ACK blockieren, um neue, von außen aufgebaute TCP-Verbindungen zu verhindern. Um Antworten an interne Clients zuzulassen, könnte ein zustandsloser Filter eingehendes TCP von Quellport 443 bei gesetztem ACK erlauben. Trudy kann sowohl diesen Quellport als auch dieses Flag in Paketen setzen. Der Filter hat keine gespeicherten Informationen darüber, ob ein interner Host die Verbindung tatsächlich geöffnet hat.

Ein TCP-ACK-Flag ist ein Feld, das der Sender setzt, kein Nachweis einer aufgebauten Sitzung. Zustandsbehaftete Filterung verbessert diese Entscheidung, indem sie den Verbindungsverlauf berücksichtigt.

Filtere gefälschte Adressen

Eingangsfilterung kann Pakete von der Internetseite zurückweisen, die eine interne Quelladresse oder eine private Adresse angeben, die dort nicht eintreffen sollte. Ausgangsfilterung weist ausgehende Pakete zurück, deren Quelle außerhalb der der Organisation zugewiesenen Bereiche liegt. Diese Prüfungen begrenzen die Fälschung unzulässiger Adressbereiche; sie identifizieren keinen einzelnen Host und verhindern nicht, dass ein Rechner eine andere erlaubte interne Adresse vortäuscht.

Zustandslose Filter prüfen Header, nicht die Bedeutung von Anwendungsdaten. Port 443 beweist nicht, dass der Verkehr HTTPS oder harmlos ist. Eine erlaubte Verbindung kann bösartige Inhalte übertragen. Paketfilterung arbeitet daher mit Anwendungsgateways, Endpunktkontrollen und Angriffserkennung zusammen.

Eine zustandsbehaftete Firewall ergänzt die Paketfilterung um Kontext. Ein Anwendungsgateway ergänzt das Verständnis für die Anfragen einer Anwendung. Die Trennung von Netzen begrenzt, was ein kompromittierter öffentlicher Server erreichen kann.

Verfolge den tatsächlichen Datenstrom

Ein zustandsbehafteter Paketfilter speichert Adressen, Ports, Protokoll und Verbindungszustand. Öffnet ein interner Client eine erlaubte Verbindung, erstellt die Firewall einen Eintrag und erlaubt passende Antwortpakete. Eine neue eingehende Verbindung benötigt weiterhin eine eigene ausdrückliche Erlaubnis. Einträge laufen ab, wenn die Verbindung geschlossen wird oder inaktiv ist.

Angenommen, die Tabelle enthält einen aufgebauten TCP-Datenstrom von 203.0.113.25:51000 nach 198.51.100.80:443. Ein eingehendes Segment mit umgekehrtem Adress- und Portpaar kann zu diesem Zustand passen. Ein ACK von 192.0.2.66:443 an 203.0.113.30:52000 passt nicht zu dem Eintrag. Sein Quellport und sein ACK-Flag würden eine großzügige zustandslose Antwortregel erfüllen, belegen aber nicht, dass es zur verfolgten Verbindung gehört.

UDP hat keinen Verbindungsaufbau wie TCP. Zustandsbehaftete Filter bilden einen Austausch näherungsweise ab, indem sie kürzlich verwendete Adress- und Portpaare mit einem Zeitlimit verfolgen. Eine DNS-Anfrage an einen gewählten Server eröffnet eine begrenzte Möglichkeit für die zugehörige Antwort, erlaubt aber nicht jedes Paket, das vorgibt, DNS zu sein.

Untersuche die Anwendungsanfrage

Ein Anwendungsgateway oder Proxy empfängt und verarbeitet Anwendungsverkehr im Auftrag der Nutzer. Ein Webproxy kann einen Nutzer authentifizieren und eine angefragte Adresse oder Inhalte anhand der Richtlinie prüfen. Um diesen Weg durchzusetzen, muss der Paketfilter Clients daran hindern, direkte Verbindungen am Proxy vorbei aufzubauen.

Ein Proxy verfügt über protokollspezifische Logik, verursacht Verarbeitungsaufwand und kann zum Engpass werden. Clients müssen möglicherweise konfiguriert werden, oder das Netz fängt den Verkehr transparent ab. Verschlüsselte Inhalte bleiben für einen Proxy verborgen, sofern er die TLS-Verbindung nicht beendet und eine weitere Verbindung aufbaut. Dadurch ändert sich, welchen Endpunkten Klartext anvertraut wird.

Isoliere öffentliche Server

Eine DMZ ist ein separates Segment für öffentliche Dienste. Die Firewall erlaubt ausgewählten Verkehr aus dem Internet in die DMZ und beschränkt gleichzeitig den Zugriff aus der DMZ auf das interne Netz. Wird ein Webserver kompromittiert, erhält der Angreifer nicht automatisch uneingeschränkten internen Zugriff. Für jede erforderliche Verbindung von der DMZ nach innen sollte eine spezifische Richtlinie gelten.

Das ist Tiefenverteidigung: Mehrere Schutzmaßnahmen begrenzen unterschiedliche Wege, auf denen ein Angriff gelingen kann. Eine Host-Firewall bleibt wichtig, wenn ein infizierter Laptop bereits im Netz ist oder eine andere Verbindung die Netzgrenze umgeht. Ein Zero-Trust-Ansatz gewährt keinen Zugriff allein deshalb, weil sich ein Gerät in einem internen Subnetz befindet; er authentifiziert und autorisiert Anfragen. Der Standort im Netz kann in die Richtlinie einfließen, Identitäts- und Berechtigungsprüfungen aber nicht ersetzen.

Eine Firewall kann eine Verbindung erlauben, die einen Angriff überträgt. Die Angriffserkennung untersucht Verkehrsinhalte und -muster auf Anzeichen von Missbrauch; die Angriffsverhinderung kann unmittelbar auf diese Befunde reagieren.

Wähle Erkennung und Platzierung

Ein IDS beobachtet gewöhnlich eine Kopie des Verkehrs und gibt Warnungen aus. Ein IPS liegt direkt im Übertragungsweg und kann verdächtigen Verkehr verwerfen. Diese Platzierung ermöglicht sofortiges Blockieren, verursacht aber zusätzliche Verarbeitungsverzögerung und kann bei einer falschen Erkennung die legitime Nutzung unterbrechen.

Snort und Suricata sind Beispiele für Systeme, die Signaturen einsetzen können. Eine Regel könnte den Anfragepfad ../../etc/passwd, mehr als 20 neue Verbindungen zum SSH-Port 22 von einer Quelle innerhalb einer Minute oder SYNs an Hunderte Ports erkennen. Diese Muster weisen auf verdächtiges Verhalten hin; eine Übereinstimmung allein beweist keinen erfolgreichen Einbruch.

Eine Anomalieerkennung könnte eine große Änderung der Verkehrsrate oder des Protokollmixes markieren. Auch ein neuer legitimer Sicherungsauftrag kann ungewöhnlich aussehen. Ein falsch positiver Befund ist eine Warnung bei harmloser Aktivität; ein falsch negativer Befund ist ein Angriff, den die Erkennung übersieht. Eine Änderung des Empfindlichkeitsschwellenwerts tauscht gewöhnlich eine Fehlerart gegen die andere ein.

Berechne, was eine Warnung bedeutet

Betrachte 1.000.000 harmlose Verbindungen und 10 Angriffe pro Tag. Eine Erkennung findet 99 % der Angriffe und gibt bei 0,1 % der harmlosen Verbindungen fälschlich eine Warnung aus.

1. Erwartete zutreffende Warnungen: $10\times \mathrm{0,99}=\mathrm{9,9}$.
2. Erwartete falsche Warnungen: $\mathrm{1.000.000}\times \mathrm{0,001}=1.000$.
3. Erwarteter Anteil zutreffender Warnungen: $\mathrm{9,9}\mathrm{/}(\mathrm{9,9}+1.000)\approx \mathrm{0,0098}$, also etwa 1 %.

Dies sind erwartete Anzahlen über viele Tage hinweg, daher muss 9,9 kein ganzzahliges Tagesergebnis sein. Die Erkennungsrate von 99 % ist der Anteil erkannter Angriffe, nicht die Wahrscheinlichkeit, dass eine Warnung einen Angriff betrifft. Seltene Angriffe und eine große Zahl harmloser Verbindungen erklären den Unterschied: Das ist das Basisratenproblem.

Platziere Sensoren dort, wo sie sehen können

Sensoren direkt hinter der Firewall beobachten Verkehr, der sie passiert hat. Sensoren in der DMZ beobachten den Verkehr öffentlicher Dienste; interne Sensoren können Angriffe aufdecken, die die Netzgrenze nie überschreiten. Ein Sensor muss den empfangenen Verkehr bewältigen. Er muss außerdem Fragmente und TCP-Segmente genauso wie das Ziel zusammensetzen; andernfalls kann ein auf Pakete verteilter Angriff einer Musterprüfung entgehen.

TLS und IPsec verbergen verschlüsselte Nutzlasten vor einem Netzwerksensor ohne Zugriff auf die Entschlüsselung. Adressen, Ports, zeitlicher Ablauf, Längen und unverschlüsselte Handshake-Felder können weiterhin helfen. Die Nutzlast kann an einem Endpunkt untersucht werden, an dem die Entschlüsselung stattfindet, aber ein gewöhnlicher kopierter verschlüsselter Datenstrom liefert diesen Klartext nicht.

Ein Honeypot ist ein Lockvogelsystem ohne vorgesehene gewöhnliche Nutzer. Ein Kontakt ist daher verdächtig und kann Scan- oder Angriffstechniken bei weniger störendem Hintergrundverkehr aufdecken. Falsch konfigurierte Clients oder harmloser automatisierter Verkehr können ihn dennoch kontaktieren, sodass ein Lockvogelsystem nicht jede Warnung eindeutig macht.