Gerätekommunikation via Virtual Private Networks (VPN)

Protokoll-Beschreibung SSL

Von den in Bild 2 dargestellten Protokollen wird hier das „Secure Socket Layer“-Protokoll (SSL) ausführlich beschrieben, da es eine Reihe von Vorteilen bietet. Es unterstützt die flexible Kommunikation zwischen wechselnden Partnern, da Schlüssel über ein unsicheres Medium ausgetauscht werden können, und bietet die wechselseitige Authentifizierung im Zusammenspiel mit einer „Public Key“-Infrastruktur (PKI) durch die Nutzung von Zertifikaten. Hierbei ist der Aspekt der wechselseitigen Authentifizierung hervorzuheben, weil beide Kommunikationspartner entsprechend überprüft werden. Darüber hinaus erlaubt das Verfahren die effiziente Nutzung gängiger symmetrischer Verschlüsselungsverfahren wie RC-4, 3DES oder AES; es ist daher besonders geeignet für die im Internet typische Kommunikation zwischen PC-basiertem Client und Servern auf einem Embedded-System. SSL ist zudem in vielen Endsystemen und Anwendungsprotokollen bereits integriert. Dies gilt insbesondere für den Web-basierten https-Verkehr, der von vielen Web-Clients (Browsern) unterstützt wird.

Es stehen aber auch Implementierungen anderer Anwendungsprotokolle zur Verfügung: z.B. Secure Copy (SCP) als FTP-Ersatz oder Secure SMTP (SSMTP) für den sicheren E-Mail-Verkehr. Zudem stellt SSL mit der Socket-Schnittstelle eine Programmierschnittstelle (API) zur Verfügung (Bild 3), die auch die einfache Einbindung von eigenen Anwendungsprotokollen erlaubt, was im Embedded-Bereich recht verbreitet ist. Schließlich kann SSL auch für Transportprotokolle eingesetzt werden, die nicht auf TCP/IP basieren, vorausgesetzt, diese stellen einen zuverlässigen Transportmechanismus bereit.

Das SSL-Protokoll wurde seit 1994 gemeinsam von Netscape und RSA Security entwickelt. Es soll einen privaten Kanal zwischen Kommunikationsanwendungen bereitstellen, durch den sich Vertraulichkeit und Integrität der Daten gewährleisten lassen und eine Authentifizierung der Partner möglich wird. Hierzu implementiert SSL den asymmetrischen RSA-Algorithmus für das Management des Sitzungsschlüssels und die Authentifizierung von Server und Client sowie einen symmetrischen Algorithmus zur Verschlüsselung der Nutzdaten. Hierbei können sowohl „Streaming“-basierte Verschlüsselungsverfahren wie RC-4 als auch blockbasierte Verschlüsselungsverfahren wie 3DES oder AES verwendet werden.

1996 gründete die IETF die Arbeitsgruppe Transport Layer Security (TLS), um ein an SSL angelehntes Protokoll zu standardisieren. Damit sollten  Ansätze von Netscape (SSLv3) und Microsoft (STLP) harmonisiert werden. Nach langen Diskussionen und Wirren konnte dann im Januar 1999 TLS als RFC 2246 verabschiedet werden. TLS und SSLv3 sind in fast allen Bereichen identisch. Viele Werkzeuge unterstützen TLS, darunter auch  der Internet Explorer von Microsoft.

SSL besteht aus einer Reihe von verschiedenen Nachrichtenarten, die mit Hilfe eines einheitlichen „Record Layers“ übertragen werden (Bild 4). Dieser modulare Aufbau verbindet die einheitliche Verarbeitung im Protokollstapel mit einer effizienten Systemeinbindung. SSL ist ein verbindungsorientiertes Protokoll. Damit gliedert sich jede Kommunikation in die drei Phasen Verbindungsaufbau, Datenübertragung und Verbindungsabbau. Für den Verbindungsaufbau wird ein mehrstufiger Handshake-Prozess definiert, dessen grundlegender Ablauf im Kasten „Ablauf eines SSL-Handshake“ beschrieben ist. Ein Beispiel für eine solche Übertragung, das mit dem Programm „ssldump“ [4] aufgezeichnet wurde, ist im Listing eines SSL-Handshake auf S. 61 wiedergegeben. Mit dem Handshake werden der Server authentifiziert (optional auch der Client) und die Schlüssel ausgehandelt, die bei der nachfolgenden verschlüsselten Datenübertragung eingesetzt werden sollen. Eine detaillierte Beschreibung des Protokolls und seiner Implementierung findet sich in [5].

Kryptographie

Zur Absicherung von Integrität und Authentifizierung kommen kryptographische Algorithmen zum Einsatz [6, 7]. Mit ihrer Hilfe lassen sich Informationen so verändern (verschlüsseln), dass sie nur von Befugten verstanden werden. Befugte sind hierbei Personen oder Geräte, die über eine geheime weitere Information verfügen: den Schlüssel. Zudem muss eindeutig nachzuweisen sein, dass eine Veränderung oder Ergänzung nur von einer Person oder einem Gerät durchgeführt wurde, die/das im Besitz einer weiteren geheimen Information ist.

Anforderungen
Die Umsetzung kryptographischer Algorithmen stellt in der Regel hohe Anforderungen an die Rechenleistung der Prozessoren. Dies gilt insbesondere für die asymmetrischen Algorithmen, deren Berechnung auf kleinen Mikrocontrollern durchaus mehrere Sekunden in Anspruch nehmen kann. Zum Glück werden aber diese Operationen nur einmal benötigt: beim Aufbau der Verbindung. Aber auch die symmetrischen Verfahren, die in der zweiten Phase der Datenübertragung zum Einsatz kommen, stellen immer noch hohe Anforderungen. Zwar sind die Grundfunktionen moderner symmetrischer Verfahren relativ einfache Operationen wie 16/32-bit-EXOR- und Schiebe-Operationen oder Tabellenfunktionen, doch werden diese zur Verschlüsselung eines 128 oder 256 bit langen Blocks in unterschiedlicher Abfolge sehr oft durchgeführt. Obwohl neuere Verfahren wie AES mit besonderer Berücksichtigung von Software-Implementierungen entwickelt wurden, erfordern diese eine gewisse Rechenleistung. So kann z.B. ein ARM7TDMI bei 20 MHz mit AES256 pro Sekunde etwa 20 kbyte verschlüsseln [8].

Für die asymmetrischen Verfahren müssen komplexe Operationen wie die modulare Exponentiation mit sehr langen Integer-Zahlen (512 bis 2048 bit) durchgeführt werden. Ohne ein spezielles Rechenwerk müssen diese Berechnungen in Software nachgebildet werden, sie sind daher sehr rechenzeitaufwendig und können auch schnelle Prozessoren über längere Zeit beschäftigen. Ein ARM7TDMI bei 20 MHz benötigt z.B. für eine 1024-bit-RSA-Operation mit dem privaten Schlüssel etwa 2 s [8]. Mit zunehmender Schlüssellänge wachsen diese Zeiten weiter an, bei 2048 bit benötigt die gleiche Operation bereits knapp 14 s [8].

Software oder Hardware
Die Umsetzung der Algorithmen in Software ist insbesondere dann vorteilhaft, wenn nur geringe Datenmengen ver- oder entschlüsselt werden müssen. Hier stehen mittlerweile diverse Bibliotheken zur Verfügung, wie die kommerzielle WAKAN-Cryptolib [9] oder die freie LibTomCrypt [10].

Für den Fall, dass erhebliche Datenmengen verarbeitet werden müssen, kann eine Hardware-basierte Lösung deutliche Vorteile bieten. So werden Mikrocontroller mit Krypto-Coprozessoren ausgestattet, z.B. für Smart Card Controller und für Netzwerk-Anwendungen. Beispiele hierfür sind der „Kirin-IIE“ von Freescale [13] oder der „SAMS“ von Atmel. Beim Einsatz eines PLD-basierten Prozessors lassen sich die zusätzlichen Rechenoperationen in der programmierbaren Hardware umsetzen. Dabei können unterschiedliche Optimierungsrichtungen beschritten werden: Symmetrische, blockorientierte Verschlüsselungsverfahren wie DES/3DES oder AES lassen sich entweder mit höherem Flächenaufwand auf minimale Rechenzeit in Pipelines parallelisieren oder mit geringerem Flächenaufwand in mehreren Zyklen betreiben [11]. Nachteilig ist, dass die Hardware-Einbindung von den für Embedded-Systeme geeigneten Bibliotheken nur selten direkt unterstützt wird. Dies bleibt den Integratoren der Protokoll-Software überlassen.

1. Gerätekommunikation via Virtual Private Networks (VPN)
2. Embedded Virtual Private Networks
3. Protokoll-Beschreibung SSL
4. Implementierungen des SSL-Protokolls