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: |
|
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 Verbindungen mittels
Mietleitungen zu eigenen lokalen Satellitenbüronetzen mit dem 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 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. |
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. |
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. |
Bei der End-to-Site
Kommunikation handelt es sich um eine Kombination der beiden |
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 |
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. |
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: |
|
Um diese Forderungen zu
erfüllen, verwendet man das AH- (Authentication Header), ESP- Bevor diese Protokolle näher
betrachtet werden, sollen die zwei Modi vorgestellt werden, |
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. |
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. |
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: |
|
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. |
Der Unterschied zum
AH-Protokoll ist, dass bei ESP die Verschlüsselungskomponente dazukommt. Das heisst, bei diesem Verfahren werden vier Sicherheitsanforderungen erfüllt. |
|
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). |
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: |
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. |
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. |
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 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. |
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: |
|
|
|
|
|
|
|
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. |
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: |
|
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 |
|