Einführung IP Sec


Die VPN / IPSec Theorie


Was ist ein 'Virtual Private Network'

Ein virtuelles privates Netz verbindet lokale Netze (Intranetze) über öffentliche Netze
(Telefonnetz, Internet) miteinander. Der Ausdruck “privat” bedeutet, dass die Verbindung
zwischen Rechnern genauso gut gesichert ist, wie wenn die Rechner zusammen in einem
geschützten lokalen Netz stehen würden. Obwohl die Rechner räumlich durch das öffentliche
Netz getrennt sind, hat man durch das Tunneling-Verfahren eine Situation geschaffen, welche
die Rechner ‘virtuell’ wie in einem lokalen Netz verbindet. Angesichts dieser Gründe folgte
der Name ‘Virtual Private Network’.
Wie erwähnt, werden die Netze über ein unsicheres öffentliches Netz verbunden, trotzdem
sind durch VPN folgende Sicherheitsvoraussetzungen für eine gesicherte Verbindung gegeben:
  • Authentifizierung des Kommunikationspartners
  • Integrität der Informationen, d.h., die gesendeten und empfangenen Daten sind nicht verändert worden
  • Abhörsicherheit durch Verschlüsselung
  • Identitätsverbergung der Kommunikationspartner und Protokollunabhängigkeit ab der dritten Schicht durch Tunneling
  • Schutz des lokalen Netzes vor dem öffentlichen Netz durch einen Firewall
Das Bilden von privaten Netzen ist nicht neu. Die alte Methode verwendet dafür temporäre oder permanent gemietete öffentliche Leitungen vom Telefonnetz , welche somit privat und daher als ‘sicher’ betrachtet werden kann. Die Skizze soll einen Überblick über die alte Methode des Anschlusses an das Firmennetz illustrieren.

Mobile Client und Tele-Heimarbeiter wählen sich mittels eines Modems in das lokale Netz
ein. Je nach Distanz (Ferngespräche) kann das zu sehr teuren Telefonkosten führen.

Verbindungen mittels Mietleitungen zu eigenen lokalen Satellitenbüronetzen mit dem
Firmennetz sind trotz steigendem Konkurrenzkampf der Leitungsanbieter eine teure
Angelegenheit. Die Gebühren einer Mietleitung beinhalten Anschluss und Distanz.

Das benützen des Internets als öffentliches Netz bringt den Unternehmen einige Vorteile:

Einsparungen von 60-80% der Telefonkosten bei Tele-Heimarbeitern und mobile Clients
Ferngespräche bezahlt man jetzt unter Nutzung des Internets zum Ortstarif.
Einsparungen von 20-50% der Kosten von Mietleitungen.
Weltweite Zugriffsmäglichkeiten aufs Internet und somit auf das lokale Firmennetz.
Weniger Hardware und somit weniger Unterhaltsarbeit im Firmennetz, also kein Remote
Access System mit seinen Modems mehr im Firmennetz
. Förderung des E-Commerce übers Internet.

Die Skizze illustriert VPN-Lösungen übers Internet:




Wie man sieht, gibt es verschiedene VPN Architekturen. Allen gemeinsam ist die Benützung
eines Tunnels, das entweder bis zu den Host’s selber geht oder nur bis zum ISP (Internet
Service Provider). Für den kommerziellen Bereich gibt es drei exemplarische Fälle für den
Einsatz von Virtual Private Networks.

VPN Architekturen

End-To-End



Diese ist die sicherste Lösung für ein VPN-Verbindung über das Internet. Der Tunnel mit den
verschlüsselten Daten deckt die ganze Verbindung bis zu den Hosts ab. Dadurch kann eine
Angriff auf der ganzen Verbindungslänge ausgeschlossen werden. Dazu muss jeder an der
verschlüsselten Kommunikation beteiligter Host mit entsprechender VPN-Software
ausgestattet sein. Voraussetzung ist aber, dass die Host-Rechner leistungsfähig sind, damit
der Aufwand und die Verzögerung, welche die VPN-Software naturgemäss mit sich bringt, im
Rahmen bleiben.


Site-to-Site



Bei Site-to-Site tauschen zwei Intranetze mit ihren Stationen Daten übers Internet aus. Die
Kommunikation über das Internet ist verschlüsselt und innerhalb eines Tunnels. Der Vorteil
dieser Art der Verbindung von Rechnern über VPN’s liegt darin, dass keine der lokalen
Arbeitsstationen mit spezieller VPN-Software ausgerüstet sein muss. Da die Gateways die
ganze Arbeit mit der Sicherheit erledigen, ist das VPN für die Rechner im LAN vollständig
transparent. Die Verwendung von sehr leistungsfähigen Security Gateways wird vorausge-
setzt. Neben der Belastung der Hosts senkt dies natürlich den zusätzlichen Verwaltungs-
aufwand für den Administrator durch ein VPN erheblich. Falls das Vertrauen gegenüber dem
Serviceprovider vorhanden ist, kann der ganze Sicherheit-Aufwand dem ISP Internet Service
Provider überlassen werden. Damit überträgt man den administrativen Aufwand und den
Support dem Provider. Aus sicherheitstechnischen Gründen ist das sicher nicht eine optimale
Lösung.




End-to-Site



Bei der End-to-Site Kommunikation handelt es sich um eine Kombination der beiden
vorangegangenen Fälle mit ihren Vor- und Nachteilen. Mit dieser Verbindungsart werden die
mobilen Clients und Tele-Heimarbeiter ins VPN miteinbezogen. Dadurch lassen sich die
vorher schon erwähnten Einsparungen bei den Telefonrechnungen erzielen, so dass in kurzer
Zeit die Kosten für das VPN-Produkt wieder hereingeholt ist. Wie man sieht wählen sich die
Benützer bei ihrem ISP ein und bauen dann eine sichere Verbindung zum Firmennetz auf.


Was für VPN-Protokolle gibt es?

Da das ursprüngliche TCP/IP–Referenzprotokoll des Internets keinen Sicherheitsaspekt
bietet, musste das TCP/IP-Referenzmodell mit Sicherheitsprotokollen ergänzt werden. Auf
dem Internet- Markt gibt es viele Protokolle, welche zur Realisierung eines VPN verwendet
werden können. Die Protokolle können in die verschiedenen Schichten des TCP/IP-
Referenzmodell
eingeteilt werden.

TCP/IP-
Referenzprotokoll
Sicherheits-Protokolle Kurze Beschreibung
Applikationsschicht IPSec (IKE)
S-HTTP

S-MIME


IP Internet Security (Internet Key Exchange)
Secure Hyper Text Transfer Protocol
Sichere Übertragung von WWW-Seiten
Secure Multiprupose Internet Mail Extention Standard zur sicheren Übertragung von
Email
TCP/UDP
Transportschicht
Socks


SSL


Socket Secure Server, Standard zur
Nutzung von Internet-Diensten über einen
Firewall
Secure Sockets Layer, Netscapes Technik
zur sicheren Üertragung von HTTP (Hyper
Text Transfer Protocol)
IP
Vermittlungsschicht
IPSec (AH, ESP)
Paket filtering

IP Internet Security
Firewall

Sicherungsschicht L2TP
PAP
CHAP

Layer 2 Tunneling Protocol
Password Authentication Protocol (PAP)
Challenge Handshake Authentication
Protocol
Bitübertragungsschicht --- ---

In diesem Projekt kommt für die Realisierung des VPN das Sicherheits-Protokoll IPSec zur
Verwendung. Wie man aus der Tabelle entnehmen kann, arbeitet IPSec mit AH, ESP und
IKE.
Zu diesem Modell ist noch zu sagen, dass die Protokolle auf dem dritten Layer die universell-
sten sind, denn die in den höheren Layern schützen nur eine spezifische Anwendung, und die
in den unteren Layern sind mediumspezifisch.


IPSEC - IP Internet Security

Entwickelt und verwaltet wird dieser VPN-Standard von der IETF- Internet Engineering Task
Force. Mit IPSec steht ein allgemein verbindlicher, herstellerübergreifender Standard zur
Verfügung, der den Datenaustausch zwischen unterschiedlichen Security Gateways im
Rahmen einer VPN-Lösung regelt. Die zu verwendeten Protokolle im Rahmen des IPSec-
Standards müssen folgende Aufgaben bewerkstelligen:
  • Authentifikation der Gesprächspartner
  • Integrität der Informationen
  • Verschlüsselung der Informationen
  • Massnahmen gegen Replay-Angriffe
  • Schlüssel Managemen

Um diese Forderungen zu erfüllen, verwendet man das AH- (Authentication Header), ESP-
( Encapsulating Security Payload) und das IKE (Internet Key Exchange) Protokoll.

Bevor diese Protokolle näher betrachtet werden, sollen die zwei Modi vorgestellt werden,
welche IPSec benützt. Je nachdem, ob man intern im lokalen Netzwerk kommuniziert oder
extern über ein öffentliches Netz, hat man die Wahl zwischen Transportmodus und Tunnel-
modus.


Transportmodus

Dieser Modus wird mehrheitlich innerhalb eines sicheren internen Netzes verwendet. Aus
diesem Grund ist der angewendete Sicherheitsgrad geringer als im Tunnelmodus. Das
ursprüngliche Datenpaket wird nur in soweit verändert, wie es nötig ist, um die Protokolle AH
und ESP anzuwenden. Das bedeutet, dass der ursprüngliche IP-Header erhalten bleibt und je
nach dem, ob AH oder ESP angewendet wird, sind die Daten entweder nur authentisiert oder
authentisiert und verschlüsselt.
Das positive dieses Modus ist das Sparen von Rechenzeit, weil die Datenpakete weniger
Rechenintensiv bearbeitet werden müssen. Dies kann zum Beispiel für Echtzeit-
Anwendungen, wie Telefonieren über das Internet, von Bedeutung sein.




Tunnelmodus

Dieser Modus wird für Verbindungen verwendet, welche über ein öffentliches Netz , wie das
Internet geht. Der Tunnelmodus in Verbindung mit dem ESP ist dafür das geeignetste Mittel.
Die ursprüngliche Anwendung von Tunneling ist ein lokales Netz, welches zum Beispiel die
Protokolle NetBIOS (IBM) und IPX (Novell) verwendet, um über ein TCP/IP-Netz zu
übertragen. Dies wird erreicht, indem das originale Datenpaket in einen IP-Datenpaket
‘eingepackt’ über das TCP/IP-Netz übertragen wird. Somit beinhaltet das neue Datenpaket
das urspüngliche Datenpaket als seine Nutzdaten.
Mit dem Ziel einen grösseren Sicherheitsgrad zu erreichen, wird diese Technik in IPSec
angewendet, denn durch das ‘Einpacken’ und zusätzlichem Verschlüsseln mittels ESP wird
das gesamte ursprüngliche Datenpaket verhüllt. Somit bleibt im Tunnelmodus die Identität
der Source- und Destination-Adresse im Verborgenen, oder anders gesagt, die Identität der
Kommunikationspartner bleibt anonym. Das ist ein Vorteil gegenüber dem Transportmodus.

Bezogen auf unser Modell sieht es folgendermassen aus:

Ein weiteres Plus von Tunneling ist die Benützung von privaten IP-Adressen. In der Regel ist
das lokale Netz mit privaten IP-Adressen aufgebaut. Wie man in der Skizze sieht, wird der IP-
Header_ Client (Bsp. 10.0.1.2) in den Nutzdaten des neuen Datenpakets versteckt, welcher
einen IP-Header_SG hat, der routingfähig und somit eine registrierte IP-Adresse (Bsp.
160.85.131.60) hat. Somit kann man also mit nicht routingfähigen Adressen, Datenpakete
durch ein öffentliches TCP/IP-Netz senden.
Nachdem nun die zwei Modi erklärt worden sind, gehen wir nun auf die IPSec Protokolle AH,
ESP und IKE näher ein.


Autentication Header (AH)

Das Authentication-Header-Protokoll (AH) erzeugt bei einem Datenpaket einen zusätzlichen
Header. Dieser Header enthält die nötigen Informationen um eine Authentifikation durchzu-
führen. Eine Authentifikation deckt die folgenden drei Sicherheits-Anforderungen ab:
  • Bestätigung, dass das empfangene Datenpaket vom richtigen Sender kommt
  • Sicherstellen der Datenintegrität
  • Schutz gegen Replay-Angriffe
Die ersten zwei Forderungen werden mittels eines Hashwertes überprüft, welcher durch einen
Hashalgorithmus erzeugt worden ist. Es stehen zwei Hashalgorithmen zur Verfügung:

HMAC-MD5, erzeugt einen Hashwert mit 128 Bit Länge
HMAC-SHA, erzeugt einen Hashwert mit 160 Bit Länge

Der Replay-Angriff wird durch die Angabe der Folgenummer verhindert, den damit kann der
Empfänger erkennen, ob ein Datenpaket wiederholt gesendet wurde. Die Skizze zeigt den
Aufbau eines AH-Headers.



Next Header:


Identifiziert den Typ des Payloads, also ob es sich zum
Beispiel um ein TCP (Nr. 6) oder um ein UDP (Nr. 17)
handelt.
Payload Length: Länge des AH-Headers.
Reserved: Für zukünftige Anwendungen reserviert.
Security Parameter Index SPI:


Dieser Wert ist ein Pointer, welcher auf die Security
Association SA zeigt, welche für dieses Datenpaket zu-
ständig ist.
Sequence Number: Schutz gegen Reply-Angriffe.
Autentication Data:

Hashwert, je nach dem welcher Hashalgorithmus
verwendet wurde ist dieser Eintrag verschieden lang.

Die Anwendung von AH bezogen auf die zwei Modi sieht folgendermassen aus:

AH im Transportmodus:


AH im Tunnelmodus:

Obwohl der AH-Header mittels des Hashwertes das ganze Datenpaket abdeckt, gibt es
einige variable Felder (Bsp. Time to Live, Header Checksum, usw.) , die im Hashwert nicht
berücksichtigt werden, da sie beim Transport vom Ursprungsort zum Zielort verändert werden
und somit den Hashwert ungültig machen würden.

Encapsulating Secutity Payload (ESP)

Der Unterschied zum AH-Protokoll ist, dass bei ESP die Verschlüsselungskomponente
dazukommt. Das heisst, bei diesem Verfahren werden vier Sicherheitsanforderungen erfüllt.
  • Bestätigung, dass das empfangene Datenpaket vom richtigen Sender kommt
  • Sicherstellen der Datenintegrität
  • Schutz gegen Replay-Angriffe
  • Vertraulichkeit der gesendeten Informationen
Durch das zusätzliche Verschlüsseln werden die Informationen vor unberechtigten Lesern
geschützt. Folgende Verschlüsselungsalgorithmen können benutzt werden:
DES_CBC (RFC 2405) Data Encryption Standard_ Cypher Block Chaining
IDEA (RFC 2451) International Data Encryption Standard
Blowfish (RFC 2451)  
3DES (RFC 2451) Triple Data Encryption Standard
CAST_128 (RFC 2451)  
Auch mit ESP wird eine Authentifikation durchgeführt. Im Gegensatz zu AH wird aber nicht
das ganze Datenpaket mit einem Hashwert abgedeckt. Im ESP bleiben die IP-Header
unberücksichtigt.
Kommt ein mit ESP gesendetes Datenpaket beim Empfänger an, dann wird zuerst die
Authentifikation durchgeführt. Falls diese in Ordnung ist, wird die Entschlüsselung
eingeleitet. Mit diese Vorgehensweise soll der Prozessor mit der sehr rechenintensiven
Entschlüsselung nur dann belastet werden, wenn es wirklich notwendig ist. Dadurch
verringert sich die Verletzbarkeit des Computers gegen 'Denial of Service'-Attacken [->
Angriffe im Netz].
Die Skizze zeigt den Aufbau eines ESP-Datenpakets. Wie man sieht, sind durch den höheren
Grad der Sicherheit auch der Umfang an Zusatzinformationen gestiegen.


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ög -
lichkeit 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).


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 bekannter-
weise 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.


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 Nutz-
datenü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]