Secure Boot für Mikrocontroller

Signieren der Software im Produktions-Prozess

Prüfen der Signatur beim Starten der Software

Durch eine erfolgreiche Verifikation kann die Urheberschaft geprüft und die Integrität der Software garantiert werden. Gebräuchliche Signaturverfahren sind:

• SHA-256 Hash-Algorithmus (Secure Hash Algorithm) kombiniert mit RSA Verschlüsselung (Rivest–Shamir–Adleman, Primfaktorzerlegung)
• SHA-256 Hash-Algorithmus kombiniert mit ECC Verschlüsselung (Elliptic Curve Cryptography, elliptische Kurven)
• DSA (Digital Signature Algorithm, diskreter Logarithmus)
• ECDSA (Elliptic Curve Digital Signature Algorithm, elliptische Kurven)

Die technische Umsetzung der Vertrauensprüfung und welche weiteren Funktionen noch geboten werden (z.B. widerrufbare Signierschlüssel (Revocable Signing Keys), Schutz vor Installation einer alten Software (Software Downgrade/ Anti-Rollback)), ist abhängig vom jeweiligen Mikrocontroller Hersteller.

Wann brauche ich Secure Boot?

Wieso ist Secure Boot für Sie wichtig? Als Hersteller müssen oder möchten Sie sicherstellen, dass das Gerät, das macht, wofür es entworfen und getestet wurde. Gründe dafür sind: regulatorische Anforderungen einhalten (z.B. IEC 62443, EU Cybersecurity Act etc.), Garantieansprüche abwenden (z.B. Sicherstellen der korrekten Funktion, Gewährleisten der Datenintegrität etc.) oder Reputationsschäden verhindern (z.B. dadurch, dass die Geräte Teil eines Bot-Netzes werden.

Was braucht es für Secure Boot?

Sicherer Speicher

Der Mikrocontroller muss verschiedene Funktionen bieten, damit Secure Boot möglich ist. Als erstes muss im Mikrocontroller ein sicherer Speicher vorhanden sein. In diesem sicheren Speicher werden alle Schlüssel-Informationen abgelegt, welche zur Prüfung der Software-Signatur benötigt werden. Abhängig von der Implementation muss der sichere Speicher nur schreibgeschützt oder lese- und schreibgeschützt sein.

Wichtig ist, dass sich der sichere Speicher innerhalb des Mikrocontrollers befindet, und nicht als externer Baustein/ IC hinzugefügt wird, z.B. als Secure Element (SE), Trusted Platform Module (TPM) oder Secure Storage. Dies ist deshalb wichtig, weil die Authentizität der SE oder TPM Bausteine nicht gewährleistet werden kann (z.B. könnten die Bausteine auf dem PCB ausgetauscht werden). Dies bedeutet nicht, dass SE und TPM Schaltungen unsicher sind, es bedeutet nur, dass Secure Boot benötigt wird, um diese Bausteine sicher betreiben zu können.

Sicherer Bootloader

Als zweites muss der Mikrocontroller einen unveränderlichen Bootloader haben, welcher die Signatur der Software prüft, bevor er die Kontrolle an diese übergibt. Dieser Bootloader wird oft ROM-Bootloader genannt, da er sich in einem schreibgeschützten Bereich des permanenten Speichers (Flash) befindet.

Diese beiden Funktionen zusammen, sicherer Schlüssel-Speicher und sicherer Bootloader, bilden den Root of Trust (RoT), also die Wurzel der Sicherheit. Manchmal wird RoT auch Hardware Trust Anchor genannt.

Was braucht es noch?

Nichts! Nichts? Die Secure Boot Funktion stellt den Startpunkt für den Bau eines sicheren Gerätes dar. Für ein komplettes und sicheres System braucht es aber noch mehr.

Braucht es einen zusätzlichen Bootloader?

Möchte man seine Software aktualisieren können, z.B. über das Netzwerk oder Over-the-Air (OTA), dann benötigt man normalerweise einen weiteren Bootloader (2^nd Stage Bootloader), z.B. u-boot für Linux-Systeme oder MCU Boot für Mikrocontroller.

Auch muss die Integrität von weiteren Boot-Daten, wie z. B. ein Linux Device Tree und/ oder ein Linux Root-Filesystem, geprüft werden. Bei einem System mit dem u-boot erfolgt diese Prüfung durch den u-boot Bootloader, bevor er die Kontrolle an den Linux-Kernel übergibt. Somit entsteht eine vertrauenswürdige Kette (Chain of Trust), bei der jede Software die nachfolgende Software prüft, bevor die Kontrolle an diese übergeben wird. Am Schluss einer solchen Kette steht dann die Gewissheit, dass nur die vorgesehene und unveränderte Software ausgeführt wird.

Secure Boot Kette

Kann Secure Boot umgangen werden?

Der Secure Boot Prozess darf nicht kompromittiert werden, indem es andere Wege gibt, eine ungeprüfte Software zu starten. Z.B. müssen sämtliche Debug-Schnittstellen (JTAG, SWD...) deaktiviert werden oder, falls dies der Mikrocontroller unterstützt, durch Verschlüsselung geschützt werden.

Weiter muss der ROM-Bootloader so konfiguriert sein, dass er nur signierte Software aus den vorgesehenen Quellen ausführt, und nicht alle möglichen Quellen nach einer Software absucht und diese dann ungeprüft startet.

Welche organisatorischen Massnahmen sind nötig?

Die Erstellung und Anwendung des Schlüsselmaterials für die Signierung benötigen eine besondere Aufmerksamkeit. Wo wird das Schlüsselmaterial zum Signieren gespeichert (z.B. Hardware-Sicherheitsmodul (HSM))? Wer hat Zugriff auf das Schlüsselmaterial (z.B. Prozesse, Vier-Augen-Prinzip)? Wie kommen die (vorgesehenen) Schlüssel in den Mikrocontroller?

Das alles sind heikle Punkte, welche Ihre Organisation und Ihre Hardware- Hersteller betreffen. Die Sicherheit hängt davon ab, dass nur gültige Signier-Schlüssel auf dem Mikrocontroller gespeichert sind und dass nur berechtigte Personen eine signierte Software erstellen können.

Was sind die Erkenntnisse?

Sicherheit kann nicht nachträglich hinzugefügt werden. Ohne die richtige Wahl beim Mikrocontroller kann kein sicheres Gerät gebaut werden. Auch sind Funktionen wie Gerätebereitstellung über das Internet (IoT Device Provisioning) oder sichere Speicherung von Daten (Secure Storage) ohne Secure Boot nicht möglich.

Beginnen Sie jetzt, sich mit dem Thema Security zu befassen. Genügen Sie den heutigen und kommenden Gesetzen und Vorschriften und vor allem: behalten Sie ihren guten Ruf auch in der Zukunft. Wir unterstützen Sie gerne dabei!

Alois Cavelti

Haben Sie zusätzliche Fragen? Haben Sie eine andere Meinung? Wenn ja, mailen Sie mir oder kommentieren Sie Ihre Gedanken unten!