© Joerg Hackemann , 123RF

Schwärmt eine Geräteflotte im Internet der Dinge erst mal in alle Welt aus, will der Kunde nicht nur sicher mit seinen Knotenpunkten reden, sondern der Hersteller notfalls aus der Ferne Sicherheitslücken stopfen. Embedded-Entwickler Julien Vermillard schildert Sicherheitsrisiken und stellt Lösungsansätze vor.

Das Internet der Dinge (Internet of Things, IoT) soll in Zukunft den Gesundheitssektor, Wohnhäuser und ganze Städte, den öffentlichen Nahverkehr und viele weitere Bereiche umkrempeln. Das vernetzte Klein-Klein hält aus technischer Sicht zahlreiche Herausforderungen bereit. Zu ihnen gehören das Hardwaredesign, Zertifizierungen, Embedded Software für Ressourcen-arme Geräte, das Servermanagement übers Internet oder die Benutzerfreundlichkeit.

Der Artikel behandelt eine der größten Herausforderungen: die Sicherheit. Er beschreibt, wie sich die Hardware schützen und sicher mit Updates versorgen lässt, nach Möglichkeit mit Hilfe von Open-Source-Lösungen.

Strikte Regeln

Für Software-Entwickler ist Geräte-Security leider nur selten ein wichtiges Thema. Ihre erste Reaktion lautet meist: Was kümmert es mich? Erhalte jemand physischen Zugriff auf ein Device, beträfe das nur dieses Gerät und würde nicht das komplette System gefährden.

Das stimmt zwar, zugleich gibt es in der realen Welt oft andere Konsequenzen als in der digitalen. Zum Beispiel kann ein Angreifer viele solche Geräte kaufen oder sich anderweitig Zugang darauf verschaffen, eine Firmware-Backdoor einfügen und sie später weiterverkaufen. So verwandelt er sie in Spamschleudern oder Spione im Eigenheim. Vor diesem Hintergrund bleibt zu hoffen, dass Hardware-Security-Funktionen wie Secure Boot, Secure Debug und abgesicherter Flashspeicher zur Norm werden.

Sichere Hardware

Secure Boot lässt sich zum Beispiel über das Verified-Boot-Feature von U-Boot [1] nutzen. Das überprüft den gebooteten Linux-Kernel oder das Bootimage, falls der Admin nicht auf Linux setzt. Mit einem RSA-Schlüsselpaar erzeugt er für den Kernel eine Signatur sowie einen Hash (siehe Hashes-Artikel in der Know-how-Rubrik), das Gerät verwahrt den zur Signatur passenden öffentlichen Schlüssel sicher auf.

Die verschiedenen Features lassen sich auch verketten: Das Device kann ein TPM (Trusted Platform Module, [2]) enthalten, das die U-Boot-Binärdatei vor dem Booten verifiziert. U-Boot wiederum überprüft das gebootete Linux-System. Das wiederum validiert die installierten Anwendungspakete.

Wenn aber die Hardware nur offizielle Firmware bootet, um den Nutzer abzusichern, verbietet das wiederum den Einsatz speziell angepasster Firmware, wie sie etwa das Open-WRT-Projekt anbietet. Hier befindet sich der Hersteller in einer Zwickmühle und muss Kompromisse finden. Will er die Firmware-Policy durchdrücken oder Optionen für Anpassungen lassen? Zumindest kann er inzwischen festlegen, wie sicher er die Bootsequenz machen möchte.

Protokolle

Geräte für das Internet der Dinge müssen natürlich mit dem Internet kommunizieren. Die Anwendungen erfordern kompakte Kommunikationsprotokolle, die in Embedded-Umgebungen und drahtlos funktionieren. Inzwischen gibt es solch effiziente Standardprotokolle für die IoT-Kommunikation. Dazu gehören unter anderem MQTT [3] und Coap [4]. Sie sind einfach und kompakt genug, um sie auf 8-Bit-Prozessoren einzusetzen, und benötigen lediglich ein paar Kilobyte an RAM und Flashspeicher.

TLS für die Kleinen

Eine weitere Security-Herausforderung besteht darin, dass IoT-Anwendungen häufig mit sensiblen persönlichen Daten hantieren. Nutzer dieser Anwendungen müssen sich daher authentifizieren und verschlüsselt kommunizieren können. Dafür gibt es jedoch nur wenige Optionen. Die populärste besteht im Einsatz von TLS und DTLS, einer TLS-Version für UDP-Pakete.

Allerdings sind die meisten 8-Bit-Prozessoren nicht in der Lage, moderne TLS-Implementierungen zu nutzen. Das gilt auch für einige 32-Bit-Prozessoren, die nur limitierte Flash- oder RAM-Ressourcen mitbringen. Glücklicherweise existieren bereits einige Embedded-freundliche Open-Source-Implementierungen:

• Mbed TLS [5]: So lautet der neue Name von Polar SSL, nachdem ARM das Projekt übernommen hat. Es handelt sich um eine Embedded-freundliche SSL-Variante, die seit Version 2.0 auch DTLS unterstützt. Sie ist in C geschrieben und lässt sich einfach portieren.
• Tiny DTLS [6]: Eine sehr kompakte DTLS-Implementierung ohne TLS-Support. Sie lässt sich einfach auf Linux oder Contiki OS [7] einsetzen und ist gut getestet für eingeschränkte Wireless-Netzwerke wie 6-Low-Pan [8]. Tiny DTLS verwendet wenig Arbeitsspeicher und unterstützt neue Chiffren-Suites für Ressourcen-arme Netzwerkknoten, die auf AES-128-CCM-8 basieren. Ein Bewerbung als Eclipse-Projekt läuft [9].
• Open SSL [10], Libre SSL [11], Gnu TLS [12]: Wer weniger eingeschränkte Embedded-Hardware nutzt, etwa den Raspberry Pi, kann auch die altbekannten Securitybibliotheken nutzen. Sie belegen aber mehr Flashspeicher und laufen nur schlecht auf Hardware ohne Linux-Unterbau.

Wer das leichtgewichtige Publish- und Subscribe-Protokoll MQTT für IoT-Anwendungen verwendet, kann sich zugleich Eclipses Paho-Projekt [13] anschauen. Es zeigt an Beispielen, wie ein Admin MQTT sicher auf verschiedenen Hardwareplattformen einsetzt.

Schlüsselmomente

Ist der sichere Kommunikations-Stack erst mal eingetütet, wandert der Blick zu den gangbaren Authentisierungsoptionen. Für TLS gibt es grundsätzlich folgende drei Möglichkeiten.

Beim Pre-Shared-Keys-Verfahren (PSK) teilen zwei Peers einen geheimen Schlüssel, den sie sicher aufbewahren, wahrscheinlich offline. Symmetrische Chiffren wie AES und SHA-1 ver- und entschlüsseln die Kommunikation über einen gemeinsamen Key. Die Grundidee besteht darin, dass der Hersteller den Schlüssel bereits ab Werk auf einem Gerät ablegt und das Gegenstück auf einem Server lagert. Meist sichert ein nur beschreibbarer Chip den Schlüssel, den nur die Kryptohardware auslesen kann.

Eine PSK-basierte TLS-Implementierung passt auch gut auf einen ARM Cortex M3 oder M4, zumal diese Plattformen bereits Hardwaresupport für AES mitbringen. Das hilfreiche Dokument [14] listet den RAM- und Flash-Konsum für Tiny DTLS auf.

Eine höhere Sicherheit verspricht der Einsatz asymmetrischer Kryptographie mit öffentlichen und privaten Schlüsseln über Raw Public Keys (RPK), wie sie auch GPG verwendet. Das Verfahren ist besser, weil die IoT-Geräte und der Kontrollserver nicht die sensiblen privaten Schlüssel austauschen, sondern nur deren öffentliche Gegenstücke.

Die dritte Möglichkeit stellt Zertifikate (X.509) für öffentliche Schlüssel aus. Diese Lösung bietet auf Basis asymmetrischer Kryptographie noch ein Stück mehr Sicherheit, ihr Einsatz bringt aber auch mehr Komplexität mit sich. Ziel ist, kryptographische Signaturen verschiedener Drittanbieter zu verketten (Signature Chain), um so eine Identität zu bestätigen. Das erfordert eine größere Menge an Code, auf Wunsch liefert aber auch ein vertrauenswürdiger Drittanbieter die Zertifikate aus.

In diesem Prozess muss die IoT-Hardware in der Lage sein, Zertifikate zu parsen, Signaturketten zu verifizieren und zu prüfen, ob auf dem Server Rückrufe für Zertifikate vorliegen. Letzteres erweist sich in der Praxis nicht unbedingt als trivial [15].

Höheres Management

Es reicht aber nicht, die Kommunikation abzusichern, ein Admin will seine IoT-Flotte auch verwalten. Meist wollen Anbieter ihre Geräte über das Internet (Over the Air, OTA) steuern, überwachen und aktualisieren.

Für das Devicemanagement verschiedener Hardwareplattformen existieren bereits Standards, etwa OMA-DM [16] und TR-069 [17], wobei der Autor OMA Lightweight M2M (LWM2M) favorisiert (Abbildung 1, [18]). Dieser lässt sich an die Bedürfnisse einer Anwendung anpassen und wickelt die genannten Geräte-Operationen über das Internet ab.

Abbildung 1: Ein Whitepaper von ARM zeigt die Möglichkeiten, die LWM2M für das Internet der Dinge bietet.

Open Source hilft

Beim Bau eines eigenen Devicemanagement-Stack können zwei Eclipse-Projekte helfen. Bei Wakaama [19] handelt es sich um eine in C geschriebene Implementierung von Lightweight M2M für Embedded-Kontexte. Es läuft auf Spark, Arduino und den Zielgeräten von Mbed.org [20]. DTLS-Varianten wie Tiny DTLS und Mbed TLS sichern es ab.

Auf dem Server kann als Gegenstück Project Leshan (Abbildung 2, [21]) laufen. Die Client-Server-Implementierung in Java lässt sich einsetzen, um Devicemanagement-Server für größere Geräteflotten zu entwickeln. Der Server aktualisiert dann etwa die veraltete Firmware eines Geräts, sobald es sich mit dem Internet verbindet. Leshan unterstützt die drei erwähnten Schlüsselvarianten (PSK, RPK, X.509) auf Basis von DTLS.

Abbildung 2: Die im Projekt Leshan entwickelte Software lässt sich als Server für die IoT-Geräte einsetzen.

Weil Lightweight M2M auch einen Bootstrap-Mechanismus für geheime Schlüssel mitbringt, kann Leshan auch private Schlüssel, Passwörter und Zertifikate an die Geräte verteilen oder sie im Rotationsprinzip austauschen. Sind die Geräte erst in freier Wildbahn, lassen sie sich nicht zurückholen, um die Firmware zu aktualisieren. IoT-Betreiber müssen sich vorher überlegen, wie sie die Schlüssel austauschen, falls die eines Tages veralten oder die Kryptographie sich als fehleranfällig entpuppt.

Wie die Wiederherstellung einer Backuplösung muss der Admin auch die Rotation der Zugangsdaten regelmäßig überprüfen. Er sollte nicht per Knopfdruck ungetestet eine Million Zugangsdaten auf einen Schlag ausliefern müssen. Der beste Weg, um Schlüssel zu erneuern, besteht darin, den Prozess für jedes neu angeschlossene Geräte zu durchlaufen – mindestens ein Mal im Laufe des Lebenszyklus. Gängige Praxis ist, die ab Werk gesetzten Zugangsdaten nach der ersten Verbindung auszuwechseln.

Update-Trouble

Das eben beschriebene Szenario zeigt auch: Ein Admin kann nicht absichern, was er nicht aktualisieren kann. Haben Hersteller nur die Zeit, ein Securityfeature zu implementieren, sollte es dieses sein. Es ist der Schlüssel, um später neue Securityfunktionen nachzurüsten oder schlicht Löcher zu stopfen.

Allerdings handelt es sich auch um das am schwierigsten umsetzbare Feature jedes Devicemanagement-Stack. Es muss kugelsicher funktionieren und Risiken einkalkulieren, die von der Stromversorgung, den Batterien, dem Netzwerk oder dem NAND-Flash ausgehen. Was passiert etwa, wenn während eines Update der Strom ausfällt oder die Netzwerkverbindung abbricht? Der Mechanismus muss das berücksichtigen. Eine Fehlerrate von 0,1 Prozent macht bei einer Million Geräten noch immer tausend, die ein Unternehmen vor Ort reparieren müsste.

Aktualisierungen sind zudem datenintensiv. Selbst eine kleine Radio-Firmware, die sich nur um Netzwerkfunktionen kümmert, schlägt mit 10 bis 20 MByte zu Buche, eingebettete Linux-Rootdateisysteme wachsen stets. Daher ergeben Updates in Form von Patches und Deltas Sinn: Kleinere Downloads flutschen dann schneller und sind robuster.

Auf Linux-Systemen erleichtert U-Boot [1] das Leben: Das Userland-Update-Image lässt sich in einen reservierten Flashbereich laden. Funktioniert das Skript, lädt U-Boot das Image beim nächsten Neustart auf das Gerät. Auch Embedded-Paketmanager wie OPKG [22] holen Updates und kümmern sich zugleich um GPG-basierte Paketsignaturen.

Wer ein IoT-Gerät ohne Linux-Support einsetzen möchte, kann auf einige andere eingebettete Open-Source-Betriebssysteme zurückgreifen. Contiki [7] läuft auf Geräten für das Internet der Dinge oder auf sparsamen Microcontrollern und hat Funktionen für Upgrades an Bord. Riot OS [23] visiert eine höhere Posix-Kompatibilität an und bietet nützliche Features wie Posix-Threads. Das Projekt arbeitet noch an einer Funktion für Firmware-Updates aus der Ferne.

Fazit

Dieser Überblick konzentriert sich auf die Sicherheitsherausforderungen, die die IoT-Hardware selbst stellt. Die altbekannten Securityregeln für Webserver gelten natürlich auch. Der Hauptunterschied zu einer herkömmlichen Infrastruktur besteht darin, dass der Betreiber die Kommunikation besonders absichern muss und dass er eine Möglichkeit braucht, Schlüssel und Software für die Geräte zu aktualisieren.

Für Gerätehersteller ist Security häufig nur ein Nebenkriegsschauplatz, der in diesem Setup aber recht viel Raum einnimmt. Zum Glück gibt es Standards und quelloffene IoT-Bausteine. Mit ihrer Hilfe lässt sich eine solide und sichere Anwendung bauen.