Ein „Stand alone“-Protokollstapel für den Embedded-Bereich
Gerätekommunikation via Virtual Private Networks (VPN)
Fortsetzung des Artikels von Teil 3
Implementierungen des SSL-Protokolls
Die Umsetzung der kryptographischen Algorithmen ist die eine Seite der Medaille. In einem zweiten Schritt müssen diese in den Protokollablauf eingebunden werden. Auch hierfür gibt es verschiedene Möglichkeiten.
Offene Stacks
SSL liegt in einer Reihe offener Implementierungen vor. Hierzu zählen die Bibliotheken von OpenSSL [12], die alle notwendigen Routinen zur Erstellung eigener Programme und Werkzeuge zur Generierung asymmetrischer Schlüssel und X.509-Zertifikate enthalten. OpenSSL hat für den PC-Bereich im Windows- und Linux-Umfeld große Verbreitung gefunden. Für diesen Beitrag ist auch der Einsatz in Embedded-Linux-Systemen interessant. Eine direkte Übernahme in Embedded-Systeme ist allerdings problematisch. Zu beachten ist die dynamische Speicherverwaltung, die nicht nur bei kleinen Systemen zu einer Segmentierung des Speichers führen kann. Dies kann bei Systemen mit kleinem Speicher und langen Laufzeiten ohne „Reboot“ zu Stabilitätsproblemen führen, die auch durch die Verwendung einer Memory Management Unit (MMU) nicht zu beheben sind.
Embedded Stacks
Die ausschließlich auf Mikrocontrollern basierten Implementierungen erfordern daher spezifische Umsetzungen. Kostengünstige Embedded-Sys-teme verfügen nicht über ausreichende Ressourcen, um darauf ein „Embedded Linux“ zu betreiben. Auch die meisten anderen Portierungen für Embedded-Systeme basieren auf der OpenSSL-Implementierung. Sie beziehen häufig alle Funktionen mit ein, ohne Rücksicht darauf, ob diese auf einem Embedded-System sinnvoll oder notwendig sind. Zusätzlich zu der Qualität der Protokoll-Implementierung ist die Sicherheit einer SSL-verschlüsselten Kommunikation abhängig von zwei weiteren Aspekten, die weitgehend in der Verantwortung des Programmierers und des Anwenders liegen:
- Erstens hängt die Sicherheit der SSL-Verbindung entscheidend von der Qualität des Zufallszahlen-Generators auf dem Embedded-System ab. Allerdings ist die Erzeugung guter Zufallszahlen auf einem Embedded-System dann schwierig, wenn nicht spezielle Hardware-Zufallszahlengeneratoren verwendet werden. Die in einigen Prozessoren integrierten Zufallszahlen-Generatoren auf Schieberegisterbasis sind für die Erzeugung kryptographisch sicherer Zufallszahlen ungeeignet. In Frage kommen daher nur Software-Zufallszahlen-Generatoren; diese müssen mit einer ausreichenden Menge zufälliger Ereignisse versorgt werden, die von außen nicht beobachtbar oder vorhersagbar sind.
- Zweitens ist die Geheimhaltung des privaten Schlüssel des Servers von entscheidender Bedeutung. Dieser muss zwangsläufig in irgendeiner Form auf dem Server gespeichert werden. Wenn dieser Schlüssel einem Angreifer in die Hände fällt, kann dieser die gesamte auf diesem Schlüssel basierende Kommunikation entschlüsseln. Daher ist es zwingend erforderlich, dass jeder Server mit einem individuellen Schlüssel ausgestattet wird, damit der Schaden im Falle eines Falles möglichst auf ein System begrenzt bleibt.
| Steinbeis Transferzentrum STZEDN |
| Das Steinbeis-Transferzentrum für Embedded Design und Networking (STZEDN – www.stzedn.de) ist an die Berufsakademie Lörrach angegliedert. Es beschäftigt sich mit allen Aspekten des Entwurfs von Embedded-Systemen – und insbesondere mit deren drahtloser und drahtgebundener Vernetzung – sowie den Aspekten des Hardware-Software-Co-Designs. Das Team fest angestellter Ingenieure rund um Prof. Dr. Sikora bietet Beratungs- und Entwicklungsdienstleistungen sowie Soft- und Hardware-Produkte an. |
| Ablauf eines SSL-Handshake |
1. Handshake HelloRequest: Der Aufbau einer SSL-Verbindung wird stets vom Client initiiert. Mit dem ServerHello Request kann jedoch ein Server einen Client veranlassen, einen SSL-Handshake zu initiieren, z.B. für einen Rehandshake. 2. GET HTTPS://: Der eigentliche Ablauf auf der Client-Seite beginnt mit dem Aufruf eines geschützten Dokuments auf dem Server, das durch eine URL mit dem Protokollbezeichner HTTPS:// gekennzeichnet ist. Üblicherweise erkennt die Client-Applikation anhand der URL, dass es sich um eine geschützte URL handelt, und startet den SSL-Handshake durch Senden eines Handshake ClientHello an den sicheren Port (z.B. Port 443 für HTTPS) des Servers (ab Punkt 3. siehe Listing). 3. Handshake ClientHello: Der Client sendet dem Server eine Liste von Algorithmen, die von ihm unterstützt werden, sowie eine Zufallszahl, die bei der Erzeugung des Schlüssels verwendet wird. SSL und TLS unterstützen dabei eine Vielzahl von unterschiedlichen Verschlüsselungsverfahren verschiedener Qualität und Komplexität. 4. Handshake ServerHello: Der Server sucht einen Algorithmus aus den vom Client angebotenen Verfahren aus und informiert den Client hierüber. 5. Handshake Certificate: Der Server sendet seinen öffentlichen RSA-Schlüssel in einem gültigen X.509-Zertifikat an den Client. Falls eine Client-Authentifizierung per Zertifikat gefordert ist, sendet der Server zusätzlich eine Liste der akzeptierten Zertifizierungsstellen als Zertifikat-anforderung. 6. Handshake ServerHelloDone: Zusätzlich versendet auch der Server eine Zufallszahl, die ebenfalls bei der Erzeugung des Schlüssels benötigt wird. 7. Handshake ClientKeyExchange: Der Client überprüft das Zertifikat des Servers. Dann erzeugt er eine zufällige Zeichenfolge (pre master secret) und sendet diese mit dem öffentlichen Schlüssel des Servers verschlüsselt an den Server. Auf der Grundlage der beiden von Server und Client erzeugten Zufallszahlen und des pre master secret berechnen Client und Server unabhängig voneinander die Schlüssel für die Verschlüsselung und die Signaturen (MAC). Der Server kann dies nur korrekt durchführen, wenn er im Besitz des zum Server-Zertifikat passenden privaten Schlüssels ist. Im Falle der Client-Authentifizierung sendet der Client zusätzlich ein passendes Client-Zertifikat sowie eine mit dem privaten Schlüssel signierte Prüfsequenz, die Client und Server im bisherigen Protokollablauf gemeinsam berechnet haben. Der Server überprüft das Client-Zertifikat und überprüft die Prüfsequenz mit Hilfe des öffentlichen Schlüssels aus dem Client-Zertifikat. 8. ChangeCipherSpec: Der Client informiert danach den Server, dass alle weiteren Pakete verschlüsselt übertragen werden. 9. Handshake Finished: Das Finished-Paket enthält ein MAC über alle übertragenen Handshake-Nachrichten. Auf diese Weise kann der Server herausfinden, ob ein „Man in the Middle“-Angriff die originalen Pakete des Clients verändert hat. 10. ChangeCipherSpec: Der Server informiert dann den Client, dass alle weiteren Pakete verschlüsselt übertragen werden. 11. Handshake Finished: Das Finished-Paket des Servers enthält ebenfalls ein MAC über alle übertragenen Handshake-Nachrichten. Auf diese Weise kann auch der Client herausfinden, ob ein „Man in the Middle“-Angriff die originalen Pakete des Servers verändert hat. |
| [1] | [1] ‑Braun, N.; Sikora, A.: Vergleich verschiedener Mikrocontroller-Plattformen für den Einsatz in Kommunikationsanwendungen. Teil 1: Elektronik 2005, H. 20, S. 54ff.; Teil 2: Elektronik 2005, H. 21, S. 49ff |
| [2] | Straub, T.; Sikora, A.: Cryptography on Embedded Systems. Embedded World Conference 2005, Nürnberg, S. 517 – 536. |
| [3] | Erschig, M.; Sikora, A.: Administration and Security Aspects for Embedded Webserver Design. Embedded World Conference 2006, Nürnberg, 14. bis 16. 2. 2006 |
| [4] | http://sourceforge.net/projects/ssldump |
| [5] | Rescorla, E.: SSL and TLS – Designing and Building Secure Systems. Addison-Wesley, 2001, ISBN 0-2016-1598-3 |
| [6] | Ertel, W.: Angewandte Kryptographie. Fachbuchverlag Leipzig im Carl Hanser Verlag, 2. Auflage 2003 |
| [7] | Menezes, A.; van Oorschot, P.; Van-stone, S.: Handbook of Applied Cryptography. CRC Press, 1997 |
| [8] | Wakan Crypto-Software-Toolkit Release 2.1 Technical Information. Ascom AG, 2002 |
| [9] | Steinbeis-Transferzentrum für Embedded Design und Networking – www.stzedn.de |
| [10] | LibTomCrypt http://libtomcrypt.bytemine.net/libtomcrypt.org_80/ |
| [11] | Sikora, A.: Hard- und Softwarelösungen für sichere Embedded Systeme. Design-&-Elektronik-Entwicklerforum „Drahtlose & drahtgebundene Netzwerke für Industrie & Automotive“. München, 7. Juli 2004 |
| [12] | OpenSSL Project – www.openssl.org |
| [13] | http://www.freescale.com/files/ftf_2005/doc/reports_presentations/MZ123_B.pdf?srch=1 |
 | Dipl.-Ing. (FH) Nathan Braun hat nach einer Ausbildung zum Elektriker das Studium der Trinationalen Ingenieurausbildung in der Fachrichtung Mechatronik an der Berufsakademie Lörrach, der Fachhochschule beider Basel (FHBB) und der Université de Haute Alsace in Mulhouse absolviert. In seiner Diplomarbeit legte er die Grundlagen für den TCP/IP-Stack des „emBetter“. Seit Anfang 2004 arbeitet er im Steinbeis-Transferzentrum für Embedded Design und Networking, wo er sich im Wesentlichen mit Embedded Kommunika-tionslösungen rund um den „emBetter“ befasst. |
 | Dr.-Ing. Thomas Gillen befasst sich seit mehreren Jahren mit der Hard- und Softwareentwicklung für industrielle Applikationen sowie mit der Systemsicherheit und der Implementation von kryptographischen Verfahren und sicheren Übertragungsprotokollen für Embedded-Systeme. Seit 2004 ist er bei Art of Technology unter anderem für die sichere Kommunikation und die sichere Authentifizierung bei kleinen Embedded-Systemen zuständig. |
 | Prof. Dr.-Ing. Axel Sikora leitet den Studiengang Informationstechnik, das Steinbeis-Transferzentrum für Embedded Design und Networking und das Steinbeis-Forschungsinstitut für Drahtlose Kommunikation an der Berufsakademie Lörrach. Schwerpunkte seiner Arbeit sind Hardware-Software-Co-Design für vernetzte Systeme sowie die Protokollentwicklung für Embedded-Netzwerke. Er ist Autor, Co-Autor und Herausgeber mehrerer Fachbücher, sowie zahlreicher Konferenzbeiträge und Fachartikel zu diesem Themenkreis. |
- Gerätekommunikation via Virtual Private Networks (VPN)
- Embedded Virtual Private Networks
- Protokoll-Beschreibung SSL
- Implementierungen des SSL-Protokolls
