Da fast alle Firmen bereits an das Internet angeschlossen sind, sorgen bereits vielerorts Firewalls und Viren-Scanner für die nötige Access- und Content-Security. Wer nun aber auch die gesamte Firmenkommunikation auf das Internet abbilden will, der sollte sich auch um Authentication- und Crypto-Security bemühen und ein VPN aufbauen.

Auf ins virtuelle Netz

Ein VPN ist ein privates Netz, das auf der Basis einer öffentlichen Netzinfrastruktur gebildet wird. Dies erreicht man durch Tunneling. Die zu übertragenden Datenpakete werden als Nutzdaten in ein anderes IP-Paket verpackt, über das Internet übertragen und vom Empfänger wieder ausgepackt. Dazu wird das ursprüngliche Datenpaket mit einem zusätzlichen IP-Header und den Protokollinformationen des verwendeten Tunneling-Protokolls versehen. Dieses Verfahren realisiert virtuelle Standleitungen durch das Internet und sorgt dafür, daß die Daten quasi in einer uneinsehbaren Röhre durch das öffentliche Netz geleitet werden. Somit hat der Hacker 1 in Bild 1 keine Chance, auf die Daten zuzugreifen.

Mittels der VPN-Technologie sollten nur Netze mit ähnlichem Sicherheitsniveau verbunden werden. Verbindet man nämlich ein hochsicheres LAN, in dem alle Mitarbeiter eine definierte Sicherheitspolitk genau befolgen, mit einem LAN, in dem keine Sicherheitsstrategie festgeschrieben ist und jeder Mitarbeiter sein eigenes Modem installieren darf, könnte sich ein Eindringling (Hacker 2 in Bild 1) Zugang zum unsicheren Netz verschaffen und von dort aus über eine vertrauenswürdige VPN-Verbindung in das sichere Netz vordringen.

Bild 1: Angriffsversuche auf ein VPN

Abhängig vom Provider?

Viele Netzadministratoren outsourcen das Thema VPN und beauftragen ihren ISP mit der Realisierung. Das hat den Nachteil, daß die sichere virtuelle Standleitung nur im Internet aufgebaut wird und der Anwender selbst die letzte Meile zum ISP sichern muß. Hierzu verwendet man die gewohnten Sicherheitmechanismen der klassischen privaten Netze, wie CLID (Calling Line Identification), Call-Back und PAP/CHAP (Password Authentication Protocol / Challenge Handshake Authentication Protocol).

Provider-unabhängige VPN-Realisierungen erlauben dagegen Ende-zu-Ende-Tunnel zwischen den Standorten und die Integration mobiler Clienten. Dazu muß man an jedem Standort ein VPN-Gateway installieren und die Notebooks der mobilen Nutzer mit einer VPN-Client-Software versehen. Es wird empfohlen, keine All-In-One-Systeme zu installieren, die Firewall und VPN-Gateway vereinen. Denn ein mehrstufiger Aufbau (siehe Bild 2) ist performanter und stellt keinen Single Point of Failure dar. Ein Sicherheitskonzept, das auf mehreren getrennten Systemen basiert, die von unterschiedlichen Herstellern kommen und auf verschiedenen Betriebssystemen laufen, macht potentiellen Eindringlingen das Leben erheblich schwerer.

Bild 2: Provider-unabhängiges VPN mit mehrstufigem Aufbau

Layer 2 oder Layer 3?

Für den VPN-Aufbau stehen mehrere Tunneling-Protokolle zur Verfügung. Man unterscheidet zwischen VPNs mit Layer-2-Tunneling und VPNs mit Layer-3-Tunneling. Layer-2-Tunneling bieten die Protokolle PPTP (Point to Point Tunneling Protocol), L2F (Layer 2 Forwarding) oder L2TP (Layer 2 Tunneling Protocol). Layer-3-Tunneling wird meist mit IPSec realisiert. Beim Layer-2-Tunneling werden Frames der OSI-Schicht 2, meist PPP-Frames, in IP-Pakete gepackt. Dies ist die übliche Methode, um auch Nicht-IP-Protokolle zu tunneln. Beim Layer-3-Tunneling werden dagegen IP-Pakete als Nutzdaten neuer IP-Pakete verschickt (Bild 3).

Bild 3: Unterschied zwischen Layer-2- und Layer-3-Tunneling

PPTP wurde ursprünglich von Microsoft und Ascend entwickelt und ist aufgrund seiner Integration in Windows weit verbreitet. Es handelt sich um eine Erweiterung des Point to Point Protokolls (PPP). PPTP ermöglicht die Protokoll-transparente Übertragung von IP-, IPX- und NetBUI-Paketen. Die einzelnen Pakete werden in eine modifizierte Form des Generic Routing Encapsulation Protocol Version 2 (GREv2) verpackt und zum Network Access Server (NAS) des ISP transportiert. Die Datenverschlüsselung erfolgt nach dem RC4-Verfahren von Ronald Rivest mit Schlüssellängen von 40 oder 128 Bit. Eine Paket-Integritätsrüfung ist nicht implementiert. Je Kommunikationspaar kann nur ein Tunnel aufgebaut werden. Zur Authentisierung dient PAP/CHAP; eine Authentisierung der Tunnelenden ist jedoch nicht vorgesehen. In PPTP sind keine Key-Management-Protokolle implementiert und PPTP ist nicht standardisiert. Der alte RFC Draft (draft-ietf-pppext-pptp-00) ist inzwischen "expired".

L2F wurde von Cisco, Nortel und Shiva entwickelt. Eine Multiplex-ID und eine Client-ID im L2F-Header erlauben den gleichzeitigen Betrieb mehrerer Tunnel und innerhalb jedes Tunnels mehrere parallele Verbindungen. Unterstützt werden Punkt-zu-Punkt und Punkt-zu-Mehrpunkt-Verbindungen. Neben PPP kann man mit L2F auch SLIP (Serial Line Internet Protocol) tunneln. Die Authentisierung erfolgt über ein Challenge-Handshake-Verfahren. Eine Verschlüsselung der Daten ist nicht vorgesehen. L2F kann über unterschiedliche Paketnetze transportiert werden, etwa X.25, Frame Relay oder ATM. Der zugehörige RFC 2341 hat den Stand "historic".

L2TP vereint die Vorteile von PPTP und L2F. Eine Tunnel-ID im L2TP-Header erlaubt den Betrieb multipler Tunnels. L2TP ist ein Proposed Standard nach IETF RFC 2661. NAT (Network Address Translation) wird unterstützt. Verschlüsselung ist nicht definiert.

IPSec

IPSec (IP Security) ist ein Layer-3-Tunneling-Protokoll. Da es ein höheres Maß an Sicherheit bietet, wird es die Layer-2-Protokolle langfristig als VPN-Standard ablösen. IPSec ist für IPv4 definiert und fester Bestandteil von IPv6. Es handelt sich bei IPSec um ein Rahmenwerk verschiedener Normen (RFC 1825-1829, bzw. 2401-2412) das festlegt, mit welchen Ergänzungen das Internet Protokoll die Integrität und die Vertraulichkeit der Daten sowie die Authentizität der Teilnehmer garantieren kann. Wesentliche Design-Ziele bei der IPSec-Definition waren,

• daß sich IPSec transparent gegenüber den Applikationen verhält und somit leicht in bestehende Netze integriert werden kann,
• daß keine Festlegung auf bestimmte Verschlüsselungsverfahren erfolgen muß,
• daß für die Authentisierung und die Verschlüsselung unterschiedliche Protokolle zum Einsatz kommen, die unabhängig voneinander oder zusammen eingesetzt werden können und
• daß es grundsätzlich möglich ist, IPSec künftig um weitere Protokolle zu ergänzen.

Die Datenintegrität und die Authentisierung des Datenursprungs wird mittels des Authentication Headers (AH) erreicht. Der AH-Header schützt die Daten und einige Header-Teile des zu übertragenden IP-Pakets vor Verfälschung. Dazu wird mittels bekannter Hash-Funktionen wie MD-5 (Message Digest) oder SHA-1 (Secure Hashing Algorithmus) eine Prüfsumme aus der IP-Payload gebildet und im AH-Header an den Empfänger übertragen. Wenn dieser die selbe Prüfsumme aus dem empfangenen Paket errechnet ist sichergestellt, daß die Nachricht während der Übertragung nicht verändert wurde und nur von dem Absender stammen kann, der den geheimen Schlüssel für das gewählte Authentisierungsverfahren kennt.

Man unterscheidet den AH-Transport- und den AH-Tunnel-Modus. Im Transport-Modus wird der AH-Header zwischen IP-Header und den Headern der Transportschicht eingefügt und somit die IP-Payload gesichert. Beim Tunnel-Modus wird eine Prüfsumme aus fast dem gesamten ursprünglichen Paket gebildet. Der AH-Header wird in diesem Fall dem ursprünglichen Paket vorangestellt und mit einem neuen IP-Header versehen. Ausgenommen von der Prüfsummenbildung sind einige Felder, wie TOS (Type of Service), TTL (Time to Live), Header-Checksum etc.. Im Tunnel-Modus enthält das innere IP-Paket im IP-Header die Source- und Destination-Adressen der miteinander kommunizierenden Rechner. Der äußere IP-Header enthält die IP-Adressen der Tunnelendpunkte (siehe Bild 4).

Bild 4: Authentication Header Format im Transport- und im Tunnel-Modus

Der AH-Header (Bild 4) enthält als wichtigsten Bestandteil die Prüfsumme (Authentication Data). Das Prüfsummenfeld ist von variabler Länge, da je nach verwendetem Prüfsummenverfahren unterschiedlich lange Prüfsummen gebildet werden. MD-5 erzeugt eine Prüfsumme der Länge 128 Bit, die Prüfsumme bei SHA-1 ist 160 Bit lang. Außerdem kann optional eine Sequenz-Nummer hinzugefügt werden, die die Datenpakete von 0 bis 2³²-1 durchnummeriert. Somit können Replay-Attacken verhindert werden. Man kann also erkennen, wenn Datenpakete kopiert und zu einem späteren Zeitpunkt erneut übertragen werden, mit der Absicht, den Empfänger zu irritieren oder zu einem späteren Zeitpunkt ein falsches Verhalten auszulösen. Der Security Parameter Index (SPI) ist ein weiterer wesentlicher Bestandteil des AH-Headers. Er beschreibt die ausgehandelten Sicherheitsparameter, wie das aktuell gültige Verfahren zur Verschlüsselung oder die Gültigkeitsdauer des Schlüssels. Zusammen mit der IP-Adresse definiert der SPI die Security Association (SA), die für jede unidirektionale Verbindung die zugehörigen Sicherheitsmechanismen beschreibt.

Verschlüsselung in IPSec

Der Encapsulation Security Payload Header (ESP) sorgt für die Vertraulichkeit der Daten. Er ist ähnlich dem AH-Header aufgebaut. Neben der Festlegung des Verschlüsselungsalgorithmus kann ESP auch die Authentisierung der Daten übernehmen. ESP kann wie AH im Transport- und im Tunnel-Modus betrieben werden (Bild 5).

Bild 5: Der ESP-Header sorgt für die Vertraulichkeit der Daten

Der Transport-Modus hat den Nachteil, daß jede Station im VPN IPSec beherrschen muß. Außerdem kann ein Angreifer erkennen, welche Stationen miteinander kommunizieren. Im Tunnel-Modus ist dies nicht der Fall. Hier können dedizierte IP-Gateways die Umwandlung in IPSec-Pakete realisieren. Eine Neukonfiguration der verbundenen LANs ist nicht nötig. Allerdings werden die Pakete im Tunnel-Modus bei gleichzeitiger Anwendung von AH und ESP um über 60 Byte verlängert. Bei großen Paketen ist somit eine Fragmentierung der Pakete nötig, was zu zusätzlichem Verwaltungsaufwand und Performance-Einbußen führt.

Zur Verschlüsselung wird häufig DES (Data Encryption Algorithumus) oder Triple-DES eingesetzt. DES ist ein symmetrischer Blockchiffrieralgorithmus. Die Symmetrie bezieht sich darauf, daß zur Codierung und zur Decodierung derselbe Schlüssel verwendet wird. Blockchiffrierung bedeutet, daß man den Klartext in eine Folge von Blöcken fester Länge zerlegt und dann jeder Klartextblock mit Hilfe derselben Abbildung verschlüsselt. Das DES-Verfahren wurde von IBM entwickelt und 1977 vom National Bureau of Standards normiert. Man unterscheidet zwei Betriebsarten, den ECB-Modus und den CBC-Modus. Im ECB-Modus (Electronic Code Book) wird genau ein Schlüssel verwendet, um die Klartextblöcke der Länge acht Byte in Chiffretextblöcke zu chiffrieren. Jeder Chiffretextblock hängt in diesem Modus nur von dem zugehörigen Klartextblock ab. Zum Entschlüsseln kann auf jeden der chiffrierten Blöcke wahlfrei zugegriffen werden, um ihn dann unabhängig von allen anderen zu entschlüsseln. Im CBC-Modus (Cipher Block Chaining), der bei IPSec Anwendung findet, wird der definierte Schlüssel nur zur Verschlüsselung des ersten Textblockes verwendet. Zur Verschlüsselung aller weiteren Textblöcke setzt man dann den jeweils vorangehenden Chiffretextblock als Schlüssel ein. Dieses Verfahren hat den Vorteil, daß die Reihenfolge der Blöcke bei der Dechiffrierung nicht verfälscht werden kann und ein absichtlicher Austausch von Chiffreblöcken bei der Übertragung bemerkt wird. DES verwendet eine Schlüssellänge von 56 Bit. Es stehen somit 2 hoch 56, also über 76 Billiarden Schlüssel zur Verfügung. Triple-DES verwendet das DES-Verfahren dreimal hintereinander mit zwei (EDE-2) oder mit drei (EDE-3) verschiedenen Schlüsseln. Bei der EDE-3-Variante wird mit Schlüssel 1 verschlüsselt, dann wird mit Schlüssel 2 dekodiert und schließlich mit Schlüssel 3 nochmals chiffriert. Die effektive Länge des Schlüssels beträgt somit 168 Bit.

Asymmetrische Verfahren wie RSA (benannt nach den Entwicklern Rivest, Shamir und Adleman) verwenden zwei Arten von Schlüssel: Einen öffentlichen Schlüssel zur Verschlüsselung und einen geheimen, privaten Schlüssel zur Entschlüsselung.

Während es heute DES-Chipbausteine gibt, die sehr effizient Datenraten von bis zu 1 Gbit/s "on the fly" verschlüsseln können, sind asymmetrische Verfahren relativ langsam und benötigen zudem sehr lange Schlüssel. Aus diesem Grund dienen diese Verfahren nicht zur Verschlüsselung von Nutzdaten, sondern zum Austausch von Schlüsseln für symmetrische Verfahren und zur digitalen Unterschrift.

IPSec erlaubt auch noch andere Verschlüsselungsalgorithmen wie IDEA (International Data Encrytion Algorithm) oder Blowfish. Wichtig ist, daß man auf starke Verschlüsselung, also Schlüssellängen größer 56 Bit, achtet. Denn wie Bild 6 zeigt, hat eine aktuelle Untersuchung der RSA Laboratories ergeben, daß ein symmetrischer 56-Bit Schlüssel mit einem Rechner-Equipment im Wert von 20 Mio. DM bereits in nur fünf Minuten geknackt werden kann.

Bild 6: 56 Bit-Schlüssel kann man in relativ kurzer Zeit errechnen

Weiterhin sollte man sicher sein, daß keine Schlüsselhinterlegung stattfindet. Denn in den letzten Jahren wurden eine Vielzahl von Key Recovery Mechanismen entwickelt. Alle großen Hersteller haben sich intensiv mit diesem Thema beschäftigt und zum Teil entsprechende Verfahren implementiert. Während manche Firmen ganz offen über das Thema sprechen, halten sich andere total bedeckt. Es ist bekannt, daß bestimmte amerikanische Hersteller beispielsweise bei Verwendung eines 64 Bit Schlüssels jeweils 24 Bit hinterlegen. Andere Hersteller  benutzen zwar lange Schlüssel, füllen aber die höherwertigen Bit mit Nullen oder Einsen auf oder verwenden Teilschlüssel, die leicht zu dechiffrieren sind. Wiederum andere Hersteller stellen die Key Recovery als besonderes Feature dar, das es erlaubt, daß zum Beispiel der Firmenleiter einen generellen Nachschlüssel für verschlüsselte Mails der Mitarbeiter einbauen kann, oder daß die Möglichkeit besteht, verlorene Schlüssel für gespeicherte Daten wiederzugewinnen. Allerdings sind diese Produkte von vornherein mit Vorsicht zu genießen. Wenn nämlich Hintertürchen ganz offensichtlich existieren, kann man nie mit Gewissheit sagen, von wem diese genutzt werden. Weiterhin ist es denkbar, daß in gewissen Produkten die Zufallszahlen, die für die Kryptographie eingesetzt werden, nicht ganz zufällig sind. Institutionen wie die NSA (National Security Agency) könnten in so einem Fall mittels Brute-Force-Attacken den Schlüssel herausfinden, weil sie nicht den kompletten Zahlenraum, sondern nur eine Teilmenge davon ausprobieren müßten, um einen Schlüssel zu knacken.

Bild 7: Das VPNgateway compact der CONWARE Netzpartner GmbH, Karlsruhe. Wer starke Verschlüssellung ohne Hintertürchen wünscht, setzt auf Produkte, die in Deutschland entwickelt und hergestellt werden.

Kein Wunder also, daß deutsche Anwender gerne zu deutschen Produkten greifen, wenn es um das Thema Security geht. Nach einer vom Bundesministerium für Wirtschaft beauftragten Studie, die im Mai 2000 vom Wissenschaftlichen Institut für Kommunikationsdienste (WIK) und der Gesellschaft für Mathematik und Datenverarbeitung (GMD) veröffentlicht wurde, liegt der Marktanteil deutscher Securtiy-Unternehmen an der deutschen Krypto-Wirtschaft bei derzeit 50 Prozent. Amerikanische Produkte genießen gerade einmal das Vertrauen von 25 Prozent der deutschen Anwender.

Stellvertretend für die deutschen Bestrebungen in diesem Bereich sei hier auf die Firma CONWARE Netzpartner GmbH verwiesen. Das Karlsruher Security-Unternehmen vereint unter dem Markennamen SecuWare aufeinander abgestimmte Produkte, Lösungen und Dienstleistungen zum Aufbau und Betrieb sicherer Netze. SecuWare gliedert sich in die drei Bereiche SecuStructure, SecuAccess und SecuControl. SecuStructure realisiert eine sichere Netzinfrastruktur, SecuAccess sichert Datenübertragung und Netzzugang und SecuControl sorgt für die sichere Verteilung, Ablage und Organisation von Daten. Die CONWARE-Produke VPNswitch, VPNgateway und VPNclient zum Aufbau sicherer virtueller privater Netze arbeiten alle mit starker Verschlüsselung ohne Schlüsselhinterlegung.

Internet Key Exchange

IPSec beschreibt auch Verfahren zum gesicherten Austausch von Schlüsseln und Security Parametern über öffentliche Netze. Die notwendigen Rahmenrichtlinien zum Key Management liefert das Internet Security Association and Key Management Protocol (ISAKMP/Oakley). In einem zweiphasigen Verbindungsaufbau werden die Security Associations ausgehandelt und die Gegenstellen authentisiert. Phase 1 erzeugt eine sichere Verbindung (ISAKMP-SA) über die die Sicherheitsparameter ausgehandelt werden können. Dazu werden die Parameter zur Berechnung eines Master-Keys mittels des Diffie/Hellmann-Algorithmus ausgetauscht und die Gegenstellen authentisiert. Phase 2 definiert dann allgemein verwendbare SAs zur Übertragung der Nutzdaten.

Der Weltmarkt für VPNs wird lt. Infonetics bis zum Jahre 2004 auf 40 Mrd. US-Dollar anwachsen. Dabei wird bereits für dieses Jahr ein VPN-Umsatz von 6,3 Mrd. US-Dollar prognostiziert. Wesentlichen Anteil an dieser Entwicklung werden IPSec-Produkte haben, da IPSec bereits die wesentlichen Security-Mechnismen definiert und die IETF (Internet Engineering Task Force) an weiteren Verbesserung und Ergänzungen arbeitet. So ist beispielsweise derzeit die Arbeitsgruppe "IPSec Remote Access (ipsra)" damit beschäftigt, die Client-Konfiguration und -Authentisierung zu standardisieren, um eine Verbesserung der Interoperabilität zu erzielen.

Autor