Der sichere Systemstart oder Secure Boot ist eine essenzielle Sicherheitsfunktion, die moderne Embedded-Systeme, insbesondere auf ARM-basierten Plattformen wie dem ODROID M1, vor unautorisierten Firmware-Manipulationen schützt. Beim ODROID M1, der auf dem Rockchip RK3568B System-on-Chip (SoC) basiert, lässt sich Secure Boot technisch anspruchsvoll aktivieren, da der Bootprozess auf eine enge Zusammenarbeit zwischen Hardware und Software setzt. Das Ziel von Secure Boot ist es, sicherzustellen, dass nur signierte und somit verifizierte Software-Komponenten während des Startvorgangs ausgeführt werden dürfen. Dies verhindert, dass potenziell schädlicher Code vor dem Laden des Betriebssystems die Kontrolle über das Gerät übernehmen kann. Für Entwickler und Entwicklerinnen, die Secure Boot auf dem ODROID M1 aktivieren möchten, stehen vielfältige technische Details und Herausforderungen bevor, deren Verständnis für eine erfolgreiche Umsetzung benötigt wird.
Grundlagen des Secure Boot auf ARM und RK3568 SoC Secure Boot in ARM-Architekturen wie beim RK3568 SoC beruht auf der Integration eines Root of Trust in die BootROM des Chips. Die BootROM ist der unveränderliche, fest im Chip integrierte Code, der sofort nach dem Einschalten des Gerätes ausgeführt wird. Auf dem RK3568 ist es nicht möglich, den kompletten Public-Key für die Signaturprüfung im OTP (One-Time Programmable) Speicher abzulegen, da dieser Speicher begrenzt und teuer ist. Stattdessen wird der Hash des öffentlichen Schlüssels in der OTP-Memory hinterlegt. Der dazugehörige Public-Key selbst ist im Pre-Loader eingebettet, welcher aus dem TPL (Tertiary Program Loader) und SPL (Secondary Program Loader) besteht. Bei aktiviertem Secure Boot berechnet die BootROM beim Starten des Gerätes den Hashwert des Public-Keys, der im Pre-Loader eingebettet ist, und vergleicht ihn mit dem in der OTP gespeicherten Hash.
Stimmen diese Werte überein, wird dieser Schlüssel verwendet, um die Signaturen des TPL und SPL zu prüfen. Nur wenn diese Prüfungen erfolgreich sind, wird das System mit einem verifizierten Pre-Loader weiter gestartet. Dieser Mechanismus stellt sicher, dass das Startsystem nicht durch manipulierte oder unautorisiert signierte Komponenten kompromittiert werden kann. Vorbereitung und Werkzeuge für die Integration Eine solide Vorbereitung ist grundlegend für den Erfolg bei der Integration von Secure Boot. Zunächst ist es notwendig, diverse Software-Repositories und Tools herunterzuladen und in der Entwicklungsumgebung bereitzuhalten. Die zentralen Komponenten sind der Rockchip-U-Boot-Code, das rkbin-Repository mit notwendigen Binärdateien wie TPL, BL31 oder dem Boot Merger Werkzeug sowie das Linux Upgrade Tool, das zum Schreiben von Images auf den SPI-Flashspeicher genutzt wird. Für den Build-Prozess des U-Boot ist das Einrichten eines passenden Cross-Compilers unabdingbar.
Die Empfehlung ist, den Linaro 6. 3. 1 Compiler zu verwenden, da andere Compiler oft zu Fehlern beim Kompilieren führen. Außerdem werden diverse Pakete für das Kompilieren benötigt, darunter gcc, make, python, libssl-dev und weitere Entwicklungsbibliotheken. Schlüsselgenerierung und Signaturen Die Erstellung der RSA-Schlüssel erfolgt mit OpenSSL, da der Secure Boot Mechanismus auf RSA-2048 Bit Keys beschränkt ist. Schlüssel mit höherer Schlüssellänge sind zwar vom SoC theoretisch unterstützt, werden aber von der implementierten Funktion rsa_burn_key_hash nicht akzeptiert. Nachdem ein privater Schlüssel und ein passendes Zertifikat generiert wurden, wird der öffentliche Schlüssel in Form eines Hashwertes auf dem OTP-Speicher abgelegt. Die Einbindung des Public Keys in die SPL erfolgt über die Erstellung einer Signatur-Node im Device Tree Blob (DTB) von u-boot-spl. dtb, welche per mkimage-Tool gesetzt wird.
Hierbei muss sichergestellt werden, dass das mkimage aus dem Rockchip Repository verwendet wird, da die Standard-Version nicht die notwendigen Eigenschaften enthält, die zum Schreiben des Hashes in die OTP benötigt werden. Ein auffälliges Attribut ist "burn-key-hash", das dem SPL mitteilt, dass der öffentliche Schlüssel-Hash in OTP geschrieben werden soll. Flash und Pre-Loader Erstellung Der Pre-Loader, welcher TPL und SPL kombiniert und signiert enthält, wird über das Boot Merger Werkzeug mit einer speziell angepassten . ini-Konfigurationsdatei erstellt. Die korrekte Referenz zum u-boot-spl. bin wird in der RKBOOT/RK3568MINIALL. ini Datei gesetzt, so dass das Tool das passende Pre-Loader Image erzeugt. Anschließend wird dieses Image über das Upgrade Tool in den SPI-Flash-Speicher des ODROID M1 geladen. Vor dem Schreiben des Pre-Loaders muss man das Gerät in den sogenannten MaskROM-Modus versetzen, welcher durch Neustart mit gedrücktem Recovery-Button erreicht wird.
Im MaskROM-Modus lässt sich über USB ein Mini-Boot-Loader laden und somit Flash-Speicherinhalt ändern. Das zielt darauf ab, den Flash-Speicher erfolgreich neu zu programmieren, ohne dass ein manipuliertes System dazwischenfunken kann. OTP Speicher und das sichere Ablegen der Schlüssel Der kritischste Schritt bei der Aktivierung von Secure Boot ist das Speichern des Hashes des öffentlichen Schlüssels im OTP Speicher. Die OTP ist eine besondere speichertechnische Komponente, in der Daten nur einmal und unwiderruflich programmiert werden können. Dies schützt vor dem Austausch des Schlüssels und damit vor unautorisierten Änderungen am Vertrauensanker des Bootprozesses. Der Prozess läuft so ab, dass der SPL beim Booten nach der Signatur-Node mit der Eigenschaft "burn-key-hash" sucht. Wird diese gefunden, schreibt SPL den Hash des eingebetteten Public Keys in den OTP-Speicher.
Danach verweigert die Hardware das Booten von nicht signierter Firmware, da der BootROM den OTP gespeicherten Hash mit dem Hash des Public Keys im Pre-Loader abgleicht. Umfangreiche Sicherheitsprüfung Nach erfolgreicher Initialisierung des Secure Boot sind Registrierungen erforderlich, um sicherzustellen, dass nur valide und signierte Images gestartet werden. Das bedeutet, dass neben der Pre-Loader-Ebene auch U-Boot selbst und dessen Konfiguration signiert und verifiziert werden müssen. Dies wird durch eine sogenannte FIT (Flattened Image Tree) Image-Struktur realisiert, in der sämtliche Boot-Komponenten organisiert und mit Hashes versehen sind. Der U-Boot SPL kann bei der Initialisierung alle in dieser FIT enthaltenen Komponenten auf korrekte Signaturen und Hash-Werte prüfen. Nur wenn der gesamte Baum der Komponenten übereinstimmt, erfolgt das Fortschreiten zum nächsten Boot-Schritt. Diese umfassende Prüfung stellt sicher, dass keine Manipulation am Systemboot vorgenommen werden kann.
Integration und Nutzung von Mainline U-Boot Für weiterführende Entwicklungen empfiehlt sich der Umstieg auf die neuere Mainline-Version von U-Boot, welche native Secure Boot-Implementierungen und besser wartbare Signaturmechanismen bietet. Die Mainline-Version kann mit einigen Modifikationen zum Einbetten des Public Keys und zum Signieren der Images kompiliert werden. Das Cross-Compile-Umfeld ändert sich hierbei dahin, dass bei Mainline die Debian-gelieferten Toolchains genutzt werden können. Gleichzeitig werden Konfigurations-Variablen gesetzt, um Speicherprobleme beim SPL zu umgehen, wie beispielsweise die Vergrößerung des STACK-RAM-Allokationsbereichs. Nachdem U-Boot mit diesen Einstellungen gebaut wurde, müssen der idbloader (zusätzliche Boot-Komponente) und U-Boot selbst signiert werden, wobei stets mit den gleichen Schlüsseln gearbeitet werden muss wie für SPL und Pre-Loader. Die Signierung erfolgt mit dem rk_sign_tool aus dem rkbin-Paket.
Anhaltspunkte, ob die Signierung erfolgreich war, sind entsprechende Ausgaben bei der Prüfung der Signaturen und Hashwerte. Verifikation der Aktivierung Der Nachweis, ob Secure Boot wirklich aktiv ist, erfolgt mit dem Ramboot Loader, der mit aktiviertem Secure Boot gebaut und signiert wird. Beim Start zeigt der BootROM im UART-Log den entsprechenden SecureMode-Status an. Ein Wert von 1 verdeutlicht, dass Secure Boot aktiviert und in Funktion ist. Darüber hinaus können Testversuche mit unsignierten oder falsch signierten Images vorgenommen werden. Ein erfolgreich aktivierter Secure Boot verhindert, dass diese Images geladen und ausgeführt werden. Dies ist ein effektives Mittel, um die Integrität des Bootprozesses sicherzustellen. Zukünftige Perspektiven und Herausforderungen Obwohl Secure Boot auf dem ODROID M1 mit der beschriebenen Vorgehensweise erfolgreich aktiviert werden kann, gibt es Raum für weitere Verbesserungen und genaue Sicherheitstests.
Dabei stellt sich die Frage, ob und wie oft der OTP-Speicher beschrieben werden kann und ob das Speichern mehrerer Schlüssel-Hashes realistisch möglich ist. Theoretisch bietet der OTP mit einem Speicherumfang von 8 Kilobit Platz für mehrere Dutzend Einträge, doch der wirkliche Nutzungsumfang hängt von der Hardwareimplementierung ab. Ein weiterer wichtiger Schritt wäre eine vollständige Integration und Unterstützung des Write-to-OTP-Mechanismus in die Mainline-U-Boot-Version. Dies würde den Implementierungsprozess deutlich vereinfachen und die Verbreitung von Secure Boot auf Rockchip-basierten Geräten fördern. Fazit Die Aktivierung von Secure Boot auf dem ODROID M1 stellt für Entwickler und Systemintegratoren eine komplexe aber lohnenswerte Herausforderung dar.
Indem der öffentliche Schlüssel-Hash sicher in der OTP gespeichert wird und Pre-Loader sowie U-Boot vollständig signiert und verifiziert werden, kann eine sichere Bootumgebung geschaffen werden, die unautorisierte Änderungen am System verhindert und somit die Geräteintegrität gewährleistet. Die sorgfältige Auswahl von Tools, die korrekte Konfiguration der Build-Umgebung und ein tiefes Verständnis der Bootarchitektur sind dabei Schlüssel zum Erfolg. Noch wichtiger ist die kontinuierliche Überprüfung und Validierung der Implementierung, um Sicherheitslücken frühzeitig zu erkennen und zu schließen. Mit diesen Maßnahmen kann das volle Potenzial von Secure Boot auf ARM-basierten Systemen wie dem ODROID M1 ausgeschöpft werden und ein robuster Vertrauensanker für weitere Sicherheitsmechanismen gesetzt werden.
