IPsec VPN auf 16-Bit Systemen Christian Scheurer HTI Biel/Bienne Juni 2004 1 EINFÜHRUNG Mit fortschreitender Integration von embedded Systemen in die lokale und auch globale IT- Landschaft ergeben sich neue Anforderungen betreffend Interoperabilität und Sicherheit. Parallelen zur PC-Welt werden auch bei kleinen Systemen langsam sichtbar: in den späten 90er Jahren hielt der Anschluss ans Internet Einzug ins Büros. Kostengünstige und effiziente Kommunikation über Email hat sich rasch etabliert. Mittlerweile ist aber jedem PC-Anwender klar geworden, dass da noch viel mehr möglich ist, als eigentlich sein sollt: Emails mit gefälschtem Absender und einem Virus oder Trojaner als Anhang, Ausspionieren von Passwörtern und Hacken von Webseiten sind die Kehrseite der Vernetzten Welt. Entfernt liegende Geschäftsstellen oder Laptops von Aussendienstmitarbeiter werden heute über ein sogenanntes VPN, ein Virtual Private Network, mit dem Hauptsitz verbunden. So können über eine Telefonleitung, ein Kabel- oder ADSL-Modem vom Hotel oder von zuhause aus Emails bearbeit oder Dokumente auf dem Server in der Firma hinterlegt werden. Für solche Anwendungen gibt es zwei weit verbreitete, standardisierte Ansätze: Zum einen ist es SSL (Secure Socket Layer), welches auf Applikations-Ebene ansetzt. Die bekannteste Anwendung sind wohl die SSL-geschützten Web-Seiten (HTTPS) von Online- Shops, über die Bestellungen und Kreditkarten-Details übertragen werden. Bei SSL müssen die Applikationen normalerweise angepasst werden, damit sie von einer gesicherten Verbindungen profitieren können. Ein anderer Ansatz ist die Verschlüsselung auf Netzwerk-Ebene durch IPsec (Internet Protocol Security). Durch Einsatz von IPsec werden sämtliche Applikationen geschützt, ohne dass diese angepasst werden müssen. Zusätzlich bietet IPsec begrenzten Schutz vor noch unbekannten Programmier-Fehlern in den höheren Netzwerk-Protokoll Schichten von Betriebssystemen: Anfragen von nicht Autorisierten Systemen werden beim Eintritt in den eigentlichen TCP/IP Stack verworfen. Beide Ansätze basieren auf bekannten kryptografischen Algorithmen wie DES, 3DES, AES oder IDEA zur Verschlüsselung und MD5 oder SHA1 zur Authentisierung. IPsec ist ein fester Bestandteil gängiger Betriebssysteme wie Windows, Linux, Unix und MacOS und wird von Netzwerk-Produkten führender Hersteller wie Cisco unterstützt. Das hat den Vorteil, dass einerseits die Interoperabilität zur bestehenden IT Infrastruktur und andererseits sichere end-to-end Kommunikation zwischen Mikrocontroller und Computer- System (z.b. SQL Datenbank Server, Security Gateway,...) gegeben ist. Die Daten werden im Innern des Mikrocontrollers ver- bzw. entschlüsselt. Auf dem Weg zwischen Datenbank- Server und Mikrocontroller sind die Daten durchgehend geschützt. Das hat den Vorteil, dass Messresultate auch über unsichere, öffentliche Netze geleitet werden können. Die Daten sind auch im firmen-internen Netz gegen Angriffe durch Viren und Würmer sowie mutwilliger Manipulation von technisch versierten Mitarbeitern geschützt. In diesem Zusammenhang spricht man häufig von einem IPsec Tunnel zwischen zwei Systemen. Über diese verschlüsselte Tunnels können Daten-Pakete sicher ausgetauscht werden.
In der Praxis könnte ein System zum Fernwirken, Ablesen von Zählerständen oder drahtloses Übertragen von sensiblen Patientendaten auf ein Handterminal etwa so aussehen: Die Daten verlassen den Mikrocontroller geschützt (verschlüsselt und authentisiert). Die IPsec-geschützten Daten können nun über GSM, WLAN, Ethernet oder über jedes andere Transport-Medium zum Server gelangen. Die goldenen Informationen im Netzwerk-Paket werden erst an ihrem Bestimmungsort sichtbar. Auf ihrem Weg bleiben sie zu jedem Zeitpunkt geschützt. Dies hat den Vorteil, dass man weder auf die Zuverlässigkeit und Sicherheit im entfernt gelegenen Netz noch jenes des Transportunternehmens (Telecom Operator, Internet) oder sogar im firmeninternen Netz angewiesen ist. Der IPsec Tunnel ist der (gepanzerte) lange Arm vom Server aus direkt in den RAM-Speicher des Mikrocontrollers. 2 E M B E D DED IPSEC DESIGN Nach dem vorangehenden Überblick soll dieser Abschnitt nun Einblick geben in eine praktische IPsec Implementation, speziell ausgelegt für low-end embedded Systeme. Die Grundlagen einer IPsec Implementation sind in den RFC (Request for Comments) Dokumenten der IETF (Internet Engineering Task Force) beschreiben. IPsec ist nicht in einem einzelnen RFC abgefasst, sondern besteht aus einer Sammlung von Standards, welche entweder elektronisch [1] oder gedruckt als Buch [2] verfügbar sind. Das Buch Netzsicherheit von Günter Schäfer [3] bietet eine gute Übersicht über alle relevanten Protokolle und kann bei Design und Implementation von Nutzen sein. Für eine einfache IPsec Implementation für 8- und 16-Bit embedded Systeme sind folgende Dokumente besonders interessant: RFC 2401: Security Architecture for the Internet Protocol (IPsec) RFC 2402: IP Authentication Header (AH) RFC 2406: IP Encapsulating Security Payload (ESP) Weitere RFCs beschreiben die MD5, SHA1 und DES Algorithmen.
Für eine vollständige IPsec Implementation müssten noch zusätzliche Protokolle wie IKE (Internet Key Exchange), Oakley Key Determination Protocol und ISAKMP (Internet Security Association and Key Management Protocol) implementiert werden. Der Gewinn daraus wäre vollständige Interoperabilität mit allen IPsec Implementationen. Diese Protokolle sind aber sehr rechenintensiv, das sie asymmetrische kryptografische Operationen wie RSA und Diffie- Hellman (DH) einsetzen. Eine 1024-Bit RSA Decrypt Operation benötigt auf einem 16-Bit 80186 Mikrocontroller bei 20 MHz etwa 48 Sekunden (Zeitangaben aus Paper von Andreas Steffen [4]). Ohne diese Zusatz-Protokolle können Verbindungen nur über Manual Keying aufgebaut werden. Eine Zwischenstufe wäre das Pre-Shared Keying, bei dem IKE an Stelle von Zertifikaten ein gemeinsames Passwort zum Initiieren der SA-Konfiguration verwendet. Eigenschaften einer grundlegenden IPsec Implementation für embedded Systeme: Dynamische Verwaltung von Security Policies Dynamische Verwaltung von Security Associations AH Protokoll mit HMAC-MD5 und HMAC-SHA1 ESP Protokoll mit 3DES, 3DES-HMAC-MD5 und 3DES-HMAC-SHA1 Tunnel Modus Anti-Replay Mechanismus verhindert Wiedereinspielen von Paketen Unterstützung für Manual Keying Schnittstelle für ISAKMP/IKE Interoperabilität geprüft mit Linux FreeS/WAN und Kernel 2.6 native IPsec Diese Anforderungen führten bei der embedded IPsec Implementation zu folgenden Modulen: TCP/IP Stack SPD SAD AH #!""# cs8900 Network Driver IPsec Device Driver!"" IPsec I/O ESP Crypto library SPD In der Security Policy Database (SPD) ist gespeichert, was für Paket verarbeitet werden sollen. Pakete werden anhand von der IP-Adresse und Port Nummern von Quell- und Ziel-Host identifiziert. Ein Pointer auf den entsprechenden Eintrag in der SAD legt dann fest, wie ein Paket verarbeitet werden muss. Ein APPLY - Eintrag veranlasst die Übergabe des Pakets ans IPsec I/O Modul. Ist eine Verarbeitung nicht erwünscht, so kann das Paket per BYPASS direkt weitergeleitet werden. Mittels
geschickter Kombination von DISCARD Einträgen, durch die ein Paket einfach gelöscht und der belegte Speicher wieder freigegeben wird, kann eine einfache aber wirkungsvolle Firewall konfiguriert werden. SAD Die Einträge in der Security Association Database (SAD) legen fest, wie ein Paket verarbeitet werden muss. Jeder Eintrag enthält alle notwendigen geheimen Schlüssel zum Verschlüsseln oder Authentisieren und legt fest, ob das Paket nach AH oder ESP verarbeitet werden muss. Die einzelnen SA s werden entweder manuell durch den Administrator eingegeben (im Falle von Manual Keying) oder durch IKE automatisch ausgehandelt. IPsec Device Driver Die IPsec Implementation muss den eingehenden Netzwerk-Verkehr ( inbound traffic : der Mikrocontroller empfängt Daten) unmittelbar nach der physikalischen Transport-Schicht (hier ein CS8900 Ethernet Controller) abfangen, noch bevor die Daten in den eigentlichen TCP/IP Stack gelangen können. Beim ausgehenden Verkehr ( outbound traffic : der Mikrocontroller sendet Daten) müssen die Daten noch mit IPsec geschützt werden, bevor sie über den Ethernet Controller ihre Reise durchs Netz antreten. Bei beiden Flussrichtungen ( inbound und outbound ) sind folgende Verarbeitungs-Szenarien möglich: o APPLY Das Paket wird nach IPsec verarbeitet o BYPASS Paket ohne IPsec Verarbeitung (als Klartext ) weiter leiten o DISCARD Paket ohne Verarbeitung direkt löschen Durch eine Abfrage der SPD findet der IPsec Device Driver heraus, wie ein Paket verarbeitet werden muss. IPsec I/O Wenn der IPsec Device Driver ein Paket mit der Regel APPLY gefunden hat, so wird es dem IPsec I/O Modul übergeben. Hier wird das Paket mit den Schüsseln aus der entsprechenden SA dem konfigurierten IPsec Protokoll Modul weiter gegeben (AH oder ESP). Nach erfolgter Verarbeitung gibt IPsec I/O das Paket an den IPsec Device Driver zum Weiterleiten zurück. AH Das Authentication Header (AH) Protokoll schützt das Paket durch eine HASH-MAC Prüfsumme vor Manipulationen. Sollte ein Paket auf dem Weg durchs Netz vorsätzlich oder auch durch einen Netzwerkfehler verändert worden sein, so wird das auf der Gegenstelle beim IPsec Empfangsvorgang erkannt. Beschädigte Pakete werden gelöscht und der Vorgang wird als auditable event in einem Log-File aufgezeichnet (falls vorhanden). Nur Daten aus integeren Paketen gelangen bis zur Applikation. Besonders in Kombination mit dem MD5 Algorithmus ist AH im Vergleich zu ESP sehr effizient, allerdings werden die Daten als Klartext übertragen. AH gewährleistet die Authentizität der Daten und der Herkunft, da bei AH auch der äussere IP-Header in die Berechnung mit einbezogen wird. ESP Mit dem Encapsulating Security Payload (ESP) Protokoll werden die Daten verschlüsselt. Als Verschlüsselungs-Algorithmus wurde hier 3DES eingesetzt und kann durch Anpassen der Konfiguration ausgetauscht werden. Dies ist besonders interessant, falls Geräte in Länder exportiert werden, für die Einschränkungen bezüglich starker Kryptografie gelten oder der Algorithmus durch eine schnellere Implementation wie z.b. AES ausgetauscht wird. Optional kann ESP mit einem HASH gegen Manipulationen im Header geschützt werden. Crypto Library In der Crypto Library wurden folgende Algorithmen vom OpenSSL Projekt [5]
übernommen: DES, 3DES, MD5 und SHA1. Die Performance dieser vorwiegend für 32-Bit Systeme entwickelte Bibliothek ist auf 16-Bit Systemen ohne Anpassung nicht besonders effizient. Interessant ist aber, dass die Implementation kostenlos erhältlich ist und seit Frühjahr 2004 FIPS 140-2 [6] zertifiziert ist. 3 IMPLEMENTAT I ON Bei einer IPsec Implementation auf einem Mikrocontroller müssen folgende Punkte beachtet werden, damit das System so effizient wie möglich arbeitet: RAM Speicher und Rechenleistung sind nur begrenz verfügbar: o Jede aktive Verbindung benötigt zum Ablegen des Status einige Bytes RAM. o Jedes Paket in einer Warteschlange muss im RAM zwischengespeichert werden. Das ist besonders in Zusammenhang mit TCP von Bedeutung: verloren gegangene TCP Segmente müssen erneut gesendet werden, solange deren Empfang nicht von der Gegenseite bestätigt wurde oder ein Timeout abgelaufen ist. Das System kann durch verlorengegangene Pakete vorübergehende blockiert oder sogar zum Absturz gebracht werden (DoS - Denial of Service). Als Gegenmassnahmen kann Lazy Receiver Processing [9] dafür sorgen, dass sich das System in einem solchen Fall zuerst ums Abarbeiten der ausgehenden Daten bemüht und keine zusätzlichen Ressourcen durch Eingehende Verbindungen bindet. Das Netzwerk-Paket muss vollständig empfangen und im RAM abgelegt sein, bevor kryptografische Operationen (effizient) darauf angewendet werden können. Ein fragmentiertes Paket muss vor der Verarbeitung wieder zusammengesetzt werden. Folgende Methoden helfen, dass der RAM-Verbrauch so gering wie möglich gehalten und gleichzeitig keine Rechenzeit durch unnütze Operationen verschwendet werden kann: Kryptografische Operationen müssen in-place ausgeführt werden Kein Kopieren oder Verschieben von Daten im Speicher ( zero copy Paradigma) Pakete werden durch Pointer übergeben Paketgrösse muss dynamisch angepasst werden können Netzwerkprotokoll Implementationen für Mikrocontroller müssen sparsam mit den Ressourcen umgehen. Die Speicherverwaltung des lwip TCP/IP Stacks [7] zum Beispiel verwendet eine PBUF (Packet Buffer) genannte Struktur, um Pakete im Speicher abzubilden. Das Prinzip entspricht in etwa den Socket Kernel Buffer (SKB) aus dem Linux Kernel.
pbuf header length = total length pbuf data space pbuf header next payload total length length flags ref free memory space next payload total length length flags ref free memory space outer IP header pbuf data space length = total length IP header TCP header IPsec header inner packet payload free memory space padding ICV Ein PBUF ist eine verlinkte Liste (singly linked list), bei der jede Protokoll-Schicht die jeweiligen Header-Daten einfach am Anfang oder Ende der Liste anhängen kann. Der Treiber des Ethernet-Controllers schlussendlich wird den PBUF durch Abarbeiten aller Elemente der Liste übers Netzwerk versenden. AH und ESP IPsec-Pakete müssen zusammenhängend im Speicher liegen, damit die kryptografischen Funktionen effizient arbeiten. Der Daten-Teil der PBUF Elemente muss also Platz für ein ganzes Paket haben. Dazu wird der Daten-Teil jedes PBUFs der gewünschten MTU (Maximum Transmission Unit, bei Ethernet normalerweise 1500 Bytes) angepasst. Höhere Protokollschichten (HTTP, TCP, IP,...) müssen bei ausgehenden Paketen berücksichtigen, dass vor und hinter dem Paket noch genügend Platz bleibt für die AH und ESP Header. Die Grafik auf der linken Seite zeigt ein normales IP Paket in einem PBUF. Bei ausgehenden Verbindungen wird das IP Paket zum inner packet und mit AH oder ESP eingepackt. Die AH oder ESP Header Informationen werden unmittelbar vor dem inneren Paket angefügt. Vor dem Senden übers Netzwerk wird noch ein äusserer IP Header angehängt. Dieser enthält die Anfang- und Endadresse des IPsec Tunnels. Bei eingehenden Paketen werden die äusseren Header entfernt und das innere Paket entschlüsselt. Der Payload-Pointer wird so angepasst, dass er auf den Anfang des inner packet zeigt. Anschliessend wird der PBUF den höheren Protokollschichten übergeben. 4 PERFORM AN C E Die Verarbeitungsgeschwindigkeit der IPsec Pakete - damit die Reaktionszeit (Latenz) und der Durchsatz - hängen in hohem Masse von den kryptografischen Operationen ab. Die Berechnung eines Pakets mit SHA1 dauert im Vergleich zu MD5 etwa doppelt so lange. Das Verschlüsseln mit 3DES nimmt etwa 10 mal mehr Zeit in Anspruch als eine MD5 Berechnung. Diese Zahlen hängen mit der Code-Qualität der verwendeten Crypto-Library und dem Zielsystem (hier OpenSSL auf dem C167) zusammen. Tendenziell können aber ähnliche Werte für andere Systeme erwartet werden.
Beachtliche Unterschiede sind auch je nach System-Architektur feststellbar: Konfiguration 16-Bit System Infineon C167, 40 MHz mit embedded IPsec 32-Bit System Motorola MPCxxx, 47MHz mit kommerziellem IPsec Stack ohne IPsec Durchsatz in kb/sec. 3DES mit HMAC-MD5 3DES mit HMAC-SHA1 Verhältnis ohne / mit IPsec 128 2 1.8 0.015.. 0.007 1400 80 71 0.057.. 0.050 Durch Ersetzen oder Optimieren der Crypto Library könnte die Leistung der 16-Bit Implementation erheblich verbessert werden. Ein Blick auf die Grösse der einzelnen Protokollteile zeigt, dass die Crypto Library (90kB) im Vergleich zu den IPsec Kern- Funktionen (18kB) oder dem TCP/IP Stack (38kB) übermässig gross ist. Code-Grösse lwip TCP/IP Stack 26% IPsec Library 12% Crypto Library 62% 5 INTEROPERAB I L I T Ä T Ein grosser Vorteil von IPsec ist sein hoher Grad an Standardisierung. Durch Einhalten der in den RFCs definierten Vorgaben sollten auch IPsec Systeme verschiedener Hersteller zusammenarbeiten. In der Praxis sind leider selten alle Features implementiert. Dies hängt mit den eingeschränkten Ressourcen in einigen Geräten zusammen oder auch mit Sicherheitsüberlegungen. Die einfachste IPsec Konfiguration ist die Manual Keying Methode, bei der die Schlüssel statisch in der SAD/SPD Datenbanken abgelegt werden. Manual Keying ist die einzige Operations-Art, welche ohne IKE/ISAKMP auskommt. Auf PC-Systemen unterstützen nur besonders flexible IPsec Implementationen das Manual Keying. Die untenstehende Tabelle zeigt, dass dies bei Linux und OpenBSD gegeben ist. Bei älteren Linux Systemen erlaubt FreeS/WAN nach einer etwas umständlichen Installation eine flexible Konfiguration. Das FreeS/WAN Projekt wurde im Frühjahr 2004 eingestellt. Nun existieren einige Nachfolge-Projekte und auch eine sehr saubere IPsec Implementation direkt im Linux Kernel 2.6.
Microsoft Windows 2000 und XP benötigt IKE/ISAKMP und unterstützt Manual Keying leider nicht. Daher ist die Interoperabilität mit embedded IPsec nicht gegeben: embedded IPsec FreeS/WAN Linux ipsec_tunnel Windows OpenBSD Konfiguration V1.96 2.6 v0.9 2000 AH HMAC-MD5-96 () - () n/a AH HMAC-SHA1-96 () - () n/a ESP 3DES () () n/a ESP 3DES HMAC-MD5 () () n/a ESP 3DES HMAC-SHA1 () () n/a unterstützt und erfolgreich getestet () unterstützt, aber nicht überprüft nicht unterstützt und überprüft () nicht unterstützt, aber nicht geprüft - Konfiguration nicht möglich n/a nicht möglich (da IKE fehlt) 6 SCHLUSSWORT In diesem Dokument wurden einige Punkte beleuchtet, welche für eine IPsec Implementation auf kleinen Geräten berücksichtigt werden müssen. Weitere Hintergründe, Implementations- Details, Messresultate sowie der vollständige Source Code der embedded IPsec Implementation sind auf der Projekt Homepage [8] abgelegt und können kostenlos heruntergeladen werden. Christian Scheurer contact@christianscheurer.ch HTI Biel/Bienne Höheweg 80 CH-2501 Biel/Bienne 7 R E FERENZEN [1] IETF Internet Engineering Task Force http://www.ietf.org/html.charters/ipsec-charter.html [2] Peter Loshin, Big Book of IPsec RFCs, Morgan Kaufmann 2000 [3] Günter Schäfer, Netzsicherheit, dpunkt Verlag 2003 [4] Andreas Steffen, Secure Communications in Distributed Embedded Systems, ZHW 2000 http://security.zhwin.ch/msy02_steffen.pdf [5] OpenSSL Projekt Homepage http://www.openssl.org/
[6] OpenSSL FIPS 140-2 Certification FAQ http://oss-institute.org/fips-faq.html [7] lwip a Lightweight TCP/IP Stack, Adam Dunkels et al, 2003 http://www.sics.se/~adam/lwip/ [8] embedded IPsec Projekt Homepage http://ww.hta-bi.bfh.ch/projects/ipsec/ http://www.embeddedipsec.org [9] Lazy Receiver Processing (LRP): A Network Subsystem. Architecture for Server Systems., Peter Druschel und Gaurav Banga, 1996 http://www.cs.rice.edu/cs/systems/lrp/osdi96.ps