IPsec (Internet Protocol Security)

IPSec steht für die gebräuchliche Kurzform von Internet Protocol Security und ist eine Erweiterung des IP-Protokolls um Authentifizierung und Verschlüsselung. Ziel ist eine sichere Kommunikation über das potentiell unsichere IP-Netz, wie beispielsweise dem Internet. Insbesondere sollen die CIA-Schutzziele, wie Vertraulichkeit (durch Verschlüsselung), Authentizität und Integrität (durch MAC), erfüllt werden. Eine beliebte Angriffstechnik in IP-Netzen ist beispielsweise das IP-Spoofing. Darunter versteht man das Versenden von IP-Paketen mit gefälschten Absender-IP-Adressen. Für den Empfänger ist dabei nicht ersichtlich, dass der angebliche Sender gar nicht der Urheber der Nachricht ist. Mit IPSec soll solch ein Angriff beispielsweise verhindert werden.

Spezifiziert ist die IPSec Architektur im RFC 2401 bzw. im neueren RFC 4301.

Häufig wird IPSec für VPNs (Virtual Private Networks) genutzt oder zum Schutz vor Replay-Angriffen.

IPSec im Protokollstack

Grundlagen

Die Grundidee hinter IPSec ist, dass im Header nur die minimal notwendigen Informationen untergebracht werden sollte, die für die eine erweiterte Verarbeitung benötigt werden. Diese Information ist ein Verweis auf einen Datei- oder Datenbankeintrag, der sogenannte Security Parameters Index (SPI). Diese SPI identifiziert in Verbindung mit der IP-Adresse und dem Sicherheitsprotokoll die Security Association (SA). Eine Security Association (Sicherheitsverbindung) umfasst verschiedene kryptographische Parameter und die zur Verarbeitung benötigten Algorithmen. Sie beschreibt, wie die beiden an der Kommunikation beteiligten Parteien Sicherheitsdienste anwenden, um so sicher kommunizieren zu können. Verwaltet werden die SAs in der Security Association Database (SAD). Die SAD liefert so die benötigten Informationen, die der Authentication Header bzw. Encapsulating Security Payload für die Ver-/Entschlüsslung und Überprüfung der ein-/ausgehenden IPSec-geschützten Pakete benötigt werden. Ausgehandelt werden die Einträge in der SAD mit dem Schlüsselaustauschverfahren Internet Key Exchange (IKE). Zu guter Letzt sei auch noch die Security Policy Database (SPD) erwähnt, in der der Administrator die Sicherheitspolitik festlegt. Darin wird spezifiziert, wie mit eingehenden und ausgehenden Traffic umzugehend ist. Anhand von Regeln wird vorgeschrieben, wie das Verarbeitungsverhalten von Paketen ist.

Übertragungsmodi

IPSec unterscheidet zwischen den beiden Übertragungsmodi: Transportmodus und Tunnelmodus.

Transportmodus

Der Transportmodus stellt Punkt-zu-Punkt-Kommunikation zwischen zwei Endpunkten her (Peer-to-Peer). Dafür wird ein zusätzlicher Protokollkopf zwischen den IP-Protokollkopf und den eigentlichen IP-Nutzdaten des betroffenen Pakets eingefügt. So ist es mit diesem Übertragungsmodus nicht wie beim Tunnelmodus möglich, verschiedene Netze miteinander zu koppeln. Auch ist es nötig, dass alle Endgeräte, die miteinander mit IPsec sicher kommunizieren möchten, diese Protokollerweiterung auch unterstützen.

Aufbau IP-Paket im Transportmodus

Tunnelmodus

Der Tunnelmodus verbindet zwei Netze über zwei Router. Dieser Modus wird im Allgemeinen beim Einsatz von IPsec in sogenannten Security Gateways gewählt. Vorteil des Tunnelmodus: Die Endgeräte müssen nicht IPsec-fähig sein. Gleichzeitig erstreckt sich der Schutz aber natürlich auch nur auf die Strecke zwischen den beiden Tunnelenden, eine Ende-zu-Ende-Sicherheit wird nicht gewährleistet. Viel mehr spricht man hier von einer Netz-zu-Netz-Sicherung. Das Besondere am Tunnelmodus ist darüber hinaus, dass dem betroffenen IP-Paket ein neuer zusätzlicher IP-Protokollkopf vorangestellt wird. Dadurch entsteht allerdings auch ein höherer Protokollaufwand als beim Transportmodus.

Aufbau IP-Paket im Tunnelmodus

Sicherheitsprotokolle

IPsec bietet die beiden Sicherheitsprotokolle Authentication Header (AH) und Encapsulating Security Payload (ESP) an, die jeweils auch noch einmal in eigene RFCs spezifiziert worden sind.

Authentication Header (AH)

Mit dem Authentication Header (AH) soll in IPSec die Integrität und Authentizität sichergestellt werden. Er kann sowohl als Zugangskontrolle als auch zum Schutz von Wiedereinspielungsangriffe (Replay-Attack) genutzt werden. Seit IPSecv3 ist das AH-Protokoll nur noch optional. AH bietet keinen Schutz der Vertraulichkeit, sprich alle Daten werden weiterhin im Klartext übertragen.

Spezifiziert ist der Authentication Header im RFC 4302 (ehemals RFC 2402)

Die kryptographische Prüfsumme berechnet sich bei AH durch die IP-Nutzdaten, sowie Teile des vorangehenden IPsec- und IP-Protokollkopfes. Sollte beispielsweise nun die IP-Adresse ausgetauscht werden, kann diese leicht erkannt werden. Das nicht alle Teile des IP-Protokollkopfes verwendet werden lässt sich ganz einfach dadurch erklären, da manche Felder während der Übertragung verändert werden müssen (Mutable Fields). Beispielsweise das TTL-Feld (time to live), das bei jedem Router um eins gesenkt wird. Diese Felder werden vor der Berechnung/Überprüfung auf einen fest definierten Wert gesetzt.

Aufbau des Authentication Headers

Encapsulating Security Payload (ESP)

Durch Encapsulating Security Payload (ESP) wird wie bei AH Integrität und Authentizität, sowie zusätzlich Vertraulichkeit breitgestellt. Im Gegensatz zu AH werden beim Encapsulating Security Payload die Daten also nicht im Klartext übertragen, sondern werden verschlüsselt. Dafür kommt symmetrische Kryptographie zum Einsatz. Damit die entsprechenden symmetrischen Verschlüsselungsverfahren auch eingesetzt werden können, ist es möglich durch das Hinzufügen von Auffüllbytes (Padding Bytes) die Nutzdaten auf eine bestimmte Blocklänge zu erweitern, hinzu gibt es die Möglichkeit einen Initialisierungsvektor mitzuschicken, welche manche Verschlüsselungsverfahren benötigen.

Zwar schützt ESP, wie auch AH, die Integrität, der Schutz fällt hier aber deutlich niedriger aus. Während AH neben den Nutzdaten auch Teile des IP-Protokollkopfes für die Berechnung der Prüfsumme mit aufnimmt, wird bei ESP nur die IP-Nutzdaten und der eingefügte IPsec-Protokollkopf beachtet.

Aufbau des Encapsulating Security Payload Headers

Der Encapsulation Security Payload Header ist dem Aufbau des Authentication Headers sehr ähnlich. Auch hier dient der Security Parameter Index zur Identifikation der SA und das Sequence Number Field zur Abwehr von Wiedereinspielungsangriffen. Das Payload Data-Feld enthält die verschlüsselten Nutzdaten, während anschließend die Auffüllbytes (Padding) und deren Anzahl (Padding Length) folgen. Das Next Header-Feld gibt Informationen über die Art der Nutzdaten, ganz am Ende findet man dann noch Platz für das Ergebnis der kryptographischen Prüfsummenfunktion im Authentication Data-Feld.

AH + ESP

Generell muss man beim Einsatz von IPsec entscheiden, welche Kombination aus Übertragungsmodus und Sicherheitsprotokoll zum Einsatz kommen soll. Diese Entscheidung fällt je nach Sicherheitsanforderung aus. Genügt einem beispielsweise die Sicherstellung der Integrität und Authentizität, dann reicht bereits der Transportmodus und AH. Wer zusätzlich Vertraulichkeit benötigt, muss AH mit ESP ersetzen. In diesem Fall werden aber weiterhin Teile der IP-Verbindungsdaten im Klartext übertragen.

Wer die höchste Sicherheit möchte, der kombiniert AH im Transportmodus mit ESP im Tunnelmodus. Durch den Tunnelmodus wird eine IP-IP-Kapselung durchgeführt und ein neuer IP-Protokollkopf eingefügt. Dank ESP findet nun eine Verschlüsselung des ursprünglichen IP-Protokollkopfes mitsamt Nutzdaten statt. Nun ist aber noch der äußere Protokollkopf ungesichert, deshalb wird nun noch AH im Transportmodus darauf angewandt. Nachteil dieses maximalen Schutzes ist die Aufblähung des ursprünglichen Pakets und damit ein erhöhter Bandbreitenbedarf.

Sliding Window – Schutz vor Wiedereinspielung

Wie man beim Aufbau der beiden Sicherheitsprotokolle gesehen hat, besitzen sowohl AH als auch ESP ein Feld für Sequenznummern. Diese Sequenznummern dienen zur Abwehr von Wiedereinspielungsangriffen. Bei der Einrichtung der SA wird das Feld mit dem Wert 0 initialisiert und mit jedem gesendeten Paket um 1 erhöht. Bevor es zu einem Überlauf der 32 Bit langen Sequenznummer kommt, muss der Sitzungsschlüssel für diese SA erneuert werden. Über ein sogenanntes Sliding Window („gleitendes Fenster“) wird entschieden, ob ein Paket mit einer bestimmten Sequenznummer angenommen oder verworfen wird. Dafür muss die Sequenznummer in einem bestimmten Bereich akzeptierter Nummern liegen. Dieser Bereich verschiebt sich durch den Empfang von akzeptierten Pakete. Ein ganzer Bereich wird benötigt, da die einzelnen Pakete nicht immer in der Reihenfolge ankommen, in der sie verschickt werden. Würde man jeweils immer nur die nächst höhere Sequenznummer erlauben, würde das den Datendurchsatz erheblich erhöhen, da Pakete mehrmals verschickt werden müssten, bevor sie angenommen werden könnten.
In RFC 2401 wird die minimale Fenstergröße mit 32 angegeben und die empfohlene Größe mit Wert 64.

Mit den Paketen wird je nach Sequenznummer folgendermaßen verfahren:

• Liegt die Sequenznummern links vom Empfangsfenster, sprich die Nummer ist kleiner als die Untergrenze, dann wird das Paket verworfen
• Liegt die Sequenznummer innerhalb des Empfangsfensters und wurde bisher noch nicht erhalten, wird das Paket nach Authentizitätsprüfung akzeptiert und die Sequenznummer als empfangen markiert. Falls es bereits erhalten worden ist, wird es verworfen.
• Liegt die Sequenznummer außerhalb rechts des Empfangsfensters, ist also größer als das bisher höchste empfangene Paket, wird das Paket nach Authentizitätsprüfung angenommen und das Fenster verschoben.

Beispiel

Das Fenster befindet sich gerade im Bereich 32-63. Das Paket 27 wurde noch nicht empfangen. Selbst wenn dieses nun aber eintrifft, wird es verworfen, da die Zahl kleiner als 32 ist und sich demnach auf der linken Seite des Fensters befindet. Alle Pakete mit der Nummer innerhalb des Fensters werden angenommen, so lange nicht schon ein Paket mit derselben Nummer davor angenommen wurde. Das Fenster verschiebt sich hier noch nicht. Würde aber nun ein Paket mit der Nummer 65 kommen, würde es angenommen werden und das Fenster würde sich auf den Bereich 34-65 verschieben.

Implementierung von IPsec

Auch die abstrakte Implementierung von IPsec wird weiter spezifiziert. Wichtige Bestandteile sind hierbei:

• Security Policy Database (SPD)
• Security Association Database (SAD)
• Internet Key Exchange (IKE)

Security Policies/Security Policy Database (SPD)

Eine Security Policy ist ein Regelsatz, wie die Pakete nach Senden und Empfangen verarbeitet werden soll. Dabei gibt es drei Grundfunktionen:

• Paket wird sofort verworfen (DISCARD)
• Paket wird ohne Änderung weitergeleitet (BYPASS)
• Paket wird durch IPsec verarbeitet (PROTECT)

Eine Security Policy Database (SPD) enthält nun alle diese Security Policies. Soll ein Paket nun verschickt werden, wird erst einmal in der SPD nachgeschaut, wie damit verfahren werden soll.

Security Associations/Security Association Database (SAD)

Eine Security Association (deutsch Sicherheitsassoziation) ist die technische Umsetzung einer getroffenen Sicherheitsvereinbarung. Eindeutig identifiziert wird diese Security Association (SA) durch den Security Parameter Index (SPI), der Zieladresse und dem IPsec-Protokoll (AH oder ESP). Neben diesen Informationen enthält eine SA weitere Informationen, wie beispielsweise der verwendete Übertragungsmodus, eingesetzte Prüfsummen- und Verschlüsselungsverfahren und die Gültigkeit (Lebensdauer). SAs sind immer nur unidirektional, möchte man die Kommunikation auf beiden Seiten der Kommunikationspartner sichern, werden zwei getrennte SAs benötigt, je eine für jede Kommunikationsrichtung.

Eine Security Association Database (SAD – teilweise auch mit SADB abgekürzt) sind nun alle SAs einer IPsec-Implementierung abgespeichert.

Bearbeiten von Datenpaketen

Nachfolgend eine schematische Darstellung, wie die Daten in IPsec verarbeitet werden.

Ausgehender Verkehr

Eingehender Verkehr

Internet Key Exchange (IKE)

Generell spezifiziert IPSec nicht, wie das benötigte Schlüsselmaterial erzeugt wird. Dies kann sowohl manuell als auch durch ein Schlüsselaustauschprotokoll erfolgen. Eine manuelle Schlüsseleingabe scheidet alleine schon wegen der schlechten Skalierbarkeit aus. Deshalb spezifiziert IPsec das Schlüsselaustauschprotokoll Internet Key Exchange Protokoll (IKE). Dessen Spezifikation erstreckt sich darüber hinaus in den RFCS 2407 bis 2409. In RFC 5996 wird die zweite Version von IKE (IKEv2) spezifiziert. Folgende Funktionalitäten bietet IKE:

• Gegenseitige Authentifizierung der Kommunikationspartner
• Erzeugung eines sicheren Kommunikationskanals
• Aushandlung von SAs für IPsec

Nachfolgend soll im speziellen auf IKEv2 eingegangen werden. Das Protokoll besteht aus zwei Phasen. In der ersten Phase wird ein gesicherter Kanal zwischen den beiden Kommunikationspartner aufgebaut. Über diesen werden Sicherheitsverfahren ausgehandelt und das nötige Schlüsselmaterial ausgetauscht.

Der Kommunikationspartner, der die Aushandlung anstößt, wird Initiator (i) genannt. Der angesprochene Kommunikationspartner nennt man Responder (r).

Erste Phase

Nachfolgend der Ablauf der ersten Phase.

In jeder Nachricht wird natürlich auch immer der jeweilige IKE Header mitgeschickt.

Mit den ersten beiden Nachrichten werden die gemeinsamen Geheimnisse erzeugt und die dafür verwendeten Algorithmen festgelegt (man spricht von den initial exchanges). Mit den danach folgenden zwei Nachrichten wird dann die Child-SA erzeugt.

In der ersten Nachricht teilt der Initiator mit SA_i die unterstützten Algorithmen für die IKE-SA mit. KEY_i ist der Diffie-Hellman-Wert des Initiators, während mit Nonce_i eine Zufallszahl vom Initiator an den Responder geschickt wird.

Der Responder antwortet in seiner Nachricht mit SA_r mit den ausgewählten Algorithmen für IKE-SA. Darüber hinaus schickt er ebenfalls seinen Diffie-Hellman-Wert und eine Zufallszahl an den Initiator. Mit CERTREQ kann er optional auch ein Zertifikat vom Initiator anfordern.

Das Ergebnis des Austausches ist eine spezielle SA mit dem Namen IKE SA. Diese SA definiert Parameter für einen sicheren Channel, über den die nachfolgenden Nachrichten ausgetauscht werden. Demnach sind alle nachfolgenden IKE Nachrichten durch Verschlüsselung und Nachrichtenauthentifizierung geschützt.

In den nun folgenden zwei Nachrichten authentifizieren sich Initiator und Responder durch ihre jeweilige ID und einer Authentifizierungsdatenstruktur (AUTH). Ist diese Authentifizierung abgeschlossen, folgt nun die Aushandlung der ersten SA zum Schutz von normaler Kommunikation zwischen den Teilnehmern. CERT bzw. CERTREQ ist optional und nur relevant, falls eine Authentifizierung mit Zertifikaten durchgeführt werden soll. Mit SA_i2 bzw. SA_r2 werden die Algorithmen vorgeschlagen bzw. ausgewählt, während mit TS_i/ TS_r die Traffic-Selectoren übermittelt werden.

Um sich vor DoS-Angriffe zu schützen, können optional Cookies genutzt werden. Dafür kann der Responder in seiner ersten Nachricht einen Cookie-Austausch vom Initiator verlangen. Damit wird die kryptografische Berechnung erst einmal auf den Initiator verschoben und der Responder muss diese erst durchführen, wenn die anschließende Nachricht auch wirklich das richtige Cookie enthält und der Responder damit sichergehen kann, dass der Initiator auch wirklich existiert.

Neben der Authentifizierung durch digitale Signaturen und gemeinsamer Geheimnis kann in IKEv2 auch EAP als Authentifizierungsmethode eingesetzt werden.

Zweite Phase

In der zweiten Phase können nun mehrere SAs (sogenannte CHILD SAs) aufgebaut werden. Dafür ist folgender Ablauf vorgesehen:

Auch hier werden wieder mit SA_i2 bzw. SA_r2 Algorithmen angeboten bzw. ausgewählt und jeweils eine Zufallszahl mitgeschickt. Durch die Traffic Selectoren (Verkehrsselektoren) können die beiden IKE-Instanzen Informationen der SPD austauschen und automatisch anpassen.

Quellen und Verweise

• Sicherheit und Kryptographie im Internet - Theorie und Praxis von Schwenk, Jörg
• Sichere Netzwerkkommunikation - Grundlagen, Protokolle und Architekturen von Bless, R., Mink, S., Blaß, E.-O., Conrad, M., Hof, H.-J., Kutzner, K., Schöller, M.
• W. Stallings; Cryptography and Network Security, 6th Edition, Prentice-Hall, 2013
• Netzsicherheit - Algorithmische Grundlagen und Protokolle, Dr.-Ing. Günter Schäfer
• http://wiki.treck.com/IPsec/IKE_Programmer%27s_Reference
• https://de.wikipedia.org/wiki/IPsec

Artikel vom 30.08.2016