Hardware-Security Embedded-Bauteile absichern

Die Absicherung von Embedded-Bauteilen gewinnt zunehmend an Bedeutung.
Die Absicherung von Embedded-Bauteilen gewinnt zunehmend an Bedeutung.

Immer mehr Hardware-Bauteile werden dem Angriff von Hackern ausgesetzt. Was kann der Anwender tun, um diese abzusichern? Es gibt mehrere Möglichkeiten, doch nicht alle führen zum Erfolg.

Das Sichern von Embedded-Bauteilen für den Einsatz im Internet of Things (IoT) oder in anderen Anwendungen gewinnt zunehmend an Bedeutung. Viele Halbleiterhersteller statten daher ihre Embedded-Prozessoren und -Mikrocontroller mit inte­grierten Sicherheitsfunktionen aus. Leider geht hohe Sicherheit mit hohen Kosten und dem Aufwand einher, die Hardware neu zu entwickeln und zu qualifizieren, um sie nutzen zu können. Jedoch lassen sich viele Anforderungen ohne große Abstriche bei der Sicherheit auch mit kostengünstiger oder älterer Hardware erfüllen.

Sicherheit, einfach umgesetzt

Eine Reihe einfacher Maßnahmen verbessert die Sicherheit kostengünstiger Systeme. Eine Technik ist, Details über die Hardware und Firmware nicht sofort verfügbar zu machen. In wissenschaftlichen Beiträgen wird häufig das Ausnutzen eines Sicherheitsproblems (Exploit) beschrieben, das mit dem Auffinden der Firmware oder der Schaltpläne eines Produkts auf einer Website oder einem File Transfer Protocol (FTP)-Server beginnt. Schaltpläne, Quellcode und Binärdateien sollten allesamt zugriffskontrolliert sein. Zudem sollten Firmware-Updates verschlüsselt werden, um zu verhindern, dass Code leicht aus einem Update extrahiert werden kann. Auch strengere Maßnahmen lassen sich ergreifen, wie die Verschleierung der verwendeten Hardware bei benutzerdefinierten Integrated Circuits (ICs).

Allerdings ist das Einschränken von Informationen nur eine Verschleierung und keine echte Sicherheit. Es erhöht die Schwierigkeit eines Angriffs. Wird der Zugriff auf wichtige Informationen eingeschränkt, verringert sich infolgedessen jedoch auch die Wahrscheinlichkeit, dass Sicherheitslücken gefunden werden und darüber informiert wird. Eine Möglichkeit ist, sich an Dritte zu wenden, die Code-Überprüfungen und Penetrationstests durchführen und die Informationen unter NDA (Non-Disclosure Agreement) zur Verfügung stellen.

Eine andere übliche Technik ist das Sichern der Debug-Schnittstelle zum Produkt. Während kostengünstige ICs keine Hardware-Funktionen wie Secure Debug Unlock bieten, ermöglichen sie es der CPU jedoch, den Debug-Zugriff zu sperren und freizuschalten. Die Funktion lässt sich nutzen, um eine sinnvolle Debug-Entsperrfunktion zu implementieren. Am einfachsten ist, jedes Bauteil mit demselben öffent­lichen Schlüssel und einer ID zu programmieren. Um es zu entsperren, muss ein Freigabe-Token generiert werden, indem eine ID mit dem privaten  Entsperrschlüssel signiert und das Zertifikat an das Bauteil gesendet wird.
Die Firmware des Bauteils überprüft dann die Signatur, um sicherzustellen, dass die ID vom privaten Schlüssel­inhaber gesendet wird. Anschließend wird überprüft, ob sie mit der ID des Bauteils übereinstimmt. Sind beide Bedingungen erfüllt, kann die Debug-Schnittstelle entsperrt werden. Es gibt natürlich fortschrittlichere Implementierungen, aber die einfache Technik erhöht bereits die Sicherheit. Insbesondere wenn es darum geht, die Schnittstelle nicht komplett zu sperren oder lediglich ein einfaches passwortbasiertes Entsperren zu ermöglichen.

Darüber hinaus bieten einige Bausteine die Möglichkeit, die Debug-Schnittstelle dauerhaft zu sperren. In Systemen, in denen der Debug-Zugriff für die Service- oder Fehleranalyse nicht erforderlich ist, ist es häufig eine sichere Methode, den Debug-Port zu deaktivieren. Schließlich werden in einigen Systemen Debug-Terminals weiterhin ausgeführt. Wie Debug-Ports, sollten sie deaktiviert werden, um zu verhindern, dass Angreifer sie verwenden, um das System zu gefährden. Zu dem Zweck können die gleichen Techniken wie beim Sperren des Debug-Zugriffs zum Einsatz kommen.

Verhindern von Angriffen

Der erste zu untersuchende Bereich ist, wie man symmetrische Schlüssel besser vor Seitenkanalangriffen schützen kann. Obwohl die Angriffe viele Formen annehmen, sind alle darauf angewiesen, einen Aspekt des Bauteils, etwa den Stromverbrauch, die elektromagne­tische Verträglichkeit (EMV) oder das Timing während der Entschlüsselung zu beobachten. Anschließend extrahiert die Schadsoftware mithilfe der Beobachtungen und statistischen Analysen den Schlüssel. Neuere Embedded-Bauteile enthalten Hardware-Gegenmaßnahmen. Sie verhindern die Be­obachtung eines brauchbaren Signals. Es ist zwar verlockend, zu versuchen, die Gegenmaßnahmen in Software zu realisieren, doch in der Realität ist die statistische Analyse durch Angreifer häufig zu effektiv. So kann die Software-Variante das Signal nicht ausreichend schützen.

Ohne spezielle Hardware-Gegenmaßnahmen ist das Ziel, Seitenkanalangriffe durch die Verwendung des Schlüssels zu verhindern. Wird der Schlüssel nicht verwendet, kann der Angreifer auch nicht die Anzahl der Beobachtungen erfassen, die für die Analyse erforderlich sind. In einigen Fällen ist das nicht möglich und der Entwickler muss damit leben, dass der Schlüssel für die Art von Angriff anfällig ist. In anderen Fällen lässt sich jedoch die Verwendung des Schlüssels effektiv einschränken und verhindern, dass der Angreifer die erforderlichen Daten sammelt.

Ein Beispiel dafür ist ein sicherer Bootloader, der ein Image im Rahmen des Installationsprozesses entschlüsselt. In dem Fall muss auf den Schlüssel nur zugegriffen werden, wenn ein gültiges Update installiert wird. In den meisten Systemen werden Updates nur wenige Dutzend Mal pro Jahr durchgeführt. Die Verwendung von Schlüsseln lässt sich damit auf einige Male im Jahr beschränken, was weitaus weniger ist, als ein Angreifer benötigt, um einen erfolgreichen Angriff durchzuführen. Der Bootloader muss zunächst verhindern, dass immer wieder dasselbe Image geladen wird. Das lässt sich einfach umsetzen, indem eine Versionsnummer in das Image eingefügt und nur dann entschlüsselt wird, wenn die Version neuer ist als das aktuell installierte Image. Das verhindert, dass Angreifer die Verwendung des Schlüssels provozieren, indem immer wieder dasselbe Image geladen oder zwischen Versionen gewechselt wird. Als nächstes gilt es zu verhindern, dass der Bootloader ein beschädigtes oder verändertes Image lädt. Das erfolgt durch Signieren des Images und aller Metadaten, wie zum Beispiel der Version. Damit wird verhindert, dass der Angreifer die Version des Images selbst bearbeitet und dem Bootloader vortäuscht, Hunderte gültiger Updates zu erhalten.

Der endgültige Angriffsvektor ist etwas schwieriger zu handhaben. Mit den oben genannten Mechanismen entschlüsselt der Bootloader das Image nur, wenn es neuer als das aktuelle und korrekt signiert ist. Angreifer können das Image jedoch beliebig oft laden, wenn sie den Installationsvorgang abbrechen, indem sie entweder die Stromversorgung unterbrechen oder den Reset-Pin belegen. Wird während der Image-Installation ein Reset durchgeführt, erkennen die meisten Bootloader, dass gerade ein Bootload ausgeführt wird, und wiederholen die Installation automatisch. Dadurch wird sichergestellt, dass eine fehlgeschlagene Installation das Bauteil nicht »blockiert«. Das führt auch dazu, dass bei jedem erneuten Versuch eine Entschlüsselung des Images erfolgt.

Durch das kontinuierliche Zurücksetzen des Bauteils während der Installation kann ein Angreifer den Bootloader veranlassen, das Image immer wieder zu entschlüsseln. Um das Szenario zu vermeiden, kann der Bootloader einen Zähler für fehlgeschlagene Updates enthalten, der bei jedem Start der In­stallation erhöht wird. Der Zähler erhöht sich bei jedem erneuten Versuch, bis er einen Wert erreicht, der anzeigt, dass ein Angriff wahrscheinlich ist, zum Beispiel bei 20 Wiederholungen. Damit lässt sich der Baustein blockieren, um weitere Angriffe auf den Schlüssel zu verhindern. Die Bootloader-Regeln erschweren in den meisten Systemen die Ausführung von Seitenkanalangriffen.

Ein weiteres Beispiel ist ein symme­trischer Schlüssel, der zum Schutz der Kommunikation mit einer externen Einheit verwendet wird. Normalerweise werden symmetrische Schlüssel ausgetauscht, die dann zur Verschlüsselung der eigentlichen Kommunikation zwischen den beiden Parteien genutzt werden. In vielen Fällen werden die symmetrischen Schlüssel über einen längeren Zeitraum verwendet, und lange genug beobachtet, um eine Seitenkanal-Extraktion zu ermöglichen. Das Ändern des symmetrischen Schlüssels in regelmäßigen Abständen verringert die Häufigkeit und die Wahrscheinlichkeit, mit der der Schlüssel durch einen Seitenkanalangriff extrahiert werden kann. Da das Erzeugen und Verteilen eines neuen Schlüssels Strom und Zeit verbraucht, ist das mit Kosten verbunden. Wenn der zu schützende Datenverkehr jedoch empfindlich ist, ist der Aufwand für mehr Sicherheit gerechtfertigt.

Bild 1 zeigt ein Kommunikationsprotokoll, bei dem der symmetrische Schlüssel sehr oft (alle 1 ms) verändert wird, indem der Sender einfach in festgelegten Intervallen einen neuen zufälligen symmetrischen Schlüssel erzeugt und ihn als Teil der verschlüsselten Daten sendet. Nach dem Senden wechselt die Verbindung zum neuen Schlüssel. Erhalten Angreifer Zugriff auf einen symmetrischen Schlüssel, können sie alle zukünftigen Nachrichten lesen, da sie den nächsten Schlüssel mit dem geknackten Schlüssel entschlüsseln können. Doch das kann verhindert werden: In größeren Abständen, zum Beispiel jede Sekunde, wird ein teurer Austausch asymmetrischer Schlüssel eingeführt. Das stellt sicher, dass bei einem geknackten Schlüssel die Daten nur 1 s lang vom Angreifer dekodiert werden können.