Medical Grade Bootloader für ARM Mikrokontroller
Firmware-Updates im Feld sind eine Herausforderung für Produkte, insbesondere für Medizingeräte. Durch den Einsatz unseres CSA Bootloaders kann in einem Embedded Projekt viel Entwicklungszeit gespart und damit ein Mehrwert im Bereich von sicheren (Remote-) Updates im Feld geschaffen werden.
Der CSA Bootloader implementiert die Funktionalität für die Installation, die Aktualisierung sowie den Schutz der Firmware gegen Veränderung und Reverse Engineering. Mit entsprechend konzipierter Hardware lässt sich somit das Risiko für Patienten durch alterungs-, umweltbedingter sowie böswilliger Modifikation der Firmware eines Medizingerätes minimieren. Der Bootloader wird vorrangig in Systemen eingesetzt, welche aus einem Host-Rechner (PC) und einem oder mehreren Mikrokontrollern bestehen. Der Bootloader und die jeweilige Applikationsfirmware implementieren eine proprietäre RPC-Schnittstelle, über welche sie von einer Applikationssoftware auf dem Host-Rechner gesteuert werden können.
Folgende Anforderungen erfüllt der CSA Bootloader (die technischen Details finden Sie im nächsten Kapitel):
- 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)
Optional:
- Downgrade Prevention: 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)
In Entwicklung:
- 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-Updates
- Production 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
Weitere Details finden Sie im Kapitel Asymmetrische Kryptographie.
Der Bootloader wird mit ARM Compiler Version 5 gebaut. Die Umstellung zu GCC ist in Planung und wurde im Rahmen des CSA Boostcamp 2022 initialisiert. Weiter wurde im Boostcamp auch die Grundlage für eine automatische Generierung des Codes für die RPC-Kommandos aus übersichtlichen JSON-Dateien gelegt.
Die CSA bietet eine fertige, lizenzierbare Bootloader-Lösung sowie kundenspezifische Anpassungen und Entwicklungen als Dienstleistung an. Der Bootloader wurde gemäss der Norm IEC 62304 entwickelt, dokumentiert und verifiziert.
Für die Integration in ein Kundenprodukt werden die Integrationspläne und Protokolle mitgeliefert, die durch den Kunden oder die CSA an das jeweilige Produkt adaptiert werden. Gerne demonstrieren wir Ihnen den gesamten Funktionsumfang des Bootloaders. Bei Interesse wenden Sie sich an unseren Verkauf, der ein Treffen mit einem Experten vereinbart.
Nachfolgend finden Sie weitere spannende Details zur Implementation, den Hardwareanforderungen und Informationen zum Aufbau der Kommunikation.
Abbildung 1: Übersicht STM32L4 Regionen im Flash
Technische Details
Aktuell werden die STM32F4 und STM32L4 Familie (Cortex-M4, ARMv7e-M) von STMicroelectronics unterstützt. Bei Bedarf kann der Support auf weitere Mikrokontroller Familien desselben Herstellers ohne grösseren Aufwand ausgeweitet werden.
Hardware-Anforderungen
On-Chip Flash-Memory: Es werden vier unabhängige Regionen im Flash-Speicher benötigt. Die Regionen müssen unabhängig voneinander lösch- und beschreibbar sein und genügend Platz für die Bootloader-Komponenten und Applikationsfirmware bieten. Das sind mindestens:
Region 1: 4kB (Prebootloader)
Region 2: 100kB (Bootloader Primär) oder 16...32kB für Varianten mit angepasster Kryptographie
Region 3: 100kB (Bootloader Sekundär) oder 16...32kB für Varianten mit angepasster Kryptographie
Region 4: Gegeben durch Applikationsfirmware
On-Chip SRAM: 32kB RAM und mehr (abhängig vom Funktionsumfang)
Beide Bootloader und die Firmware haben in der aktuellen Implementation eine Check-Summe zur Überprüfung. In der Option mit asymmetrischer Kryptographie wird die Checksumme mit einer kryptographischen Signatur ersetzt.
Bootloader Update
Nebst der Applikationsfirmware kann auch der Bootloader sicher im Feld aktualisiert werden. Damit das Gerät selbst bei einem fehlgeschlagenen Update weiterhin verwendbar oder immerhin wiederherstellbar ist, existieren auf dem Target-System zwei Kopien des Bootloaders. Ein Bootloader kann immer nur die andere Kopie überschreiben, womit im Fehlerfall ein Fallback garantiert ist.
Asymmetrische Kryptographie (in Entwicklung)
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.
Abbildung 2: Typische Anwendung mit Daisy Chain
Die Funktionen des Bootloaders können über ein proprietäres RPC-Protokoll (Remote Procedure Call) verwendet werden. Dasselbe Protokoll kann ebenfalls in der Applikationsfirmware eingesetzt werden, was eine optimale Integration von Bootloader und Applikation erlaubt. Softwarebibliotheken für C, C++ und Python stehen bei Bedarf zur Verfügung. RPC Kommandos/Antworten und Events werden als einzelne Pakete über das unterliegende Data Link Protokoll ausgetauscht. Die RPC Pakete werden dabei in Frames aufgeteilt. Die maximale Framegrösse ist abhängig von der RAM/DMA Kapazität der eingesetzten Controller. Jeder Data Link Endpunkt hat eine eigene Adresse, welche aus der Adresse des Empfängers selbst und dem entsprechenden Port zusammengesetzt wird. Das Data Link Protokoll kann somit über die meisten verfügbaren elektronischen Schnittstellen eingesetzt werden.
Die folgenden unterschiedlichen Topologien können konfiguriert werden:
- Point to Point – Ein Host (Master) und ein Mikrokontroller (Slave): Master > Slave 1
- Daisy Chain – Ein Host (Master) und mehrere in Serie geschaltete Mikrokontroller (Slaves): Master > Slave 1 > Slave 2 >...
- Stern – Ein Host (Master) mit mehreren physikalischen Point-to-Point Verbindungen
- Netzwerk – Ein Host (Master) mit mehreren logischen Point-to-Point Verbindungen, z.B. über ein bestehendes TCP/IP Netzwerk, einen I2C oder SPI Bus mit mehreren adressierbaren Slaves.
Einschränkungen
Da der Bootloader in den meisten Fällen, gleich wie die Applikationsfirmware selbst, im normalen Programmspeicher abgelegt wird, empfehlen wir, ihn zusätzlich durch Hardware-Massnahmen gegen böswillige Modifikation (z.B. über JTAG) zu schützen. Die meisten Mikrokontroller enthalten bereits von Haus aus verschiedene Möglichkeiten dazu.