MedTech ARM Bootloader: Sichere Updates & Signaturen

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-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
• 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.

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 Struktur

Mit 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…