Artikel von: Mohamed BELOUARGA & Fabien Lahoudere
Die Welt wird immer vernetzter, und es werden Millionen von Geräten entwickelt, die entweder mit Servern oder untereinander verbunden sind. Diese Hyperkonnektivität bringt viele Bedrohungen mit sich, und Linux-basierte eingebettete Systeme sind davon nicht ausgenommen.
In diesem Artikel wird eine Technik besprochen, 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 Embedded-Linux-Ingenieur und kein Experte für Cybersicherheit ist.
Bei Secure Boot geht es um die Implementierung einer Vertrauenskette zwischen verschiedenen Softwarekomponenten eines eingebetteten Linux-Geräts. Diese Vertrauenskette wird implementiert, um zu verhindern, dass auf den Geräten beschädigte Software oder Software, die nicht vom Gerätehersteller stammt, ausgeführt wird.
Bei dieser Vertrauenskette handelt es sich in der Tat um einen mehrstufigen Überprüfungsprozess, der die Herkunft dieser Softwarekomponenten ermittelt
Zunächst prüft der ROM-Code, ob der Bootloader vom Hersteller stammt, dann prüft der Bootloader , ob der Linux-Kernel ebenfalls vom Hersteller stammt, bevor er ihn startet, und schließlich prüft der Kernel, ob das ROOTFS (die Anwendung) vom Hersteller stammt.
Im Folgenden werden wir sehen, wie diese Vertrauenskette funktioniert - oder was wir sicheres Booten nennen - und wie man sie implementiert.
Dieser Teil ist hardwareabhängig und wird durch Hardware- und ROM-Code realisiert. Der ROM-Code verifiziert, dass der Bootloader vom Hersteller stammt, indem er seine Signatur überprüft. Die Signatur des Bootloaders ist normalerweise sein Hash, der mit einem privaten Schlüssel verschlüsselt ist.
Wenn die Signatur beschädigt ist, kann der ROM-Code den Bootloader nicht starten, so dass das Gerät nicht hochfährt.
Nach seiner Verifizierung startet der ROM-Code den Bootloader.
Der Bootloader initialisiert gerade genug Hardware (zumindest SDRAM und serielle Konsole), um den Kernel zu booten und den Kernel sowie den Gerätebaum in den RAM zu laden.
Der Bootloader prüft den Kernel und die Gerätebaumsignatur (und ggf. andere Binärdateien), bevor er den Kernel bootet.
Wenn Binärdateien überprüft werden müssen, kann ein FIT-Image, das alle diese Binärdateien enthält, verwendet werden, um diesen Prozess effizienter zu gestalten.
Um das ROOTFS zu sichern, ist es vorzuziehen, 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 wird. Schicht0 des Hash-Baums enthält die ROOTFS-Hashes - ein Hash für alle 4k.
Weitere Einzelheiten finden Sie im folgenden Schema.
Um DM-verity auf der ROOTFS-Partition zu verwenden, ist es einfacher, ein InitRamFS zu verwenden, das DM-verity auf der Partition des ROOTFS startet, bevor es zum ROOTFS wechselt.
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 wenn sich der Root-Hash geändert hat, erzeugt die Funktion eine Kernel-Panik, die den Start blockiert.
Um einige hardwareabhängige Aspekte des sicheren Bootens zu veranschaulichen, nehmen wir den imx8 als Beispiel:
Bevor wir versuchen, Secure Boot auf dem imx8 zu implementieren, müssen wir einige private Schlüssel erzeugen, die zum Signieren der Binärdateien verwendet werden. NXP stellt CST-Tools (Code Signing Tool) zur Verfügung, die private und öffentliche Schlüssel erzeugen und es uns ermöglichen, den Bootloader und andere Binärdateien zu signieren.
Imx8 verfügt über ein Modul namens CAAM(Cryptographic Acceleration and Assurance Module), das zur Beschleunigung der Überprüfung aller Signaturen verwendet wird. Der Imx8 verfügt auch über einige Register mit der Bezeichnung One-Time Programmable Registers (eFuse).
Um die Signaturprüfung zu ermöglichen, müssen die SRK_HASH eFuses mit den generierten Hashes der öffentlichen Schlüssel programmiert werden, und um die Karte zu sperren, sollte eine weitere eFuse programmiert werden.
All diese Elemente werden für die Implementierung des HAB (High Assurance Boot) verwendet: der sichere Boot von imx.
Beim Booten prüft der ROM-Code, ob die SRK_HASH eFuses programmiert sind. Wenn dies der Fall ist, ü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 stoppt ihn:
Der Rom-Code prüft ein Bild, wie die folgende Abbildung zeigt:
Hinweis: Andere eFuses müssen ebenfalls programmiert werden, um Secure Boot korrekt zu implementieren. Zum Beispiel die eFuse, die den JTAG deaktiviert.
Nach Ü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 es die Signatur des FIT-Images überprüft, wenn der HAB aktiviert ist. Die Überprüfung der Signatur des FIT-Abbilds erfolgt durch einige Aufrufe an den ROM-Code (über ATF).
U-boot verhält sich dann wie der ROM-Code im vorherigen Schritt: Wenn die Karte gesperrt und die Signatur beschädigt ist, wird der Bootvorgang abgebrochen.
Das Fit Image enthält mindestens drei Elemente: den Kernel, den Gerätebaum und das InitRamFS.
Wenn U-boot die Signatur des Images überprüft, extrahiert es diese Elemente und startet den Kernel.
Wenn der Kernel mit InitRamFS gestartet wird, wendet er DM-verity auf die ROOTFS-Partition an und gibt dem Kernel den Root-Hash. Schließlich fährt der Kernel mit dem Booten auf dem ROOTFS fort.
Diese verschiedenen Schritte bildeten den sicheren Bootvorgang für imx8:
Der neugierige Leser kann mehr Dokumentation über die HAB-Implementierung im Internet finden. Dieser zweite Teil des Artikels sollte nicht die gesamten HAB-Details erklären, sondern nur die Beziehung zwischen Secure Boot und der Hardware aufzeigen.
Stellen Sie Ihre Fragen und finden Sie Lösungen für Ihre Produktentwicklung
Kontakt
Dieser Artikel beschreibt Indianas Werdegang bei T&S und hebt die Investitionen des Unternehmens in die Mitarbeiterentwicklung und interne Mobilitätsmöglichkeiten hervor. Erfahren Sie, wie Indiana ihre Fähigkeiten nutzte, um sich von der Verwaltungsassistentin zum HR Business Partner & Team Leader zu entwickeln.
READ MORE
Entdecken Sie Sophies bemerkenswerte Reise durch die Reihen von T&S , von einem 6-monatigen Praktikum bis zu einer Festanstellung in der Abteilung Employee Experience. Erfahren Sie mehr über ihr Durchhaltevermögen, ihre Anpassungsfähigkeit und wie sie Hindernisse überwunden hat, um beruflich erfolgreich zu sein.
READ MORE
Reduzieren Sie Ihre Auswirkungen! ♻️ Erfahren Sie, wie die Erstellung von CO2-Fußabdrücken Unternehmen bei der Bekämpfung des Klimawandels hilft.
READ MORE
