Medical Grade Bootloader für ARM Mikrokontroller (UPDATE), Winterthur

Medical Grade Bootloader für ARM Mikrokontroller (UPDATE)

Mehr als sechs Monate sind bereits seit der Veröffentlichung unseres ersten Blogbeitrags zum Thema Bootloader vergangen. Seither hat sich einiges getan.

So durften wir die Konzepte und unsere Lösungsansätze an der Embedded Computing Conference (ECC) in Winterthur in einem Gastvortrag vorstellen.

In einemübervollen Vorlesungssaal zeigte sich, dass das Thema Bootloader die Industrie, beziehungsweise die Entwickler, noch immer vor grosse Herausforderungen stellt. Neben der Vorstellung unserer medical grade Bootloader Lösung an der ECC, wurde auch

substanziell an dessen Funktionsumfang gearbeitet . So wurde beispielsweise die

Umstellung von ARM-Keil zu GCC und CMake

erfolgreich umgesetzt. Neu kann jetzt ein Generator zum

Erstellen der RPC-Befehle

genutzt werden, der den Aufwand für die Implementation von neuen Kommandos massiv reduziert. Die wohl interessanteste Änderung ist jedoch die Möglichkeit,

Update Files zu verschlüsseln und die Firmware vor dem Booten kryptographisch zu verifizieren. Der CSA Bootloader erfüllt nachfolgende Anforderungen (neue Anforderungen in fett): Installation der Firmware während der Produktion Update der Firmware und des Bootloaders im Feld (In-Application Programming)Resistenz gegen Fehler sowie Verhinderung des Unbrauchbarwerdens oder zumindest Sicherstellung der Wiederherstellbarkeit des Geräts bei fehlgeschlagenen Updates (z.B. bei Stromausfall) Resistenz gegenüber Angriffen Begrenzung des Schadens eines erfolgreichen Angriffs (z.B. Auslesen von Schlüsseln aus dem Mikrokontroller)Integritäts- und Authentizitätsprüfung der Firmware beim Start Schutz des Gerätes gegen die Installation von unautorisierter Firmware Schutz gegen die Installation der Firmware auf unautorisierten Geräten Schutz gegen Modifikation der Firmware oder des Firmware-Updates Schutz gegen Reverse-Engineering der Firmware oder des Firmware-UpdatesProduction Keys– Sicherstellen, dass Geräte oder Komponenten, welche z.B. auf dem Weg vom Elektronikhersteller zur Montagefirma "vom Laster fallen", nicht verwendet werden können Automatisiertes Builden und Testen des Bootloaders respektive der Applikationsfirmware Optional (wenn gewünscht):Downgrade Prävention: Verhindern der Installation von älteren Firmware-Versionen Gerätespezifische Firmware: Die Firmware ist an die Hardware eines Geräts gebunden (z.B. via Unique Identifier des Mikrokontrollers) Nachfolgend werden die neu integrierten Anforderungen etwas genauer beschrieben.Asymmetrische Kryptographie

Durch die Verwendung von asymmetrischer Kryptographie für die Ver- und Entschlüsselung der Firmware sowie Generierung und Verifikation der digitalen Signaturen können Schlüssel, welche von einem Angreifer aus einem Gerät extrahiert wurden, nicht direkt für weitere Angriffe auf andere Geräte oder das Gesamtsystem verwendet werden. Ein Schlüssel,der z.B. für die Verifikation einer Signatur im Speicher des Gerätes liegt, kann nicht zur Generierung von gültigen Signaturen verwendet werden.In der aktuellen Version werden die Update Files verschlüsselt.

Die für die asymmetrische Verschlüsselung benötigten Metadaten werden im Header des Firmware Update Files (FUF) respektive im Bootloader Update File (BUF) hinterlegt und kryptographisch signiert.

Die Signatur dient zur Feststellung von böswilliger oder ungewollter Veränderung des Headers.

Mit den Metadaten wird das eigentliche, in einzelne Blöcke aufgeteilte Firmware/Bootloader Update blockweise verschlüsselt. Das BUF/FUF File kann so an aussenstehende Personen verteilt werden, ohne dass sie Zugriff auf das eigentliche Binary-File erhalten. Abbildung 1: Firmware Update File StrukturMit Hilfe des RPC Tools können die zuvor beschriebenen FUF/BUF Files auf das Zielgerät übertragen werden.

Dabei erfolgt zuerst der Upload des FUF/BUF Headers, um das Update und die damit verbundene Entschlüsselung zu initialisieren. Block um Block werden im Anschluss an das Zielgerät gesendet und dort mit Hilfe der Metadaten des Headers entschlüsselt. Aufgrund der limitierten Arbeitsspeichergrösse werden die einzelnen Blöcke direkt an ihre entsprechende Stelle im Flash-Speicher geschrieben.Abbildung 2: Bootloader Update File Struktur Ein weiteres Sicherheitselement ist die Verifizierung der Firmware mittels kryptographischer Signatur.

Die Signatur wird bei jedem Boot-Vorgangüber die Header Fields (exkl. Versions- und Signatur Feld), den Keystore und die eigentliche Firmware gerechnet. Die errechnete Signatur muss mit der im Header hinterlegten Signatur übereinstimmen, damit der Boot-Vorgang fortgesetzt wird. Abbildung 3: Firmware VerifizierungUmstellung von ARM Keil zu GCC und CMake

Damit der Bootloader mit der Embedded Toolchain kompiliert und in unser CSA BuildingBlocks Framework integriert werden kann, wird neu CMake/Ninja und GCC eingesetzt.

Bootloader Images und Updates können nun automatisiert in der Pipeline auf einem Build-Server erstellt werden. Die Verwendung von CMake bietet zusätzlich den Vorteil, dass auch andere Kompiler unterstütz werden. Der neu entwickelte Code Generator stellt sicher, dass der (Kommunikations-) Code auf Mikrocontroller- und Host-Seite synchron ist.

Ein weiterer Gewinn ist die einfachere Erweiterbarkeit von Bootloader und vor allem auch der applikationsspezifischen Firmware um weitere RPC Kommandos. Der Code Generator unterstützt in der aktuellen Version auf der Mikrocontroller Seite C und auf Host Seite C++ und Python. Der Generator kann ebenfalls dafür verwendet werden, automatisierte (Integrations-) Tests zu unterstützen indem spezifische Test-Kommandos generiert werden kann.Wir setzen den Bootloader in unseren internen Projekten ein. Dabei werden neue Prozessoren aus der STM32 Familie unterstützt.

Mit der eingebauten Verschlüsselung ist der Bootloader nun bereit in Ihr (MedTech-) Projekt eingebaut zu werden!

#J-18808-Ljbffr