Technik
Secure Boot mit GELin - Vertrausenwürdiger Systemstart für Embedded Systems
Mit steigender Vernetzung bzw wachsender Softwarekomplexität nimmt die Angriffsfläche bei Embedded Systems zu.
Mit steigender Vernetzung und wachsender Softwarekomplexität von Embedded Systemen nimmt auch die Angriffsfläche deutlich zu. Ein zentrales Sicherheitsziel moderner Embedded-Linux-Plattformen ist es daher sicherzustellen, dass ausschließlich geprüfte, freigegebene und unveränderte Software ausgeführt wird. Secure Boot bildet hierfür die Grundlage. GELin, die Ginzinger Embedded Linux Distribution, implementiert einen durchgängigen Secure-Boot-Ansatz, der vom ersten Instruktionszyklus der Hardware bis zum laufenden Root-Dateisystem reicht.
Kryptografische Grundlagen
Secure Boot basiert auf etablierten kryptografischen Verfahren zur Sicherstellung von Authentizität und Integrität.
Symmetrische Kryptografie
Bei symmetrischen Verfahren wird derselbe Schlüssel zum Ver- und Entschlüsseln verwendet.
- Advanced Encryption Standard (AES)
- Hohe Performance, geringer Rechenaufwand
- Typischer Einsatz: Verschlüsselung von Daten (z. B. Dateisysteme, Speicher)
Symmetrische Verfahren eignen sich jedoch nicht für Vertrauensprüfungen in offenen Systemen, da der Schlüssel geheim bleiben muss.
Asymmetrische Kryptografie
Asymmetrische Verfahren arbeiten mit Schlüsselpaaren:
- Privater Schlüssel: zum Signieren
- Öffentlicher Schlüssel: zur Verifikation
Eingesetzte Verfahren sind RSA (Rivest-Shamir-Adleman) und ECC (Elliptische Kurvenkryptografie). Asymmetrische Kryptografie ist die Grundlage für Secure Boot, da nur der öffentliche Schlüssel im Zielsystem hinterlegt werden muss.
Chain of Trust - Die Vertrauenskette
Das Secure-Boot-Konzept von GELin basiert auf einer mehrstufigen Chain of Trust. Ziel ist es, jede Softwarekomponente durch die vorherige kryptografisch zu verifizieren und so eine durchgängige Vertrauensbasis aufzubauen.
Prinzip
- Mehrere aufeinanderfolgende Bootstufen
Jede Stufe enthält den öffentlichen Schlüssel der nächsten Stufe und validiert deren digtale Signatur. - Alle Software-Komponenten innerhalb der Chain of Trust werden durch den Kunden signiert
- Die Signierung erfolgt jeweils mit dem zugehörigen privaten Schlüssel
Damit wird die Kundschaft selbst zu einem aktiven Teil des Sicherheitskonzepts. Die Verwaltung, Absicherung und Geheimhaltung der privaten Schlüssel liegt vollständig in seiner Verantwortung. Ein kompromittierter privater Schlüssel untergräbt die gesamte Vertrauenskette.
Vorteile
- Einzelne Stufen können unabhängig aktualisiert werden
- Klare Sicherheitsgrenzen zwischen Bootphasen
- Hohe Flexibilität bei gleichzeitig hoher Sicherheit
Startpunkt
- BootROM des SoC
- Enthält einen fest eingebrannten (fused) öffentlichen Schlüssel
- Bildet den unveränderlichen Root of Trust
Secure Boot Chain in GELin
Für NXP i.MX Prozessoren nutzt GELin den integrierten Sicherheitsmechanismus:
- High Assurance Boot (HAB), der signierte Bootloader-Komponenten verifiziert
- Code Signing Tool (CST) zur Signierung der Bootloader-Konfiguration und einzelner Bootloader-Bestandteile
Manipulierte oder unsignierte Bootloader werden vom SoC nicht ausgeführt.
U-Boot: Signierte Images mit FIT
Als sekundärer Bootloader kommt U-Boot zum Einsatz.
- Verwendung von FIT Images (Flattened Image Tree)
- FIT-Image als Container für:
- Linux Kernel
- Device Tree
- initRAM-FS
- Konfigurationen
Alle Bestandteile können individuell signiert werden. U-Boot lädt ausschließlich Images, deren Signatur erfolgreich geprüft wurde.
Linux Kernel: Verifikation und Root-Dateisystem
dm-verity - Ist im Kernel fest einkompiliert.
- Integritätsprüfung blockweise über einen Hash-Baum
- Root-Hash ist signiert und vertrauenswürdig
- Jeder gelesene Block wird beim Zugriff überprüft
Der öffentliche Schlüssel zur Verifikation wird dem Kernel über CONFIG_SYSTEM_TRUSTED_KEYS hinzugefügt.
Root-Dateisystem
- Das RootFS wird ausschließlich im verifizierten Zustand gemountet
- Initiale Verarbeitung erfolgt in einer RAM-Disk
- Änderungen am Dateisystem führen zu Mount-Fehlern
Damit wird sichergestellt, dass das System ausschließlich mit einem unveränderten Root-Dateisystem läuft.
Secure Updates mit GELin
Auch Software-Updates sind Teil der Sicherheitskette.
- ge-update basiert ebenfalls auf einem Dateisystem
- Es werden nur signierte Update-Images akzeptiert
- Verifikation erfolgt vor der Installation
So wird verhindert, dass manipulierte oder nicht autorisierte Updates eingespielt werden.
Zusätzliche, sicherheitsrelevante Maßnahmen
Kontrolle der Bootchain
Um Umgehungsangriffe zu vermeiden, sind weitere Maßnahmen notwendig:
- Keine interaktive Bootloader-Befehlszeile
- Bootloader-Umgebungsvariablen fest in das Image kompiliert
- Kernel-Parameter können nicht zur Laufzeit verändert werden
Absicherung der Hardware
- Blockieren von JTAG- und Debug-Schnittstellen
- Schutz vor physischem Zugriff auf sicherheitskritische Komponenten
Lizenzierung und Compliance
- Beachtung der GPLv3
- Vermeidung von Tivoisation
- Nutzer müssen prinzipiell eigene Software installieren können
- Sicherheit darf nicht zur unzulässigen Einschränkung führen
Einschränkungen und operative Auswirkungen von Secure Boot
Der Einsatz von Secure Boot führt zwangsläufig zu Einschränkungen im Systembetrieb:
- Private-Key-Handling
- Sichere Erzeugung, Speicherung und Zugriffskontrolle erforderlich
- Verlust oder Kompromittierung des Schlüssels kann Geräte unbrauchbar machen
- Eingeschränkte Debug- und Analysefähigkeit
- Gesicherte Systeme sind weitgehend geschlossen
- Fehleranalyse und Untersuchungen im Reparaturfall werden deutlich aufwendiger
- Erhöhter Aufwand bei Entwicklung und Wartung
- Strikte Prozesse für Signierung und Release
- Klare Trennung von Entwicklungs-, Test- und Produktionsschlüsseln notwendig
Secure Boot erhöht somit nicht nur die Sicherheit, sondern auch die Komplexität im Lebenszyklus eines Produkts. Sicherheit ist wirksam – aber selten bequem.
Secure Boot als Teil eines ganzheitlichen Security-Konzepts
Secure Boot wird häufig als alleinige Sicherheitsmaßnahme betrachtet. In der Praxis ist es jedoch nur ein Baustein eines umfassenden Security-Konzepts. Die Entscheidung für Secure Boot sollte daher stets aus einem übergeordneten Sicherheitskonzept heraus getroffen werden, das unter anderem folgende Aspekte berücksichtigt:
- Bedrohungsanalyse und Angriffsmodelle
- Schutz vor physischem Zugriff
- Schlüsselmanagement und organisatorische Prozesse
- Update-Strategien
- Wartung, Reparatur und Debugging im Feld
Der Einsatz von Secure Boot erhöht die Sicherheit signifikant, bringt jedoch auch konzeptionelle und organisatorische Konsequenzen mit sich.
Secure Boot mit GELin realisiert eine durchgängige, hardwaregestützte Sicherheitsarchitektur für Embedded Linux Systeme. Von der ersten Instruktion im SoC über Bootloader, Kernel und Root-Dateisystem bis hin zu Software-Updates wird jede Komponente kryptografisch geprüft.
Gleichzeitig erfordert der Einsatz von Secure Boot ein bewusstes Sicherheitskonzept, klare Prozesse und die Bereitschaft, die damit verbundenen Einschränkungen zu akzeptieren. Richtig eingesetzt ist Secure Boot ein wirkungsvolles Werkzeug – kein Allheilmittel, sondern ein zentraler Baustein moderner Embedded-Security-Strategien.