Virtuelle Private Netzwerke (Teil II)
Werbung
Seminar Rechnernetze Sommersemester 1999 Virtuelle Private Netzwerke (Teil II) Von Nils Hanßen Inhalt: Tunneling................................................................................................................................... 3 Generic Routing Encapsulation..................................................................................................4 RADIUS.....................................................................................................................................6 Service Level Agreements (SLAs).............................................................................................7 Tunneling Protokolle..................................................................................................................8 Layer-2 Tunnelungen..................................................................................................................8 Point-to-Point Tunneling Protokoll (PPTP)................................................................................8 Layer-3 Tunnelungen..................................................................................................................9 Datenverschlüsselung................................................................................................................10 Zertifikate..................................................................................................................................12 Aufbau des IPSec-Frameworks.................................................................................................14 Security Associations................................................................................................................16 Zertifikate in IPSec...................................................................................................................17 Secure Sockets Layer (SSL).....................................................................................................18 S-MIME....................................................................................................................................20 2 Tunneling Tunneling bezeichnet eine Methode der Datenübertragung, bei der Datenströme über eine virtuelle, auf das unterliegende öffentliche Netz aufgeprägte Struktur – den sog. Tunnel – übertragen werden. Man spricht hierbei auch von einem Overlay-Modell. Ein Tunnel kann sich dabei nur über einen Teil des zurückzulegenden Weges oder über die gesamte Distanz erstrecken. Jeder Tunnel besitzt einen Ingress- und einen Egress-Punkt, also einen Tunneleingang und einen Tunnelausgang. Der Tunneleingang wird häufig auch als ForeignAgent und der Tunnelausgang als Home-Agent bezeichnet, falls sich ein mobiler Rechner über ein öffentliches Netzwerk in ein privates Netz einwählt. Man unterscheidet zwischen statischen und dynamischen Tunneln. Statische Tunnel werden dort eingesetzt, wo die getunnelte Verbindung über einen längeren Zeitraum aufrechterhalten werden soll. Ein Anwendungsbeispiel für solch einen statischen Tunnel wären z.B. zwei LANs einer Firma, die über das Internet miteinander verbunden werden sollen, da die Zweigstellen der Firma an unterschiedlichen Orten stehen. Da solche Firmen-LANs in der Regel über den ganzen Tag Daten austauschen, würde man einen solchen Tunnel als statisch bezeichnen; der Tunnel bleibt den ganzen Tag über bestehen. Dynamische Tunnel hingegen werden bei kurzzeitigen Verbindungen, also sozusagen auf Anforderung etabliert. Hier wäre als Beispiel eine Internet-Banking Session zu nennen, bei der während der Sitzung ein Tunnel zwischen der Bank und dem Kunden errichtet wird. Ist der Kunde mit seinen Aktivitäten fertig, wird die getunnelte Verbindung wieder geschlossen. Tunnel können an unterschiedlichen Positionen des gesamten Übertragungsweges beginnen und enden. Je nach verwendetem Tunneling-Protokoll befinden sich die Tunnelenden Direkt beim Client und Server (die gesamte Route wird getunnelt) Bei zwei Routern, die geographisch getrennt sind (Teilstrecke wird getunnelt) Jeweils bei den NASs (Network Access Switches) der POPs (Point of Presence) (Teilstrecke wird getunnelt). Mischformen Bild 1: Tunnel überbrücken Gesamt- oder Teilstrecken. PPTP: Tunnel reicht vom Client bis zum Server ATMP: Tunnel reicht von NAS zu NAS. 3 Um Datenpakete unterschiedlichster Protokolle über ein öffentliches Netz (z.B. das Internet) zu übertragen, werden die Daten am Tunneleingang in Header desjenigen Protokolls gekapselt, das in dem öffentlichen Netz benutzt wird. Die Datenpakete durchlaufen den Tunnel nun wie „gewöhnliche“ Datenpakete des öffentlichen Netzes und sind von ihnen nicht zu unterscheiden. Haben die Pakete den Endpunkt des Tunnels erreicht, wird der hinzugefügte Header wieder entfernt und das Paket an seinen Zielort weitergeleitet. Man unterscheidet sogenannte „voluntary“ und „compelling“ Tunnel, also „freiwillige“ und „zwingende“. Ein freiwilliger Tunnel wird dabei auf Wunsch des Benutzers errichtet, z.B. wenn sich ein Nutzer per Internet mit seiner Bank verbindet. Eine Firma, deren Mitarbeiter sich von zuhause in die Firmenrechner über ein VPN verbinden möchten, hat hingegen Interesse an einem zwingenden Tunnel. Für den Mitarbeiter ist es weniger relevant, ob die Daten von einem Drittem abgehört werden, für die Firma hingegen schon. Generic Routing Encapsulation (GRE) Mit dem GRE-Protokoll wurde eine erste Standardisierung in Tunneling vorgenommen. Der eigentlichen Nutzlast (payload) wird ein spezieller Header hinzugefügt, der Informationen über das Protokoll der Nutzlast, eine Checksumme, Informationen über die Identität der Datenquelle, Informationen über die Verwendete Verschlüsselung sowie RoutingInformationen über den Tunnelausgang enthält. Diesem vorgelagert ist ein IP-Header, der zur Versendung über das Internet (oder eines anderen öffentlichen Netzes) genutzt wird. GRETunnel werden überlicherweise über einen Ingress- sowie einen Egress-Router implementiert, wobei die Daten konventionell bis zum Tunneleingang (dem Ingress-Router) transportiert und dort in den GRE-Header „verpackt“ werden. Diese „Verpackung“ wird nun normal über das öffentliche Netz geroutet, bis sie den Egress-Router (Tunnel-Endpunkt) erreicht hat. Dort wird der Inhalt wieder „ausgepackt“ und zu seinem entgültigen Zielort transportiert, der sich durch den Original-Header der Nutzlast ermitteln läßt. Die Router, über die das Paket seinen Weg durch das öffentliche Netz zurücklegt, wissen nichts über das VPN. Die Adresse eines Tunnelausgangs wird stets in dem Protokoll des öffentlichen Netzes (meist IP) spezifiziert, da das Routing über das öffentliche Netz erfolgt. Die Adresse des Tunneleingangs hingegen wird mit der Adresskonvention des privaten Netzes angegeben. Dies erfordert natürlich, daß sich die Tunnelenden an den Übergängen der Netze befinden. Bild 2: Generic Routing Encapsulation (GRE) 4 GRE-Tunnelungen sind überwiegend als Point-to-Point Lösungen zu finden, wenn auch vereinzelt Umsetzungen mit Point-to-Multipoint existieren. Hierbei kann ein Tunnel mehrere Ausgänge haben, die beim Tunneleintritt eines Pakets spezifiziert werden. Kapselungstechniken kommen auch dann häufig zum Einsatz, wenn sich die Protokolle der Nutzlast und des öffentlichen Netzes nicht unterscheiden. Ein Beispiel wären zwei TCP/IPLANs an geographisch unterschiedlichen Positionen, die über das Internet kommunizieren möchten, sich intern allerdings nicht an die Adress-Konventionen des Internet halten oder keine eindeutigen Adressen verwenden. Um korrekt über das Internet geroutet zu werden müssen sie am Tunneleingang mit IP-Headern gekapselt werden, die den AdressKonventionen entsprechen. Obwohl die Protokolle identisch sind besteht also die Notwendigkeit der Kapselung, da etwa bei der Planung des LANs die Möglichkeit über das Internet zu kommunizieren nicht bedacht wurde. Im Gegensatz zu Router-Router Tunnels gibt es auch Point-Point (Host-Host) Tunnels, wie etwas bei dem Layer-2 Tunneling Protokoll (L2TP) oder dem Point-to-Point Tunneling Protokoll (PPTP), die später noch detaillierter betrachet werden. Während sich bei PPTP der Tunnel über die gesamte Strecke von der Quelle bis zum Ziel erstreckt, ist dies bei RouterRouter Tunnels nicht der Fall, da dort die Daten zunächst ungekapselt bis zum Ingress-Router geschickt werden und auch ab dem Tunnelausgang bis zu ihrem Zielort ungekapselt transportiert werden. Bild 3: Ablauf einer GRE-Verbindung 5 Anstatt eines werden auch häufig mehrere Tunnels benutzt, um z.B. mehrere Zweigstellen eines Unternehmens miteinander zu verbinden. Die Struktur der Tunnelverbindungen kann dabei frei gewählt werden und es können auch redundante Tunnel – die also die gleichen Quell- und Zielpunkte haben angelegt werden. Es muß beachtet werden, daß die Spezifizierung der Tunnelenden stets mittels der in dem öffentlichen Netz verwendeten Adressen erfolgt. Einer der großen Vorteile der Tunnel-Technik ist, daß unterschiedliche VPNs, dich sich ihrer gegenseitigen Existenz nicht bewußt sind, intern die gleichen Adreßräume benutzen können ohne daß sich Probleme beim Routing in dem öffentlichen Netz ergeben. Im Gegensatz zum Controlled Route Leaking (CRL), wo die Daten nicht gekapselt werden, können sich nämlich keine doppelten Adressen ergeben, vorausgesetzt die Tunneleingänge halten sich an die Adress-Konventionen des öffentlichen Netzes. Weiterhin kann ein Tunnel ohne großen Aufwand auf neue interne Protokolle des VPN eingestellt werden, so daß die interne Struktur des privaten Netzes weitgehend irrelevant ist und der eigentliche Vorgang des Tunnelns für den Benutzer transparent ist. Als Nachteil des GRE-Tunneling gelten die hohen Verwaltungskosten, die schnell mit der Anzahl der bestehenden Tunnel anwachsen. Da die Ingress- und Egress-Router manuell konfiguriert werden müssen (bei neuen sowie bei Änderungen bestender Tunnel), ist der Verwaltungsaufwand bei großen VPNs nicht zu unterschätzen. Lösungen, in denen Tunnel automatisch errichtet werden - man spricht hier auch von „triggered Tunnels“ - haben den Nachteil, daß sehr leicht Situationen auftreten können, in denen das Routing suboptimal verläuft. Dabei kann es passieren, daß ein Paket mehrmals über den gleichen Tunnel geschickt wird. Auch die Performance und somit auch die QoS (Quality of Service) verschlechtern sich bei gleichzeitiger Verwaltung von vielen Tunnels. Außerdem sinkt auch die Performance der Einkapselung an den Tunneleingängen mit der Anzahl der implementierten Tunnels. Ist die Kapselung am Tunneleingang langsamer als die Verarbeitungsgeschwindigkeit des Routers, so bedeutet dies natürlich auch Einbußen in der Routing-Performance des Tunnels. Der generelle Nachteil bei Overlay-Modellen ist in dem fehlenden Einfluß auf das Routing zu sehen. Es ist bei der Planung eines Overlay-VPN nur schwer abzusehen, mit welcher Geschwindigkeit das Netz später arbeiten wird. Die Ingress- und Egress-Router können sich entweder beim VPN-Benutzer selber als sog. CPE (Customer Premise Equipment) oder beim ISP (Internet-Service Provider) befinden. Entscheidet sich der Nutzer für eine Verwaltung der Router durch den ISP, so kann er von den Kenntnissen des ISP über die Netzinfrastruktur profitieren und dadurch die RoutingPerformance erhöhen. Verwaltet der Nutzer die Geräte hingegen selber, so kann es dadurch zu suboptimalem Routing - zumindest im Einflußbereich des ISP - kommen. Bei dieser Vorgehensweise errichtet er sogar ohne Wissen des ISP ein VPN, das auch viele weitere Subnetze überspannen kann. RADIUS RADIUS steht für „Remote Authentication Dial-In User Service“ und bezeichnet einen zentralen Server, der die Daten der Benutzer eines VPN verwaltet. Verbindet sich der ein Benutzer über eine temporäre Verbindung mit dem VPN, so kontaktiert der Home-Agent (also das Tunnelende) den RADIUS-Server und verifiziert mit seiner Hilfe den Benutzernamen sowie das Passwort und optionale zusätzliche Informationen über den 6 Benutzer. Verläuft der Vorgang positiv, wird erst dann der Benutzer mit dem eigentlichen privaten Netz „hinter“ dem Home-Agent verbunden. Auch Zugangsrechte und Nutzungsdauern der einzelnen Benutzer werden auf dem RADIUS-Server gespeichert. Der RADIUS-Server führt auch häufig Statistiken über das VPN und benachtigt die Netzwerkadministatoren bei vordefinierten kritischen Zuständen. Daten wie durchschnittliche oder Spitzennetzauslastung sowie ein Profil über das Benutzerverhalten über die Stunden des Tages werden aufgezeichnet und in einer Datenbank zur späteren Auswertung und Verbesserung des Netzes festgehalten. Der RADIUS-Server wurde eingeführt um eine zentrale Verwaltung aller mit dem Netz zusammenhängenden Informationen zu ermöglichen. Wird in einem firmenweiten Netz ein Benutzer zu einer sog. „Community of Interest“, also einem bestimmten Benutzerkreis des VPN hinzugefügt, so muß dies nur an einer Stelle, nämlich genau auf dem RADIUS-Server geschehen. Selbst wenn der Benutzer später in einer anderen Abteilung oder sogar einer anderen Stadt arbeitet, so müssen nur einmal die Informationen auf RADIUS verändert werden. Die Überprüfung des Passworts des Benutzer erfolgt häufig mit dem Challenge Handshake Authentication Protokoll (CHAP). Dieses Protokoll macht eine Übertragung des Passworts über das Netz nicht erforderlich. Vielmehr erzeugt der RADIUS-Server eine sog. „Challenge“, einen Datenblock, der an den Benutzer geschickt wird. Auf dem Computer des Nuters wird diese Challenge mit einem vorher vereinbarten Hash-Algorithmus und seinem Passwort zerhackt. Das Ergebnis dieser Zerhackung wird an den RADIUS-Server zurückgeschickt. RADIUS nimmt nun selber die Zerhackung der ursprünglichen Challenge mit dem Passwort des Benutzers vor und vergleicht das Ergebnis des Benutzers mit seinem eigenen. Sind die Ergebnisse identisch, so ist der Benutzer im Besitz des richtigen Passwort für den eingeloggten Account und bekommt Zutritt zu dem privaten Netzwerk. Durch Vergleich der Challenges vor und nach dem Zerhacken auf das richtige Passwort zu schließen ist sehr unwahrscheinlich, erfolgreiche Lausch-Attacken bei diesem Verfahren sind also auszuschließen. Service Level Agreements (SLAs) Service Provider bieten häufig sogenannte Service Level Agreements (SLAs) an, die dem Nutzer einen bestimmten Quality of Service (QoS) des VPN-Verkehrs zusichern. Der Anbieter verpflichtet sich also gegenüber dem Kunden Netzausfälle unter einem bestimmtem Maß zu halten sowie Pakete in annehmbarer Zeit zuzustellen. Je nach den Anforderungen der jeweiligen Anwendung wird dabei individuell auf den Nutzer eingegangen. Weicht der ISP signifikant von diesen Zusicherungen ab, so erhält der Nutzer häufig ein Teil der Gebühren für die Bereitstellung der Infrastruktur zurück. Die selbständige Verwaltung des VPN durch den Nutzer hätte auch den Nachteil, daß SLAs fehlen und somit keine Zusicherungen bezüglich der Verfügbarkeit des Netzes bestehen. Möchte ein Benutzer ein VPN errichten, daß sich über mehrere Subnetze erstreckt, so ist die Aushandlung eines SLAs schwierig, da nun mehrere ISPs die Verantwortung für die Performance des Netzes tragen. Um zu verhindern, daß Netzteilnehmer von außerhalb des VPN Daten in den Tunnel einspeisen bedient man sich häufig Ingress-Filter, die Datenpakete, die nicht aus dem VPN kommen herausfiltern. Somit ist der Zugriff auf die Tunneleingänge auf einen bestimmten Personenkreis beschränkt. 7 Tunneling-Protokolle Es gibt viele Spezifikationen von Netzwerkprotokollen, die sich im RFC (Request for Comment) Status der IETF (Internet Engineering Task Force) befinden. Drei verbreitete Spezifikationen sind das Point-to-Point Tunneling Protokoll (PPTP), das Layer-2 Tunneling Protokoll (L2TP) sowie das IPSec (IP Security) Protokoll. Alle drei oder eine Kombination dieser sollen in der nächsten Version des IP-Protokolls Ipv6 unterstützt werden. IPSec findet bereits teilweise in der aktuellen Version (Ipv4) des Internet-Protokolls Verwendung. Layer-2 Tunnelungen Point-to-Point Tunneling Protokoll PPTP wurde von Microsoft und der Firma Ascend ins Leben gerufen und ist eine Erweiterung des Point-to-Point Protokolls (PPP) von Microsoft. Ursprünglicher Einsatzbereich des Protokolls war das Tunneln von Paketen für einen Remote Access Server (RAS) Ascends sowie für Windows NT bei Microsoft. Es setzt auf OSI-Ebene 2 (Transport-Layer) an. PPTP ermöglicht den sicheren Datentransfer zwischen einem Client und einem Server, der z.B. in einer großen Firma steht. Die Tunnelung erfolgt auf TCP/IP-basierten öffentlichen Netzen, also z.B. dem Internet. Das Protokoll kapselt PPP-Datenpakete in IP-Datagramme und verschickt sie über das Internet. Ein typischer Anwedungsfall des PPTP ist ein Client (u.U. auch mobil), der mit einem Firmeninternen LAN kommunizieren möchte. Dabei verbindet sich der Client mit dem Network Access Server (NAS) seines Internet Service Providers (ISP). Steht die PPPVerbindung zwischen Client und NAS, wird eine weitere Verbindung zwischen NAS und einem PPTP-Server in der Firma hergestellt. Diese Verbindung stellt den eigentlichen Tunnel dar, wobei der NAS den Tunneleingang und der PPTP-Server den Tunnelausgang bezeichnet. Bild 4: Eine getunnelte PPP-Connection L2TP verbindet die guten Eigenschaften von PPTP und dem Layer-2 Forwarding Protokoll (L2F) der Firma Cisco. Auch L2TP arbeitet auf der Layer 2 des OSI-Modells. 8 Layer-3 Tunnelungen IP-Security (IPSec) IPSec ist aus dem generellen Bestreben der Implementierung von Sicherheitseinrichtungen in das IP Protokoll entstanden. Es besteht aus einem ganzen Framework von offenen Standards, die auf Bestreben der IETF entstanden. Es findet weitreichende Unterstützung durch eine Vielzahl von großen Netz-Herstellern sowie der Automotive Network Exchange Group (ANX), eine Vereinigung von Herstellern und Zulieferern von Netzwerkkomponenten. IPSec eignet sich ausschließlich für auf IP aufbauende VPNs, beinhaltet allerdings starke Sicherheitsmechanismen, Verschlüsselung, Autenzität sowie Datenintegrität und Schlüsselverwaltung. Alle diese Sicherheitsmechanismen IPSecs sind optional. IPSec kommt in OSI-Ebene 3 zum Einsatz (Netzwerk-Ebene). Folgende Bereiche sollen mit IPSec abgedeckt werden: Data origin authentication – stellt sicher, daß jedes Datagramm tatsächlich von dem Sender stammt, von dem es zu kommen scheint. Data integrity (Datenintegrität) – stellt sicher, daß Daten nicht während der Übertragung verändert wurden. Diese Veränderunge schließen vorsätzliche und durch die Hardware verursachte Fehler mit ein. Test auf Datenintegrität dient also auch der Fehlererkennung und Fehlerbereinigung. Vertrauliche Behandlung der verschickten Daten – wird durch entsprechende Verschlüsselung erreicht. Replay protection – stellt sicher, daß ein Angreifer nicht in der Lage ist, einzelne Datagramme abzufangen und später wiederzugeben ohne entdeckt zu werden. Automatisierte Schlüsselverwaltung für unterschiedliche Verschlüsselungsverfahren. Diese Automatisierung soll den manuellen administrativen Aufwand auf ein Minimum beschränken und somit die Skalierbarkeit auch bis zu sehr großen VPNs ermöglichen. Später, nach einem kurzen Einblick in die Datenverschlüsselung wird noch näher auf die Implementierung von Sicherheitsmechanismen in IPSec eingegangen. PPTP und L2TP werden eher bei nicht auf IP aufbauenden Umgebungen eingesetzt, in denen auch mehrere Protokolle gleichzeitig verarbeitet werden können. 9 Bild 5: Eigenschaften von PPTP, L2TP und IPSec Datenverschlüsselung Um dem Wort „private“ gerecht zu werden, muß neben der bereits behandelten virtuellen Struktur, die dem unterliegenden Netz aufgeprägt wird, besonders auch die Verschlüsselung der versendeten Daten gewährleistet werden. Verschlüsselungsverfahren können in zwei Klassen – symmetrische und asymmetrische – Verfahren aufgeteilt werden. Symmetrische Verfahren zeichnen sich dadurch aus, daß zur Kodierung sowie Dekodierung der Daten ein (geheimer) Schlüssel verwendet wird, der beiden Seiten bekannt sein muß. Es gibt zwei Typen von symmetrischen Algorithmen: 1. Block-Algorithmen – Sie teilen die Daten in Blöcke vorgegebener Größe auf und kodieren blockweise. Häufig werden Kodierungsergebnisse aus früheren Blöcken in die Codierung folgender Blöcke eingebunden. Somit hängt die Kodierung späterer Blöcke von der Kodierung aller vorhergehenden Blöcke ab. Dieses Verfahren wird auch Cipher-Block-Chaining genannt. Einem Eindringling, der sich nur einen Teil der Blöcke beschafft, gelingt es also nicht, diese Teilmenge der Nachricht zu entschlüsseln – selbst wenn er das für einen einzelnen Block richtige 10 Codebuch besitzt. Ein Codebuch ist dabei eine Art Tabelle, in der Klartext und deren korrespondierende Zeichen in der Verschlüsselung miteinander assoziiert werden. Ein bekannter Vertreter der Block-Algorithmen ist der in den 70er Jahren von IBM entwickelte Data-Encryption-Standard (DES). 2. Stream-Algorithmen – Sie operieren auf den einzelnen Bits bzw. Bytes des Datenstroms. Ein bekannter Vertreter dieser Algorithmen ist der A5, der im Mobilfunkstandard GSM eingesetzt wird. geheimer Schlüssel ABC geheimer Schlüssel $?@ Verschlüsselung Klartext ABC Entschlüsselung Chiffrierter Text Person A Originaltext Person B Bild 6: Symmetrische Verschlüsselung und Entschlüsselung Bei den symmetrischen Verfahren muß der Schlüssel also vor der Etablierung einer sicheren Verbindung über einen sicheren Kanal ausgetauscht werden. Wie aber soll der Austausch über einen sicheren Kanal erfolgen, wenn die Voraussetzung für einen solchen Kanal wiederum ein Schlüssel ist, der beiden Seiten bekannt sein muß ? Um dieses Problem zu lösen bedient man sich oft sogenannter asymmetrischer Verfahren, um den anfänglichen Austausch des geheimen Schlüssels (des symmetrischen Verfahrens) über einen „sicheren“ Kanal zu ermöglichen. Dabei besitzt jede Seite jeweils einen sog. Privaten sowie einen öffentlichen Schlüssel (private und public key). Der öffentliche Schlüssel wird dabei (wie der Name schon impliziert) der Öffentlichkeit verfügbar gemacht. Er wird benutzt um Daten für einen bestimmten Adressaten zu verschlüsseln. Daten, die mit dem öffentlichen Schlüssel von Subjekt A chiffriert wurden, können einzig und allein mit dem privaten Schlüssel des Subjektes A wieder entschlüsselt werden. Selbst der Sender kann also einmal für einen Empfänger chiffrierte Daten nicht selber wieder entschlüsseln! Sind der öffentlichen Schlüssel des asymmetrischen Verfahrens dem jeweils anderen Kommunikationspartner bekannt, kann die sichere Übertragung oder Aushandlung des „symmetrischen“ Schlüssels erfolgen. Nun kann die Übertragung der eigentlichen Nutzdaten beginnen, die mit dem Schlüssel des symmetrischen Verfahrens kodiert werden. Der wohl bekannteste Algorithmus, der mit dem private/public key Verfahren arbeitet ist der Internal Data Encryption Algorithm (IDEA), der auch in der Shareware-Krypto-Programm „Pretty Good Privacy“ (PGP) Verwendung findet. 11 B´s öffentlicher Schlüssel ABC B`s privater Schlüssel $?@ Verschlüsselung Klartext ABC Entschlüsselung Chiffrierter Text Person A Originaltext Person B Bild 7: Verschlüsselung/Entschlüsselung mit öffentlichem/privatem Schlüssel Der Grund, warum man nicht für alle Datenversendungen asymmetrische Verfahren benutzt ist vor allem in der Rechenintensität dieser Methoden zu suchen. Symmetrische Verfahren sind meist sehr viel effizienter und können wesentlich leichter in Hardware realisiert werden. Eine Kombination der beiden Verfahren, bei der die Schlüsselaushandlung/Übertragung asymmetrisch und die eigentlich Datenverschlüsselung symmetrisch realisiert wird kompensiert also Schwächen der separaten Lösungen. Um die Sicherheit der Kommunikation auch über langfristige Zeiträume aufrechtzuerhalten, wird oft nach einer bestimmten Zeit, die sich hauptsächlich nach der Sensitivität der Daten richtet, ein neuer Schlüssel ausgehandelt. Auch private/public-Key Verfahren sind keineswegs absolut sicher. Der Algorithmus basiert auf der Faktorisierung großer Zahlen und mit der Rechenleistung moderner Computeranlagen ist es heute durchaus möglich Schlüssel zu knacken. Gerade im Internet gibt es immer wieder öffentlich ausgeschriebene Wettbewerbe in denen aufgerufen wird von einem öffentlichen Schlüssel auf den zugehörigen privaten Schlüssel zu schließen. Je länger ein Schlüssel dabei ist, umso länger dauert es auch ihn zu knacken. Üblich sind heutzutage Schlüssellängen von 128 Bit und mehr und sie wird auch mit steigender Rechenleistung moderner Rechenanlagen in Zukunft deutlich in die Höhe schnellen. Nicht zuletzt die Entdeckung eines Algorithmus zur Faktorisierung von großen Zahlen in polynomieller Zeit (bis vor einigen Jahren unbekannt) wird seinen Beitrag zum schnellen Anstieg der Schlüssellänge leisten. Zertifikate Ein grundlegendes Problem der asymmetrischen Verfahren beim Schlüsselaustausch ist das der Authentizität. Denn man kann sich keineswegs sicher sein, daß der Kommunikationspartner auch wirklich derjenige ist, für den er sich ausgibt. Ein Dritter, der den Kanal belauscht, könnte den öffentlichen Schlüssel des Gegenübers abfangen und stattdessen seinen eigenen Schlüssel übermitteln ohne, daß der Adressat dies merkt. Somit 12 könnte dieser Dritte jede Nachricht mittels seines privaten Schlüssels lesen, da sie ja in Wirklichkeit mit seinem öffentlichen Schlüssel kodiert wurde. Weiterhin könnte er die abgefangenen Nachrichten mit dem öffentlichen Schlüssel des tatsächlichen Adressaten verschlüsseln und weiterleiten, so daß die Nachrichten auch ihren wirklichen Adressaten erreichen und somit niemand die Abhörattacke bemerkt. Abhilfe zu diesem Problem schaffen sogenannte Zertifikate, durch die ein Individuum seine Identität beweisen kann. Zertifikate assoziieren den öffentlichen Schlüssel mit der Identität seines Besitzers. Sie werden von vertrauenswürdigen öffentlichen Einrichtungen – Certification Agencies (CAs) – vergeben und mittels des privaten Schlüssels der CA signiert. Eine Signierung ist dabei nichts anderes als eine Chiffrierung des Zertifikats mit einem privaten Schlüssel. Vor der eigentlichen Datenübertragung tauschen die Partner nun anstatt der öffentlichen Schlüssel ihre Zertifikate aus und überprüfen die Authentizität derselben mit Hilfe des öffentlichen Schlüssels der CA. Sind sie in der Lage, daß Zertifikat mit dem öffentlichen Schlüssel der CA zu entschlüsseln, dann können sie sicher sein, daß das Zertifikat auch wirklich von der CA ausgegeben wurde, weil ja nur sie im Besitz des privaten CA-Schlüssels ist. Daraus kann man also auf die Richtigkeit des Zertifikates schließen. Nach positivem Verlauf können die Subjekte nun sicher sein, daß sie den richtigen öffentlichen Schlüssel des Adressaten besitzen. Neben dem öffentlichen Schlüssel und den Benutzerdaten enthält ein Zertifikat auch häufig zusätzliche Daten wie Ausgabedatum und Verfallsdatum. Die Signierung eines Dokumentes kann auch als eine Unterschrift verstanden werden. Da der private Schlüssel geheim ist, ist nur der Besitzer des Schlüssels in der Lage ein Dokument mit seiner „Unterschrift“ zu signieren. Ob ein Subjekt A ein Dokument signiert hat, kann stets mit dem öffentlichen Schlüssel des Subjektes A überprüft werden. Herrscht eine Signierungspflicht bei Verträgen oder geschäftlicher Email kann nun jemand nicht mehr behaupten, er hätte ein bestimmtes Dokument nicht verfaßt, weil dies mittels seines öffentlichen Schlüssels widerlegt werden kann. A`s öffentlicher Schlüssel A´s privater Schlüssel ABC $?@ Verschlüsselung Klartext ABC Entschlüsselung und Beurkundung Chiffrierter Text Person A Originaltext Person B Bild 8: Beurkundung durch signieren mittels privatem Schlüssel 13 Aufbau des IPSec - Framworks Die Sicherheitsmechanismen des IPSec-Frameworks sollen nun näher beleuchtet werden. Im Kern besteht dieses Framework aus drei Protokollen: IP Authentication Header (AH) Ermöglicht Data Origin Authentication, Data Integrity und Replay Protection. IP Encapsulating Security Payload (ESP) Beinhaltet Data Confidentiality, Data Origin Authentication, Data Integrity und Replay Protection Internet Security Association and Key Management Protocol (ISAKMP) oder auch schlicht IKMP Bild 9: Struktur eines IPSec-Frames Authentication Header (AH) Der IP Authentication Header unterstützt verbindungslose (also pro Paket) Datenintegrität und Data Origin Authentication für IP-Datagramme. Weiterhin bietet AH Schutz vor Wiederholungsattacken, entlarvt also während einer vorhergenden Verbindung aufgenommene und nun wiedergegebene Datagramme als falsch. Die Datenintegrität wird mittels eines Checksummen-Algorithmus (z.B. MD5) realisiert, der sowohl vorsätzliche als auch versehentliche Veränderungen erkennt. Data Origin Authentication wird mittels der Signierung der Daten durch den privaten Schlüssel des Senders erreicht. Ob ein Datenpaket von dem erwarteten Absender stammt kann wie gewöhnlich mit dem öffentlichen Schlüssel des Absenders überprüft werden. Durch eine laufende Nummer im AH der Datenpakete können Wiederholungsattacken erfolgreich abgeschmettert werden. Die drei obigen Eigenschaften von IPSec werden unter dem gemeinsamen Begriff „Name Authentication“, also Namensbeglaubigung/Beurkundung zusammengefaßt. 14 IP Encapsulation Security Playload (ESP) Das IP Encapsulating Security Payload unterstützt Datenvertraulichkeit durch Verschlüsselung, verbindungslose Datenintegrität (pro Paket), Data Origin Authentication sowie Schutz gegen Wiederholungsattacken. Im Gegensatz zum Authentication Header unterstützt ESP zusätzlich Datenverschlüsselung. Wird ESP anstatt AH für Authenzitätszwecke benutzt, so kommen dabei die gleichen Algorithmen wie bei AH zum Einsatz. AH oder ESP können als eigenständige Lösungen oder auch in verschiedenen Mischformen eingesetzt werden. Insgesamt werden durch beide Protokolle Datenverschlüsselungsmechanismen und Authenzitätskontrolle zwischen zwei Rechnern, zwischen zwei Firewalls oder zwischen einem Rechner und einer Firewall ermöglicht. Das Internnet Security Association Key Management Protokoll (ISAKMP/Oakley) ISAKMP spezifiziert ein standardisiertes Framework zur Aushandlung von sicherheitsrelevanten Daten und Schlüsselpaaren einer Kommunikation. Diese Spezifizierung der verwendeten Algorithmen wird auch Security Association (SA) genannt. Weiterhin verwaltet es auch eine an die Anwendung angepaßte Generierung von neuen Schlüsseln nach einem bestimmten Zeitintervall. Oakley bezeichnet ein Schlüssel-Management-Protokoll, das meist in einem ISAKMP-Framework benutzt wird. Der sichere Austausch der Schlüssel ist der kritischste Punkt in der Etablierung einer sicheren Kommunikation. Egal wie sicher die auf den Schlüsseln aufbauenden Verschlüsselungsmethoden auch sind, wenn sie einem Dritten in die Hände gelange, sind sie wertlos. ISAKMP ist in der Lage über unsichere Verbindungen Schlüsselaushandlungen durchzuführen. ISAKMP kann also als eine Art Initialisierungsroutine für die anderen Protokolle von IPSec angesehen werden. Tatsächlich sind die in den ISAKMP-Protokollen benutzten Algorithmen die rechenintensivsten in der gesamten IPSec-Architektur. Allerdings kommen sie ja auch nur in einem Bruchteil der gesamten Kommunikation, nämlich in der Initialisierung zum Einsatz. ISAKMP erfordert es, daß alle ausgetauschten Informationen verschlüsselt und beglaubigt werden. Ansonsten könnten Schlüsselverhandlungen belauscht und die Schlüssel für eine Attacke mißbraucht werden. Die ISAKMP-Nachrichten selber werden als UDP-Playload verschickt. Da die Schlüsselaushandlung der sensibelste Teil der Übertragung gegenüber Angriffen ist, stellt das IKMP eine Reihe von robusten Schlüsselaushandlungsprotokollen zur Verfügung. Die Aushandlung erfolgt in 2 Phasen: 1. In dieser ersten Phase wird ein sogenannter Hauptschlüssel (master key) ausgehandelt, von dem alle folgenden während dieser Verbindung erzeugten Schlüssel abgeleitet werden. In den meisten Fällen wird dabei ein public-key Verfahren wie RSA benutzt. Zur Identifizierung des Kommunikationspartners bedient werden gegenseitig Zertifikate angefordert und diese mit dem öffentlichen Schlüssel der CA auf ihre Richtigkeit überprüft. Dieser Master-Key wird zunächst nur benutzt, um die Daten, die zur weiteren IKMP-Aushandlung notwendig sind zu sichern – die Daten der Benutzer werden nicht verschlüsselt. Die Phase-1 15 Aushandlungen sind sehr prozessorintensiv und werden nur sehr selten ausgeführt (in der Regel einmal am Tag, bei einer dauerhaften Verbindung). Das Ziel der Phase-1 Aushandlungen ist also die Herstellung einer sicheren abhörsicheren Umgebung für die weitere Aushandlung von sicherheitsrelevanten Informationen. 2. Die durch die erste Phase hergestellte sichere Umgebung wird nun benutzt, um die Schlüssel auszuhandeln, die die Daten der Benutzer schützen. Phase-2 Aushandlungen werden nun je nach erforderter Sicherheitsstufe etwas alle 1-10 Minuten durchgeführt und dabei jeweils neue Schlüssel erzeugt. Die Aushandlung der Schlüssel braucht nun nicht mehr über asymmetrische Verfahren stattzufinden, da durch Phase 1 eine sichere Umgebung hergestellt wurde. Security Associations (SAs) Security Associations legen in einem gewissen Rahmen die verwendeten Algorithmen und Verschlüsselungsmethoden fest, die während einer Verbindung benutzt werden sollen. Hiermit erfolgt also die entgültige Spezifikation der verwendeten Methoden. Eine Security Association beschreibt eine unidirektionale Verbindung zwischen zwei IPSec-Systemen, spezifiziert also die Sicherheitsparameter für nur eine Richtung der Verbindung. Eine bidirektionale Verbindung benötigt also immer mindestens zwei SAs. Bestandteil einer typischen Security Associon sind dabei folgende: Der zur Beurkundung der Identität benutzte Algorithmus (wird bei Umsetzung des Authentication Headers (AH) gebraucht, um den Modus des Vorgangs genau zu beschreiben) Spezifizierung der Schlüssel, die vom Verschlüsselungsalgorithmus benutzt werden (wird bei Implementationen gebraucht, die AH verwenden) Beschreibung des eigentlichen Verschlüsselungsalgorithmus, der zur Chiffrierung der Daten im Encapsulating Security Payload (ESP) benutzt wird Spezifizierung der Schlüssel, die im Rahmen des ESP benutzt werden Festlegung, ob ein Initialisierungsvektor (Startwert) für den Verschlüsselungsalgorithmus des ESP existiert. Gültigkeitsdauer für diese Security Association Adressen der Security Association. Wenn mehrere sendende Systeme die gleiche Security Association benutzen, kann diese Spezifizierung auch mit Jokerzeichen versehen werden. Eine SA wird durch folgenden Vektor eindeutig bezeichet: <Security Parameter Index, IP Destination Address, Security Protocol> 16 Der Security Parameter Index (SPI) ist ein 32-Bit Wert, der auch unterschiedliche SAs auf ein und demselben Rechner mit dem gleichen Security Protocol bezeichnen. Der SPI wird im Header des Security Protocols (AH oder ESP) mitgeführt. Er kann bei der Erschaffung einer neuen SA frei gewählt werden. Die Werte 1-255 sind von der Internet Assigned Numbers Authority (IANA) reserviert. Die IP Destination Address bezeichnet die Zieladresse der beschriebenen SA. Dieser Wert kann „AH“ oder „ESP“ sein. Zertifikate in IPSec In IPSec-Zertifikaten können folgende Identitätsbezeichner eines Subjektes enthalten sein: Die IP-Adresse Die Subnetz-Adresse Der Domain-Name allein Ein beliebiger Text. Wird zu Beginn einer Verbindung ein Zertifikat der Gegenseite angefordert, so behält es bis zum Beenden der Verbindung seine Gültigkeit. Dies ist der Fall, da sich die IP-Adresse des Gegenübers nicht ändert. Ein Zertifikat sollte also auch Informationen enthalten, die während der Verbindung überprüft werden können (IP-Adresse, Domain-Name usw.). Implementationformen von IPSec Ein auf IPSec aufbauendes Virtual Private Network kann je nach Anwendung mit unterschiedlicher Hard- und Software realisiert werden. Meist handelt es sich um eine Kombination von Clients, Servern, Firewalls und auch Routern, die auf der IPSecTechnologie basieren. Dabei kommen die einzelnen Komponenten häufig von unterschiedlichen Herstellern. Diese Tatsache erfordert natürlich eine starke firmenübergreifende Standardisierung, damit die Komponenten reibungslos zusammenarbeiten können. Andere VPN Protokolle Prinzipiell kann man sich auf jeder Ebene des OSI-Schichtenmodells ein Protokoll zur sicheren Übertragung über das Internet vorstellen. Dabei kann die Wahl des richtigen Protokolls je nach Anwendungsfall unterschiedlich ausfallen. 17 Bild 10: VPN-Protokolle im OSI-Stack Secure Sockets Layer (SSL) Bei Secure Sockets Layer handelt es sich um eine sogenannte Transport-Layer-Security (TLS). SSL agiert im OSI-Stack zwischen der Transportschicht (TCP/UDP) und der Applikationsschicht. Es ermöglicht eine sichere Ende-zu-Ende Verbindung basierend auf TCP. SSL erfreut sich zunehmender Popularität und hat sich als inzwischen als quasiStandard für sichere Web-Transaktionen etabliert. SSL wurde von der Firma Netscape ins Leben gerufen und wurde von der IETF als offener Standard erklärt. SSL kann in zwei unterschiedlichen Vorgehensweisen in eine Umgebung eingebunden werden: 1. Es wird komplett in das Protokoll der unterliegenden Transportschicht eingegliedert und ist somit für alle Applikationen transparent, da diese wie gewohnt auf die Transportschicht zugreifen. Neue Software braucht nicht auf SSL zugeschnitten zu werden, wenn man diese Vorgehensweise realisiert. 2. SSL wird als PlugIn in bestehende Softwarepakete eingebunden. Dies können z.B. Webbrowser oder auch Webserver wie z.B. von Netscape und Microsoft sein. Nachteil hier: Existiert für eine Software (noch) kein SSL-PlugIn kann keine sichere Kommunikation mittels SSL erfolgen. 18 Applikationsschicht SSL Transport-Schicht Bild 11: Die Position von SSL im OSI-Stack. In einem Browser wird SSL für eine Verbindung benutzt, wenn ein Link mit dem Prefix „https://“ gewählt wird. Der Browser erkennt, daß eine sichere Verbindung hergestellt werden soll und spricht den Webserver nun nicht auf Port 80, sondern auf dem für SSL festgelegten Port 443 an. Dort kommuniziert er mit dem serverseitigen SSL-PlugIn und empfängt nach dem Aushandeln der verbindungsrelevanten Informationen die Daten, die sich hinter dem Link verbergen – und zwar über die sichere Verbindung. Ist solch eine sichere Verbindung erst einmal hergestellt, wird dies meist durch ein visuelles Feedback für den Benutzer im Browser erkennbar. Große Firmen wie Netscape und Microsoft haben SSL schon seit einigen Versionen in ihren Web-Browsern integriert. SSL unterscheidet zwischen einer Connection und einer Session Eine Session ist eine Verbindung zwischen einem Client und einem Server. Beim Erschaffen einer Session werden sicherheitsrelevante Daten für die Verbindung ausgehandelt. Eine Connection ist eine logische Verbindung zwischen einem Client und einem Server, die auf den ausgehandelten Daten der zugehörigen Session aufbaut. Durch dieses Verfahren spart man die aufwendige Aushandlung der sicherheitsrelevanten Daten bei jeder neuen Connection. Üblicherweise bestehen während einer sicheren Übertragung zwischen dem Client und dem Server genau eine Session aber mehrere Connections. Wenn auch theoretisch die Möglichkeit besteht mehrere Sessions zwischen den selben Punkten gleichzeitig zu verwalten, macht dies in der Praxis meistens keinen Sinn. Auch wenn SSL nicht ausschließlich für Webtransaktionen benutzt werden kann liegt hier doch das hauptsächliche Einsatzgebiet des Protokolls. Mögliche Einsatzgebiete sind sämtliche Transaktionen von vertraulichen Daten wie z.B. Homebanking oder Bestellung per Kreditkarte. 19 Secure Mail (S-MIME) Ein weiterer Standard, der allerdings auf der Applikationsebene ansetzt ist die „Secure Multipurpose Internet Mail Extension“ (S-MIME). Es ist eine um Sicherheitsmechanismen erweiterte Version des MIME. S-MIME beschränkt sich im Wesentlichen auf die sichere Übertragung von E-Mail und benutzt dabei Datenverschlüsselung sowie digitale Signaturen. Für die Verschlüsselung werden public-key Verfahren benutzt, die Identität der Benutzer wird anhand von Zertifikaten festgestellt. 20 Quellenverzeichnis: [1]: http://www.ietf.org (Internet Drafts und RFC´s zu PPTP, IPSec) [2]: http://www.redbooks.ibm.com (Dokumente „sg245201.pdf“ und „sg245234.pdf“ mit dem Titel ( „A Comprehensive Guide ToVirtual Private Networks Part I & II“ ). [3]: http://www.cisco.com/ipj ( Anbieter von VPNs / Internet Protocol Journal). [4]: Microsoft Developer Network CDs ( Einführung in VPNs ) [5]: C´T-Artikel „Privatissimo“, Ausgabe Nr.4 vom 15.02.1999, S.190 21
