Artikel von: Mohamed BELOUARGA & Fabien Lahoudere

Die Welt wird immer vernetzter, und Millionen von Geräten werden so entwickelt, dass sie entweder mit Servern oder untereinander verbunden sind. Diese Hypervernetzung bringt zahlreiche Gefahren mit sich, und auch Linux-basierte eingebettete Systeme sind davon nicht ausgenommen.

In diesem Artikel werden wir eine Technik erörtern, die die Sicherheit von Embedded-Linux-Geräten erhöht; der Leser sollte sich jedoch bewusst sein, dass diese Methode Embedded-Linux-Geräte nicht vor allen Bedrohungen schützt. 

Der Leser sollte wissen, dass der Autor ein Entwickler für eingebettete Linux-Systeme und kein Experte für Cybersicherheit ist.

Was ist Secure Boot?

Beim Secure Boot geht es darum, eine Vertrauenskette zwischen verschiedenen Softwarekomponenten eines eingebetteten Linux-Geräts zu etablieren. Diese Vertrauenskette soll verhindern, dass auf den Geräten beschädigte Software oder Software ausgeführt wird, die nicht vom Gerätehersteller stammt.

Diese Vertrauenskette ist im Grunde ein mehrstufiger Verifizierungsprozess, der die Herkunft dieser Softwarekomponenten ermittelt

Zunächst überprüft der ROM-Code, ob der Bootloader vom Hersteller stammt, dann überprüft der Bootloader , ob auch der Linux-Kernel vom Hersteller stammt, bevor er diesen startet, und schließlich überprüft der Kernel, ob das ROOTFS ( die Anwendung) vom Hersteller stammt.

Im Folgenden werden wir sehen, wie diese Vertrauenskette funktioniert – oder wie wir es nennen: Secure Boot – und wie man sie implementiert.

So implementieren Sie Secure Boot

Sichern des Bootloaders

Dieser Teil ist hardwareabhängig und wird durch Hardware und ROM-Code realisiert. Der ROM-Code überprüft anhand der Signatur, ob der Bootloader vom Hersteller stammt. Die Signatur des Bootloaders ist in der Regel sein mit einem privaten Schlüssel verschlüsselter Hashwert.

Ist die Signatur beschädigt, startet der ROM-Code den Bootloader nicht, sodass das Gerät nicht hochfährt.

Sicherung des Kernels

Nach der Überprüfung startet der ROM-Code den Bootloader.

Der Bootloader initialisiert gerade so viel Hardware (mindestens SDRAM und serielle Konsole), wie nötig ist, um den Kernel zu starten und sowohl den Kernel als auch den Gerätebaum in den Arbeitsspeicher zu laden.

Der Bootloader überprüft die Signatur des Kernels und des Gerätebaums (sowie gegebenenfalls anderer Binärdateien), bevor er den Kernel startet.

Wenn Binärdateien überprüft werden müssen, kann ein FIT-Image, das alle diese Binärdateien enthält, verwendet werden, um diesen Vorgang etwas zu beschleunigen.

Sichern des ROOTFS

Um das ROOTFS zu sichern, empfiehlt es sich, ein schreibgeschütztes ROOTFS zu verwenden und eine vom Kernel bereitgestellte Funktion namens DM-Verity zu nutzen.

Dm-verity verwendet einen Hash-Baum, um sicherzustellen, dass das ROOTFS nicht beschädigt ist. Die Ebene 0 des Hash-Baums enthält die ROOTFS-Hashes – einen Hash pro 4 KB.

Weitere Einzelheiten finden Sie in der folgenden Übersicht.

• Ebene 0 enthält Hashes des ROOTFS, einen Hash pro 4 kB Speicher
• LAYER 1 enthält die Hashwerte von LAYER 0
• Hashes von LAYER 1 in LAYER 2 …
• Bis wir am Ende einen Hash namens „Root-Hash“ erhalten.

Um DM-Verity auf der ROOTFS-Partition zu nutzen, ist es einfacher, ein InitRamFS zu verwenden, das DM-Verity auf der ROOTFS-Partition startet, bevor zum ROOTFS gewechselt wird.

Das InitRamFS (das den Root-Hash enthält) sollte dem FIT-Image hinzugefügt und ebenfalls signiert werden.

Wenn DM-Verity eine Beschädigung im ROOTFS feststellt oder sich der Root-Hash geändert hat, löst die Funktion einen Kernel-Panic aus, wodurch der Start blockiert wird.

Beispiel für imx8

Um einige hardwareabhängige Aspekte des Secure Boot zu veranschaulichen, nehmen wir imx8 als Beispiel:

CST-Tools

Bevor wir versuchen, Secure Boot auf dem IMX8 zu implementieren, müssen wir einige private Schlüssel generieren, die zum Signieren der Binärdateien verwendet werden. NXP stellt CST-Tools (Code Signing Tool) zur Verfügung, die private und öffentliche Schlüssel generieren und es uns ermöglichen, den Bootloader und andere Binärdateien zu signieren.

Sicherungen und CAAM

Der Imx8 verfügt über ein Modul namens CAAM (Cryptographic Acceleration and Assurance Module), das zur Beschleunigung der Überprüfung aller Signaturen eingesetzt wird. Der Imx8 verfügt außerdem über einige Register, die als einmalig programmierbare Register (eFuse) bezeichnet werden.

Um die Signaturprüfung zu ermöglichen, müssen die SRK_HASH-eFuses mit den generierten Hash-Werten der öffentlichen Schlüssel programmiert werden; zum Sperren der Karte sollte ein weiterer eFuse programmiert werden.

All diese Elemente werden zur Implementierung des HAB (High Assurance Boot) verwendet: dem IMX Secure Boot.

ROM-Code

Beim Booten prüft der ROM-Code, ob die SRK_HASH-eFuses programmiert sind. Ist dies der Fall, überprüft er die Signatur des Bootloaders (SPL + ATF + OPTEE + U-Boot). Je nachdem, ob die Karte gesperrt ist oder nicht, setzt der ROM-Code den Bootvorgang fort oder bricht ihn ab:

Der Rom-Code überprüft ein Bild, wie die folgende Abbildung zeigt:

Hinweis: Zur ordnungsgemäßen Implementierung von Secure Boot müssen auch andere eFuses programmiert werden. Zum Beispiel die eFuse, die JTAG deaktiviert.

Imx-boot

Nach der Überprüfung der Signatur startet der ROM-Code den Bootloader (SPL, dann ATF und OPTEE, dann U-Boot).

U-Boot sollte so konfiguriert werden, dass die Signatur des FIT-Images überprüft wird, wenn der HAB aktiviert ist. Die Überprüfung der Signatur des FIT-Images erfolgt durch Aufrufe des ROM-Codes (über ATF).

U-Boot verhält sich dann wie der ROM-Code im vorherigen Schritt: Wenn die Karte gesperrt ist und die Signatur beschädigt ist, bricht es den Bootvorgang ab.

Fit Image und ROOTFS

Das Fit-Image enthält mindestens drei Elemente: den Kernel, den Device Tree und das InitRamFS.

Wenn U-Boot die Signatur des Images überprüft, extrahiert es diese Elemente und startet den Kernel.

Wenn der Kernel mit dem InitRamFS gestartet wird, wendet dieses DM-Verity auf die ROOTFS-Partition an und übermittelt dem Kernel den Root-Hash. Schließlich setzt der Kernel den Bootvorgang auf dem ROOTFS fort.

Diese verschiedenen Schritte bildeten den Secure Boot für imx8:

Der interessierte Leser findet im Internet weitere Informationen zur HAB-Implementierung. Dieser zweite Teil des Artikels sollte nicht alle Einzelheiten von HAB erläutern, sondern lediglich den Zusammenhang zwischen Secure Boot und der Hardware aufzeigen.