Bei einem klassischen Boot-Prozess wird zunächst ein ROM-Code ausgeführt, der ein Ladeprogramm von einem externen Flash-Speicher in den internen Speicher überträgt und ausführt, um das System weiter zu initialisieren (Initialisierung der Uhrzeit, des externen DRAM-Speichers etc.). Anschließend überträgt das Programm die Software (z.B. (Echtzeit-)Betriebssystem oder Applikationen) aus dem Speicherbereich (externer nichtflüchtiger Speicher) in den externen DRAM-Speicher. Bild 2 zeigt eine typische Mikrocontroller-Architektur für Embedded-Systeme.
Ist das Ladeprogramm inkorrekt, kann es unter Umständen völlig falsche Anwendungen übertragen und dadurch die Fehlerfreiheit des Embedded-Systems gefährden. Dieses wiederum kann dann von nicht autorisierten Nutzern gesteuert werden. Die erste Aufgabe eines sicheren Bootens ist es, das Boot-Programm zu authentifizieren, zu entschlüsseln und anschließend auszuführen. Ein sicherer Boot-Prozess muss den Inhalt des nichtflüchtigen, zu bootenden Speichers auf Richtigkeit überprüfen. Der Authentifizierungsprozess spielt sich dabei zwischen dem Prozessor und dem externen Flash-Speicher ab, auf dem das Programm abgelegt ist. Ein Hacker, der den Inhalt des externen Flash-Speichers kopiert, ihn in einen anderen Speicher programmiert und mit einem anderen ATSAMA5 verbindet, erhält so keinen Zugriff. Die Applikation wird einfach gestoppt.
Elemente für sicheres Booten
Ein komplett sicherer Boot-Prozess lässt sich durch folgende Komponenten implementieren (Bild 3):
Ein klassischer ROM-Code-Bootloader enthält keinerlei Sicherheitsvorkehrungen. Hier wird der Anwendungscode in den externen, mit dem Mikrocontroller verbundenen Boot-Speicher geladen. So lässt sich der Inhalt des Boot-Speichers kopieren und die Applikation klonen.
Der sichere ROM-Code-Bootloader ergänzt den Standard-Bootloader um Signaturfunktionen. Sobald ein sicherer Bootloader aktiviert ist, führt er – wenn ein verschlüsseltes Ladeprogramm in den externen Speicher geladen wurde – zuerst eine Authentifizierung des Ladeprogramms durch. Dazu wird dessen Signatur anhand geschützter Schlüssel und Verschlüsselungs-Hardware-Beschleuniger überprüft.
Stimmt die berechnete Signatur mit der im Ladeprogram gespeicherten überein, startet die Dechiffrierung des Ladeprogramms mit Hilfe der Entschlüsselungs-Engine, die auf dem internen SRAM gespeichert ist. Um gleichzeitig das Auslesen des ROM-Codes zu verhindern, wird JTAG während der Ausführung des sicheren Boot-Prozesses deaktiviert. ROM-Speicher sowie das Sicherungs-Array werden verborgen, das Sicherungs-Array ist nur durch den sicheren ROM-Code-Bootloader zugänglich. Um die Prozesssicherheit zu verbessern, lässt sich der JTAG-Zugang durch die Nutzung von Fuse Bits komplett deaktivieren. Auch der Versuch, den ROM-Code zu umgehen und auf einem externen XIP-Gerät (eXecute-In-Place) zu booten, lässt sich dadurch verhindern.
Wichtig ist, dass der Anwendungsschlüssel zur Dechiffrierung der Applikation im gesicherten Ladeprogramm gespeichert ist. So bleibt er nach der Authentifizierung und Entschlüsselung verfügbar. Die Dechiffrierung der Anwendung durch einen Schlüssel, der in einem chiffrierten Ladeprogramm integriert ist, garantiert die Verwendung des korrekten Schlüssels. Mit Malware infizierte Schlüssel, die während eines Firmware Update installiert wurden, lassen sich damit genauso verhindern wie das Kopieren des externen Flash-Speichers.
Nach dem Start des Ladeprogramms werden folgende Schritte ausgeführt:
Die Sicherheit eines Embedded-Systems in der Industrie beginnt bereits mit einem sicheren Boot-Prozess. Atmel hat dieses sichere Booten bereits in die Mikrocontroller-Familie SAMA5 integriert und ermöglicht so Embedded-Systeme, die gegen Angriffe und Manipulationen gewappnet sind.
Der Autor
David Dumas |
---|
war bereits für einige Branchengrößen als Digital Designer zuständig, bevor er 2002 zu Atmel kam. Er hat einen Doktortitel in Mikroelektronik von der Universität von Montpellier und ist seit 2008 Field Application Engineer bei Atmel. |