Security ist essenziell

Nicht nur die klassische IT ist von Cyberkriminalität betroffen, auch zunehmend Embedded-Systeme – selbst vor den kleinsten Baugruppen wird nicht Halt gemacht. So zielte bereits der Mirai-Wurm speziell auf IoT-Geräte wie Router, Überwachungskameras, Smart-TVs und andere smarte Geräte ab, um Distributed-Denial-of-Service-Attacken durchführen zu lassen. Es müssen also keine wichtigen Daten in den Embedded-Systemen gespeichert oder ein Schaden für eine Produktionsanlage anrichtbar sein, um für Cyberkriminelle ein Ziel zu werden. Security muss deshalb schon zu Beginn einer jeden Embedded-Entwicklung mit im Fokus stehen und eine lückenlose Sicherheitskette bilden. Das gilt auch für den Betrieb einer Embedded-Baugruppe, also mit dem Anlegen der Betriebsspannung und dem sich anschließenden Boot-Vorgang. Dieser lässt sich mit Secure Boot absichern.

Secure Boot ist eine Methode, um ein System durch modernste Kryptografie gegen Manipulationen des Boot-Vorgangs abzusichern. Secure Boot bezeichnet somit das sichere Laden der Boot-Firmware (Boot Loader) durch den ROM-Loader (fixer Code, zuerst ausgeführt). Diese Firmware (zum Beispiel TF-A, U-Boot, ELE-Firmware und andere) wird durch ein asymmetrisches Signaturverfahren signiert. Der Begriff Secure Boot umfasst im Kontext dieses Dokuments ausschließlich die Chain-of-Trust vom Boot-ROM bis zum Laden des bei TQ-Modulen genutzten Bootloaders U-Boot.

Der öffentliche Schlüssel des asymmetrischen Verfahrens ist auf dem Gerät abgelegt und ermöglicht die Verifikation der Signatur der Firmware. Die Signierung der Firmware erfolgt mit dem privaten Schlüssel des Geräteherstellers. Secure Boot verhindert damit, dass Firmware auf dem Gerät ausgeführt wird, die nicht vom Hersteller signiert wurde. Es kann auch dazu verwendet werden, um vor dem Klonen von Images zu schützen und so den Nachbau von Geräten zu verhindern.

Voraussetzungen für Secure Boot

Um Secure Boot nutzen zu können, benötigen Gerätehersteller eine grundlegende Public-Key-Infrastruktur (PKI), mit der sich die erforderlichen Zertifikate und Schlüssel verwalten lassen. Dabei muss es sich nicht um eine umfassende PKI-Verwaltungslösung handeln. Es ist jedoch unerlässlich, dass dies professionell mit geeigneten, produktionsreifen Tools erfolgt. Der SoC-Hersteller NXP liefert die notwendigen Komponenten einer PKI gebündelt in dem kompakten Werkzeug Code Signing Tool (CST). Alternativ können Kunden auch ihre eigenen Tools verwenden, um eine PKI einzurichten.

Absicherung des Geräts

Nachdem die Infrastruktur für den Einsatz von Secure Boot vorbereitet wurde, kann das Gerät abgesichert werden. Dazu schreibt der Gerätehersteller den geforderten Hash des öffentlichen Schlüssels (erzeugt von der vorher aufgesetzten PKI) in den dafür vorgesehenen nonvolatilen Speicherbereich des SoC. Über weitere Befehle lässt sich das Gerät dann abschließen, was bedeutet, dass die Boot-, Security- und Lock-Fuses geschrieben sind, und daher ist ab sofort nur noch das Booten von Firmware möglich, deren Signatur zum im Gerät hinterlegten öffentlichen Schlüssel passt. Werden diese Geräte ins Feld gebracht, hindert Secure Boot den Gerätenutzer daran, Firmware zu laden, die nicht vom Gerätehersteller signiert wurde.

TQ ermöglicht das Erzeugen signierter Images mit dem Yocto-BSP. Kunden müssen hier lediglich wenige Konfigurationsoptionen anpassen und das Schlüsselmanagement entsprechend vorbereiten. Die Integration der Signatur in das BSP soll einen schnellen Zugriff auf den Secure-Boot-Mechanismus ermöglichen, beispielsweise für Prototypen oder Machbarkeitsstudien. Bei der Produktion sind jedoch Aspekte wie „Wer hat Zugriff?“, „Wo werden die Schlüssel gespeichert?“ und „Wer kann Images signieren?“ zu berücksichtigen. In Zusammenarbeit mit dem Kunden kann TQ die Geräte direkt bei der Fertigung absichern. Dadurch ist ab Produktion sichergestellt, dass ausschließlich signierte Firmware auf das Gerät geladen wird. Dokumentation zum Secure-Boot-Feature ist in den Readme-Dateien des TQ-BSP enthalten.

Auf die Boot-Firmware folgt im Boot-Prozess typischerweise der Linux-Kernel zusammen mit einem Device Tree. Im weiteren Verlauf bindet der Kernel das Root-Dateisystem ein, in dem die Daten und Applikationen des Kunden enthalten sind. Diese drei Komponenten, Kernel, Device Tree und Root-Dateisystem, müssen zusätzlich verifiziert werden, um die Integrität des Systems bis hin zur Kundenapplikation zu gewährleisten.

Managed Hardware: Neue Sicherheitsdimensionen mit dem TQMa95xx

Das Thema Sicherheit (Safety & Security!) wird mit dem TQMa95xx (Bild 1) auf ein neues Niveau gehoben. Auf Basis der Applikationsprozessor-Familie NXP i.MX95 ist für das Modul das Konzept der Managed Hardware realisierbar: Die einzelnen Cores des i.MX95 sind getrennt und voneinander isoliert, sie können sich aber über den System Manager (SM) Ressourcen wie Sensoren, RTC und Ähnliches kontrolliert teilen. Das Arm System Control und Management Interface (SCMI) liefert dazu ein standardisiertes Protokoll und hat in den Linux Mainline Support Einzug gehalten. Ebenfalls Open Source ist der SM-Code, der eine BSD-Lizenz hat und damit auch für geschlossene Applikationen nutzbar ist.

Die unabhängigen Logical Machines (LM) ermöglichen es, eine bedarfsgerechte Trennung und Isolation der Software zu realisieren. So lässt sich beispielsweise auf dem Cortex-M7-Core ein RTOS installieren, um den Ansprüchen an die Functional Safety (FuSa) zu genügen. Als eigenständige LM kann sie ein Echtzeit-Betriebssystem (RTOS) nutzen, um die notwendigen Reaktionszeiten einhalten zu können – unabhängig von den anderen Cores und Betriebssystemen, die auf dem TQMa95xx laufen. Die leistungsfähigen Cortex-A55-Cores können jeweils ihre eigenen Betriebssysteme haben, getrennt durch einen Hypervisor oder bei besonderen Security-Anforderungen isoliert mittels Trusted Firmware und Trusted OS. Hypervisors können zudem virtuelle Maschinen (VM) einrichten und so eine weitere Trennung durchführen. Der Cortex-M33-Core ist dabei der System Manager.

NXP hat den i.MX 95 darüber hinaus mit einer speziellen Sicherheitseinheit namens „EdgeLock Secure Enclave“ ausgestattet. Diese ist physisch vom Rest des SoC isoliert und verfügt über einen eigenen CPU-Kern sowie einen eigenen Speicher. Sie schützt die Integrität des SoC, verhindert den direkten Zugriff von Anwendungskernen auf sensible Daten und bietet eine verbesserte Isolierung für die Ausführung kritischer und sensibler Sicherheitsfunktionen. Außerdem bietet sie einen zusätzlichen Schutz, der über den Schutz durch standardmäßige Trusted Execution Environments (TEEs) hinausgeht. In Kombination mit den EdgeLock-2GO-Schlüssel-Verwaltungsdiensten von NXP können Hersteller Produkte auf Basis des i.MX 95 sicher bereitstellen, um vor Ort eingesetzte Geräte fernzuverwalten, einschließlich sicherer Over-the-Air-Updates (OTA).

TQ integriert optional das NXP Secure Element SE050/51 als Root of Trust, das die Speicherung und Bereitstellung von Zugangsdaten sowie die Durchführung von kryptografischen Operationen für sicherheitskritische Kommunikations- und Steuerungsfunktionen ermöglicht. Er ist vielseitig einsetzbar in IoT-Sicherheitsanwendungen wie der Verbindung zu öffentlichen/privaten Clouds, Device-to-Device-Authentifizierung oder Schutz von Sensordaten. Wie bei allen Sicherheitsmaßnahmen ist ein Co-Design von Hard- und Software gefordert, um eine lückenlose Sicherheitskette zu gewährleisten. Dank der mit dem TQMa95xx geleisteten Vorarbeit lässt sich die Geräteentwicklung deutlich beschleunigen.

Chain-of-Trust: Vom ROM-Loader zur Applikation

Bis zum vollständig verifizierten Linux-System sind zwei weitere Verifikationsschritte notwendig. Die Boot-Firmware, die den Linux-Kernel inklusive eines Device Trees vom Boot-Medium lädt, kann diese auch verifizieren. Der Kernel, der Device Tree und das InitRAMFS müssen dazu in einem FIT-Image kombiniert werden. Das resultierende Image wird daraufhin ebenfalls mit einem privaten Schlüssel signiert. Um die Signatur des FIT-Images zu verifizieren, muss der dazu passende öffentliche Schlüssel vorher in der Boot-Firmware hinterlegt werden. Dies zeigt, dass die Integrität des Systems nur gewährleistet ist, wenn jedes Glied der Chain-of-Trust intakt ist. Ohne Secure Boot kann die Boot-Firmware zusammen mit den öffentlichen Schlüsseln so ausgetauscht werden, dass ein beliebiges, passendes FIT-Image verifiziert wird – ohne Verifikation der Boot-Firmware ist die Verifikation des FIT-Image also wertlos!

Der zweite Schritt ist die Verifikation des Dateisystems, in dem alle notwendigen Anwendungen enthalten sind. Der Linux-Kernel bietet verschiedene Möglichkeiten an, um dies zu realisieren. Die einfachste Variante ist dm-verity. Bei dm-verity wird das Dateisystem in Blöcke unterteilt und für jeden Block ein Hash-Wert berechnet. Sobald sich Daten in diesem Block ändern, ändert sich auch dessen Hash.

Durch eine Kaskade von Hashes wird ein einzelner Root-Hash berechnet, der sich ändert, sobald sich Daten in nur einem Block ändern. Soll ein mit dm-verity gesichertes Dateisystem geöffnet werden, berechnet das Verity-Tool den Root-Hash dieses Dateisystems und vergleicht ihn mit dem übergebenen Root-Hash. Sind beide Hashes identisch, so ist das Dateisystem seit der Erzeugung des Root-Hashes unverändert, andernfalls gab es Änderungen.

dm-verity gewährleistet die Offline-Integrität eines Dateisystems, das heißt, der Nutzer kann prüfen, ob das Dateisystem manipuliert wurde, während es inaktiv war. Potenziell anfällig für diese Art der Manipulation sind alle Geräte, auf die unautorisierte Personen ausreichend Zugriffszeit haben – zum Beispiel externe Festplatten, Laptops, Smartphones, aber auch eingebettete Systeme im Feld. Im konkreten Anwendungsfall eines per dm-verity gesicherten Root-Dateisystems prüft der Linux-Kernel die Integrität des Root-Dateisystems beim Booten gegen den in der Kernel-Kommandozeile übergebenen Root-Hash. Damit die Integritätsprüfung wirkungsvoll ist, muss der Kernel inklusive Kommandozeilen-Parameter selbst integer sein, und dm-verity muss auch an die Chain-of-Trust angeschlossen sein.

Der wichtigste Punkt, den Kunden bei der Nutzung von dm-verity beachten müssen, ist, dass auf ein mit dm-verity gesichertes Dateisystem im Online-Betrieb nur lesend zugegriffen werden kann. Muss etwas am Dateisystem geändert werden (Update), so ist auch ein neues signiertes FIT-Image mit aktualisiertem Root-Hash notwendig.

Es gibt weitere Mechanismen, die Dateisysteme absichern und diese dabei zur Laufzeit schreibbar halten. So ist dm-crypt ebenfalls eine Funktion des Linux-Kernels, ermöglicht aber zusätzlich zur Integrität auch Vertraulichkeit der Daten durch deren Verschlüsselung. Das entschlüsselte Dateisystem ist zur Laufzeit les- und schreibbar.

Im Vergleich zu dm-verity benötigt dm-crypt für die Ver- und Entschlüsselung mehr Rechenleistung, dazu kommt der logistische Aufwand zur Verwaltung des Schlüssels (TPM oder Passphrase beim Entschlüsseln). Der Verwaltungsaufwand steigert sich nochmals, sobald eine Flotte von Geräten ins Feld kommt, da jedes einzelne Gerät einen einzigartigen Schlüssel besitzen sollte.

Fazit

Secure Boot ist, wenn es richtig konfiguriert ist, die Grundlage für die Bereitstellung einer Chain-of-Trust und eine Voraussetzung für die Systemsicherheit. TQ-Module bieten die Hardware, leistungsstarke kryptografische Algorithmen und eine Support-Infrastruktur, die zur Unterstützung des sicheren Bootens erforderlich sind, so dass Entwickler Systeme entwickeln können, die ihre gewünschten Sicherheitsziele erfüllen.