IP Security (IPsec)

IP Security (IPsec)

IPsec (Kurzform für IP Security) wurde 1998 entwickelt, um die Schwächen des Internetprotokolls (IP) zu beheben. Es stellt eine Sicherheitsarchitektur für die Kommunikation über IP-Netzwerke zur Verfügung. IPsec soll die Schutzziele Vertraulichkeit, Authentizität und Integrität gewährleisten. Daneben soll es vor so genannten Replay-Angriffen bzw. einer Replay-Attacke schützen - das heißt, ein Angreifer kann nicht durch Abspielen eines vorher mitgeschnittenen Dialogs die Gegenstelle zu einer wiederholten Aktion verleiten.

IPsec entstand im Zuge der Entwicklung von IPv6 und ist in verschiedenen RFCs spezifiziert:

RFC 2401: Sicherheitsarchitektur für das Internetprotokoll
RFC 2402: Authentication Header
RFC 2406: Encapsulating Security Payload
RFC 2407: IPsec Domain of Interpretation (IPsec DoI)
RFC 2408: Internet Security Association and Key Management Protocol (ISAKMP)
RFC 2409: Internet Key Exchange (IKE)

Der RFC 2401 bildet das Hauptdokument zu IPsec, er beschreibt die Architektur von IPsec. Von dort aus werden die oben genannten RFCs referenziert. Wesentliche Inhalte von IPsec sind das Authentication Header Protokoll (AH) und das Encapsulated Security Payload Protokoll (ESP) sowie das Internet Key Exchange Protokoll (IKE) zum Austausch der Schlüssel.

Im Gegensatz zu anderen Verschlüsselungsprotokollen wie etwa SSH arbeitet IPsec auf der Netzwerkschicht (Schicht 3) des OSI-Referenzmodells.

Verbindungsaufbau

Schlüsselaustausch

Manual Keying

Die Schlüssel werden vorab ausgetauscht und auf beiden Tunnelendpunkten fest konfiguriert.

IKE

Das Internet Key Exchange (IKE) Protokoll dient der automatischen Schlüsselverwaltung für IPsec. Es verwendet den Diffie-Hellman-Schlüsselaustausch für einen sicheren Austausch von Schlüsseln über ein unsicheres Netzwerk und ist wohl der komplexeste Teil von IPsec. IKE ist in RFC 2409 spezifiziert und basiert auf dem Internet Security Association and Key Management Protocol (ISAKMP, RFC 2408), der IPsec Domain of Interpretation (DOI, RFC 2407), OAKLEY (RFC 2412) und SKEME.

Vor dem eigentlichen Start einer verschlüsselten Verbindung muss man sich auf die zu verwendenden Schlüssel und Algorithmen einigen. Hierfür ist IKE gedacht. IPsec arbeitet mit verschiedenen symmetrischen wie asymmetrischen Schlüsseln. IKE unterstützt die Verfahren Pre Shared Keying (PSK) und Certificate

IKE basiert auf UDP und nutzt standardmäßig den Port 500 als Quell- und Ziel-Port. Es arbeitet in zwei Phasen:

Aushandlung einer Security Association (SA) für ISAKMP mittels Aggressive Mode (Aggressiver Modus) oder Main Mode (Hauptmodus)

Erzeugung einer SA für IPsec mittels Quick Mode (Schnellmodus)

Eine Security Association (SA) ist ein Vertrag zwischen den kommunizierenden Stellen. Hierin wird festgelegt, welche Authentifizierungs- und Verschlüsselungsalgorithmen genutzt werden sollen.

Phase 1

Main Mode

Der Main Mode kann in der ersten Phase der Internet Key Exchange genutzt werden. Hierbei handeln der Initiator (derjenige, der die Verbindung aufnehmen will) und der Antwortende miteinander SAs für ISAKMP aus. Diese "Verhandlung" geschieht in folgenden sechs Schritten:

Initiator sendet einen oder mehrere Vorschläge mit Authentifizierungs- und Verschlüsselungsalgorithmen

Antwortsender wählt einen Vorschlag aus und bestätigt

Initiator sendet öffentlichen Teil der Diffie-Hellmann-Schlüsselvereinbarung und einen zufälligen Wert (Nonce - wird nicht gesendet)

Antwortsender schickt ebenfalls öffentlichen Teil der Diffie-Hellmann-Schlüsselvereinbarung und einen zufälligen Wert (Nonce - wird nicht gesendet)

Initiator berechnet Signatur (aus öffentl. Teil und seiner Nonce) und sendet diese mit seiner Identität an Antwortsender. Diese Daten werden mit einem symmetrischen Schlüssel verschlüsselt.

Antwortsender schickt gleiche Daten von seiner Seite an den Initiator

Aggressive Mode

Im Aggressive Mode werden die obigen Schritte auf drei zusammengefasst. Hierbei fällt dann die Verschlüsselung des obigen fünften Schrittes weg. Stattdessen werden die Werte im Klartext übertragen. Daher sollte man diesen Modus nach Möglichkeit nicht verwenden.

Phase 2

Quick Mode

Der Quick Mode wird in der zweiten Phase von IKE zur Anwendung gebracht. Die gesamte Kommunikation in dieser Phase erfolgt verschlüsselt. Wie in der ersten Phase wird zunächst ein Vorschlag (Proposal) gemacht. Dieser wird zusammen mit einem Hashwert und der Nonce übertragen. Später werden die Schlüssel neu berechnet, und es gehen keinerlei Informationen aus den zuvor generierten SAs ein. Dies stellt sicher, dass niemand von den zuvor generierten Schlüsseln auf die neuen schließen kann.

Authentication Header

Der Authentication Header (AH) soll die Integrität und Authentizität der übertragenen Pakete sicherstellen. Weiterhin existiert hier ein Schutz gegen Replay-Angriffe. AH versucht alle möglichen Felder eines IP-Datagramms zu schützen. Es werden lediglich Felder ausgeschlossen, die sich auf dem Weg eines IP-Pakets durch ein IP-Netz durch die Router verändern können.

Ein AH-Paket sieht folgendermaßen aus:

Byte 0	Byte 1	Byte 2	Byte 3
Bit 0 1 2 3 4 5 6 7	Bit 0 1 2 3 4 5 6 7	Bit 0 1 2 3 4 5 6 7	Bit 0 1 2 3 4 5 6 7
Nächster Header	Nutzerdaten	reserviert
Security Parameters Index (SPI)
Feld mit Sequenznummern
Authentizitätsdaten (variabel)

Bedeutung der Felder:

Nächster Header (next header): identifiziert das Protokoll der im Paket übertragenen Daten
Nutzdaten Länge (payload length): Größe des AH-Paketes
reserviert (RESERVED): reserviert für zukünftige Nutzung
Security Parameters Index (SPI): identifiziert in Verbindung mit der IP-Adresse und dem Sicherheitsprotokoll die Sicherheitsassoziation
Feld mit Sequenznummern (sequence number): ansteigende Nummer, die vom Absender gesetzt wird, soll Schutz vor Replay-Angriff bieten
Authentizitätsdaten (authentication data): enthält den Wert des Integritätstests (integrity check value, ICV) welcher sich aus einem Hash des übrigen Paketes ergibt

Encapsulated Security Payload (ESP)

Encapsulating Security Payload (ESP) soll die Authentifizierung, Integrität und Vertraulichkeit von IP-Paketen sicher stellen. Im Unterschied zu AH wird der Kopf des IP-Paketes vom ICV nicht mit berücksichtigt. Jedoch werden die Nutzdaten verschlüsselt übertragen.

Ein ESP-Paket sieht folgendermaßen aus:

Byte 0								Byte 1								Byte 2								Byte 3
Bit 0	1	2	3	4	5	6	7	Bit 0	1	2	3	4	5	6	7	Bit 0	1	2	3	4	5	6	7	Bit 0	1	2	3	4	5	6	7
Security Parameters Index (SPI)
Sequenznummer
Nutzdaten * (variabel)
								Füllung (0-255 bytes)
																Länge Füllung								Nächster Header
Authentizitätsdaten (variabel)

Bedeutung der Felder:

Security Parameters Index (SPI): identifiziert in Verbindung mit der IP-Adresse und dem Sicherheitsprotokoll die Sicherheitsassoziation
Sequenznummern (sequence number): ansteigende Nummer, die vom Absender gesetzt wird, soll Schutz vor Replay-Angriff bieten
Nutzdaten (payload data): enthält die Datenpakete
Füllung (padding): wird für eingesetzte Blockchiffre genutzt, um Daten bis zur vollen Größe des Blocks aufzufüllen
Länge Füllung (pad length): enthält Anzahl der eingefügten Bits für Padding
Nächster Header (next header): identifiziert das Protokoll, der im Paket übertragenen Daten
Authentizitätsdaten (authentication data): enthält den Wert des Integritätstests (integrity check value, ICV)