[ Zurück ] [ Home ] [ Weiter ]

5         Bestandteile eines VPN

In diesem Kapitel wird aufgezeigt, aus welchen Bestandteilen sich ein VPN zusammensetzt. Bis jetzt haben wir erfahren, dass ein VPN im Wesentlichen aus zwei oder mehreren Teilnetzwerken besteht, die verschlüsselt miteinander über ein öffentliches Netzwerk kommunizieren. Ein Teilnetzwerk besteht in diesem Überlegungen nicht nur aus ein paar Rechnern, die miteinander vernetzt sind, sondern hat vielleicht noch Rechner, die spezifische Aufgaben erfüllen. Dies können z.B. Firewalls, Router oder VPN-Gateways sein.

Die Verschlüsselung selbst ist ebenfalls ein wesentlicher Bestandteil eines VPN. Es gibt verschiedene Verschlüsselungsverfahren, die wiederum von unterschiedlichen Netzwerkprotokollen unterstützt werden.

5.1    Protokolle

Ursprünglich war das Internet nicht dafür gedacht, geheime Daten zu transportieren. Im TCP/IP Protokoll wurde keine Möglichkeit vorgesehen, die gesendeten Daten zu verschlüsseln oder anderweitig zu sichern. Durch moderne Internetanwendungen (z.B. E-Commerce) haben sich die Anforderungen geändert. Deshalb wurde eine Reihe von Protokollen zur sicheren Übermittlung von Daten entwickelt und z.T. auch standardisiert. Wie bereits erwähnt setzen diese Protokolle auf verschiedenen Ebenen an. Als vorteilhaft für VPN-Lösungen haben sich Protokolle der Transportschicht erwiesen, da höhere Schichten oft zu anwendungsspezifisch und niedere Schichten mediumspezifisch sind.

5.1.1       IPSec

Die IETF (Internet Engineering Task Force) publizierte 1995 die ersten Papers (RFC 1825 – 1829) die sich mit IPSec beschäftigten. Sie versuchten, einen herstellerunabhängigen, offenen Standard zu entwickeln. IPSec ist ein fixer Bestandteil von IPv6, wurde aber soweit modifiziert, dass es auch mit IPv4 funktioniert.

IPSec selbst ist nur ein Standard, der verschieden Protokolle verwendet.  Folgende Ziele sollen damit erreicht werden:

• Authentizität der Gesprächspartner
• Integrität der übertragenen Daten
• Vertraulichkeit der übertragenen Daten
• Schutz gegen Replay-Angriffe
• Schlüssel Management

Um dies zu erreichen werden dem Datenpaket zwei zusätzliche Informationblöcke hinzugefügt:

• der Authentication Header (AH, RFC 2402)  für die Authentizität
• die Encapsulated Security Payload (ESP, RFC 2406) für die Verschlüsselung und optional auch für die Authentizität

Nun stellt sich die Frage, wofür es noch den AH gibt, wenn die Authentizität schon vom ESP garantiert wird? Grundsätzlich müssen nicht beide Header gleichzeitig vorkommen, sie können aber miteinander kombiniert werden. Außerdem kann IPSec in zwei verschiedenen Modi angewendet werden, dem Transport Mode und dem Tunneling Mode, die wieder verschiedene Kombinationen von AH und ESP ermöglichen.

5.1.1.1       Transport Mode

Beim Transport Mode bleibt der ursprüngliche IP-Header erhalten. Es werden lediglich der AH oder ESP Header nach dem IP-Header eingefügt. Dadurch kann ein Angreifer feststellen, welche Rechner miteinander kommunizieren, da die Source- und Destination-Adresse für jedermann lesbar im Datenpaket enthalten sind.

Der Transport Mode ist aus oben genannten Gründen nicht so sicher wie der Tunneling Mode und wird meistens nur für interne Netzwerke verwendet. Der Vorteil liegt darin, dass nicht soviel Rechenzeit beim Modifizieren der Pakete verbraucht wird.

5.1.1.2       Tunnel Mode

Im Tunnel Mode wird das gesamte Paket in ein neues Paket verpackt, d.h. es bekommt einen neuen IP-Header. So können auch interne IP-Adressen über das öffentliche Netz verschickt werden, da der alte IP-Header mit den internen Adressen von den Routern nicht mehr gelesen wird.

Der Tunnel Mode wird vor allem von Security Gateways verwendet. Das sind Gateways, die den gesamten Datenverkehr verschlüsseln. Vom internen Netzwerk wird das Paket an den Security Gateway geschickt, dieser schickt das Paket im Tunnel Mode über das Internet an den Security Gateway am anderen Standort, dort wird es entschlüsselt und an den Zielrechner gesendet.

5.1.1.3       Authentication Header (AH)

Der AH ist für die Authentizität eines Pakets zuständig, d.h. das Paket kann während des Transports nicht unbemerkt verändert werden. Es wird damit auch sichergestellt, dass der Absender des Pakets derjenige ist, der im IP-Header steht. Dies wird durch eine kryptografische Prüfsumme erreicht. Der AH wird nach dem IP-Header und vor den eigentlichen Daten platziert. Der Inhalt des Pakets wird dabei nicht verändert.

Der AH besteht aus fünf  Feldern:

• Next Header: Identifiziert den Typ des Payloads, also ob es sich zum Beispiel um TCP oder um UDP handelt.
• Payload Length: Länge des AH.
• Security Parameter Index (SPI): Gibt an, welche Sicherheitsprotokolle beim Sender verwendet werden.
• Sequence Number: Schutz gegen Replay-Angriffe.
• Authentication Data: Prüfsumme bzw. Hashwert. Je nach dem welcher Hashalgorithmus verwendet wurde ist dieser Eintrag verschieden lang.

Zur Berechnung der Prüfsumme wird entweder HMAC-MD5 (RFC 2085,  2403) oder HMAC-SHA-1 (RFC 2404) verwendet. Welcher Hashalgorithmus im Paket verwendet wird, ist im SPI festgelegt. HMAC (hash based message authentication code) ist ein relativ neuer Algorithmus der die Sicherheit der bereits etablierten Hashalgorithmen MD5 und SHA-1 erhöht. HMAC-MD5 liefert eine Prüfsumme mit 128 bit, HMAC-SHA eine mit 160 bit.

Die Prüfsumme wird über das gesamte Datenpaket berechnet, lediglich einige variable Felder, die sich während des Transportes verändern können (Time to Live,  Header Checksum, usw.) werden nicht berücksichtigt.

AH im Transport Mode

ursprüngliches Datenpaket

 

Datenpaket mit AH

AH im Tunnel Mode

ursprüngliches Datenpaket

Datenpaket im Tunnel Mode

 

Tunnel Mode mit AH

 

Der AH kann nicht verhindern dass die Daten des Pakets gelesen werden, er stellt aber sicher, dass Modifikationen erkannt werden. Die Sequence Number im AH verhindert auch, dass das selbe Paket ein zweites mal gesendet werden kann. Um den Inhalt gegen unbefugtes Lesen zu schützten braucht man zusätzlich noch den ESP.

5.1.1.4       Encapsulating Security Payload (ESP)

Der ESP ist für die Verschlüsselung des Datenpakets zuständig. Optional kann der ESP auch eine Authentifizierung des Pakets vornehmen. Wie der AH wird auch der ESP-Header nach dem ursprünglichem IP-Header eingefügt. Da die Daten verschlüsselt werden ändert sich natürlich der Inhalt des Datenpakets. Zur Verschlüsselung kann jedes beliebige Verschlüsselungsverfahren verwendet werden, standardmäßig wird bei IPSec aber zumindest das DES-CBS (DES mit Cipher Block Chaining, RFC 2405) Verschlüsselungsverfahren verwendet, das mit einem 56-bit Schlüssel arbeitet.

Der ESP besteht aus folgenden Komponenten:

• Security Parameter Index (SPI): Gibt an, welche Sicherheitsprotokolle beim Sender verwendet werden.
• Sequence Number: Schutz gegen Replay-Angriffe.

Am Ende des Datenpakets werden zusätzlich noch folgende Felder hinzugefügt:

• Padding: 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.

• Padlength: Länge des Paddings.
• Next Header: Identifiziert den Typ des Payloads, also ob es sich zum Beispiel um TCP oder um UDP handelt.
• Authentication Data (optional): Im ESP ist das Erzeugen eines Hashwertes optional, wird in der Regel aber aus Sicherheitsgründen gemacht. Auch wenn die Daten verschlüsselt sind, wäre die Möglichkeit, gegeben die Daten zu verfälschen. Durch den Hashwert wird das unmöglich gemacht.

Padding, Padlength und Next Header bilden zusammen den sog. ESP-Trail.

 Wird eine Authentifizierung des Datenpakets vorgenommen, wird beim Empfänger des Pakets zuerst geprüft, ob die Prüfsumme stimmt. Erst wenn diese richtig ist, wird das Paket entschlüsselt. Das spart Rechnerzeit und vermindert so z.B. die Rechnerbelastung bei „Denial of Service“ Attacken.

Der Unterschied bei der Authentifizierung zum AH besteht darin, dass der IP-Header nicht mit authentifiziert wird, es wäre also möglich, diesen zu verändern. Der ESP alleine wird deshalb nur bei sicheren, internen Netzwerken verwendet.

ESP im Transport Mode

ursprüngliches Datenpaket

Datenpaket mit ESP

 

ESP im Tunnel Mode

ursprüngliches Datenpaket

Datenpaket im Tunnel Mode

Tunnel Mode mit ESP

 

5.1.1.5       Kombinationen

Nach den jeweiligen Anforderungen an ein VPN kann man verschiedene Kombinationen von ESP, AH, Transport Mode und Tunnel Mode verwenden. In der Praxis werden die Kombinationen von den einzelnen VPN-Lösungen teilweise vorgegeben und können nicht immer durch den Administrator selbst verändert werden. Abhelfen kann man sich durch Verwendung von verschiedenen VPN-Lösungen (z.B. eine für intern, eine für extern).

 Bei einer reinen Host-to-Host Verbindung wird der Tunnel Mode nicht viel Sinn machen, durchaus aber eine Kombination von AH und ESP. So ist das gesamte Paket authentifiziert und der Inhalt verschlüsselt.

Eine weiter nützliche Kombination ist die Verbindung von Tunnel Mode, AH und ESP. Diese kommt meist bei Verwendung von VPN-Gateways vor.

Mit dieser Methode werden interne IP-Adressen vor fremdem Zugriff geschützt (weil sie verschlüsselt sind), es ist lediglich die IP-Adresse der beiden VPN-Gateways zu erkennen.

5.1.2       PPTP

Das PPTP (Point to Point Tunneling Protocol) wird vor allem in Windows-basierenden Netzwerken verwendet. Es basiert auf dem PPP (Point to Point Protocol) das dazu entwickelt wurde, um sich bei einem Server über eine Telefonleitung einzuwählen. Weil PPTP ein Bestandteil von Windows NT 4.0 ist, fand es schnell Verbreitung. Am Anfang wurde es nur zur Einwahl beim Server verwendet (Client to LAN), später wurde auch eine LAN to LAN Version entwickelt. PPTP basiert auf dem Layer 2 (im Gegensatz zu IPSec, das auf Layer 3 basiert) und hat dadurch den Vorteil, dass es nicht nur IP tunneln kann, sondern auch IPX und NetBIOS.

PPP wird unter Verwendung einer modifizierten GRE (Generic Routing Encapsulation, RFC 2784) in PPTP eingepackt. So kann eine Einwählverbindung über das Internet getunnelt werden. Die Authentifizierung basiert wie bei PPP auf PAP (Password Authentication Protocol, RFC 1334) und CHAP (Challenge Handshake Authentication Protokoll, RFC 1334). Da PPTP stark mit Windows NT zusammenhängt, kommt auch noch ein von Microsoft erweitertes MS-CHAP zum Einsatz. Zur Verschlüsselung kann PPP verwendet werden, oder mit einer stärkeren Verschlüsselung das MPPE (Microsoft Point-to-Point Encryption).

PPTP ist in Windows NT und Windows 9x integriert. Deshalb wird es oft für Einwahl-VPNs in Windows-Umgebungen verwendet. Ein VPN mit PPTP ist einfach zu implementieren, da schon alle Komponenten im Betriebssystem enthalten sind. Eine Integration in eine vorhandene (Windows-) Umgebung ist damit einfach möglich. Hat man jedoch kein Windows-Netzwerk, so kann der Einsatz von PPTP mehr Schwierigkeiten bereiten, da es nicht für jedes Betriebssystem bzw. Hardware verfügbar ist bzw. nicht vollständig unterstützt wird.

Um einen PPTP-Tunnel aufbauen zu können, muss zuerst eine PPP-Verbindung hergestellt werden. Diese ist für die Erstellung und Beendigung der Verbindung und für die Authentifizierung des Clients zuständig. Nachdem eine PPP Verbindung besteht übernimmt PPTP die Verpackung der PPP-Pakete. Dazu werden zwei verschiedene Typen von Paketen verwendet: Kontroll- und Datenpakete. Jeder bekommt einen eigenen Kanal zugewiesen. Der Kontrollkanal läuft über TCP, der Datenkanal über IP mit Hilfe des GRE.

Die modifizierte Version des GRE, die bei PPTP verwendet wird, enthält zusätzliche Information über die Rufnummer des Clients, die für Zugriffsrechte ausgewertet werden kann, sowie Informationen über die Bandbreite der Verbindung. Der GRE-Header verpackt das PPP-Paket in einem IP-Datagramm. Der Inhalt des PPP-Pakets bleibt dabei weitgehend unverändert.

Da PPTP ein Layer 2 Protokoll ist, gibt es noch ein zusätzliches Feld „Media“. Dieses enthält Informationen, wie der Tunnel übertragen wird. Je nach der vorhandenen Infrastruktur kann dies mittels Ethernet, Frame Relay oder PPP erfolgen.

Es können zwei verschiedene Arten von Tunnels unterschieden werden:

·        Voluntary Tunnels

·        Compulsory Tunnels

5.1.2.1       Voluntary Tunnels (freiwilliger Tunnel)

Der Benutzer stellt den Tunnel selbst her. Gleichzeitig kann der Benutzer andere TCP/IP Verbindungen zum Internet aufbauen, die nicht getunnelt werden. Der Endpunkt auf der Client-Seite ist der Computer des Benutzers.

5.1.2.2       Compulsory Tunnel (verpflichtender Tunnel)

Der Tunnel wird ohne Einfluss und Wissen des Benutzers beim ISP (Internet Service Provider) hergestellt. Beim Benutzer ist also keine zusätzliche Software nötig, für ihn erfolgt das Tunneling völlig transparent. Die Einwahl erfolgt beim RAS (Remote Access Server), der meistens beim ISP stehen wird. Von dort aus wird der gesamte Datenverkehr zum PPTP-Server getunnelt. Der eigentliche PPTP-Client ist also der RAS bzw. ISP. Welche Dienste zur Verfügung gestellt werden, hängt vom Administrator des RAS-Knoten beim ISP ab. Weiters können mehrere Verbindungen über den selben Tunnel laufen, es ist nicht nötig für jeden Benutzer einen eigenen Tunnel zu öffnen.

Der Comupulsory Tunnel erlaubt das Auslagern von VPN-Technologie zum ISP, d.h. der ISP kümmert sich um das VPN. Dabei bleibt aber die Telefonverbindung vom Client zum ISP ungeschützt, was eine mögliche Sicherheitslücke darstellen kann.

5.1.2.3       Authentifizierung und Verschlüsselung

Die Authentifizierung erfolgt wie bei PPP mittels PAP, CHAP oder MS-CHAP. PAP und CHAP haben den Nachteil, dass das Passwort auf beiden Seiten gespeichert sein muss. Bei einem Verbindungsaufbau wird das Passwort außerdem unverschlüsselt übertragen. Bei MS-CHAP wird aus dem Passwort eine MD4-Prüfsumme gebildet um sich anzumelden.

Als Verschlüsselungsart wird die „Microsoft Point-to-Point Encryption“ (MPPE) verwendet die auf dem RSA-RC4 Standard basiert. Der 40-bit Schlüssel wird mit Hilfe der MD4-Prüfsumme des Passworts errechnet. Dieser kann nach einer bestimmten Dauer oder einer bestimmten Datenmenge gewechselt werden.

5.1.3       L2TP

Das L2TP (Layer 2 Tunneling Protocol,RFC 2661) vereint die Vorzüge von PPTP und L2F (Layer 2 Forwarding Protocol, RFC 2341).

PPP wird verwendet um die Verbindung herzustellen. Danach übernimmt L2TP und überprüft, ob der Netzwerk-Server die Verbindung des Client erlaubt. Ist der Tunnel einmal hergestellt, können mehrere Verbindungen gleichzeitig über einen Tunnel geführt werden. Jede Verbindung erhält eine eigene „Call ID“, die in den L2TP-Header geschrieben wird. Es ist aber auch möglich, mehrere Tunnels zwischen Server und Client zu betreiben um z.B. verschiedenen Tunnels verschiedene Bandbreiten zuzuordnen.

Wie beim PPTP gibt es auch beim L2TP Kontroll- und Dateninformationen. Diese werden aber über den selben Kanal gesendet. Wird ein IP-Netzwerk verwendet, werden beide Informationen im selben UDP-Datagramm gesendet. Die Kontrollinformationen sind für die Errichtung, das Management und den Abbruch von Verbindungen innerhalb eines Tunnels zuständig und ebenso für den Zustand des Tunnels selber. Die Dateninformationen entsprechen im wesentlichen den ursprünglichen PPP-Daten. Lediglich einige Medien-spezifische Informationen entfallen.

L2TP bekommt, da es ein Layer 2 Protokoll ist, einen eigenen Media-Header, der Informationen enthält wie der Tunnel übertragen wird. Dies kann per Ethernet, Frame Relay,  X.25, ATM oder PPP erfolgen.

Auch bei L2TP gibt es die beiden Tunnelvarianten „Voluntary Tunnel“ und „Compulsory Tunnel“. Der Server wird „L2TP Network Server“ genannt, der Client beim ISP (Compulsory Tunnel) „L2TP access concentrator“.

5.1.3.1       Authentifizierung und Verschlüsselung

Die Authentifizierung eines Benutzers erfolgt in 3 Phasen:

1. Beim ISP kann entweder die Telefonnummer des Anrufers, die gewählte Telefonnummer oder der Benutzername zur Authentifizierung verwendet werden. Hat sich der Benutzer authentifiziert, so wird ein Tunnel aufgebaut.
2. Nach dem Aufbau des Tunnels vergibt der L2TP Access Concentrator beim ISP eine Identifikationsnummer, die an den Netzwerkserver weitergeleitet wird. Dieser entscheidet aufgrund der erhaltenen Informationen (PAP, CHAP, EAP oder andere Authentifizierungmethoden) ob er die Verbindung zulässt oder nicht.
3. Die dritte Phase ist optional und basiert auf  PPP.

Nachdem sich der Client jetzt authentifiziert hat, ist es immer noch möglich, die übermittelten Daten zu lesen und zu verändern oder gleich eine ganze Verbindung zu übernehmen (Session Hijacking). PPTP und L2TP bieten standardmäßig keine Verschlüsselung an. Deshalb wird bei IP-Netzwerken IPSec verwendet, um den Tunnel zu sichern. Probleme treten auf, wenn kein IP-Netzwerk eingesetzt wird, da der Schlüsselaustausch mittels UDP erfolgt.

5.1.4       Vergleich VPN Technologien

VPN Technology Standards Compared

Aus: Virtual Private Networks, A Partnership Between Service Providers and Network Managers, INFONETICS RESEARCH, 1997

P L2TP IPSec

Notes:    1. Not in standard, not offered

               2. Vendor-specific implementation only

               3. Refers to IPSec for implementation

5.2    Verschlüsselung

5.2.1       Verschlüsselungsverfahren

Es gibt zwei Arten von Verschlüsselungsverfahren:

• Private-Key Verfahren oder auch symmetrische Verschlüsselung
• Public-Key Verfahren oder auch asymmetrische Verschlüsselung

5.2.1.1       Private-Key

Bei einer Private-Key Verschlüsselung gibt es nur einen einzigen Schlüssel, eben den Private-Key. Dieser ist nur den beiden Seiten bekannt. Die Nachricht wird auf der einen Seite verschlüsselt und auf der anderen Seite mit dem selben Schlüssel wieder entschlüsselt. Jeder, der den Schlüssel kennt, kann die Nachricht ebenfalls entschlüsseln.

Bekannte Private-Key Verfahren sind DES, Triple-Des, IDEA und Blowfish. Sie unterscheiden sich im verwendeten Verschlüsselungsalgorithmus und in der Länge des Schlüssels. Je länger ein Schlüssel ist, desto sicherer (oder auch stärker) ist die Verschlüsselung gegen Brut-Force-Angriffe. Mit der Schlüssellänge steigt aber auch der Rechenaufwand.

Eine praktische Anwendung für das Private-Key Verfahren ist z.B. CodedDrag [28] .

 Die Schwierigkeit bei Verwendung dieses Verschlüsselungsverfahrens ist das Schlüsselmanagement. Gibt es in einem VPN z.B. 100 Knoten und alle sollen miteinander verschlüsselt kommunizieren, muss jeder Knoten 99 Schlüssel kennen. Da ein gleicher Schlüssel immer auf beiden Gegenstellen vorhanden sein muss, sind im System 4950 verschiedene Schlüssel erforderlich (AnzahlKnoten * AnzahlBekannterSchlüssel / 2 = 100*99/2).

Sollen diese Schlüssel auch noch periodisch gewechselt werden, ist der Aufwand nicht mehr vertretbar. Gelingt es einem Angreifer, in nur einen dieser Knoten einzudringen, hat er alle geheimen Schlüssel für die Kommunikation zu sämtlichen Knoten.

Ein weiterer Nachteil bei der symmetrischen Verschlüsselung ist die Notwendigkeit eines sicheren Weges zur Schlüsselübertragung. Ohne eine entsprechend sichere Übertragung des Schlüssels ist die Verschlüsselung hinfällig, da jeder, der den Schlüssel bei der Übertragung abfängt, die folgenden Nachrichten entziffern kann. Das wiederum bedeutet, dass ein Schlüsselübertragungsweg gefunden werden muss, der Niemandem bekannt ist oder keinen Zugriff von außen erlaubt. Da die Länge heutiger Schlüssel eine nicht-digitale Form der Schlüssel­über­tragung kaum mehr zulässt, wird dies sehr aufwendig und umständlich.

 Aus den oben genannten Gründen kommen deshalb reine Private-Key Verfahren in VPN-Produkten nicht zur Anwendung

5.2.1.2       Public-Key

Bei dem Public-Key Verfahren gibt es zwei Schlüssel, den geheimen Private-Key und den öffentlichen Public-Key. Dieses Schlüsselpaar wird zuerst auf einer Seite berechnet, der Private-Key bleibt dann geheim auf dem Rechner gespeichert, der Public-Key wird an die Partner versendet oder anderweitig veröffentlicht.

Public-Key Verfahren werden hauptsächlich dazu verwendet, kleinere Nachrichten (z.B. Emails oder geheime Schlüssel) als Ganzes zu verschlüsseln oder um Nachrichten zu signieren. Dabei werden große Schlüssellängen (meist > 1024bit) verwendet da Rechenzeiten keine so große Rolle spielen.

 Ein weiteres Anwendungsgebiet ist der Austausch von Schlüsseln über unsichere Leitungen. So können mit Hilfe der asymmetrischen Verschlüsselungsverfahren Schlüssel für die symmetrische Verschlüsselung ausgetauscht werden, die dann für den weiteren Datenaustausch verwendet werden. Die symmetrische Verschlüsselung ist aufgrund ihrer verwendeten Algorithmen um bis zu 1000 mal schneller als die asymmetrische Verschlüsselung.

RSA (Rivest Shamir Adleman) ist ein Public-Key Verfahren, das zum Signieren von Nachrichten verwendet werden kann. Mit dieser digitalen Signatur wird sichergestellt, dass die Nachricht von der Person kommt, die unterschrieben hat und dass die Nachricht bei der Übermittlung nicht verändert wurde.

Eine weiteres Public-Key Verfahren wird verwendet, um einen gemeinsamen geheimen Schlüssel über ein öffentliches Netzwerk zu vereinbaren. Diffie-Hellman (DH) berechnet aus einem Private-Key und einem Public-Key einen neuen Schlüssel, das sog. „Shared Secret“.

• es existiert eine Primzahl q und eine Zahl z, die beide öffentlich sind. z ist eine ganze Zahl, kleiner als q und teilerfremd zu q, d.h. es ist möglich jede Zahl zwischen 1 und p-1 zu bilden indem man z mit sich selbst multipliziert und dann modulo q.
• Alice berechnet ihren privaten Schlüssel X_a, der kleiner ist als q. Bob berechnet analog dazu X_b.
• Bob und Alice berechnen dann ihren öffentlichen Schlüssel nach der Formel

(x steht hier für a (Alice) und b (Bob))

• Will nun Alice mit Bob kommunizieren, so berechnet sie das Shared Secret K auf folgende Weise:

Bob berechnet das Shared Secret mit:

• Nun haben beide Seiten das selbe Shared Secret und können mit Hilfe einer schnellen symmetrischen Verschlüsselung Daten austauschen.

Geht man davon aus, dass der öffentliche Schlüssel von Bob wirklich zu Bob gehört, beinhaltet dieses Verfahren auch eine Authentifizierung, da ja das Shared Secret nur mit dem richtigen Private Key berechnet werden kann.

5.2.1.3       Hybride Verfahren

Hybride Verfahren kombinieren die hohe Sicherheit von Public-Key Verfahren und die höhere Geschwindigkeit von Private-Key Verfahren.

 Ein Beispiel für ein hybrides Verfahren ist PGP „Pretty Good Privacy“, das beim Austausch von verschlüsselten Emails zum Einsatz kommt. Dabei wird zuerst die zu verschlüsselnde Nachricht komprimiert. Dann wird ein einmaliger Sitzungsschlüssel aus Tastatureingaben und Mausbewegungen erzeugt. Mit diesem Sitzungsschlüssel wird die Nachricht verschlüsselt (symmetrische Verschlüsselung). Anschließend wird der Sitzungsschlüssel mit dem Public-Key des Empfängers verschlüsselt (asymmetrische Verschlüsselung) und an die Nachricht angehängt.

Die Entschlüsselung erfolgt in umgekehrter Reihenfolge. Der Empfänger entschlüsselt zuerst mit seinem Private-Key den Sitzungsschlüssel, mit dem er wiederum die Nachricht entschlüsseln kann. Nach dem Dekomprimieren hat der Empfänger die Nachricht in ihrer ursprünglichen Form.

5.2.2       Schlüsselmanagement

Je nach verwendetem Protokoll der VPN-Verbindung werden verschiedene Verschlüsselungstechniken angewendet. Alle Verschlüsselungstechniken arbeiten mit einem bestimmten Schlüssel, mit dem die Daten auf einer Seite verschlüsselt und auf der anderen Seite wieder entschlüsselt werden. Dazu müssen auf beiden Seiten die selben Schlüssel bzw. Schlüsselpaare verwendet werden, d.h. die beiden Seiten müssen sich auf gemeinsame Schlüssel einigen.

Am gebräuchlichsten sind zur Zeit folgende Möglichkeiten:

• manueller Austausch der Schlüssel
• SKIP (Simple Key Management for Internet Protocols, [29] )
• Internet Key Exchange (IKE, RFC 2409)

Beim manuellen Austausch wird auf einer Seite ein Schlüssel erzeugt und dieser dann auf sichere Weise an die andere Seite übermittelt. Dies kann geschrieben auf einem Blatt Papier geschehen oder man speichert den Schlüssel auf eine Diskette.

SKIP wurde von SUN entwickelt, konnte sich aber nicht wirklich durchsetzten und wird von der IPSec Working Group nicht unterstützt. SKIP Implementationen fanden sich nur vereinzelt in VPN-Produkten und werden von neueren Versionen meist nicht mehr unterstützt.

Bei einer größeren Anzahl an Schlüsseln ist der manuelle Austausch unpraktikabel. Deshalb wurde IKE entwickelt, ein Framework, der den sicheren Austausch von Schlüsseln über das Internet ermöglicht. IKE setzt sich wiederum aus zwei Protokollen zusammen, „Internet Security Association and Key Management Protocol“ (ISAKMP) und Oakley. In der Praxis treten deshalb entweder der Name ISAKMP/Oakley oder nur kurz IKE auf.

IKE soll folgendes garantieren:

• beide Seiten verwenden die selben Protokolle, Verschlüsselungsverfahren und Schlüssellängen.
• der Partner ist der, der er vorgibt zu sein.
• das Management der Schlüssel
• der Schlüsselaustausch ist sicher

IKE besteht aus zwei Phasen. In der ersten Phase wird ein sicherer Tunnel etabliert, über den dann alle ISAKMP Transaktionen geleitet werden. Dazu werden Hash- und Verschlüsselungsalgorithmen ausgetauscht, beide Seiten identifiziert und ein starker (>1024bit) Sitzungsschlüssel generiert. In der zweiten Phase werden allgemeine Sicherheitsvereinbarungen ausgetauscht. Es werden Sitzungsschlüssel erzeugt, die nicht so stark sind (aber dafür schneller) und keine sehr lange Lebensdauer haben. Die erste Phase wird zu Beginn eines Verbindungsaufbaues stehen, während die Phase zwei  regelmäßig neu durchgeführt wird (z.B. jede Stunde).

Für den sicheren Tunnel muss vorher folgendes in einer sog. Security Association (SA) festgelegt werden:

• ein Verschlüsselungsalgorithmus
• Ein Hashalgorithmus
• eine Authentifizierungsmethode
• Informationen über den Diffie-Hellman Schlüsselaustausch

Oakley kennt drei verschiedene Modi um Informationen auszutauschen: Main Mode und Agressive Mode sind für die Phase eins und der Quick Mode für die Phase zwei.

5.2.2.1       Main Mode

Der Main Mode erfordert drei mal den Austausch von Daten zwischen beiden Seiten. Beim ersten Austausch einigen sich beide Seiten auf grundlegende Hash- und Verschlüsselungsalgorithmen. Beim zweiten Austausch werden die Public Keys für Diffie-Hellman sowie Zufallszahlen übermittelt. Diese Zufallszahlen werden von der Gegenseite signiert und im dritten Datenaustausch zurückgesendet. Diese Signatur wird am Ende überprüft.

5.2.2.2       Aggressive Mode

Der Aggressive Mode hat die selbe Aufgabe wie der Main Mode, allerdings werden hier nur 3 Pakete anstatt 6 ausgetauscht. Der Sender schickt gleich mit dem ersten Paket alle notwendigen Informationen mit. Das sind der Diffie-Hellman Public Key, die Zufallszahl und die ID (Zertifikat). Der Empfänger schickt mit dem nächsten Paket genug Informationen um die Phase eins abzuschließen. Das dritte Paket dient nur mehr zur Bestätigung des Verbindungsaufbaues.

5.2.2.3       Quick Mode

Quick Mode ist einfacher als die anderen beiden Modi, weil bereits ein sicherer (verschlüsselter) Tunnel existiert. Alle Quick Mode Pakete haben am Anfang einen Hash-Code, der das ganze gesendete Paket sichert. Der Sender schickt im ersten Paket seinen Hash und eine Zufallszahl. Der Empfänger generiert aus der empfangenen Zufallszahl und einer Eigenen einen neuen Hash, den er dem Sender samt seiner eigenen Zufallszahl zurückschickt. Der Sender schickt dann zur Bestätigung noch einmal einen neuen Hash über beide Zufallszahlen an den Empfänger. Zum Abschluss wird auf beiden Seiten aus den beiden Zufallszahlen und dem Sitzungsschlüssel aus der ersten Phase ein neuer Hash gebildet, der zum neuen Sitzungsschlüssel für Phase zwei wird.

5.3    Certification Authority (CA) und Public Key Infrastructure (PKI)

Eine CA ist eine Instanz, die Datensätze (sog. Zertifikate), bestehend aus den Benutzerinformationen, dem Public-Key und weiteren spezifischen Daten (z.B. Ablaufdatum des Schlüssels) verwaltet. Von der CA wird zu den Datensätzen noch eine digitale Signatur angehängt, was zusammen dann ein Zertifikat ergibt.

Der verbreitetste Standard für Zertifikate ist X.509 in der Version 3 und legt fest, welche Informationen in den Zertifikaten abgelegt sein müssen.

Bekommt jemand eine signierte Nachricht, enthält das mitgeschickte Zertifikat alle notwendigen Informationen um die Nachricht zu authentifizieren und zu überprüfen. Zuerst muss das Zertifikat mit dem Public-Key der CA überprüft werden. Mit dem Public-Key des Zertifikats kann wiederum die Signatur der empfangenen Nachricht geprüft werden.

Auf diese Art und Weise können über eine CA Public-Key’s ausgetauscht werden. Das einzige was benötigt wird ist der Public-Key der CA der unbedingt auf sichere Weise ausgetauscht werden muss.

Dabei wirft sich die Frage auf, welchen CA‘s man vertrauen kann. Dafür gibt es die PKI, die „Public Key Infrastructure“, die in drei Kategorien unterteilt werden kann:

• Zentrale Zertifizierungsstelle. Alle Zertifikate werden von einer einzigen CA unterzeichnet und meist manuell an die Hosts verteilt.
• Hierarchische Zertifizierung. Die Zertifikate der lokalen CA’s werden von übergeordneten Instanzen unterzeichnet. An der Spitze der Hierarchie steht in der Regel eine anerkannte Institution (Root CA).
• Vertrauensgeflecht (Web of Trust). Jeder Host kann sich selber als CA betätigen und Zertifikate unterzeichnen. Darum liegt es am Benutzer zu entscheiden, wem er vertrauen will und wem nicht. Dieses Konzept wird z.B. bei Pretty Good Privacy (PGP) verwendet.
  Jeder Benutzer von PGP erhält Zertifikate von anderen Benutzern. Diese sind solange ungültig, bis sie vom Benutzer genehmigt (unterschrieben) werden. Dabei kann der Benutzer den anderen Benutzern verschiedene Vertauensstufen zuordnen. Bei der geringsten Stufe werden erhaltenen Zertifikate automatisch als „nicht vertrauenswürdig“ eingestuft. Bei der höchsten Stufe vertraut man jedem Zertifikat, dem auch der als vertrauenswürdig eingestufte Benutzer vertraut, d.h. diese Zertifikate werden automatisch unterschrieben.

Bei einigen VPN-Lösungen sind bereits Programme inkludiert, mit denen man seine eigene CA aufbauen kann, sonst muss man auf z.T. frei verfügbare CA-Server-Software im Internet (z.B. Open SSL unter www.openssl.org) zurückgreifen. Der Einsatz eines eigenen CA-Servers ist aber erst bei einer größeren Anzahl von Zertifikaten (ca. > 20) zu empfehlen. Dieser kann nicht nur für das VPN verwendet werden, sondern auch um jedem Mitarbeiter ein Zertifikat auszustellen, mit dem er seine Emails signiert.