Secure Boot

Mikrocontroller und elektronische Steuerungen bestimmen unser Leben. Von Atomkraftwerken über Industrieanlagen bis hin zu Zügen findet man sie überall. Vor weniger als 10 Jahren waren dies noch kleine Kästen mit proprietärer Hard- und Software: Inseln ohne Datenverbindung zur Außenwelt. Im Fehlerfall kam ein Servicetechniker zur Anlage. Zur Zeit- und Kostenreduktion werden immer mehr Steuerungen online verfügbar gemacht. Der Techniker kann so viele Incidents remote lösen. Dies eröffnet aber ein komplett neues Bedrohungsszenario: Cyber-Physical-Attacks.

Motivation für einen Angriff

Integrität: Warum sollte jemand eine Steuerung manipulieren? Denken Sie hier an Terrorismus oder Geheimdienste? Möglich, man denke an Stuxnet. Und Sabotage? Klingt zwar unwahrscheinlich aber was ist ein Hackerangriff auf eine unzureichend geschützte Steuerung anderes als Sabotage? Bei einer offline betriebenen Steuerung muss ein Saboteur vor Ort sein, um Schaden anzurichten. Er muss sich Zutritt verschaffen verbunden mit dem Entdeckungsrisiko. Bei einem online zugänglichen System und einer damit verbundenen Cyber-Attacke ist das Risiko für den Angreifer minimal. Der Angreifer kann sein Wissen bündeln und unerkannt mit vielen Gleichgesinnten zusammenarbeiten. Dabei spielt es keine Rolle, ob er dies aus politischen Gründen macht, jemanden erpressen will oder einfach nur beweisen will, dass er es kann.

Aber auch ein Betreiber kann ein Interesse haben, die Steuerung zu manipulieren, um seine Maschine oder Anlage zu „tunen“. Doch der Betrieb außerhalb der vorgesehenen Parameter birgt Risiken, von denen erhöhter Verschleiß noch das Geringste ist. Aus Gewährleistungs- und Haftungsgründen möchte der Hersteller dieses Tuning unterbinden oder doch zumindest nachweisen können.

Vertraulichkeit: Industriespionage ist ein weiteres oft unterschätztes Bedrohungsszenario. Sowohl die Prozessparameter des Betreibers, als auch die Steuerlogik der Anlage sind für die jeweiligen Konkurrenten höchst interessant. Auch hier vereinfacht eine Remote Schnittstelle den Datendiebstahl. Während man in Action-Filmen immer sofort sieht, wer auf welche Dateien zugreift, wird in der Regel auf realen Systemen nur das Einloggen protokolliert. Oft können diese Protokolle leicht manipuliert werden. Der Datendiebstahl bleibt meist unerkannt und der Angreifer kann die Daten offline in aller Ruhe analysieren.

Wie muss ich mich schützen?

Viele Steuerungen setzen heute auf Standard-Hardware wie Industrie-PCs mit Standard-Betriebssystemen wie VxWorks, QNX, Windows oder Linux Embedded. Auch die Laufzeit-Umgebung der Steuerung ist oft ein gemeinsamer Standard (zum Beispiel CODESYS). Natürlich sollte der Zugang zum Remote-Netzwerk durch VPN- und Firewall- Lösungen geschützt sein. Dies ist aber kein ausreichender Schutz für die Steuerung selbst. Der Angreifer, der diese Hürde übersprungen hat, kann sich frei im internen Netz bewegen. Passwörter und Zugangsschlüssel für die VPNs unterschiedlicher Kunden liegen oft ungeschützt auf dem Rechner des Service-technikers. Da ein Gesamtsystem nur so stark sein kann wie sein schwächstes Glied reicht schon ein unachtsamer Techniker oder die Wahl eines unzureichenden Passwortes, um das komplette System zu korrumpieren.

Auf der anderen Seite können Firewall- und VPN-Lösungen Fehler und Hintertüren enthalten oder Schlüssel können zu kurz gewählt sein, speziell bei der Verwendung von RSA. Auch zeigen aktuelle Enthüllungen, dass die Sicherheit solcher Systeme nicht als ultimativ angesehen werden kann. Die Kehrseite der Veröffentlichungen ist das Risiko, dass sich mit diesen Informationen potenzielle Angreifer auf veröffentlichte Schwachstellen konzentrieren können.

Aber auch Insellösungen sind betroffen: Unterschiedliche Personen in einem Unternehmen haben physikalischen Zugang zu den Steuerungen. Servicetechniker verbinden diese mit ihren Notebooks wenn sie vor Ort sind. Backups der Steuersoftware und der Prozessparameter liegen an unterschiedlichen Stellen im Unternehmen.

Dies bedeutet, dass der Schutz schon auf dem Zielsystem, also der Steuerung selbst, anfangen muss. Auf der Steuerung darf nur Code laufen und es dürfen nur Konfigurationen sowie Prozessparameter verwendet werden, die von der autorisierten Stelle genehmigt wurden.

Die meisten Steuerungen sind im Feld aktualisierbar. Damit können neue Funktionen nachträglich ausgeliefert oder Fehler behoben werden. Diese Update-Fähigkeit ist gleichzeitig die Schwachstelle, da ein Angreifer auf diesem Weg eigenen, manipulierten Code auf die Steuerung bringen kann sowohl remote als auch lokal an der Steuerung. Um dies zu verhindern, muss die Steuerung in einer sicheren Umgebung booten und ablaufen. Alle Komponenten der Steuerung, beginnend mit dem Pre-Bootloader bis zur Applikation sollten kryptografisch authentifiziert und somit vertrauenswürdig sein. Man spricht hier von „Secure Boot“.

Warum so kompliziert? Reicht nicht auch ein Hash?

Bei asymmetrischer Kryptografie wie ECC wird immer ein Schlüsselpaar aus einem privaten Schlüssel und einem öffentlichen Schlüssel verwendet. Der Rückweg ist mathematisch unmöglich. Vom öffentlichen Schlüssel kann man nicht auf den privaten Schlüssel zurückrechnen.
Der private Schlüssel wird geheim verwahrt. Am sichersten kann er in einem CmDongle verwahrt werden. Der öffentliche Schlüssel ist, wie der Name bereits sagt, öffentlich für jeden verfügbar.

Und wozu sind jetzt die beiden Schlüssel? Mit dem privaten Schlüssel wird eine Signatur erzeugt, was nur die Person kann, welche diesen Schlüssel besitzt. Mit dem öffentlichen Schlüssel kann jeder die Gültigkeit der Signatur überprüfen. Aber niemand kann damit eine gültige Signatur erzeugen.

Im Gegensatz dazu hat man bei einer Hash-Funktion mit oder ohne Salt den gleichen Schlüssel zum Erzeugen des Hashwertes wie beim Überprüfen. Somit kann jeder, der diesen Hash überprüfen kann, auch einen gültigen Hash erzeugen. Eine Signatur sollte daher niemals durch einen Hash ersetzt werden. Die Sicherheit ist nur vorgegaukelt.

Wie funktioniert Secure Boot?

Die einzelnen Bestandteile auf der Steuerung werden vom Hersteller oder Anlagenentwickler digital signiert. Doch wie funktioniert die Überprüfung? Auf der einen Seite überprüft die vorherige Stufe, ob die nächste Stufe gestartet werden kann. Also der Pre-Bootloader der Bootloarder. Der Bootloader das Betriebssystem. Und so weiter bis zur Application, wie in der Grafik dargestelt. Da es für die Sicherheit der ganzen Kette essenziell ist, dass der öffentliche Schlüssel bei den ersten Prüfung nicht ausgetauscht wurde, das heißt der Schlüssel muss authentisch sein. Die erste Stufe sollte nicht änderbar sein. Hier spricht man von einem sicheren Anker. Die höchste Sicherheit bietet hier ein Pre-Bootloader, der als System-On-Chip (SOC) fest eingebrannt ist. Ein zweiteiliger Bootloader, bei dem der erste Teil nicht aktualisiert werden kann, ist eine kostengünstige Alternative. Diese bietet zumindest ausreichenden Schutz gegen Remote-Angriffe.

Bin ich in einer sicheren Umgebung?

Es ist eine zusätzliche Anforderung, dass die nächste Stufe überprüft, ob die vorherige Stufe korrekt durchgelaufen ist. CodeMeter bietet beides: die Überprüfung vorwärts als auch rückwärts. Die Rückwärtsüberprüfung wird mittels einer State-Engine im CmDongle 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 CmDongle gesetzt ist, kann die nächste Stufe entschlüsselt werden. 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. Dies verhindert Spionage, aber auch das Suchen nach Schwachstellen und Implementierungsfehlern mit dem Zweck eines späteren Angriffes und trägt somit zusätzlich zum Schutz des Gerätes bei.

Fazit

Secure Boot und Integritätsschutz durch Signatur und Verschlüsslung sind ein wesentlicher Anteil bei der Sicherung einer Steuerung. Sie erschweren physikalische Attacken nachhaltig und machen Cyber-Physical-Attacks nahezu unmöglich.

CodeMeter bietet eine Lösung, die bereits tief im Gerät eingreift und bei der sich alle Komponenten gegenseitig überprüfen. Berechtigungsstufen können fein granular definiert und an den entsprechenden Anwendungsfall angepasst werden. CodeMeter schützt gegen Spionage, Manipulation und Sabotage.

 

KEYnote 26 – Herbstausgabe 2013