Seminar MCUboot Integration mit Trusted Firmware-M

Das dreitägige Fachseminar vermittelt die Einbindung von MCUboot als BL2 in eine auf Trusted Firmware-M basierende sichere Bootkette. Die technischen Zusammenhänge werden nicht nur beschrieben, sondern an einem durchgängigen Beispielsystem bis zu prüfbaren Boot- und Updatezuständen nachvollzogen.

Die Bearbeitung umfasst die Themenfelder Bootkette, Domänen und Build-Struktur, Signierung, Abhängigkeiten und Security Counter, Update, Recovery und Produktionshärtung. Jeder Themenblock beginnt mit einem eigenen Inhaltsverzeichnis, wird anschließend in klaren Arbeitsschritten umgesetzt und endet mit einer praktischen Prüfung einschließlich typischer Fehler- und Grenzfälle.

Inhaltsverzeichnis

• Zielgruppe
• Voraussetzungen
• Lernziele
• Seminarinhalte
• Tag 1: Bootkette, Domänen und Build-Struktur
• Tag 2: Signierung, Abhängigkeiten und Security Counter
• Tag 3: Update, Recovery und Produktionshärtung
• Praxisanteil
• Arbeitsweise

Zielgruppe

Arm- und TrustZone-Entwickler, Security-Architekten, Plattformintegratoren und Firmware-Teams.

Voraussetzungen

Gute Kenntnisse von Arm TrustZone, Secure und Non-secure Images, CMake sowie MCUboot-Grundlagen.

Lernziele

• die Rollen von ROM-Stufe, BL2, Secure Processing Environment und Non-secure Anwendung abgrenzen
• Secure- und Non-secure Images einschließlich Abhängigkeiten und Security Counter signieren
• Flash-Layout, Übergabedaten und Bootkonfiguration von TF-M und MCUboot abstimmen
• Update-, Rollback- und Recovery-Szenarien für eine mehrstufige Vertrauenskette testen

Seminarinhalte

Die Inhalte werden in aufeinander aufbauenden Kapiteln bearbeitet. Jedes Tageskapitel enthält ein eigenes Inhaltsverzeichnis und einen schrittweisen Praxisablauf.

Tag 1: Bootkette, Domänen und Build-Struktur

Inhaltsverzeichnis des Tageskapitels

• Root of Trust, erste Bootstufe und MCUboot als BL2
• Secure Processing Environment, Non-secure Processing Environment und Übergänge
• TF-M-Build, BL2-Optionen und verwendete MCUboot-Komponenten
• Speicheraufteilung für Bootloader, Secure Image und Non-secure Image
• gemeinsamer Build und Zuordnung der erzeugten Binärartefakte

Schrittweise Bearbeitung

1. Schritt 1: „Root of Trust, erste Bootstufe und MCUboot als BL2“ wird fachlich eingeordnet; Systemgrenzen, Voraussetzungen und Abhängigkeiten werden festgehalten.
2. Schritt 2: Für „Secure Processing Environment, Non-secure Processing Environment und Übergänge“ werden die relevanten Konfigurationswerte, Datenstrukturen und Werkzeuge am Beispielprojekt nachvollzogen.
3. Schritt 3: „TF-M-Build, BL2-Optionen und verwendete MCUboot-Komponenten“ wird am Beispielprojekt praktisch umgesetzt und mit Bootmeldungen, Speicherinhalten oder Prüfdaten kontrolliert.
4. Schritt 4: Zu „Speicheraufteilung für Bootloader, Secure Image und Non-secure Image“ wird ein Fehler- oder Grenzfall gezielt erzeugt, ausgewertet und mit einer belastbaren Korrektur behoben.
5. Schritt 5: „gemeinsamer Build und Zuordnung der erzeugten Binärartefakte“ wird abschließend in einen wiederholbaren Arbeits- und Prüfablauf für Entwicklungs- oder Produktionsprojekte überführt.

Praktische Umsetzung

Ein TF-M-Beispiel wird mit aktivem BL2 gebaut; Bootstufen, Images und Speicherbereiche werden anhand der erzeugten Artefakte nachvollzogen.

Tag 2: Signierung, Abhängigkeiten und Security Counter

Inhaltsverzeichnis des Tageskapitels

• Signaturprofile und Schlüssel für Secure und Non-secure Images
• Image-Kennungen, Versionsbeziehungen und geschützte Abhängigkeits-TLVs
• Security Counter und Schutz vor Rückstufung
• gemeinsames oder getrenntes Aktualisieren mehrerer Images
• Validierungsfehler an den Grenzen zwischen BL2 und Laufzeit

Schrittweise Bearbeitung

1. Schritt 1: „Signaturprofile und Schlüssel für Secure und Non-secure Images“ wird fachlich eingeordnet; Systemgrenzen, Voraussetzungen und Abhängigkeiten werden festgehalten.
2. Schritt 2: Für „Image-Kennungen, Versionsbeziehungen und geschützte Abhängigkeits-TLVs“ werden die relevanten Konfigurationswerte, Datenstrukturen und Werkzeuge am Beispielprojekt nachvollzogen.
3. Schritt 3: „Security Counter und Schutz vor Rückstufung“ wird am Beispielprojekt praktisch umgesetzt und mit Bootmeldungen, Speicherinhalten oder Prüfdaten kontrolliert.
4. Schritt 4: Zu „gemeinsames oder getrenntes Aktualisieren mehrerer Images“ wird ein Fehler- oder Grenzfall gezielt erzeugt, ausgewertet und mit einer belastbaren Korrektur behoben.
5. Schritt 5: „Validierungsfehler an den Grenzen zwischen BL2 und Laufzeit“ wird abschließend in einen wiederholbaren Arbeits- und Prüfablauf für Entwicklungs- oder Produktionsprojekte überführt.

Praktische Umsetzung

Zwei zusammengehörige Images werden signiert und aktualisiert; eine absichtlich unzulässige Versionskombination wird erkannt und dokumentiert.

Tag 3: Update, Recovery und Produktionshärtung

Inhaltsverzeichnis des Tageskapitels

• Teststart, Bestätigung und Revert in einer TF-M-Konfiguration
• Bootdaten, Messwerte und Übergabe an sichere Dienste
• Recovery-Pfade und Einschränkungen durch die Root-of-Trust-Architektur
• Schlüsselbereitstellung, Debug-Sperren und sichere Produktionsparameter
• End-to-End-Test vom signierten Paket bis zur gestarteten Anwendung

Schrittweise Bearbeitung

1. Schritt 1: „Teststart, Bestätigung und Revert in einer TF-M-Konfiguration“ wird fachlich eingeordnet; Systemgrenzen, Voraussetzungen und Abhängigkeiten werden festgehalten.
2. Schritt 2: Für „Bootdaten, Messwerte und Übergabe an sichere Dienste“ werden die relevanten Konfigurationswerte, Datenstrukturen und Werkzeuge am Beispielprojekt nachvollzogen.
3. Schritt 3: „Recovery-Pfade und Einschränkungen durch die Root-of-Trust-Architektur“ wird am Beispielprojekt praktisch umgesetzt und mit Bootmeldungen, Speicherinhalten oder Prüfdaten kontrolliert.
4. Schritt 4: Zu „Schlüsselbereitstellung, Debug-Sperren und sichere Produktionsparameter“ wird ein Fehler- oder Grenzfall gezielt erzeugt, ausgewertet und mit einer belastbaren Korrektur behoben.
5. Schritt 5: „End-to-End-Test vom signierten Paket bis zur gestarteten Anwendung“ wird abschließend in einen wiederholbaren Arbeits- und Prüfablauf für Entwicklungs- oder Produktionsprojekte überführt.

Praktische Umsetzung

Ein vollständiger Updatezyklus wird mit Fehlerfällen durchgeführt; danach wird eine produktionsnahe Konfigurations- und Prüfcheckliste abgeleitet.

Praxisanteil

Der praktische Anteil umfasst ein tf-m-beispiel wird mit aktivem bl2 gebaut; bootstufen, images und speicherbereiche werden anhand der erzeugten artefakte nachvollzogen; zwei zusammengehörige images werden signiert und aktualisiert; eine absichtlich unzulässige versionskombination wird erkannt und dokumentiert; ein vollständiger updatezyklus wird mit fehlerfällen durchgeführt; danach wird eine produktionsnahe konfigurations- und prüfcheckliste abgeleitet. Die Übungen verwenden signierte Test-Images, kontrollierte Flashzustände und nachvollziehbare Prüfergebnisse.

Arbeitsweise

Kurzvorträge ordnen die Konzepte ein. Demonstrationen zeigen die Wirkung der Konfiguration auf Image, Flash und Bootentscheidung. Die anschließenden Übungen werden schrittweise durchgeführt, durch Negativtests ergänzt und mit einer technischen Prüfliste dokumentiert.