Bestandteile
In dieser interaktiven Lerneinheit lernst du die wichtigsten Protokolle und Komponenten von IPsec im Detail kennen. Du verstehst die Funktionsweise von Authentication Header (AH) und Encapsulating Security Payload (ESP) sowie deren Rolle bei der sicheren Datenübertragung. Diese Grundlagen sind essentiell für die spätere Konfiguration und Fehlersuche in IPsec-Implementierungen.
Einführung
Stell dir vor, jemand gelangt in den Besitz deines privaten Schlüssels für verschlüsselte Kommunikation. Mit diesem Zugang könnte er nicht nur frühere Nachrichten entschlüsseln – sondern auch zukünftige, sobald sie versendet werden.
Genau dieses Risiko besteht in vielen Netzwerken – insbesondere dann, wenn Sicherheitsrichtlinien unklar sind oder Perfect Forward Secrecy fehlt. Letzteres bezeichnet eine Schutzmaßnahme, die verhindert, dass vergangene Sitzungen nachträglich entschlüsselt werden können, selbst wenn ein Schlüssel kompromittiert wurde.
In dieser Lerneinheit erfährst du, wie das Sicherheitsprotokoll IPsec solche Schwachstellen absichert – mithilfe von Authentifizierung, Verschlüsselung und verbindlichen Sicherheitsvereinbarungen.
Lernziele
Nach dieser Lerneinheit kannst du:
- den Zweck und die Funktionsweise des Authentication Header (AH) und Encapsulating Security Payload (ESP) beschreiben – inklusive deren Stärken und Schwächen.
- den Ablauf von IKE Phase 1 und 2 erklären und verstehen, wie Schlüssel durch Diffie-Hellman (DH) sicher ausgetauscht werden.
- Perfect Forward Secrecy (PFS) verständlich erläutern und begründen, warum PFS ein wichtiges Sicherheitsmerkmal ist.
- die Aufgaben von SA, SPD und SAD in IPsec-Systemen differenzieren und erklären, wie diese zusammenwirken, um sichere Datenübertragung zu ermöglichen.
Überleitung
Um zu verstehen, wie IPsec die Sicherheit im Netzwerkverkehr verbessert, schauen wir uns drei zentrale Komponenten an: den Authentication Header (AH), die Encapsulating Security Payload (ESP) und das Schlüsselmanagement mit IKE.
Was ist der Authentication Header (AH)?
Der Authentication Header (AH) dient dem Schutz der Integrität und Authentizität von IP-Paketen. Das bedeutet: AH stellt sicher, dass ein Paket während der Übertragung nicht verändert wurde und vom angegebenen Absender stammt. Dazu wird dem IP-Paket ein spezieller Header hinzugefügt, der unter anderem eine Integritätsprüfsumme (ICV) enthält.
Diese Prüfsumme wird anhand der unveränderlichen Teile des IP-Headers und der Nutzdaten berechnet.
Was ist der Authentication Header (AH)?
Ein wichtiger Punkt:
AH bietet keine Verschlüsselung. Die Daten bleiben also für Dritte sichtbar. Es geht ausschließlich um Integrität und Authentifizierung, nicht um Vertraulichkeit. Ein weiterer Nachteil ist die mangelnde Kompatibilität mit NAT-Geräten. Wird der IP-Header unterwegs verändert (z. B. durch NAT), schlägt die Prüfsumme fehl und das Paket wird verworfen.
Wie funktioniert Authentication Header (AH) im Tunnelmodus?
Im Tunnelmodus kapselt IPSec das gesamte IP-Paket inklusive des ursprünglichen Headers in ein neues Paket ein. In Kombination mit dem Authentication Header (AH) wird eine Prüfsumme über das gesamte IP-Datenpaket gebildet. Diese Prüfsumme – auch “Message Integrity Code” genannt – dient zwei Zwecken:
- Integrität: Der Empfänger kann prüfen, ob das Datenpaket unterwegs verändert wurde.
- Authentizität: Er erkennt, ob das Paket tatsächlich vom angeblichen Absender stammt.
Die Authentifizierung umfasst dabei das gesamte ursprüngliche IP-Paket, mit Ausnahme einiger variabler Felder wie der TTL (Time to Live). Für den AH-Header werden dabei 28 bis 32 Byte zusätzlich benötigt. Auch der neue IP-Header schlägt mit weiteren 20 Byte zu Buche.
Problem mit NAT-Routern
Ein häufiges Problem im Tunnelmodus ist der Einsatz von NAT-Routern. Diese Geräte manipulieren IP-Adressen, um mehrere Geräte im internen Netz über eine einzige öffentliche IP-Adresse ins Internet zu bringen.
Das Problem: Die vom NAT-Router veränderte Absenderadresse passt nicht mehr zur Originaladresse im ursprünglichen Paket. Da die Prüfsumme die Original-IP-Adresse mit einbezieht, erkennt der Empfänger die Änderung – und verwirft das Paket als ungültig.
Wie funktioniert Authentication Header (AH) im Transportmodus?
Für IPSec ist es nicht zwingend erforderlich, IP-Pakete vollständig neu zu kapseln. In manchen Fällen – abhängig von der Kommunikationsart – reicht der sogenannte Transportmodus aus.
Beim Transportmodus wird der Original-IP-Header beibehalten, lediglich ein AH-Header wird eingefügt. Auch hier beträgt die zusätzliche Datenmenge für den AH-Header 28 bis 32 Byte. Ein entscheidender Vorteil des Transportmodus ist der geringere Overhead im Vergleich zum Tunnelmodus.
Allerdings kann der Transportmodus nur bei einer Host-to-Host-Verbindung eingesetzt werden, also wenn beide Endpunkte der Kommunikation direkt an der Verschlüsselung beteiligt sind.
Was ist die Encapsulating Security Payload (ESP)?
Die Encapsulating Security Payload (ESP) erweitert den Schutzumfang von AH: ESP verschlüsselt die Nutzdaten eines IP-Pakets und kann optional auch für Authentizität und Integrität sorgen. Damit bietet ESP Vertraulichkeit und Schutz vor Manipulation – alles in einem.
Was ist die Encapsulating Security Payload (ESP)?
ESP funktioniert durch das Anhängen eines eigenen Headers, eines Trailers und gegebenenfalls eines Authentifizierungswerts (ICV) an das IP-Paket. Der ESP-Trailer enthält Informationen über die Struktur der Daten und unterstützt die Integritätsprüfung.
Was ist die Encapsulating Security Payload (ESP)?
ESP kann im Transportmodus (nur Nutzdaten werden geschützt) oder im Tunnelmodus (das gesamte IP-Paket wird geschützt) eingesetzt werden. Auch ESP hat Schwierigkeiten mit NAT, da verschlüsselte Inhalte für NAT-Geräte nicht lesbar sind. Hier hilft NAT-T (NAT-Traversal), indem ESP-Pakete in UDP gekapselt werden.
Wie funktioniert Encapsulating Security Payload (ESP) im Tunnelmodus?
Im ESP-Tunnelmodus (Encapsulating Security Payload) wird das gesamte IP-Paket verschlüsselt – einschließlich Nutzdaten und Header. Zusätzlich werden der ESP-Trailer und ein ESP-Header hinzugefügt. Der ESP-Header steht am Anfang des verschlüsselten Bereichs, der Trailer am Ende.
Die Authentifizierung erfolgt von Beginn des ESP-Headers bis einschließlich des ESP-Trailers Der dabei erzeugte Hash-Wert wird an den ESP-Trailer angehängt und ermöglicht dem Empfänger die Integritätsprüfung.
Für den ESP-Header kommen 8 Byte hinzu, für den ESP-Trailer 16 bis 20 Byte, und der neue äußere IP-Header beträgt weitere 20 Byte. Auch hier ist die Original-IP-Adresse nicht mehr sichtbar – der Tunnelmodus verschleiert die Quelladresse.
Wie funktioniert Encapsulating Security Payload (ESP) im Transportmodus?
Im Transportmodus bleibt der ursprüngliche IP-Header erhalten. Ergänzt wird dieser durch den ESP-Header (8 Byte) sowie den ESP-Trailer, der 16 bis 20 Byte umfasst. Nur die Nutzdaten des Pakets – also der Teil hinter dem Header – werden verschlüsselt. Die Authentifizierung bezieht sich auf den Bereich vom ESP-Header bis einschließlich ESP-Trailer.
Wir wissen:
Ein wesentlicher Vorteil des Transportmodus ist der geringe Overhead, da auf eine komplette Neukapselung des Pakets verzichtet wird. Das spart Rechenleistung und Bandbreite – ein Pluspunkt für Systeme mit begrenzten Ressourcen oder hoher Last.
Allerdings bringt diese Variante auch Einschränkungen mit sich: Da der ursprüngliche IP-Header nicht verschlüsselt wird, kann ein potenzieller Angreifer erkennen, dass eine VPN-Verbindung besteht – auch wenn die eigentlichen Inhalte geschützt sind. Außerdem ist der Einsatz auf reine Endpunkt-zu-Endpunkt-Verbindungen beschränkt, also ohne zusätzliche Gateways oder NAT-Geräte.
Schlüsselmanagement mit IKE
Damit AH und ESP sicher arbeiten, benötigen sie kryptografische Schlüssel. Diese Schlüssel werden über das Protokoll IKE (Internet Key Exchange) ausgehandelt.
IKE definiert sogenannte Security Associations (SA) – Vereinbarungen darüber, welche Algorithmen, Schlüssel und Parameter verwendet werden. Die Basis dafür bildet der Diffie-Hellman-Schlüsselaustausch, bei dem beide Seiten ein gemeinsames Geheimnis erzeugen, aus dem dann Sitzungsschlüssel abgeleitet werden.
Schlüsselmanagement mit IKE
IKE besteht aus zwei Phasen:
-
Phase 1: Aufbau einer sicheren Management-Verbindung (IKE-SA). Dies kann entweder im Main Mode (mehr Sicherheit, aber langsamer) oder im Aggressive Mode (weniger sicher, dafür schneller) erfolgen.
- Main Mode: Bietet Identitätsschutz, verwendet sechs Nachrichten.
- Aggressive Mode: Nur drei Nachrichten, aber gibt Identitäten preis – dafür schneller.
-
Phase 2: Innerhalb dieser geschützten Verbindung wird die eigentliche IPsec-SA ausgehandelt, mit der dann die Nutzdaten gesichert werden.
- Diese Phase läuft innerhalb der durch Phase 1 aufgebauten sicheren Verbindung ab.
Zwar ist auch eine manuelle Schlüsselvergabe möglich, diese ist jedoch fehleranfällig und wenig flexibel und wird deshalb nur selten verwendet.
Begriffe
- IKE (Internet Key Exchange): Protokoll zur Aushandlung von Sicherheitsparametern.
- SA (Security Association): Abmachung zwischen zwei Partnern über Algorithmen, Schlüssel etc.
- DH (Diffie-Hellman): Verfahren zum sicheren Schlüsselaustausch.
Überleitung
In sicherheitskritischen Netzwerken reicht es nicht, nur einen starken Schlüssel zu verwenden. Entscheidend ist auch: Was passiert, wenn dieser Schlüssel irgendwann kompromittiert wird? Genau hier kann uns Perfect Forward Secrecy (PFS) behilflich sein.
Was ist Perfect Forward Secrecy (PFS) ?
PFS bedeutet, dass der Verlust eines Schlüssels nicht automatisch frühere oder zukünftige Kommunikation gefährdet. Das wird erreicht, indem für jede Sitzung ein eigener temporärer DH-Schlüssel erzeugt wird – entweder über klassisches Diffie-Hellman (DH) oder effizientere Varianten wie ECDH (Elliptic Curve DH). RSA selbst wird nicht zur Schlüsselableitung genutzt, kann aber beim Schutz von temporären Schlüsseln helfen.
Was ist Perfect Forward Secrecy (PFS) ?
Diese Methode kostet Rechenleistung und macht die Konfiguration etwas komplexer – bietet aber einen enormen Sicherheitsgewinn: Selbst wenn ein Langzeitschlüssel später in falsche Hände gerät, bleiben alte und neue Sitzungen verschlüsselt und sicher.
| Merkmal | Mit PFS | Ohne PFS |
|---|---|---|
| Schlüsselsicherheit | Frühere/spätere Sitzungen bleiben geschützt | Alle Sitzungen gefährdet bei Kompromittierung |
| Leistung | Höherer Aufwand (neue DH-Schlüssel je Sitzung) | Geringere Last durch Schlüsselwiederverwendung |
| Konfiguration | Komplexer (z. B. Auswahl DH-Gruppen) | Einfacher, aber sicherheitsschwächer |
SA, SPD und SAD – Die Regelwerke hinter IPsec
Damit IPsec weiß, wann und wie es Daten schützen soll, greifen drei zentrale Datenbanken ineinander: SA, SPD und SAD. Sie regeln Entscheidungslogik, Umsetzung und Sicherheitsparameter.
Was ist eine Security Association (SA) ?
Eine SA ist eine konkrete „Abmachung“ zwischen zwei IPsec-Teilnehmern. Sie beschreibt, welche Algorithmen, Schlüssel, Modi und Laufzeiten verwendet werden. Wichtig: Eine SA ist immer unidirektional – für die Rückrichtung braucht es eine zweite.
Beispiel:
Wenn Server A Daten an Server B sendet, nutzt er eine eigene SA. Für die Rückantwort braucht Server B eine eigene.
Was ist die Security Policy Database (SPD) ?
Die SPD ist die Entscheidungsebene: Sie prüft jedes Paket und entscheidet, ob es…
- unverschlüsselt weitergeleitet
- mit IPsec verarbeitet
- oder verworfen werden soll.
Diese Entscheidung basiert auf Regeln wie IP-Adressen, Ports oder Protokolltypen.
Was ist die Security Association Database (SAD) ?
Die SAD ist die Ausführungsebene: Sobald die SPD festlegt, dass ein Paket mit IPsec verarbeitet werden soll, liefert die SAD alle dafür nötigen Informationen: Schlüssel, Modus (z. B. Tunnel oder Transport), Sequenznummern und weitere Parameter der zugehörigen SA.
Kurz gesagt:
- Die SPD entscheidet was zu tun ist
- Die SAD regelt wie es getan wird
Zusammenfassung und Ausblick
Zusammenfassung
Authentication Header (AH) und Encapsulating Security Payload (ESP)
In IPsec gibt es zwei Hauptmechanismen für Schutzfunktionen auf Netzwerkebene:
-
AH (Authentication Header) sorgt für Integrität und Authentizität der IP-Pakete. Er prüft, ob die Daten unterwegs verändert wurden und vom angeblichen Absender stammen. Ein Nachteil ist, dass AH nicht verschlüsselt – die Inhalte bleiben sichtbar. Außerdem ist AH nicht NAT-kompatibel, da Änderungen am IP-Header die Integritätsprüfung scheitern lassen.
-
ESP (Encapsulating Security Payload) bietet neben Authentizität auch Vertraulichkeit durch Verschlüsselung. ESP schützt Nutzdaten und kann zusätzlich Authentifizierungsdaten enthalten. Je nach Modus (Transport oder Tunnel) wird dabei nur der Inhalt oder das gesamte IP-Paket geschützt. Auch ESP hat Einschränkungen bei NAT, die durch NAT-Traversal (NAT-T) umgangen werden können.
Schlüsselmanagement mit IKE
Für den sicheren Schlüsselaustausch sorgt IKE (Internet Key Exchange). Es besteht aus zwei Phasen:
- Phase 1: Aufbau einer sicheren Management-Verbindung (IKE-SA) über Main Mode (sicherer) oder Aggressive Mode (schneller).
- Phase 2: Aushandlung der eigentlichen IPsec-SA, mit der die Nutzdaten gesichert übertragen werden.
Der Diffie-Hellman-Schlüsselaustausch bildet die Grundlage für die gemeinsame Geheimniserzeugung. Daraus werden Sitzungsschlüssel abgeleitet. Alternativ kann eine manuelle Schlüsselvergabe erfolgen – diese ist jedoch fehleranfälliger und unflexibler.
Perfect Forward Secrecy (PFS)
PFS verhindert, dass der Verlust eines Schlüssels alle früheren oder späteren Sitzungen kompromittiert. Das wird erreicht, indem für jede Sitzung ein neuer DH-Schlüssel erzeugt wird. Varianten wie ECDH sorgen für hohe Sicherheit bei geringerer Schlüsselgröße. Die Nutzung von PFS erhöht die Rechenlast, bietet aber höchste Sicherheit.
| Merkmal | Mit PFS | Ohne PFS |
|---|---|---|
| Schlüsselsicherheit | Sitzungsschlüssel getrennt | Alle Sitzungen bei Schlüsselverlust gefährdet |
| Leistung | Mehr Rechenlast | Effizienter, aber schwächer |
| Konfiguration | Aufwendiger | Einfacher |
Sicherheitsrichtlinien: SA, SPD und SAD
- SA (Security Association): Beschreibt die Rahmenbedingungen einer gesicherten Verbindung (Algorithmus, Schlüssel, Modus etc.). Jede Kommunikation benötigt zwei SAs – eine pro Richtung.
- SPD (Security Policy Database): Entscheidet, ob und wie IPsec angewendet wird – je nach IP, Port, Protokoll.
- SAD (Security Association Database): Hält die Details zu aktiven SAs bereit, z. B. Schlüssel, Modus, Sequenznummern – sie ist für die technische Umsetzung zuständig.
Merksatz: SPD entscheidet, SAD setzt um – basierend auf der SA.
Ausblick
Diese Grundlagen bilden das Fundament für den sicheren Einsatz von IPsec. In der nächsten Lerneinheit lernst du die Transport- und Tunnelmodi im Detail kennen und verstehst, wann du welchen Modus einsetzen solltest.