ipsec.goout.ch, Einführung IPsec

Einführung IP Sec

Wir haben uns erlaubt, die Einführung in die VPN - Theorie der Diplomarbeit von Olivier Gärtner und
Berkant Uenal zu entnehmen. Das Komplette Dokument Ihrer Diplomarbeit kann man hier einsehen.

Die VPN / IPSec Theorie
ist in folgende Kapitel unterteilt:

Security Parameter Index SPI:
Sequence Number:
Payload Data:
Padding:

Pad Length:
Next Header:
Authentication Data:

[à Authentication Header AH]
[à Authentication Header AH]
Verschlüsselte Nutzdaten
Je nach verwendetem Verschlüsselungsalgorithmus wird als Input eine ganz bestimmte Länge des Datenpakets verlangt um die Verschlüsselung durchzuführen. Das Padding dient zum Erreichen der gewünschten Länge.
Länge des vorangehenden Padding Feldes.
Daten-Typ der Nutzdaten (TCP/UDP etc.)
Im ESP ist das Erzeugen eines Hashwertes optional, aber aus Sicherheitsgründen wird es in der Regel gemacht. Auch wenn die Daten verschlüsselt sind, wäre die Möglichkeit gegeben eine Fälschung der Daten vorzunehmen.
Durch den Hashwert wird das ganz klar verunmöglicht.

Die Anwendung von ESP bezogen auf die zwei Modi sehen folgendermassen aus:

ESP im Transportmodus:

ESP im Tunnelmodus

Jetzt könnte man sich die Frage stellen, warum brauchen wir das AH-Protokoll. Es genügt doch, wenn wir im ESP-Protokoll zusätzlich zur Verschlüsselung einen AH-Header erzeugen. Zwei Gründe dafür sollen hier kurz erwähnt werden:

In bestimmten Ländern (Frankreich), wo Kryptographie verboten ist , hat man gar kein andere Wahl, als das AH-Protokoll zu verwenden. Somit gibt es also für das AH-Protokoll weltweit keinen Einschränkung für deren Benützung. Eine Verbindung, welche nur Authentifikation braucht, zum Beispiel Kommunikation innerhalb eines firmeninternen, abhörsicheren Netzes, spart man Zeit ( Prozessor muss weniger arbeiten) und Bandbreite (Datenpaket enthalten weniger zusätzliche Headers).

zurück

Praktisch genutzte Kombinationen

Wie wir gesehen haben, gibt es verschiedene Möglichkeiten eine sichere Verbindung aufzubauen.
Je nach Situation wählt man den geeigneten Modus und das passende IPSec-Protokoll aus.
In der Praxis haben sich die folgenden Kombinationen als die sinnvollsten herausgestellt:

Host-to-Host-Verbindung

Bei Host-to-Host-Verbindungen macht es keinen Sinn Tunneling zu verwenden, da der IP- Header der gleiche wäre. Darum benützt man den Transportmodus mit AH und ESP. Wie man sieht, wird mit dem zusätzlichen benützen des AH-Headers die Authentifikation auf das ganze Datenpaket ausgeweitet. Dadurch erhöht sich natürlich der Sicherheitsgrad der Verbindung.

Typische VPN-Verbindung

Zwei Hosts (H1 und H2) mit privaten Adressen werden über Security Gateways (SG1 und SG2) mit öffentlichen Adressen ans Internet verbunden. Die folgende Skizze soll Aufschluss geben, welcher Modus und welche Kombination von IPSec Protokollen innerhalb der VPN-Verbindung verwendet wird.

Beschreibung

H1 erzeugt ein Datenpaket mit Source (Src) und Destination (Dest.) Adresse im IP-Header und dem Payload im Klartext. Private IP-Adressen werden für die Adressierung verwendet.

Bevor H1 die Daten auf das lokale Netz (10.0.1.0) sendet, wird das Datenpaket mittels dem ESP-Protokoll bearbeitet. An dieser Stelle könnte man sich fragen, ob es wirklich nötig ist ESP im Transportmodus anzuwenden, den in der Regel betrachtet man die lokalen Netze als sicher.

Für optimalen Schutz über das Internet verwenden die Security Gateways den Tunnelmodus und die beiden IPSec-Protokolle AH und ESP zusammen. Durch das Tunneling bleibt die Identität von Host 1 und 2 im Verborgenen, denn diese befindet sich in den Nutzdaten, welche durch das ESP-Protokoll verschlüsselt worden sind. Das einzige, was man jetzt an diesem Paket erkennen kann, sind die öffentlichen IP-Adressen der Security Gateways SG1 und SG2. Ein Sniffer hat somit weder Kenntnis über die Existenz der Subnetze, noch über die angeschlossenen Hosts. Er sieht nur die beiden Security Gateways. Durch den zusätzlichen AH-Header wird die Authentifikaton auf das ganze Datenpaket ausgeweitet, was bekannterweise nur mit dem ESP-AH nicht gegeben ist.

Beim SG2 angekommen, wird das Paket zuerst mittels AH-Header authentisiert. Falls die Hashwerte für die Authentifizierung vom Sender und Empfänger übereinstimmen, wird das Datenpaket vom SG2 so bearbeitet, dass es wieder die Form hat wie in 2, also sich im Transportmodus mit ESP befindet und so ins Subnetz (10.0.2.0) durchgeroutet wird.

Am Ziel angekommen, wird mittels ESP-AH wieder eine Authentifikaton durchgeführt. Dies Schützt die Daten vor Angriffen aus dem Subnetz. Falls keine Änderung des Datenpakets vorgenommen worden ist, wendet der H1 das ESP-Protokoll an, um so das Datenpaket zu entschlüsseln. Jetzt liegt das ursprüngliche Datenpaket authentisiert und entschlüsselt für weitere Verarbeitungen für die oberen Layer zur Verfügung.

zurück

IKE Internet Key Exchange

Ein sehr heikles Thema bei jeder Verschlüsselung und Authentifizierung ist die Erzeugung und Geheimhaltung der notwendigen Schlüssel, sprich das Schlüsselmanagement. Die verwendeten Algorithmen können auch noch so sicher sein, wenn die Geheimhaltung der Schlüssel unsicher ist, nützt auch der ausgereifteste Verschlüsselungsalgrorithmus nichts.
Genau diese Sicherheit wird durch IKE geboten, wenigstens was die Erzeugung anbelangt. Wie wir noch sehen werden, kann man auf zwei Arten eine sichere Verbindung übers Internet mit IPSec aufbauen und zwar mit ‘Manueller Schlüsselverbindung’ und ‘Automatischer Schlüsselverbindung’. Da in grösseren VPN’s mit mehreren Benutzern der Administrative Aufwand in Grenzen gehalten werden möchte, wird der ‘Automatischer Schlüsselverbindung’ mittels IKE ganz klar bevorzugt.
Bevor IKE näher betrachtet wird, soll für das bessere Verständnis des Protokolls das Prinzip von Diffie-Hellman erklärt werden, das ein wichtiger Bestandteil davon ist. Eingesetzt wird dieses Verfahren einerseits als Inputparameter bei der Schlüsselerzeugung und anderseits für das Sicherstellen von Perfect Forward Secrecy.

Diffie-Hellman

Diffie Hellman gehört zu den Public-Key-Systemen, welcher zum Schlüsselaustausch verwendet wird. Mit Diffie Hellman wird das Problem gelöst, das zwei Personen ein Geheimnis, also in diesem Fall einen Schlüssel, vereinbaren können, auch wenn sie es laut und vor aller Augen der Öffentlichkeit tun müssen, sprich übers Internet. Anhand eines Beispiels soll der Algorithmus von Diffie-Hellman erläutert werden.

Ausgangslage:
Alice und Bob wollen einen gemeinsamen geheimen Schlüssel vereinbaren. Einziges Problem ist der Schlüsselaustausch. Es muss über das unsichere Internet geschehen, wo bekannterweise das Sniffen von Datenpaketen im Netz kein Problem ist.

Voraussetzung:
Alice und Bob verfügen je über zwei Schlüssel. Einer wird als privater Schlüssel bezeichnet und der andere als öffentlicher Schlüssel. Der private Schlüssel muss geheim gehalten werden. Der öffentliche Schlüssel kann für jedermann zugänglich sein.

Person	Privater Schlüssel (512 Bit, je grösser umso besser)	Öffentlicher Schlüssel (grosse Primzahl > 10 100 )
Alice	x	n
Bob	y	g

Damit jetzt Alice und Bob einen geheimen Schlüssel über das Internet vereinbaren können, braucht es nur zwei Datentransfers. Innerhalb dieser zwei Datentransfers befinden sich die nötigen Informationen, damit Alice und Bob ihren geheimen Schlüssel erzeugen können. Dieses Prinzip ist so raffiniert, dass ein Spion, obwohl er diesen Datentransfer aufzeichnet, keine Chance hat, den geheimen Schlüssel herauszufinden. Raffiniert oder?

Wie man sieht, wird im ersten Datentransfer die beiden öffentlichen Schlüssel und das Resultat des Rechenausdrucks ‘g^x mod n’ gesendet. Mit Hilfe dieser Zahl wird dann der geheime Schlüssel berechnet. Bob sendet nun seinerseits den gleichen Rechenausdruck, aber mit dem Unterschied, dass der Exponent diesmal sein privater Schlüssel ist. Nachdem nun beide im Besitz dieser beiden Resultate sind, potenzieren sie es noch mit ihren privaten Schlüsseln. Alice berechnet also (g^x mod n)^y und Bob (g^y mod n)^x . Nun gilt folgender Zusammenhang:
Nach dem Gesetz der modularen Arithmetik ergeben beide Berechnungen (g^(y*x) mod n) .
Somit haben Alice und Bob einen gemeinsamen geheimen Schlüssel erzeugt.

Solange kein Algorithmus existiert, welcher aus den Rechenausdrücken ‘g^x mod n’ und ‘g^y mod n’ die privaten Schlüssel x und y berechnet, kann man den Diffie-Hellman für die Erzeugung eines geheimen Schlüssels verwenden.

Aufgabe von IKE

Nachdem nun das Prinzip von Diffie-Hellman erklärt worden ist, wird jetzt näher auf das IKE Protokoll eingegangen. IKE‘s Hauptaufgabe ist es, das automatische Realisieren der folgenden drei Komponenten für ein sicheres Schlüsselmanagemant:

Authentifikation des Kommunikationspartners

IKE bietet vier verschiedene Authenitfikatonsmethoden an, um sicherzustellen, dass man auch wirklich mit der richtigen Person kommuniziert.

Authentifikation mit Pre-Shared-Key
Authentifikation mit Digitaler Signatur
Authentifikation mit Public-Key-Verschlüsselung
Verbesserte Methode für Authentifikation mit Public-Key-Verschlüsselun

In Rahmen dieser Arbeit gehen wir auf die Authentifikationmethoden mit Pre-Shared-Key und Digitaler Signatur näher ein.

Erzeugen der Security Association SA

Schlüsselerzeugung und Regenerierung Während des IKE Vorganges werden mehrere Schlüssel erzeugt [-> Automatische Schlüs-selverbindung]. Folgende Input-Parameter werden für das Erzeugen der Schlüssel benützt:

Einige Parameter aus den ersten vier Datenpaketen, welche durch die zukünftige sichere Verbindung zwischen den Hosts ausgetauscht werden.
Wahl der Authentisierungsmethode ergibt je nach dem einen anderen Input-Parameter
Parameter, welche mittels Diffie Hellman erzeugt werden

Der Verschlüsselungsschlüssel und Authentifizierungsschlüssel für die eigentliche Nutzdatenübertragung werden dann aus diesen Schlüsseln abgeleitet. Das Regenerieren der Schlüssel nach einer bestimmten Zeit erhöht zusätzlich den Sicherheitsgrad.

ISAKMP/Oakley Protokoll

IKE basiert auf zwei Protokollen, nämlich ISAKMP (Internet Security Association and Key Management Protocol) und Oakley (Name des Entwicklers). ISAKMP gibt dem Rahmen vor für die Authentifikation und den Schlüsselaustausch. Es gibt keine Auskunft, wie es implementiert werden soll. Somit können verschieden Verfahren benützt werden, welche die Rahmenvorstellung von ISAKMP erfüllen. ISAKMP wird in zwei Phasen realisiert:

Phase 1 erzeugt ISAKMP-SA, also diejenige Security Associtaton, welche zuständig ist für die Verschlüsselung der ISAKMP-Datenpaket selbst.
Phase 2 erzeugt die IPSec-SA, die auf die Nutzdaten angewandt wird.

Da ISAKMP den Rahmen vorgibt, übernimmt das Protokoll Oakley die konkrete Ausführung der zwei Phasen. Oakley besitzt folgende drei Modi:

Modus	Anwendung	Aufgabe
Main Modus	Phase 1	Erzeugt ISAKMP-SA
Aggressive Modus	Phase 1	Erzeugt ISAKMP-SA schneller als im Main Modus, aber auf Kosten der Sicherheit
Quick Modus	Phase 2	Erzeugt IPSec-SA

Beim Verbindungsaufbau zwischen zwei Gateways mit IPSec wird die Phase 1 nur einmal durchgespielt. Hingegen die Phase 2 kann mehrere Male für das Regenerieren der Schlüssel, welche in der IPSec-SA angewandt wird, wiederholt werden.

Wie man gesehen hat, authentifiziert IKE Kommunikationspartner, erzeugt und regeneriert Schlüssel und zusätzlich bietet es Schutz gegen verschiedene Attacken, wie

Denial-of-Service [-> Angriffe im Netz]
Man-in-the-Middle [-> Angriffe im Netz]

zurück