Seminar STM32 – SBSFU zu MCUboot und OEMiRoT migrieren

Eine Migration betrifft nicht nur den Bootloader. Im Feld vorhandene Images, Schlüssel, Versionsregeln, Speicherlayouts, Updateprotokolle, Produktionsschritte und Servicewerkzeuge bilden einen bestehenden Vertrag. Das Seminar entwickelt einen Übergang, der diese Abhängigkeiten sichtbar macht und das Risiko eines nicht mehr aktualisierbaren Geräts minimiert.

Inhaltsübersicht

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

Zielsetzung

• Legacy-SBSFU-Architektur, Feldbestand und betriebliche Abhängigkeiten vollständig erfassen
• MCUboot- oder OEMiRoT-Zielarchitektur mit klarer Konzeptzuordnung entwerfen
• Image-, Schlüssel-, Counter-, Speicher- und Anwendungsmigration kontrolliert umsetzen
• Übergangsrelease, Recovery und Rollout mit realistischen Feldtests absichern

Zielgruppe

Maintainer bestehender X-CUBE-SBSFU-Produkte, Bootloader- und Embedded-Entwickler, Product Security, Release Management und technische Projektleitung.

Voraussetzungen

Praktische Erfahrung mit dem vorhandenen SBSFU-Projekt, Zugriff auf Quellcode, Speicherlayout, Schlüsselmodell, Updateprozess und mindestens ein repräsentatives Zielgerät.

Seminarinhalte

1. Schritt 1: Bestand und Feldrealität erfassen

   Bootloader-Versionen, MCU-Revisionen, Flashlayouts, Schlüssel, installierte Firmwarestände, Counter, Updatekanäle, Produktionszustände und Recoverymöglichkeiten werden inventarisiert.

2. Schritt 2: Legacy-Vertrauensgrenzen analysieren

   Secure Engine, Bootbereich, Anwendung, Downloadslot, Schlüsselablage, Schutzmaßnahmen und Servicezugänge werden mit tatsächlichen Annahmen dokumentiert.

3. Schritt 3: Zielpfad auswählen

   Direkte MCUboot-Portierung oder STM32Cube-OEMiRoT/OEMuRoT wird nach Zielserie, Hardware-Schutz, Wartungsmodell, TrustZone und gewünschter Bootstufenteilung ausgewählt.

4. Schritt 4: Konzepte abbilden

   Legacy-Header, Status, Version, Slot, Schlüssel und Updatezustände werden auf MCUboot-Header, TLVs, Trailer, Security Counter, Teststart und Bestätigung abgebildet.

5. Schritt 5: Speicherlayout migrieren

   Neue Bootloadergröße, Headerreserve, Trailer, Scratch oder Overwrite, Recovery, Datenbereiche und externe Flash-Nutzung werden gegen vorhandene Feldgeräte geprüft.

6. Schritt 6: Schlüsselstrategie festlegen

   Weiterverwendung, Übergang mit mehreren Trust Anchors, neuer Root, operative Schlüssel und Widerruf werden so geplant, dass ein autorisiertes Übergangsrelease möglich bleibt.

7. Schritt 7: Anwendung konvertieren

   Linkeradresse, Vektortabelle, Startcode, Bootübergabe, Updateanforderung, Image-Bestätigung und Statusmeldung werden von Legacy-Schnittstellen entkoppelt.

8. Schritt 8: Image- und Buildpipeline umstellen

   Neue Header- und Signaturwerkzeuge, Version und Security Counter, Slotgrenze, Artefaktnamen und automatisierte Prüfungen werden in den Releaseprozess integriert.

9. Schritt 9: Übergangsmechanismus entwerfen

   Ein Legacy-signiertes Release installiert oder aktiviert die neue Bootarchitektur, ohne bei Reset oder Stromausfall den einzigen gültigen Bootpfad zu verlieren.

10. Schritt 10: Updatekanal kompatibel halten

    Backend, Servicewerkzeug und Transport können während der Übergangsphase alte und neue Pakettypen eindeutig unterscheiden und dem passenden Gerät zuordnen.

11. Schritt 11: Recovery und Rückfall definieren

    Factory-Image, dualer Bootloader, Servicezugang oder kontrollierte Rückkehr werden gegen Flashbedarf und Sicherheitsrisiko bewertet.

12. Schritt 12: Pilotmigration testen

    Repräsentative Geräte mit unterschiedlichen Altständen werden mehrfach migriert, unterbrochen, wiederhergestellt und anschließend mit neuen Releases aktualisiert.

13. Schritt 13: Rollout und Sperrpunkt festlegen

    Geräteerkennung, Pilotquote, Abbruchkriterien, Supportfenster, endgültige Ablehnung alter Pakete und Außerbetriebnahme alter Schlüssel werden festgelegt.

Praxisübungen

• Erstellung einer Legacy-zu-Ziel-Konzeptmatrix
• Neuberechnung von Flashlayout und Anwendungsladeadresse
• Entwurf eines Schlüssel- und Übergangsrelease-Modells
• Simulation einer unterbrochenen Bootloader-Migration und Recovery
• Erstellung einer Pilot- und Rollout-Testmatrix für heterogene Feldstände

Methodik

Der Kurs arbeitet mit einer migrationsorientierten Differenzanalyse. Jede technische Änderung wird gegen Feldbestand, Produktionszustand und Rückfallfähigkeit geprüft. Ein Übergangsrelease gilt erst nach Power-Fail-, Downgrade- und Wiederholbarkeitstests als freigabefähig.