Seminar STM32 – TrustZone und Trusted Firmware-M mit MCUboot

TrustZone trennt Ausführungs- und Speicherbereiche, ersetzt aber keine vertrauenswürdige Bootkette. Trusted Firmware-M stellt isolierte Secure Services bereit und verwendet typischerweise MCUboot als sichere Bootstufe. Das Seminar verbindet diese Ebenen von der ersten Authentisierung bis zum kontrollierten Aufruf eines Secure Service aus der Nonsecure-Anwendung.

Inhaltsübersicht

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

Zielsetzung

• Secure und Nonsecure Processing Environment mit klaren Assets und Schnittstellen entwerfen
• MCUboot als authentisierte Bootstufe in eine TF-M-Chain of Trust integrieren
• TF-M-Profile, PSA-Services, Isolation und Multi-Image-Updates passend konfigurieren
• Provisionierung, Bestätigung, Recovery und Angriffe auf die Isolationsgrenze testen

Zielgruppe

Erfahrene Embedded- und Security-Entwickler, TrustZone- und TF-M-Integratoren, Systemarchitekten, Bootloader-Teams und technische Verifikation.

Voraussetzungen

Sehr gute C- und Cortex-M-Kenntnisse, Erfahrung mit STM32Cube, Linkerskripten, Interrupts und Debugging. Secure-Boot- und MCUboot-Grundlagen werden vorausgesetzt.

Seminarinhalte

1. Schritt 1: Assets und Partitionen entwerfen

   Schlüssel, Gerätezustand, Kryptografie, Storage, Attestation, Update und produktbezogene Secure Services werden Secure- oder Nonsecure-Bereichen zugeordnet.

2. Schritt 2: TrustZone-Hardware konfigurieren

   SAU, IDAU oder plattformspezifische Attribution, Speicher- und Peripheriegrenzen, Secure Gateways, Interruptzuordnung und privilegierte Zugriffe werden abgestimmt.

3. Schritt 3: Chain of Trust festlegen

   Immutable erste Stufe, optionaler BL1, MCUboot als BL2, TF-M Secure Image und Nonsecure-Anwendung werden mit ihren Trust Anchors und Übergaben modelliert.

4. Schritt 4: TF-M-Profile auswählen

   Speicherbedarf, Isolationsebene, Secure Services, Multi-Image-Bedarf und Performance werden gegen Small-, Medium- oder Large-orientierte Konfigurationen bewertet.

5. Schritt 5: Referenzprojekt reproduzieren

   Bootloader, Secure Image, Nonsecure-Anwendung und Testservices werden unverändert gebaut, signiert, programmiert und mit erwarteten Logs gestartet.

6. Schritt 6: Secure- und Nonsecure-Layout anpassen

   Flash- und RAM-Partitionen, Veneers, Header, Slots, Datenbereiche, Stack, Heap und gemeinsame Mailboxen werden konsistent konfiguriert.

7. Schritt 7: MCUboot-Imagekonfiguration festlegen

   Single- oder Multi-Image, getrennte Signaturschlüssel, Abhängigkeiten, Versionen, Security Counter, Update-Modus und Trailer werden eingerichtet.

8. Schritt 8: TF-M-Secure-Services integrieren

   Kryptografie, Internal Trusted Storage, Protected Storage, Attestation oder eigene Partitionen werden über PSA-Schnittstellen aus der Nonsecure-Anwendung verwendet.

9. Schritt 9: Eigene Secure Partition entwickeln

   Manifest, Berechtigungen, IPC-Endpunkte, Assetzugriff, Fehlerbehandlung und Ressourcenbegrenzung werden für einen produktspezifischen Dienst umgesetzt.

10. Schritt 10: Provisionierung und Schlüsselablage planen

    Boot-Trust-Anchor, TF-M-Assets, Geräteschlüssel, Lifecycle-Daten und Debugberechtigungen werden in geeignete geschützte Speicherbereiche eingebracht.

11. Schritt 11: Secure und Nonsecure Images aktualisieren

    Gemeinsame oder unabhängige Versionierung, Abhängigkeiten, atomare Freigabe, Teststart und Bestätigung werden anhand des gewählten Image-Modells umgesetzt.

12. Schritt 12: Bootstatus und Fehlerübergaben absichern

    Fehlende oder ungültige Secure-Komponente, inkompatibles Nonsecure-Image, Servicefehler und Watchdog-Reset führen zu definierten Recoveryzuständen.

13. Schritt 13: Isolation verifizieren

    Nonsecure-Zugriffe auf Secure Flash, RAM, Peripherie, Debug, Secure Services und geschützte Storageobjekte werden positiv und negativ getestet.

14. Schritt 14: Angriffs- und Robustheitstests ergänzen

    Manipulierte Images, falsche Abhängigkeit, beschädigte IPC-Nachricht, Ressourcenerschöpfung, Reset und unzulässiger Secure-Service-Aufruf werden geprüft.

15. Schritt 15: Produktintegration konsolidieren

    Build- und Signaturpipeline, Boot- und Partitionskonfiguration, Schlüsselrollen, Updateablauf, Testkatalog und Diagnose werden als wartbarer Referenzstand zusammengeführt.

Praxisübungen

• Aufbau einer Secure/Nonsecure-Referenzanwendung mit MCUboot
• Anpassung von TrustZone-Attribution und Flash-/RAM-Partitionen
• Nutzung eines TF-M-Secure-Service aus der Nonsecure-Anwendung
• Signierung und Update getrennter Secure- und Nonsecure-Images
• Negativtests gegen Speicher-, Peripherie- und Service-Isolation

Methodik

Die Laborumgebung startet mit einem funktionierenden TF-M-Referenzprojekt. Änderungen an Attribution, Image-Modell oder Secure Services werden einzeln vorgenommen und jeweils mit Boot-, Schnittstellen- und Isolationstests abgesichert.