SecIE e.v. Interoperabilität. Interoperabilität von Geräten zum Aufbau von Virtual Private Networks (VPN) Themengebiet. Task

Transkript

1 SecIE e.v. Verein zur Förderung von Security im Industrial Ethernet Themengebiet Interoperabilität Task Interoperabilität von Geräten zum Aufbau von Virtual Private Networks (VPN) Dokument Version : Draft / Final Letzte Bearbeitung : Mittwoch, 21. Oktober 2009 Classification : Intern Contact : Themengebietsleiter : PD Dr.-Ing. habil. A. Lüder

2 Inhaltsverzeichnis 1 Einleitung Virtual Private Networks Grundlegende Architekturen Site-to-Site Kommunikation Site-to-End Kommunikation Host-to-Host Kommunikation Technologien Verschlüsselungsmethoden Zertifikate IPSec SSL/TLS PPP L2TP PPTP SSH CIPE OpenVPN ViPNet Anwendung Geräte zum Aufbau von Virtual Private Networks... Fehler! Textmarke nicht definiert. 3.1 Xx1 (Hirschmann)... Fehler! Textmarke nicht definiert. 3.2 Xx2 (Nortel)... Fehler! Textmarke nicht definiert. 3.3 Xx3 (Weidmüller)... Fehler! Textmarke nicht definiert. 4 Interoperabilitätstests... Fehler! Textmarke nicht definiert. 4.1 Testaufbau... Fehler! Textmarke nicht definiert. 4.2 Ausgeführte Tests... Fehler! Textmarke nicht definiert. 5 Referenzen...27 SecIE e.v. 2

3 1 Einleitung Ziel dieses Dokumentes ist die Beschreibung der Technologie der Virtual Private Networks (VPN) und ihrer Anwendung in der Industrieautomation. Besonderen Wert legt dabei dieses Dokument auf die Darstellung der Interoperabilität von Geräten verschiedener Hersteller. Ein Virtual Private Network (VPN) ist ein virtuelles Computernetzwerk, das zur Übermittlung von privaten Daten auch die Nutzung eines öffentlichen Netzwerkes zulässt. Dabei ist es für die einzelnen Kommunikationsteilnehmer zumeist transparent, ob ein öffentliches Netzwerk verwendet wird oder nicht, d.h. für jeden Teilnehmer wirkt die Datenübertragung wie eine Übertragung innerhalb eines internen LAN. Ein VPN verbindet dabei zumeist Teilnetzwerke über so genannte Tunnel. Die Tunnel werden jeweils zwischen zwei Teilnetzwerken aufgebaut, wie es in der folgenden Grafik dargestellt ist. Teilnetz 1 Teilnetz 2 Endgerät Endgerät Endgerät Internet VPN Tunnel Endgerät Endgerät Switch/Hub VPN fähiges Infrastrukturgerät VPN fähiges Infrastrukturgerät Switch/Hub Endgerät Vcc1 b1 a1 6 3 b2 a2 7 4 b3 a3 8 b4 a Vcc1 a1 b1 2 7 a2 b2 3 8 a3 b3 4 a4 b4 Endgerät Endgerät Vcc1 b1 a1 6 3 b2 a2 7 4 b3 a3 8 b4 a Vcc1 a1 b1 2 7 a2 b2 3 8 a3 b3 4 a4 b4 Endgerät Abbildung 1-1: Prinzipielle Struktur eines VPN Endgerät Grundsätzlich gibt es dabei 3 Varianten von VPN bezüglich der Größe der einzelnen Teilnetze und der Kombination der verschiedenen in diesen Teilnetzen genutzten aktiven Infrastrukturkomponenten. Werden zwei lokale Netzwerke mit mehreren Endgeräten über einen VPN Tunnel verbunden, dann spricht man von einer site-to-site Architektur. Beide Teilnetze werden mit je einem VPN Gateway pro Teilnetz verbunden, die gemeinsam den VPN Tunnel etablieren. Endgeräte des einen Teilnetzes benutzen den Gateway ihres Teilnetzes zur Datenübertragung an das andere Teilnetz. Damit werden alle in Abbildung 1-1 genannten aktiven Infrastruktur in dieser Architektur verwendet. Es kann jedoch der Switch/Hub als VPN fähige Infrastrukturkomponente gestaltet sein. Wichtigste Anwendungsfälle dieser Architektur sind die Verbindung von zwei Unternehmenstandorten, die Verbindung von zwei Fertigungszellen, oder die Verbindung von mehreren Standorten eines Energieversorgungsnetzwerkes. SecIE e.v. 3

4 Soll ein einzelnes Endgerät mit einem Teilnetz verbunden werden, dann sprich man von einer Site-to-End Architektur. Das einzelne Endgerät ist in dieser Architektur mit einer VPN fähigen Netzwerkschnittstelle ausgestattet. Das Teilnetz besitzt ein VPN Gateway. Das Endgerät und das VPN Gateway etablieren gemeinsam den VPN Tunnel. Das einzelne Endgerät benutzt den VPN Gateway zur Kommunikation mit den Endgeräten des Teilnetzes. Für dieses einzelne Endgerät stellt sich die Kommunikation mit den Endgeräten des Teilnetzes genau so dar wie die Kommunikation in einem lokalen Netzwerk. Ein sehr wichtiger Anwendungsfall dieser Architektur ist der Remote-Access auf Geräte eines Fertigungsnetzes zum Zwecke der Fernwartung, Ferndiagnose und Fernüberwachung. In besonders sicherheitskritischen Anwendungsfällen kann es notwendig sein, zwei Endgeräte direkt mit einander zu verbinden. Diese Architektur nennt man Host-to-Host Architektur. Sie setzt voraus, dass beide Endgeräte mit VPN fähigen Netzwerkschnittstellen ausgestattet sein müssen. Für beide Endgeräte stellt sich damit die wechselseitige Kommunikation wie eine Kommunikation über ein Kreuzkabel dar. Diese Architektur wird jedoch selten eingesetzt. Anwendungsfälle dieser Architektur sind nur in hoch sicherheitsrelevanten Systemen zu finden, wie sie zum Beispiel im Rahmen von Transaktionssystemen im Bankenbereich oder in der Atomindustrie auftreten. Der Begriff Private in VPN suggeriert zumeist, dass die Datenübertragung in einem VPN gegen den Einblick anderer Kommunikationsteilnehmer gesichert ist. Das ist jedoch nicht notwendig der Fall. Es wird dabei in VPN zwischen Transportmodus für den ungesicherten Datentransport und dem Tunnelmodus für den gesicherten Datentransport unterschieden. Im Tunnelmodus erfolgt eine Verschlüsselung der Daten. Zur Implementierung von VPN können verschiedenste Technologien verwendet werden. Da sich die industriellen Kommunikationssysteme in den letzten Jahren durch die steigende Anwendung von Ethernet basierten Kommunikationsprotokollen stark verändert haben, sich derzeit für die Implementierung von VPN voranging (aber nicht nur) Technologien von Interesse, die auf der Struktur der Ethernet TCP/IP Protokollfamilie und den auf dieser Protokollfamilie aufbauenden Anwendungsprotokollen wie http oder FTP aufbauen und diese sicherheitsgerichtet erweitern. Wichtigste (weil weit verbreitete) Protokollerweiterungen bilden hier IPSec, dass direkt das IP Protokoll nutzt, und SSL/TSL, dass eine Erweiterung des http Protokolles darstellt. Diese und weitere relevante Technologien sollen in dieser Arbeit betrachtet werden. Ein weiterer wichtiger Bestandteil der Technologiegruppe zur Implementierung von VPN stellen Verschlüsselungsverfahren dar. Sie werden im Rahmen von VPN genutzt um die Daten in einem VPN Tunnel gegen den Zugriff Dritter zu schützen. Es existieren verschiedenste Verschlüsselungsverfahren, die sich sowohl in ihrer Schlüsselstruktur (symmetrische Schlüssel / asymmetrische Schlüssel) wie auch in der Struktur der Verschlüsselung selbst unterscheiden. Es können im Rahmen dieser Arbeit nur einige der wichtigsten Verschlüsselungsverfahren betrachtet werden. Im Folgenden soll die Technologiefamilie der VPN detaillierter beschrieben werden. Dazu wird auf die grundsätzlichen Architekturen, die verwendbaren Technologien zur Verschlüsselung und gesicherten Übertragung, und mögliche Anwendungsfälle eingegangen. Im Anschluss auf die Technologiebeschreibung wird auf die notwendigen Geräte zur Implementierung und deren Interoperabilität eingegangen. Ziel ist dabei die Beschreibung der Konfiguration von Infrastrukturgeräten und deren möglich Zusammenarbeit in (bezüglich der Hersteller) heterogenen Systemen. 2 Virtual Private Networks Ziel dieses Abschnittes ist die Darstellung der verschiedenen im Rahmen der VPN Technologiefamilie nutzbaren Technologien und Spezifikationen zur Implementierung eines Virtual Private Networks. Dabei sollen zum ersten die grundlegende Architektur eines VPN beschrieben, dann die verschiedenen im Rahmen dieser Architektur anwendbaren SecIE e.v. 4

5 Technologien und abschließend mögliche Anwendungen der beschriebenen Technologien beschrieben werden. 2.1 Grundlegende Architekturen Dieser Unterabschnitt beschreibt detailliert die grundlegenden Architekturen eines VPN, die in der Einleitung bereits genannt wurden und benennt die verschiedenen an diesen Architekturen beteiligten Geräte/Systeme Site-to-Site Kommunikation Die verbreitetste Nutzung von VPN geschützten Kommunikationsbeziehungen bezieht sich auf den Schutz der Kommunikation zwischen zwei Kommunikationsnetzen durch einen geschützten Kommunikationskanal. Diese Nutzung nennt man Site-to-Site Kommunikation. Sie ist dadurch charakterisiert, dass ein oder mehrere VPN Tunnel zwischen zwei Infrastrukturgeräten aufgebaut werden, die die Grenze zweier Kommunikationsnetze zu ihrer Umwelt und damit zum ungeschützten Bereich bilden. Dies ist in der nachfolgenden Grafik dargestellt. Öffentliches ungeschütztes Netzwerk Netzwerk Netzwerk VPN Tunnel Im Rahmen der Site-to-Site Kommunikation werden alle Kommunikationsverbindungen, die zwischen den beiden Kommunikationsnetzen über das ungeschützte Netz aufgebaut und genutzt werden zwischen den beiden Netzwerkzugangpunkten in einem oder mehreren VPN Tunneln zusammengefasst und verschlüsselt. Hauptanwendungsfall der Site-to-Site Kommunikation ist die Kommunikation zwischen zwei Standorten eines Unternehmens bzw. einer Behörde. Dabei ist die Größe der beiden Standorte irrelevant. Als Beispiele können die Anbindung von dezentralen Stationen von Energieversorgungsunternehmen an die Leitstelle, die Kommunikation zwischen Produktionsstandorten und Unternehmenszentrale, oder die Kommunikation zwischen verschiedenen Standorten des Bundesinnenministeriums Site-to-End Kommunikation Eine weitere Variante der Nutzung VPN geschützter Kommunikationsbeziehungen bezieht sich auf den Schutz der Kommunikation zwischen einem Kommunikationsnetz und einem Endgerät in einem ungeschützten Netzwerk durch einen geschützten Kommunikationskanal. Diese Nutzung nennt man Site-to-End Kommunikation. Sie ist dadurch charakterisiert, dass ein oder mehrere VPN Tunnel zwischen einem Infrastrukturgerät und einem Endgerät (zumeist einem PC oder Laptop) aufgebaut werden, wobei das Infrastrukturgerät die Grenze eines Kommunikationsnetzes zu seiner Umwelt und damit zum ungeschützten Bereich bilden. Dies ist in der nachfolgenden Grafik dargestellt. SecIE e.v. 5

6 Öffentliches ungeschütztes Netzwerk Netzwerk VPN Tunnel Im Rahmen der Site-to-End Kommunikation werden alle Kommunikationsverbindungen, die zwischen dem Kommunikationsnetz und dem Endgerät über das ungeschützte Netz aufgebaut und genutzt werden, zwischen dem Netzwerkzugangpunkt und dem Endgerät in einem oder mehreren VPN Tunneln zusammengefasst und verschlüsselt. Hauptanwendungsfall der Site-to-End Kommunikation ist die Kommunikation zwischen einem Unternehmensstandort bzw. einem Behördenstandort und einem externen Gerät. Als wichtigstes Beispiel der Anwendung kann das Homeoffice angesehen werden, bei der zumeist ein privater Arbeitsplatzrechner virtuell an ein geschütztes Netzwerk angeschlossen wird Host-to-Host Kommunikation Eine dritte Variante der Nutzung VPN geschützter Kommunikationsbeziehungen bezieht sich auf den Schutz der Kommunikation zwischen zwei Endgerät in einem ungeschützten Netzwerk durch einen geschützten Kommunikationskanal. Diese Nutzung nennt man Hostto-Host Kommunikation. Sie ist dadurch charakterisiert, dass ein oder mehrere VPN Tunnel zwischen zwei Endgeräten aufgebaut werden, die beide in einem ungeschützten Netzwerk positioniert sind. Dies ist in der nachfolgenden Grafik dargestellt. Öffentliches ungeschütztes Netzwerk VPN Tunnel Im Rahmen der Host-to-Host Kommunikation werden alle Kommunikationsverbindungen, die zwischen den beiden Endgeräten über das ungeschützte Netz aufgebaut und genutzt werden, zwischen den Endgeräten in einem oder mehreren VPN Tunneln zusammengefasst und verschlüsselt. Hauptanwendungsfall der Host-to-Host Kommunikation ist die Kommunikation zwischen einer Maschine und einem externen Gerät wie sie zum Beispiel im Falle der Fernwartung gegeben ist. Es ist festzustellen, dass in der praktischen Anwendung häufig Site-to-Site Kommunikation und Host-to-Host Kommunikation verbunden werden. Dies ermöglicht eine skalierbare Sicherheit der Kommunikationsverbindungen und eine klare Zuweisung von Rechten an einzelne Geräte bzw. Personen. 2.2 Technologien Dieser Abschnitt beschreibt die Technologien, die zur Implementierung eines VPN genutzt werden können. Er beschreibt damit die Basis für die verschiedenen Konfigurationsmöglichkeiten von VPN Geräten. SecIE e.v. 6

7 2.2.1 Verschlüsselungsmethoden Verschlüsselnde Sicherheitsalgorithmen sind ein wichtiger Grundbaustein für die Kommunikationssicherheit. Sie dienen der Verhinderung der Einsicht Dritter in übertragende Daten durch deren gezielte unleserlich Machung mit anschließender Wiederherstellung der Daten. Prinzipiell gibt es zwei Typen von Verschlüsselungsalgorithmen. Symmetrische Verschlüsselungsalgorithmen sind einfach zu implementieren, sind schnell und werden für einen Großteil der Verschlüsselungen verwendet. Asymmetrische Verschlüsselungsalgorithmen sind langsam im Vergleich zu symmetrischen Verschlüsselungsalgorithmen, aber sie haben große Vorteile, die die Verteilung von Schlüsseln betreffen Symmetrische Verschlüsselungsalgorithmen Allgemeines Symmetrische Verschlüsselungstechniken benutzen einen gemeinsamen Schlüssel für die Verschlüsselung vertraulicher Datenkommunikation. Dieser Schlüssel muss allen mit der Kommunikation beschäftigten Partnern bekannt sein. Symmetrische Techniken sind sehr relevant in der Praxis, weil die Verschlüsselungs- und Entschlüsselungsalgorithmen normalerweise auf einfachen Vorgängen (Shifts, XOR) basieren und leicht in Hard- oder Software implementiert werden können. Der symmetrische Verschlüsselungscode wird beinahe in allen Sicherheitsmechanismen verwendet, um Bedrohungen der Vertraulichkeit abzuwehren. Block- und Datenstromcode Symmetrische Verschlüsselungsalgorithmen können in Datenstrom- und Blockcodes eingeteilt werden. Datenstromcodes benutzen einen geheimen Schlüssel, um einen Datenstrom von Schlüsselsymbolen zu produzieren. Diese Schlüsselsymbole sind mit Symbolen des einfachen Texts kombiniert. Für die Kombination wird eine invertierbare Funktion wie XOR verwendet. Ein Schlüsselsymbol ist eine Zeichenfolge von Bits einer definierten Länge, zum Beispiel 1 Bit oder 8 Bits. Wenn Datenstromcodes genutzt werden, ist es wichtig, verschiedene Schlüsseldatenströme für die Verschlüsselung von verschiedenen Meldungen zu verwenden. Wenn dieselben Schlüsseldatenströme für verschiedene Meldungen verwendet werden, ist es möglich, Information über die Originalmeldung zu erschließen. Blockcodes arbeiten mit Blöcken des einfachen Texts, um die Originaldaten zu verschlüsseln. Jeder Block wird von demselben Schlüssel verschlüsselt. Blockcodes werden in verschiedenen Betriebsmodi verwendet: o ECB: Electronic Code Book mode Die Originalmeldung ist in Blöcke geschnitten. Jede dieser Blöcke ist einzeln verschlüsselt. ECB ist verletzlich gegenüber unerkannten Änderungen und das Einfügung von Blöcken. Daher soll ECB nur für kurze Meldungen wie Schlüssel verwendet werden. o CBC: Cipher Block Chaining Im CBC-Modus ist jeder einfache Textblock mit dem vorherigen Blockcode über ein XOR verkettet (XORed) und damit ist das Ergebnis verschlüsselt. Der erste Block ist mit einem so genannten Initialisierungsvektor verschlüsselt, der per Zufall gewählt werden sollte. CBC ist gut für die Verschlüsselung von Massendaten geeignet. Datenverschlüsselungsstandard (DES) Der Datenverschlüsselungsstandard ist eine CBC basierter Algorithmus mit einem 64 Bit Eingangsblock und einer Schlüssellänge von 64 Bit. Aber nur 56 Bit des Schlüssels sind relevant, so dass DES eine effektive Schlüssellänge von 56 Bit hat. DES ist ein symmetrischer Algorithmus, der für Verschlüsselung und SecIE e.v. 7

8 Entschlüsselung verwendet werden kann. Bitpermutation, Ersetzung und Addition einzelner Bits sind kombiniert. DES ist im Allgemeinen als ein sicher verschlüsselter Algorithmus angesehen, aber heute wird häufig vereinbart, dass 56-Bit Schlüssel nur geringfügigen Schutz vor Angriffen bieten. Triple DES (3DES) Eine Möglichkeit die Schwäche von DES zu entfernen, ist die Schlüssellänge zu erhöhen. Dreifaches DES verwendet drei Verschlüsselungen mit drei verschiedenen Schlüsseln. Er hat dabei eine Schlüssellänge von 192 Bit. Da es nur 56 Bit für eine einzelne DES- Verschlüsselung sind, führt dies zu einer Schlüssellänge von 168 Bit. Aufgrund spezieller Angriffstypen gegen Multiverschlüsselung mit DES (Man-in-the-Middle- Attack) hat 3DES eine effektive Schlüssellänge von 108 Bit. Weil 3DES drei DES- Verschlüsselung erfordert, ist seine Leistung eher schwach. Fortschrittlicher Verschlüsselungsstandard (AES) Der Rijndael-Verschlüsselungsalgorithmus ist 2001 vom nationalen Institut für Standards und der nationalen Technik (NIST), als der neue Verschlüsselungsstandard und als der Nachfolger von DES angenommen worden. Nach der Auswahl von der NIST, wurde der Verschlüsselungsalgorithmus Advanced Encryption Standard (AES) (Fortschrittlicher Verschlüsselungsstandard) genannt. Rijndael ist ein symmetrischer Blockcode mit variabler Block- und Schlüssellänge. Jeder einfache Textblock ist mit einer Folge von Funktionen in mehreren Runden verarbeitet. Die Anzahl von Runden hängt vom Schlüssel und von der Blocklänge ab. Für AES wird der Rijndael-Algorithmus mit einer Blockgröße von 128 Bit und mit Schlüssellänge von 128, 192 und 256 Bit verwendet Der Rijndael-Algorithmus wurde so gestaltet, dass er in Hard- und Software wirksam ausgeführt werden kann. Die vom Algorithmus geforderten Ressourcen ermöglichen auch eine wirkungsvolle Implementierung für Smart Cards. RC6 RC6 wurde von Ronald Rivest und einer Gruppe aus den RSA-Labors entwickelt. Der RC6- Algorithmus wird von US-Patenten geschützt. RC6 ist ein Blockcode, der eine variable Blockgröße, Schlüssellänge und eine variable Anzahl von Runden verwendet. Die Maximalschlüssellänge ist 2040 Bit. RC4 RC4 ist ein von Ronald Rivest für RSA-Sicherheit entworfener Datenstromcode. Er ist ein Datenstromcode mit variabler Schlüssellänge mit byte-orientierten Operationen. Der Algorithmus basiert auf der Verwendung einer zufälligen Permutation. Acht bis sechzehn Maschinenvorgänge sind pro Ausgabebyte erforderlich und es kann erwartet werden, dass der Code sehr schnell in der Software läuft. Unabhängige Analytiker haben den Algorithmus untersucht und als sicher betrachtet. Blowfish Blowfish wurde 1994 auf der Basis von Arbeiten von Bruce Schneier erstmal veröffentlicht. Er hat als Blockchiffrecodierung eine fixe Blocklänge von 64 Bit und basiert auf der Nutzung von 32 bis 448 Bit langen Schlüsseln. Die Ver- und Entschlüsselung bei Blowfish erfolgt Rundenweise unter Nutzung der Feistelnetzwerkstruktur. Aufgrund dieser Netzwerkstruktur ist zur Entschlüsselung kein expliziter Umkehralgorithmus notwendig. Es wird der selbe Algorithmus jedoch mit umgekehrter Schlüsselreihenfolge verwendet. Blowfish ist öffentlich verfügbar und kann vollständig Lizenzfrei verwendet werden Asymmetrische Verschlüsselungsalgorithmen Allgemeines SecIE e.v. 8

9 Symmetrische Verschlüsselungsalgorithmen haben einen entscheidenden Nachteil. Da sie mit einem einzigen Schlüssel (oder einer festen Menge von Schlüsseln) für die Ver- und die Entschlüsselung arbeiten, ist die Geheimhaltung dieses Schlüssels unbedingte Voraussetzung für die sichere Funktionalität dieser Verfahren. Jedoch muss dieser Schlüssel sowohl beim Absender als auch beim Empfänger vorliegen. Somit wird der Transfer dieses Schlüssels zu einem schwierigen Problem. Es wird hier ein zusätzlicher, abgesicherter Kommunikationsweg benötigt. Asymmetrische Verschlüsselungsalgorithmen (auch öffentliche Verschlüsselungsalgorithmen genannt) lösen dieses Problem. Jeder Kommunikationspartner hat zwei Schlüssel. Der öffentliche Schlüssel, der zumeist frei zugänglich ist, kann von jedem verwendete wird, der mit jemandem kommunizieren will. Der andere Schlüssel, der private Schlüssel, ist nur dem Empfänger bekannt. Es wird verlangt, dass eine Nachricht, die mit dem einen Schlüssel verschlüsselt wird ausschließlich von dem anderen Schlüssel dieses Schlüsselpaares dekodiert werden kann. Asymmetrische Verschlüsselungsalgorithmen basieren auf Verschlüsselungsfunktionen, die nicht rückgängig gemacht werden können sondern mit verschiedenen Schlüsseln je einmal ausgeführt werden. Die Verschlüsselung von Daten wird mit Hilfe des öffentlich verfügbaren Schlüssels vom gewünschten Kommunikationspartner unter Anwendung des Algorithmus ausgeführt. Man muss sicher sein, den echten öffentlichen Schlüssel vom gewünschten Partner und nicht den öffentlichen Schlüssel von einem Nichtberechtigten zu benutzen. Um die Authentizität von öffentlichen Schlüsseln zu sichern, werden Zertifikate verwendet (siehe Kapitel 2.2.2). Mit demselben Algorithmus und dem privaten Schlüssel erfolgt die Entschlüsselung. Da die Ver- und Entschlüsselung mit asymmetrischen Algorithmen einen erheblichen Rechenaufwand verbunden ist, werden in der Praxis keine größeren Datenmengen damit verschlüsselt. Ein Sicherheitssystem arbeitet immer mit einer Mischform, d.h. es wird ein zufällig erzeugter Schlüssel für eine symmetrische Verschlüsselung der zu transportierenden Daten erzeugt. Dieser Schlüssel wird über Verschlüsselungsverfahren mit öffentlichen Schlüsseln ausgetauscht. RSA Der RSA-Algorithmus basiert auf dem Problem der Faktorzerlegung großer natürlicher Zahlen. Die Schlüsselgenerierung für RSA benötigt zwei große Primzahlen und eine Verarbeitung dieser beiden Zahlen. Die Schlüsselgeneration führt zu drei Zahlen, die das Schlüsselpaar formen: Eine RSA-Nummer n, das Produkt der zwei Primzahlen und zwei Parameter e und d. Der öffentliche Schlüssel besteht aus e und n, der private Schlüssel besteht aus d und n. Der Algorithmus wird für das sichere Austauschen von Schlüsseln und zum generieren von digitalen Unterschriften (Zertifikaten) verwendet. Der RSA-Algorithmus erfordert effiziente Algorithmen für Berechnung von großen ganzen Zahlen und effiziente Algorithmen für das Potenzieren. Dennoch ist die RSA- Verschlüsselung in Hardware etwa 1000-mal langsamer als eine DES-Verschlüsselung. Eine Softwarerealisierung ist dann etwa 100-mal langsamer als eine DES Softwareimplementierung. ElGamal Der ElGamal, ein öffentlicher Verschlüsselungscode, wurde von ElGamal entwickelt. Der Verschlüsselungsalgorithmus basiert auf dem Problem des diskreten Logarithmus in einem begrenzten Feld. Er verwendet dasselbe Prinzip wie der Diffie Hellman-Algorithmus. Der ElGamal-Signaturalgorithmus wird auch für digitale Unterschriften verwendet. Elliptische Kurvenkryptographie (ECC) Die Motivation für elliptische Kurvenkryptographie (ECC) ist die Vorstellung, dass das diskrete Logarithmenproblem für elliptische Kurven über begrenzte Felder, verglichen mit SecIE e.v. 9

10 dem diskreten Logarithmenproblem über begrenzten Feldern allein, schwerer zu lösen ist, und daher kleiner Schlüssel bei gleicher Sicherheitsstufeverwendet werden können. Öffentliche Schlüsseloperationen sind sehr intensiv computergestützt, besonders für große Schlüssel, deshalb ist ECC sehr attraktiv, denn es bietet dieselbe Sicherheit, wie andere Verschlüsselungssysteme mit kleinerer Schlüssellänge an. Diffie-Hellman Schlüsselaustausch Eines der Probleme, die von Verschlüsselung mit öffentlichem Schlüssel gelöst wurden, war das Problem der Schlüsselvereinbarung. Ohne Verschlüsselung mit öffentlichem Schlüssel war es notwendig, dass zwei Parteien, die im Geheimen kommunizieren wollten, einen gemeinsamen Schlüssel von einer vertrauten dritten Partei bekommen. Diffie Hellman schlug einen Algorithmus vor, der den zwei Parteien erlaubt, sich auf ein gemeinsames Schlüsselmaterial ohne solch einen Dritten zu einigen. Der Diffie Hellman-Algorithmus verwendet die Anzahl theoretischer Probleme, um einen diskreten Logarithmus modulo einer großen Primzahl zu berechnen. Er wird insbesondere bei IPSec und TLS verwendet. Der Diffie Hellman Schlüsselaustausch macht es möglich, sich auf einen gemeinsamen Schlüssel zwischen zwei Parteien zu einigen, aber es ist kein Authentifizierungsmechanismus vorausgesetzt. Das bedeutet, dass eine Kommunikationsverbindung sicher genutzt werden kann, jedoch keine Sicherheit über die Richtigkeit des Kommunikationspartners besteht. Deshalb muss dieser Schlüsselaustausch immer von einer zusätzlichen Bestätigung begleitet werden Hash-Funktionen Allgemeines Eine verschlüsselnde Hash-Funktion ist eine Funktion, die eine Meldung von beliebiger Länge und Inhalt aufnimmt und eine feste Länge ausgibt. Die Ausgabe wird Nachrichten- Hash oder Fingerabdruck genannt. Hash-Funktionen werden wie Kontrollsummen verwendet, um die Integrität von Daten zu überprüfen. Damit eine Hash-Funktion sinnvoll verschlüsselt ist, muss sie widerstandsfähig gegen Zusammenstöße sein, das bedeutet, dass, wenn zwei verschiedene Meldungen haschiert werden, sollen sie verschiedene Hash- Werte liefern. Verschlüsselnde Hash-Funktionen sind ein wichtiger Teil von Sicherheitsprotokollen. Der Fingerabdruck einer Meldung macht es möglich, die Integrität einer Meldung zu überprüfen. SHA1 Der sichere Hash-Algorithmus SHA 1 ist Teil des sicheren Hash-Standards und wurde im Jahr 1993 vom nationalen Institut für Standards und der nationalen Technik veröffentlicht. SHA 1 produziert ein 160 Bit langen Hash-Wert. Die Berechnung des Hashes basiert auf 512 Bitblöcken. Chinesische Kryptologen veröffentlichten theoretische Ergebnisse über Zusammenstoßsuchangriffe, die die Komplexität senken, die dafür erforderlich ist, einen Zusammenstoß in SHA 1 bis 263 zu finden. Das ist Grund dafür, warum SHA 1 nicht mehr für neue Einsätze empfohlen wird. NIST hat eine Serie von neuen Hashfunktionen unter dem Etikett von SHA 2 veröffentlicht. Sie werden entsprechend ihrer Hashlänge SHA 224, SHA 256, SHA 384 und SHA 512 genannt. MD5 Die Nachrichten-Hash-Methode wurde von R.Rivest mit der Hash-Funktion MD4 eingeführt. MD5 ist eine Erweiterung von MD4. Es produziert ein Hashwert von 128 Bit. Wie SHA 1 arbeitet es mit 512 Bitblöcken der Meldung. MD5 ist in realistische Abfolgen unterteilt worden. Das ist der Grund, warum die Verwendung von MD5 für digitale Unterschriften nicht erfolgreich ist. RIPEMD 160 SecIE e.v. 10

11 RIPEMD ist eine Variante der Hash-Funktion MD5. Es besteht im Grunde genommen aus zwei parallelen Versionen von MD5. RIPEMD 160 ist eine erweiterte Version von RIPEMD. Die Länge des produzierten Hash-Wertes beträgt 160 Bit. Bis jetzt gibt es keinen bekannten Angriff gegen RIPEMD 160. Hashed Message Authentication Codes (HMAC) Hash-Funktionen werden verwendet, um die Integrität einer Meldung zu überprüfen. Mitteilungsauthentifizierungscodes (MACs) sind mit Hash-Funktionen vergleichbar, verwenden aber zusätzlich einen geheimen Schlüssel, um den Nachrichten-Hash zu berechnen. MACs werden normalerweise für eine Beglaubigungsinformation verwendet, welche zwischen zwei Parteien gesendet wird, die ein gemeinsames Geheimnis aufbewahren. RFC 2104 beschreibt eine Methode, um einen MAC aufgrund einer Hash-Funktion zu berechnen. Diese Klasse von MACs wird HMAC genannt. All die oben genannten Hash- Funktionen können verwendet werden, um ein HMAC zu berechnen Digitale Unterschriften Digitale Unterschriften werden verwendet, um Meldungen zu beglaubigen oder um den Absender einer Meldung zu authentifizieren. Das Schema von digitalen Unterschriften besteht aus einem Signaturalgorithmus und einem Bestätigungsalgorithmus. Der Absender einer Meldung benutzt seinen privaten Schlüssel zusammen mit seinem Signaturalgorithmus um eine Unterschrift der Meldung zu generieren. Die Meldung ist zusammen mit der Unterschrift an einen Empfänger zu senden. Der Empfänger nimmt die Meldung, die Unterschrift und den öffentlichen Schlüssel vom Absender auf und überprüft die Gültigkeit der Meldung mit dem Bestätigungsalgorithmus. Mit dem Signaturalgorithmus ist es normalerweise nicht möglich eine ganze Meldung zu unterschreiben, deshalb wird eine Meldung zuerst haschiert, und nur der Hash-Wert ist unterschrieben. Die NIST hat einen digitalen Unterschriftsstandard (DSS, FIPS 186-2) veröffentlicht. Dieser Standard schließt die folgenden öffentlichen Schlüsselalgorithmen für das Unterschreiben einer Meldung ein: o RSA Signature Scheme o Digital Signature Algorithm (based on the ElGamal algorithm) o Elliptic Curve Digital Signature Algorithm Die verwendeten Hash-Funktionen sind SHA 1 und MD5. Digitale Unterschriften werden von verschlüsselten Protokollen, wie IPSec und OpenVPN verwendet, um einen Meldungstransfer zu beglaubigen Zertifikate Ein Zertifikat bindet die Identität einer Person oder einer Einheit an einen öffentlichen Schlüssel. Diese Bindung muss von einer Berechtigung bestätigt oder beglaubigt werden. Dies bedeutet, dass die Berechtigung diese Bindung unterschreiben muss. Bescheinigungen mildern die Verbreitung des öffentlichen Schlüssels. Um sicher zu sein, dass ein öffentlicher Schlüssel wirklich einer gewissen Einheit oder Person gehört, kann das Zertifikat überprüft werden. Die Überprüfung schließt immer einen vertrauten Dritten, die so genannte Zertifizierungsstelle (CA) ein. Da das Zertifikat mit dem privaten Schlüssel vom CA unterschrieben ist, kann seine Gültigkeit mit dem öffentlichen Schlüssel vom CA geprüft werden X.509 Der X.509-Standard definiert die Information und das Format der Information, die in einem Zertifikat enthalten sein können. Das X.509-Format ist innerhalb RFCs 3280 definiert. Zusätzliche Erweiterungen für die Zertifikatssperrlisten sind in RFC 4325 angegeben. SecIE e.v. 11

12 X509- Zertifikate enthalten die folgende Information: o Version: Version der verwendeten Spezifikation. Die aktuelle Version ist 3. o Seriennummer: Die Seriennummer ist ein eindeutiger Bezeichner des Zertifikats. Die Seriennummer ist nur für ein bestimmtes CA eindeutig. o Unterschrift: Dieses Feld enthält den Algorithmenbezeichner, für den Signatur- Algorithmus der vom CA verwendet wird, um das Zertifikat zu unterschreiben. o Herausgeber: Dieses Feld enthält den Namen des CAs. o Gültigkeitsdauer: Eine Bescheinigung ist nur für einen beschränkten Zeitraum gültig. o Diese Periode wird von einem Zeitintervall angegeben. o Thema: Dieses Feld enthält die unterschiedenen Namen des Themas, das an den o öffentlichen Schlüssel gebunden ist. o Thema der öffentlichen Schlüsselinformation: Dieses Feld enthält den öffentlichen Schlüssel in Verbindung zum Thema. o Ausgabe eindeutiger Bezeichner: Optionales Feld. Wenn anwesend, dann enthält es einen eindeutigen Bezeichner vom CA. o Thema eindeutiger Bezeichner: Optionales Feld. Wenn vorhanden, dann enthält es einen eindeutigen Bezeichner für das Thema. o Erweiterungen: X509 v3 ermöglicht Erweiterungen. Das Erweiterungsfeld enthält eine Folge von einem oder mehreren Zertifikatserweiterungs. o Unterschriftswert: Der digitale Unterschriftswert wird durch das Berechnen einer digitalen Unterschrift über allen Bescheinigungsdaten (ausschließlich dem Unterschriftswert) erzeugt. Der verwendete Algorithmus ist im Unterschriftswert angegeben. Der benutzte Schlüssel ist der private Schlüssel vom CA IPSec Überblick Das Internetprotokoll (IP) hat eine sehr weite Verbreitung im Rahmen der Netzwerkprotokolle gefunden. Dies bewirkt, dass beinahe alle Anwendungsprotokolle auf dem Internetprotokoll basieren. Das ist der Grund, warum es so attraktiv ist, einen Sicherheitsmechanismus in der IP-Ebene anzubieten. Durch das Sichern von IP-Paketen wird der ganze Bereich der Anwendungsprotokolle, die auf IP basieren, auch gesichert. Dies vermindert die Notwendigkeit, Sicherheit für jede Anwendung gesondert zu implementieren. Das IP Sicherheitsprotokoll wurde dafür entworfen, IP-Verkehr zu sichern. Es bietet die folgenden Merkmale an: o Integrität von Paketen: IPSec bietet Mittel an, um Pakete gegen Änderung zu schützen (d.h. eine Änderung kann wahrgenommen werden). o Bestätigung von Paketen: IPSec garantiert, dass Pakete, die vom authentischen Absender stammten, akzeptiert werden. o Vertraulichkeit von Paketen: IPSec bietet die Verschlüsselung von IP-Paketen an. o Vertraulichkeit vom Ablauf des Verkehrs: Im Tunnelmodus verschlüsselt IPSec auch die IP- Adressen von Originalabsender und Empfänger. o Schutz vor Wiederholungsangriffen: IPSec verhindert die Akzeptanz von Paketen, die von Nichtberechtigten aufgezeichnet und weitergesendetet wurden. o Schutz vor DoS Angriffen: Die Schlüsselaustauschphase (IKE) erfordert Zeit, wenn sie Berechnungen beinhaltet. IPSec hat Mechanismen, um solche Angriffe komplizierter zu machen. IPSec ist ein IETF Sicherheitsstandard und definiert eine Sicherheitsarchitektur für die Internetprotokolle IPv4 und IPv6. Während IPSec ein Nachtrag zu IPv4 ist, ist es ein integraler Bestandteil von IPv6. Dies bedeutet, dass es keine IPv6-konforme Implementierung gibt, die IPSec nicht einschließt. Aber in allen beiden Fällen befindet sich IPSec innerhalb der IP-Ebene. IPSec wird vom folgenden RFCs genormt: o RFC 2401: Security Architecture for the Internet Protocol o RFC 2402: IP Authentication Header SecIE e.v. 12

13 o RFC 2403: The Use of HMAC-MD5-96 within ESP and AH o RFC 2404: The Use of HMAC-SHA-1-96 within ESP and AH o RFC 2405: The ESP DES-CBC Cipher Algorithm with explicit IV o RFC 2406: IP Encapsulating Security Payload (ESP) o RFC 2407: The Internet IP Security Domain of Interpretation for ISAKMP o RFC 2408: The Internet Security Association and Key Management Protocol o RFC 2409: The Internet Key Exchange o RFC 2412: The OAKLEY Key Determination Protocol o RFC 2451: The ESP CBC-Mode Cipher Algorithm Diese Liste zeigt, dass IPSec aus vielen Standards besteht. Dies macht IPSec leider mehrdeutig und komplex Architektur von IPSec Ein wichtiger Teil von IPSec ist die Sicherheitsrichtliniendatenbank (SPD / security policy database). Die SPD stellt fest, wie IP-Pakete zu behandeln sind. Das heißt, sie beschreibt die Vorgehensweise für die Verarbeitung von IP-Paketen. Diese Vorgehensweise basiert auf Regeln welche bestimmen, ob ein Paket verschlüsselt überwiesen werden soll, ob es ohne weiteren Eingriff von IPSec vorbeigehen soll oder ob es fallen gelassen werden soll. Die Entscheidung, wie man ein Paket verarbeiten kann, basiert jeweils auf dem Satz von Attributen des IP-Headers, des TCP-Headers oder des UDP-Headers der zu verareitenden Nachricht. IPSec verwendet die folgenden Attribute als Entscheidungsgrundlage: o Quelladresse: Die Quell-IP-Adresse kann als eine einzelne Adresse, ein Adressbereich oder Joker angegeben werden o Zieladresse: Die Ziel-IP-Adresse kann als eine einzelne Adresse, ein Adressbereich oder Joker angegeben werden o Protokoll: Dies ist das Protokollfeld des IP-Headers o Portnumber: Wenn das Protokoll über IP Anschlüsse (wie TCP oder UDP) hat. Diese Anschlüsse können auch als Wählschalter verwendet werden o Name: Dieses Feld wird gegenwärtig von IPSec nicht verwendet Ein Eintrag in der SPD könnte die folgende Form haben: Filter rule: Source address: Destination address: Protocol; UDP Port Action: Process, ESP required Parameters: Cipher DES3 or AES Integrity HMAC MD5, key length 128 or HMAC SHA1 keylength160 Expiry 60 Minutes Mode Tunnel Diese SPD-Regel bestimmt, dass Pakete, die zur oben genannten Filterrolle passen, durch einen IPSec-Tunnel an den entfernten Endpunkt gesendet werden sollen. Der Eintrag gibt auch an, was für eine Verschlüsselung und Authentifizierungsmethode angewandt werden soll. Wie aus dem oben genannten Beispiel deutlich wird, beschreibt ein SPD-Eintrag einen Satz von Sicherheitsparametern. Wenn eine IPSec-Verbindung hergestellt wird, verhandeln beide Partner darüber, welche Sicherheitsparameter tatsächlich für diese Verbindung verwendet werden. IPSec-Verbindungen werden Sicherheitszuordnungen genannt. Die Information über alle feststehenden Sicherheitszuordnungen von einer Einheit ist innerhalb der Sicherheitszuordnungsdatenbank gespeichert. Diese Information besteht aus den tatsächlichen gebrauchten Parametern, der übrigen Lebensdauer und aus den wichtigsten SecIE e.v. 13

14 Bestandteilen, die von den Schlüsseln für die Verschlüsselung und für die Bestätigung genutzt wird. Wie IPSec verschiedene Schlüssel für die Richtung des Sendens und Empfangen benutzt, gibt es zwei Sicherheitszuordnungen für eine einzelne IPSec-Verbindung. Verschiedene Schlüssel für das Senden und Empfangen zu benutzen, verbessert die Sicherheit. Wenn die Lebensdauer einer Sicherheitszuordnung endet, wird sie nicht mehr verwendet und die Sicherheitszuordnung ist freigegeben. Eine Sicherheitszuordnung wird vom Internetschlüsselaustauschprotokoll (IKE) eingeführt. Das folgende Bild zeigt, welche Schritte mit der Verarbeitung eines ausgehenden IP-Paketes verbunden sind. Es zeigt auch wie die verschiedenen Teile der IPSec zusammenarbeiten. Internet Key Exchange Security Policy Database Security Policy IP UDP Data New IP header Packet Encapsulation Security Association Database IP ESP IP UDP Data 3Des, keys 3Des IP ESP HMAC-SHA1, keys HMAC SHA1 IP ESP Auth Abbildung 2-1: Verarbeitung eines ausgehenden IP-Paketes Protokolle und Betriebsmodi IPSec bietet zwei verschiedene Protokolle für das Sichern von IP-Paketen, das Authentification Header Protocol (AH) und das Encapsulating Security Payload Protocol (ESP) an. Das AH-Protokoll stellt Authentizität und Integrität von IP-Paketen sicher. AH erreicht dies durch die Berechnung eines HMACs über den vollständigen Paketen. Wenn AH bei Tunnelmodus benutzt wird (siehe unten), ist auch der äußere IP-Header in die HMAC- Berechnung einbezogen. Das Ergebnis der HMAC-Berechnung wird im Integrity Check Value (ICV) gespeichert und innerhalb des AH Protokoll-Headers gesendet. Das HMAC ist von Geheimnissen (Schlüsseln) berechnet worden, die den beiden Kommunikationspartnern gemeinsam sind. Die folgenden HMAC-Algorithmen werden von IPSec unterstützt: MD5, SHA1, SHA2, DES und RIPEMD Außerdem liefert das AH Protokoll Sicherheit gegen Wiederholungsangriffe. Ein Folgezähler wird für diesen Zweck benutzt. Er ist für jedes Paket inbegriffen, welches über eine IPSec- SecIE e.v. 14

15 Verbindung gesendet wird. Dieser Zähler wird auch in den AH-Protokoll-Header gesendet. Ist AH ein IP-Protokoll, bekommt es die Protokollnummer 51 zugewiesen. Das AH Protokoll kann beim Übertragungsmodus und beim Tunnelmodus verwendet werden. Im Übertragungsmodus kommunizieren die zwei Endpunkte direkt über IPSec. Der AH- Protokoll-Header befindet sich zwischen dem ursprünglichen IP-Header und den Originaldaten. IP TCP Data Original IP packet IP AH TCP Data authenticated Transport mode with IPSec AH New IP header IP TCP Data Original IP packet IP AH IP TCP Data authenticated Tunnel mode with IPSec AH Abbildung 2-2: IPSec Authentification Header Protocol (AH) für den Übertragungsmodus und für den Tunnelmodus Der Tunnelmodus wird normalerweise verwendet, wenn die IPSec-Verarbeitung nicht von den Endpunkten gemacht wird. In diesem Fall reden die Endpunkte mit Sicherheitstoren (Routern, Switches), die die IPSec-Verarbeitung ausführen. Sicherheitstore sichern normalerweise vollständige IP-Unternetze. Wenn eine gesicherte Kommunikation zwischen zwei Unternetzen eingeführt werden soll, stellen die zwei Sicherheitstore eine IPSec- Verbindung her. Die Kommunikation zwischen diesen Unternetzen kann jetzt durch diese Verbindung gesendet werden. Das ist Grund dafür, dass man es "Tunnelmodus" nennt. Da das vollständige IP-Paket AH beglaubigt wird, ist keine IP-Adressübersetzung (NAT/NAPT) im Kommunikationspfad zwischen den zwei Endpunkten möglich (aber es könnte außerhalb des Tunnels erreicht werden). Das ESP Protokoll unterstützt Authentizität und Integrität von IP-Paketen, im Gegensatz zum AH Protokoll, der den IP-Header nicht beglaubigt, d.h. nicht in die HMAC-Berechnung einbezieht. ESP verwendet dieselben Algorithmen wie AH für die HMAC-Berechnung. Der Integritätsüberprüfungsvektor ist in einem Kennsatz(Auth) eines Dateiendes, der an dem IP- Paket angehängt ist, gespeichert. Der Wiederholungsschutz wird auch unterstützt. Zusätzlich zu AH, unterstützt das ESP Protokoll Vertraulichkeit von IP-Paketen. Dies wurde beim Verschlüsseln eines Teils des IP-Paketes getan. Die Verschlüsselung wird von symmetrischen Verschlüsselungsalgorithmen ausgeführt. Die Schlüssel für die Verschlüsselung müssen von den kommunizierenden Partnern gekannt werden. Folgende Verschlüsselungsalgorithmen werden unterstützt: AES, DES, 3DES, RC5, RC4, IDEA, CAST, BLOWFISH. Auch die NULL-Verschlüsselung (überhaupt keine Verschlüsselung) ist erlaubt. Wie das AH Protokoll, kann auch das ESP Protokoll mit dem Übertragungsmodus und dem Tunnelmodus verwendet werden. SecIE e.v. 15

16 IP TCP Data Original IP packet IP ESP encrypted Auth Transport mode with IPSec ESP authenticated New IP header IP TCP Data Original IP packet IP ESP IP encrypted Auth Tunnel mode with IPSec ESP authenticated Abbildung 2-3: IPSec Encapsulating Security Payload Protocol (ESP) für den Übertragungsmodus und für den Tunnelmodus Internetschlüsselaustausch (IKE) Wenn ein IP-Paket gesendet werden soll, gibt es als erstes eine Suche in der SPD, sobald die IPSec-Verarbeitung für dieses Paket benötigt wird. Wenn die IPSec-Verarbeitung erforderlich ist, wird die Sicherheitszuordnungsdatenbank nach einer entsprechenden Sicherheitszuordnung durchsucht. Wenn eine Sicherheitszuordnung gefunden wird, wird das Paket gesendet, indem es die Sicherheitsparameter und Schlüsselmaterialen von dieser Zuordnung verwendet. Wenn nicht, dann wird das IKE-Protokoll gebraucht, um Sicherheitszuordnungen einzuführen. Das IKE-Protokoll ist in zwei Phasen eingeteilt. Innerhalb der ersten Phase wird eine spezielle Sicherheitszuordnung ausgehandelt. Diese spezielle Sicherheitszuordnung wird bei der zweiten Phase verwendet, um Sicherheitszuordnungen für Datenkommunikation auszuhandeln. Innerhalb der ersten Phase wird ein gemeinsames Geheimnis mittels des Diffie Hellman- Algorithmus zwischen den zwei Einheiten eingeführt. Dann beglaubigen sich die zwei Einheiten wechselseitig und handeln die Sicherheitsparameter aus. IKE unterstützt vier verschiedene Authentifizierungsdarstellungen: o Pre-shared key o Digital signature o Public key encryption (RSA) o Revised public key encryption (RSA) Beglaubigungen mit voreingeteilten Schlüssel sind nur innerhalb kleiner Netze möglich, weil jedes Verbindungspaar, seinen eigenen Schlüssel braucht. Die anderen drei Authentifizierungsmethoden erfordern eine öffentliche Schlüsselinfrastruktur. IKE bietet zwei Arten von Schlüsselaustauschen an. Der erste Typ wird Hauptmodus genannt, der zweite Typ wird aggressiver Modus bezeichnet. Der Hauptmodus ist aus sechs Meldungen zusammengesetzt. Er bietet Identitätsschutz und Sicherheit gegen Ablehnung von Anwendungsangriffen an. Identitätsschutz bedeutet, dass die Meldungen, die die Identität der Einheiten senden, schon verschlüsselt sind. Eine Ablehnung des Anwendungsangriffs auf das IKE-Protokoll bewirkt, dass eine IKE-Implementierung die Zeit ausführt, die die Diffie Hellman-Berechnung benötigt. Der Hauptmodus vermeidet diesen Angriff durch den Gebrauch von Cookies. Der aggressive Modus erfordert nur 3 Meldungen und ist deshalb schneller. Aber die Identitäten der Einheiten werden nicht verschlüsselt. Dementsprechend ist dieser Modus gegenüber Denial of Service-Attacken verwundbar. Die zweite Phase des Schlüsselaustausches wird Schnellmodus genannt. Dieser Schlüsselaustausch findet unter dem Schutz der in der Phase 1 gemachten Sicherheitszuordnung statt, d.h. die Sicherheitsparameter und Schlüssel von der ersten Phase werden benutzt, um zu SecIE e.v. 16

17 verschlüsseln und zu beglaubigen. Das ist der Grund dafür, weshalb dieser Schlüsselaustausch viel schneller ist SSL/TLS Überblick Das Secure Socket Layer Protocol (SSL) befindet sich über der Transportebene (TCP). Es ist ursprünglich von Netscape für die Erstellung von sicheren HTTP-Verbindungen entwickelt worden. Die SSL Version 3.0 wird inzwischen als eine De-Facto-Internetnorm für sichere HTTP-Kommunikation eingeführt. Sie wird heutzutage von fast allen WWW-Browsern unterstützt. Aber SSL ist auch dazu fähig weitere Anwendungsprotokolle zu sichern. Die folgende Abbildung zeigt, wie SSL in das ISO/OSI Referenzmodell einzuordnen ist. Client Telnet FTP HTTP SMTP POP3 Application layer Server Telnet FTP HTTP SMTP POP3 Change Chipher Alert Handshake Handshake Change Chipher Alert Record Layer Record Layer TCP/IP TCP/IP Abbildung 2-4: Position von SSL innerhalb des Ebenenmodells Die Funktionen, die SSL anbietet, sind: o Authentifizierung der Kommunikationsendpunkte: Die Authentifizierung wird von einer asymmetrisch verschlüsselten Methode in Verbindung mit einem Zertifikat ausgeführt. o Verschlüsselung von Daten mit symmetrischer Verschlüsselung o Datenintegrität durch das Verwenden einer Meldungsauthentifizierung. SSL verwendet eine Transportverbindung, diese ist vorhanden, weil TCP als das zugrunde liegende Protokoll verwendet wird SSL Record-Ebene Auf der Absenderseite erhält die SSL-Datensatzebene einen Datenstrom von einer Transfer- Anwendung an einen Empfänger. Der Datenstrom ist zuerst zerstückelt; ein Teil hat dabei eine maximale Länge von 214 Byte. Nach der Zerstückelung werden die Daten wahlweise komprimiert. Nach Kompression wird ein Message Authentication Code (HMAC) hinzugefügt. Eine Folgenummer ist zwischen den einzelnen Teilen eingefügt, zusätzlich gibt es eine Berechnung des Hash-Werts, so dass wiederholte oder verloren gegangene Pakete entdeckt werden können. Anwendungsdaten (die wahlweise komprimiert sind) und der Hash-Wert werden dann verschlüsselt, anschließend in einen Protokollrahmen der Datensatzebene platziert und dann über einer TCP-Verbindung gesendet. Auf der Empfängerseite wird die Prozedur im entgegen gesetzter Richtung durchgeführt, um die ursprünglich gesendeten Daten herzustellen SecIE e.v. 17

18 Die Datensatzebene verwendet für die Berechnung des HMACs und für die Verschlüsselung der Daten das Schlüsselmaterial, das in der Verbindungserstellungsphase getauscht worden ist. Die Verbindungserstellung wird vom Quittungsbetriebsprotokoll ausgeführt. Das Quittungsbetriebsprotokoll verwendet auch die Datensatzebene für den Transfer seiner Daten. Da es noch kein verfügbares Schlüsselmaterial gibt, sind die meisten Daten vom Quittungsbetriebsprotokoll unverschlüsselt SSL-Handshake Der Hauptteil von SSL ist das Quittungsbetriebsprotokoll. Es stellt den komplexesten Teil der SSL Technologie dar. Der Quittungsbetrieb wird für die Verhandlung von Parametern und für den Schlüsselaustausch zwischen Client und Server verwendet. Folgende Parameter werden verhandelt: o Protokollversion o Ziffernsuite: Eine Ziffernsuite besteht aus einer Authentifizierungsmethode, einer Verschlüsselungsmethode und einem HMAC-Verschlüsselungsalgorithmus. Zum Beispiel verwendet die Ziffernsuite TLS_RSA_WITH_RC4_128_MD5 RSA für Bestätigung, RC4 für Verschlüsselung und MD5 für die HMAC-Berechnung. o Gebrauch von Datenkomprimierung und dem Kompressionstyp. Die folgende Abbildung zeigt beim SSL-Handshake ausgetauschte Meldungen. Client Server ClientHello ServerHello (SessionId) Certificate ServerHelloDone ClientKeyExchange ChangeCipherSpec Finished ChangeCipherSpec Finished Abbildung 2-5: SSL-Handshake mit RSA und ohne Clientauthentifizierung Der Client beginnt mit der Verbindungserstellung durch das Senden einer Meldung ClientHello. Die Meldung enthält die bevorzugte Protokollversion, die unterstützten Ziffernsuiten und die bevorzugte Komprimierungsmethode, wenn überhaupt vorhanden. Außerdem sendet der Client eine Zufallszahl (aus Zeit und Datum und einer echten Zufallszahl aufgebaut), die später verwendet wird, um das Schlüsselmaterial abzuleiten. Nachdem der Empfang eines ClientHellos, wählt des Servers die zu nutzenden Parameter aus und sendet seine Auswahl zurück zum Client als ServerHello. In dieser Meldung gibt der Server auch einen Bezeichner für die Sitzung zurück, die gegenwärtig eingeführt wird. Als Bestätigung sendet der Server dem Client auch seinen (in eine X509-Bescheinigung gepackten) öffentlichen Schlüssel zu. Der Server beendet diese Folge mit einer Meldung ServerHelloDone. Der Client kann die Authentizität jetzt überprüfen, indem er ein vorinstalliertes ROOT- Zertifikat des Servers verwendet. Der Client wählt jetzt einen geheimen Wert aus (das Premaster-Geheimnis), verschlüsselt ihn mit dem öffentlichen Schlüssel vom Server und sendet ihn mit Hilfe der Meldung ClientKeyExchange zum Server. Nach Transfer des ClientKeyExchange haben beide Parteien all die Information, um die Verschlüsselung, Zertifikate und Authentifizierungen zu berechnen. Das ist der Grund, SecIE e.v. 18

19 warum der Client und der Server jetzt ein ChangeCipherSpec senden, um anzuzeigen, dass die neuen Schlüssel jetzt berechnet sind und für die weitere Kommunikation benutzt werden sollen. Server und Client beenden den Quittungsbetrieb durch das Senden einer fertigen Meldung. Die fertige Meldung wird schon verschlüsselt und beglaubigt. Um sicherzustellen, dass es keine Man-in-the-Middle-Attack während des Quittungsbetriebs gab, werden alle getauschten Quittungsbetriebsmeldungen in der fertigen Meldung haschiert und gesendet. SSL unterscheidet zwischen Verbindungen und Sitzungen. Wenn es schon eine Verbindung zwischen einem Server und Client eingeführte Sitzung ist, kann diese Sitzung für die Erstellung von zusätzlichen Verbindungen verwendet werden. Die Verbindungen verwenden das Premaster-Geheimnis der Sitzung, um das Schlüsselmaterial abzuleiten, sie verwenden auch dieselben Parameter (Ziffernsuite, Kompressionsalgorithmus) wie die Sitzung. Sitzungen werden implizit mit der Erstellung der ersten Verbindung zwischen einem Server und einem Client eingeführt. Wenn ein Client eine vorhandene Sitzung verwenden will, sendet er die Sitzungs-ID mit der Meldung ClientHello. Der Server bestätigt diese, wenn er diese SitzungsID in seinem ServerHello zurückgibt. Wenn der Server nicht übereinstimmt, diese Sitzung zu verwenden, gibt er eine neue Sitzungs-ID zurück. Der Gebrauch einer vorhandenen Sitzung spart die Zeit um asymmetrische verschlüsselte Berechnungen für den Schlüsselaustausch zu einzunehmen. Eine SSL-Verbindung ist mit der Beendigung der zugrunde liegenden TCP-Verbindung beendet SSL ChangeCipherSpec und SSL Alert Protokoll Die Meldung ChangeCipherSpec wird verwendet, um zwischen verschiedenen verschlüsselten Parametern umzuschalten. Wie mit jedem Kommunikationsprotokoll können Fehler und Missverständnis geschehen. Das Alert Protocol wird verwendet, um von Fehlern zu berichten Öffentliche Schlüsselinfrastruktur für SSL/TLS SSL wird hauptsächlich bei Verbindung mit HTTP verwendet, dies wird als HTTPS bezeichnet. HTTPS verwenden normalerweise keine Client-Authentifizierung, deshalb benötigt nur der Server eine Bestätigung. Die meisten Browser haben die ROOT-Zertifikate aller größeren Zertifizierungsstellen (CA) schon standardmäßig installiert. Das ist der Grund, warum ein normaler Benutzer über ein nicht vorhandenes Überprüfungszertifikat verärgert ist. Er muss die Gültigkeit von Bescheinigungen nicht überprüfen und das Wichtigste ist, es gibt keinen Grund, dass sich ein Benutzer aus einem CA eine Bescheinigung kauft, die sehr kostspielig sein kann. Das Ergebnis ist, wenn SSL für ein Anwendungsprotokoll außer HTTP verwendet wird und wenn eine Clientauthentifizierung erforderlich ist, muss man sich um eine öffentliche Schlüsselinfrastruktur (PKI) kümmern Transport Layer Securitiy (TLS) SSL Version 3 war mit von der IETF als akzeptierter Internetstandard nur eine geringfügige Änderungen. Er ist in RFC 2246 beschrieben und wird "das TLS-Protokoll Version 1.0" genannt. TLS steht für Transportebenensicherheit (Transport Layer Security). Die Änderungen gegenüber SSL 3.0 betreffen: o Zusätzliche Alert-Meldungen o Meldungsauthentifizierung: Die Meldungsauthentifizierung in SSL 3.0 hat sich nicht als sicher erweisen, deshalb wurde sie durch genormtes HMAC ersetzt. o Erzeugung des Schlüsselmaterials o Meldung CertificateVerify (die Meldung CertificateVerify wird als Clientauthentifizierung verwendet) SecIE e.v. 19

20 o Die Fortezza-Ziffernsuite ist nicht mehr obligatorisch PPP Überblick Das Point-to-Point Protocol (PPP) ist ein Netzwerkprotokoll mit dem eine Datenübertragung zwischen zwei dedizierten Knoten ermöglicht wird. Es findet hautsächlich Anwendung bei der Herstellung einer Einwahlleitung (Modem etc.) zu einem Internetprovider und ermöglicht so den Netzzugang. Es ist aber so allgemein definiert, dass es beliebige paketorientierte Protokolle der Netzwerkschicht zwischen zwei Punkten transportieren kann. Das Protokoll ist in der RFC 1661 [Sim94] spezifiziert. Für die Adaption zum Aufbau einer PPP Session und zum Einbinden von PPP Paketen in spezifische Layer 2 Frames gibt es die Spezifikationen für PPP over Ethernet (PPPoE) (RFC 2516 [Mam99]) bzw. PPP over ATM (PPPoA) (RFC 2364 [Gro98]). Bei PPP werden drei Komponenten spezifiziert. Dies ist zum einen die Datenkapselung verschiedenster Protokolle der Vermittlungsschicht (network layer) zur Übertragung. Dabei ist es möglich mehrere Protokolle simultan über die Verbindung zu transportieren. Zum anderen wird das Link Control Protocol (LCP) definiert, über das die Verbindungen aufgebaut, konfiguriert und getestet werden. Es bildet eine Abstraktion um mit verschiedensten herstellerspezifischen Protokollen und physikalischen Transportmedien umgehen zu können. LCP wird verwendet um automatisch die Optionen zur Datenkapselung und die Begrenzungen in der Paketgröße zu vereinbaren, um Fehler in der Konfiguration der Verbindung zu entdecken oder auch die Verbindung wieder abzubauen. Der dritte Bestandteil sind die Network Control Protocols (NCPs). Dies ist eine Familie von Protokollen, welche die spezifischen Anforderungen der Transportprotokolle der Vermittlungsschicht hinsichtlich des Aufbaus und Konfiguration von Punkt-zu-Punkt Verbindungen regelt. Dazu existieren eigene Spezifikationen zu den verschiedenen Protokollen (z.b. Internet Protocol Control Protocol (IPCP) in der RFC 1332 [McG92]) Funktionsweise Der Prozess zum Aufbau, Konfigurieren und Beenden einer PPP Verbindung erfolgt über eine Reihe dedizierter Zustände. Diese sind in der folgenden Abbildung dargestellt. Keine Verbindung (Link Dead) fehlgeschlagen Verbindung terminieren Verbindung aufbauen geöffnet Authentifizierung fehlgeschlagen schließen Vermittlungsschicht konfigurieren Abbildung 2-6: PPP Zustandsdiagramm Mit dem Zustand Link Dead, also ohne existierende Verbindung, beginnt und endet natürlicherweise jede PPP Sitzung. Durch ein externes Ereignis welches anzeigt, dass die physikalische Schicht bereit ist, wechselt PPP in den Zustand zum Verbindungsaufbau. In der Phase des Verbindungsaufbaus wird das LCP genutzt, um über den Austausch von Konfigurationspaketen eine Verbindung herzustellen. Hierüber werden von beiden Seiten die Konfigurationsoptionen ausgehandelt. Wenn beide Seiten die ausgehandelte Konfiguration bestätigen, ist die Verbindung aufgebaut und geöffnet. Die nächste Phase ist die Authentifizierung, bei der sich beide Partner gegenseitig authentifizieren. Laut Spezifikation ist dies aber optional und nicht zwingend vorgeschrieben. erfolgreich / keine SecIE e.v. 20