Embedded security: Softwareschutz am Beispiel Raspberry Pi...

Transkript

1 :... Immer mehr kleine vernetzte Computersysteme verdrängen in der Industrie die alten proprietären Insellösungen. Gleichzeitig steigen die Anforderungen an die Sicherheit. Am Beispiel des Raspberry Pi lässt sich exemplarisch zeigen, wie ein Softwareschutz auf einem Embedded-Systemaussehen kann und dabei zu einem Baustein eines Secure-Boot-Prozesses wird. Wibu-Systems Der Markt für Embedded-Systeme wächst kontinuierlich. Viele Steuerungen, die in der Vergangenheit eine dedizierte Funktionalität ausführten, werden heute mit leistungsfähigen und universellen Rechnern ausgestattet. Diese Systeme sind eigenständige Computer mit den bekannten Merkmalen eines Desktop-PC. Neben CPU und RAM-Speicher gibt es Flash-Speicher, teilweise Display-Anschlüsse, Netzwerk-Anschluss und in der Regel USB-Ports. Die Systeme verwenden abgewandelte Formen der Desktop-Betriebssysteme wie Linux, Windows Embedded oder VxWorks. Und natürlich Android, das auf immer mehr kleinen Rechnern läuft. Lokal erfolgt der Zugriff über USB oder Bluetooth und im Netzwerk sind die Rechner über ihre IP-Adresse via Ethernet, WLAN oder industrielle Feldbusse zu erreichen. Die Vernetzung dieser Komponenten sowie die Nutzung gängiger Betriebssysteme auf multifunktionalen, leistungsfähigen Plattformen eröffnet eine Reihe von neuen Angriffsvektoren, die auf bisherigen proprietären Inselsystemen ohne Netzwerk- oder USB-Anschluss in der Form nicht existiert haben. Dabei lässt sich die Motivation für die meisten Angriffe in eine der folgenden vier Kategorien einordnen: 1. Diebstahl des Know-hows des Anlagenbauers (Steuerungssoftware, Art der Implementierung, Suche nach Exploits). 2. Diebstahl des Know-hows des Anlagenbetreibers (Rezepte, Prozessparameter, Logdateien). 3. Manipulation der Daten durch den Anlagenbetreiber mit dem Ziel, Betriebsdaten zu verändern etwa um Fehlbedienung zu verschleiern, unberechtigt Garantieleistungen in Anspruch zu nehmen oder nutzungsbezogene Abrechnungsmodelle zu verfälschen. 4. Sabotage der Anlage beispielsweise durch einen unzufriedenen Mitarbeiter, Mitbewerber, Hacker oder einen Geheimdienst. Als prominentestes Beispiel eines Angriffes auf Embedded-Systeme ist hier Stuxnet zu nennen. Neben der Sicherheit spielt die Freischaltung von Features On Demand eine zunehmend größere Rolle. Oft 1 von :55

2 enthalten unterschiedliche Geräte die gleiche Hard- und Software. Die Funktionalität und damit der Preis unterscheiden sich nur durch Einstellungen in der Software oder zusätzliche Softwaremodule. Ergo sollten Security-Lösungen für Embedded-Systeme neben den Sicherheitsfunktionen idealerweise Funktionen für das Lizenzmanagement beinhalten. Bei der CodeMeter-Lösung von Wibu etwa beruht diese Funktionalität auf denselben kryptographischen Prinzipien und lässt sich daher wahlweise zusätzlich nutzen. Das notwendige API ist dabei Bestandteil der Embedded-Software. Teil 1 von 5 1.

3 Fortsetzung des Artikels von Teil 1. Lizenzen installieren Wie kommt nun die Lizenz auf das Gerät? In der vernetzten Welt ist dies ganz einfach. Der Hersteller liefert das Gerät mit einem so genannten Container aus. Dieser kann leer sein oder bereits aktivierte Lizenzen enthalten. Im Falle eines Hardware-Dongles wird dieser mit dem Gerät verbunden. Dies kann in Form einer CF-Karte, einer SD-Karte, einer μsd-karte oder eines USB-Dongles erfolgen. Bei einer rein softwarebasierten Lösung wie im Folgenden für den Raspberry Pi beschrieben wird im Fall der CodeMeter-Technologie eine so genannte CmActLicense im System registriert. Dies erfolgt über einen Aufruf des entsprechenden API. Wibu-Systems Das Sicherheitstool ExProtector verschlüsselt das Programm und fügt selbstständig die Signatur an. Der Entwickler muss dafür kein Kryptoexperte sein. Um eine Lizenz zu aktivieren, erstellt der Hersteller zuerst ein Ticket mit dem Management-Tool License Central. Ein Ticket hat zum Beispiel die Form NFGSXVWNYJ-T74CD- 48H5B-7NEEJ. Die Erstellung kann manuell oder automatisch über SAP oder ein anderes ERP-System erfolgen. Dabei werden die zu erstellenden Lizenzen mit dem Ticket verknüpft und in der License Central zum Abholen bereitgelegt. Die Lizenz ist immer an das individuelle Zielsystem gebunden und wird nur auf diesem funktionieren. Das Übertragungsmedium ist dabei zweitranging, da die Datei mit dem Lizenz- Update ebenfalls verschlüsselt ist. Teil 2 von 5 1.

4 Fortsetzung des Artikels von Teil 3. Integration ins Betriebssystem Alle kryptographischen Funktionen für die Entschlüsselung des Anwendungsprogramms befinden sich bereits integriert im Betriebssystem. Auch der Treiber für den Zugriff auf die Lizenzen im Dongle oder den softwarebasierten ActLicenses befindet sich als nativer Code direkt im Loader des Betriebssystems. Bedingt durch die vielen Kombinationsmöglichkeiten von Betriebssystem und Hardwareplattform im Embedded-Umfeld ist hier in der Regel immer eine individuelle Implementierung erforderlich. Das Open-Source-Konzept von Linux und Android bietet die Möglichkeit einer Integration in die jeweiligen Systeme. Wind River etwa stellt mit VxWorks 7 bereits eine komplette Integration des Loaders in VxWorks zur Verfügung. Die tiefe Verankerung im Betriebssystem erhöht sowohl die Effizienz als auch die Sicherheit. Der Loader überprüft die Integrität des mit dem ExProtector gesicherten Programms oder der Daten anhand des Hash und der Signatur, nachdem er es autorisiert und entpackt hat. Teil 4 von 5 1.

5 Fortsetzung des Artikels von Teil 4. Der sichere Boot-Vorgang In Kombination mit Secure-Boot-Prozeduren, die sich mit der CodeMeter-Technologie ebenfalls abbilden lassen, erhält man ohne weitere zusätzliche Software ein rundum gegen Kopieren und Manipulation geschütztes System. Die einzelnen Bestandteile auf der Steuerung werden vom Hersteller oder Anlagenentwickler digital signiert. Während des Bootprozesses wird dann in zwei Richtungen geprüft. Auf der einen Seite überprüft die vorherige Stufe, ob die nächste Stufe gestartet werden darf also der Pre-Bootloader den Bootloader, der Bootloader das Betriebssystem und so weiter. Für die Sicherheit der ganzen Kette ist es essenziell, dass der öffentliche Schlüssel bei der ersten Prüfung nicht ausgetauscht wurde. Das heißt: Der Schlüssel muss authentisch sein. Die erste Stufe sollte daher nicht änderbar sein. Hier spricht man von einem sicheren Anker. Die höchste Sicherheit bietet ein Pre-Bootloader, der als System-On-Chip (SOC) fest eingebrannt ist. Ein zweiteiliger Bootloader, bei dem der erste Teil nicht nachträglich aktualisiert werden kann, ist eine kostengünstige Alternative. Diese bietet zumindest ausreichenden Schutz gegen Remote-Angriffe. Eine zusätzliche Anforderung besteht bei der Rückwärtsprüfung darin, dass die nächste Stufe überprüft, ob die vorherige Stufe korrekt durchgelaufen ist. CodeMeter bietet bei entsprechender Integration in die unterschiedlichen Bootprozesse beides: die Überprüfung vorwärts und rückwärts. Die Rückwärtsüberprüfung wird mittels einer State-Engine im Dongle und einer mit dieser State-Engine verknüpften Verschlüsselung realisiert. Nur wenn eine Stufe ordnungsgemäß ausgeführt wurde und damit der richtige Zustand im Dongle gesetzt ist, lässt sich die nächste Stufe entschlüsseln. Dies verhindert, dass Teile der Software auf einer Simulation des Gerätes im Labor eines Angreifers laufen. Damit ist eine Analyse der Software in dieser Umgebung unmöglich. Auf diese Weise lassen sich sowohl Spionage und Manipulation verhindern als auch das Suchen nach Schwachstellen und Implementierungsfehlern mit dem Zweck eines späteren Angriffes. Die Integration dieser Secure-Boot-Kette ist immer systemspezifisch und muss an die jeweilige Umgebung angepasst werden. Autor: ist Produktmanager Embedded bei Wibu-Systems. gh Teil 5 von :56

6 2 von :56