Seminar STM32 – Secure Boot Grundlagen und Root-of-Trust-Architektur

Secure Boot ist keine einzelne Signaturfunktion, sondern eine Vertrauenskette aus unveränderlicher Startstufe, geschütztem Trust Anchor, überprüften Metadaten, Hardware-Schutz und kontrollierter Übergabe. Das Seminar schafft die Architekturgrundlage, bevor konkrete Pakete oder Bootloader portiert werden.

Inhaltsübersicht

• Zielsetzung
• Zielgruppe
• Voraussetzungen
• Seminarinhalte
• Praxisübungen
• Methodik

Zielsetzung

• Schutzbedarf, Angreifer und Vertrauensgrenzen eines STM32-Produkts präzise beschreiben
• Immutability, Root of Trust, Chain of Trust und Runtime Protection voneinander abgrenzen
• Authentizität, Integrität, Vertraulichkeit und Anti-Rollback korrekt zuordnen
• Einen passenden STM32-Lösungspfad und ein belastbares Boot- und Speicherlayout auswählen

Zielgruppe

Embedded-Entwickler, System- und Security-Architekten, technische Projektleitung, Testverantwortliche und technische Entscheider.

Voraussetzungen

Grundkenntnisse in Mikrocontroller- und Firmwareentwicklung, Flash-Speicher, Bootvorgängen und Embedded-C. Tiefe Kryptografiekenntnisse sind nicht erforderlich.

Seminarinhalte

1. Schritt 1: Assets und Angreifer bestimmen

   Firmware-IP, Geräteschlüssel, Sicherheitsfunktionen, Produktidentität und Verfügbarkeit werden gegen Remote-, lokalen und physischen Angreifer abgegrenzt.

2. Schritt 2: Sicherheitsziele formulieren

   Nur autorisierte Software, unveränderte Metadaten, kontrollierte Updates, Downgrade-Abwehr, Schutz vor Auslesen und definierte Recovery werden als getrennte Anforderungen festgelegt.

3. Schritt 3: Root of Trust definieren

   Erste ausgeführte Stufe, Trust Anchor, immutable Speicherung und minimale Codebasis werden so festgelegt, dass spätere Stufen nicht selbst ihre Vertrauensgrundlage verändern können.

4. Schritt 4: Chain of Trust modellieren

   Boot-ROM, OEM-Bootstufe, Secure Runtime, Nonsecure-Anwendung und zusätzliche Firmwarekomponenten werden mit ihren Prüf- und Übergabepunkten verbunden.

5. Schritt 5: Kryptografische Prüfungen einordnen

   Hash, digitale Signatur, symmetrische Verschlüsselung, Schlüsselableitung und Zufallswerte werden ihren jeweiligen Schutzzielen zugeordnet.

6. Schritt 6: Bootmetadaten absichern

   Version, Zielkennung, Länge, Startadresse, Abhängigkeit, Security Counter und Flags werden als sicherheitsrelevanter Teil des Images behandelt.

7. Schritt 7: Hardware-Schutzmaßnahmen planen

   Write Protection, Readout Protection, TrustZone, geschützte Speicherbereiche, Bootoptionen und Debugschutz werden als Teil der Bootarchitektur berücksichtigt.

8. Schritt 8: Updatearchitektur ergänzen

   Ein- und Zwei-Slot-Modelle, Staging, Bestätigung, Revert, Recovery und Power-Fail-Sicherheit werden bereits im Grundlayout eingeplant.

9. Schritt 9: STM32-Implementierungen vergleichen

   X-CUBE-SBSFU, MCUboot-basierte SBSFU-Varianten, OEMiRoT/OEMuRoT und TF-M werden nach Zielserie, Wartbarkeit, Offenheit und Sicherheitsumfang eingeordnet.

10. Schritt 10: Architekturentscheidung dokumentieren

    Bootstufen, Speicherplan, Schlüsselrollen, Provisionierung, Updatekanal, Servicezugang und Testkriterien werden in einem konsistenten Entscheidungsmodell zusammengeführt.

Praxisübungen

• Erstellung eines Threat Models für ein vernetztes STM32-Produkt
• Zeichnung einer Chain of Trust mit klaren Prüf- und Schutzgrenzen
• Vergleich eines Legacy-SBSFU- und eines MCUboot/OEMiRoT-Lösungspfads
• Entwurf eines ersten Flash-, Schlüssel- und Recovery-Konzepts

Methodik

Architekturdiagramme, Bedrohungsfälle und kleine Binärbeispiele werden gemeinsam analysiert. Produktnahe Entscheidungsfragen stehen vor Tooldetails, damit spätere Implementierungen auf einer konsistenten Sicherheitsannahme aufbauen.