STM32 TrustZone: Isolation von sicherheitskritischen Anwendungen

STM32 TrustZone ermöglicht es, sicherheitskritische Funktionen in Embedded-Systemen deutlich besser zu isolieren, ohne dass dafür ein komplexes Betriebssystem oder teure zusätzliche Sicherheitschips zwingend erforderlich sind. Gerade in vernetzten Geräten – von Industrie-Gateways über Smart-Home-Komponenten bis zu Mess- und Medizintechnik – ist die Angriffsfläche groß: Netzwerk-Stacks, Dateisysteme, Funkprotokolle und UI-Code wachsen, während gleichzeitig Schlüssel, Zertifikate, Firmware-Update-Mechanismen oder Messdaten zuverlässig geschützt werden müssen. TrustZone für Arm Cortex-M (typischerweise Cortex-M33 in STM32-Serien wie L5, U5 oder H5) teilt das System in zwei Welten: eine Secure World für vertrauenswürdige, minimal gehaltene Sicherheitsfunktionen und eine Non-Secure World für „normale“ Anwendungsteile. Dadurch können Sie zentrale Assets wie Kryptoschlüssel, Secure Boot, Attestation oder geschützte Speicherbereiche vor typischen Softwarefehlern (Buffer Overflows, Use-After-Free, fehlerhafte Parser) in nicht-sicherem Code abschirmen. Dieser Artikel zeigt, wie STM32 TrustZone konzeptionell funktioniert, wie Sie Isolation sinnvoll planen, welche Hardware- und Software-Bausteine zusammengehören und wie Sie typische Designfehler vermeiden – damit die Trennung nicht nur auf dem Papier existiert, sondern im Produkt echte Sicherheitswirkung entfaltet.

TrustZone für Cortex-M: Das Grundprinzip der zwei Welten

TrustZone auf Mikrocontroller-Ebene unterscheidet sich von TrustZone auf großen Anwendungsprozessoren, verfolgt aber dasselbe Ziel: Eine hardwaregestützte Trennung von Code und Daten. Auf Cortex-M basiert diese Trennung auf zwei Security-States:

• Secure: Ausführung und Zugriff auf Ressourcen, die als sicher markiert sind.
• Non-Secure: Ausführung der regulären Anwendung, die nur auf nicht-sichere Ressourcen zugreifen darf.

Die Umschaltung zwischen Secure und Non-Secure erfolgt kontrolliert über definierte Eintrittspunkte (Secure Gateway). Der Secure-Bereich kann Services bereitstellen, die der Non-Secure Code aufrufen darf – ähnlich wie ein API-Boundary. Wichtig ist: TrustZone ist keine „Sandbox“, die automatisch jeden Bug behebt, sondern ein Werkzeug, um kritische Funktionen in einen kleineren, auditierbaren Bereich zu verlagern.

Für eine konzeptionelle Einordnung ist die Arm-Übersicht zu Arm TrustZone hilfreich. Für die Security-Methodik dahinter eignet sich Arm PSA Certified, weil dort Root-of-Trust und Secure Services strukturiert beschrieben werden.

Welche STM32 unterstützen TrustZone und warum das relevant ist

TrustZone setzt einen TrustZone-fähigen Cortex-M voraus (in der Praxis meist Cortex-M33). Bei STM32 ist TrustZone vor allem in security-orientierten Familien anzutreffen. Für Ihr Architekturdesign bedeutet das: Sie können echte Hardware-Isolation zwischen sicherheitskritischem Kern und Funktionscode umsetzen, statt alles im gleichen Privileg- und Adressraum zu betreiben.

• Typische Einsatzfälle: Secure Boot, Schlüsselverwaltung, sichere Firmware-Updates, Gerätezertifikate, Lizenzschutz, Messdaten-Integrität.
• Warum es sich lohnt: Der Non-Secure Teil ist oft groß (Netzwerk, Parser, GUI) und damit fehleranfälliger. TrustZone reduziert die Folgen eines Fehlers im großen Teil, indem Assets im kleinen Teil geschützt bleiben.

Für Entwicklung und Konfiguration sind STM32CubeIDE und STM32CubeMX gängige Werkzeuge, um TrustZone-Projekte, Memory-Layouts und Peripheriezuordnung konsistent aufzusetzen.

Isolation richtig planen: Threat Model vor Memory Map

Bevor Sie Secure/Non-Secure Speicherbereiche zeichnen, sollten Sie festlegen, welche Assets geschützt werden müssen und von wem. Ein praxistaugliches Threat Model beantwortet mindestens diese Fragen:

• Welche Geheimnisse gibt es? (Private Keys, Tokens, Zertifikate, Lizenzschlüssel)
• Welche Funktionen sind kritisch? (Firmware-Update, Boot-Policy, sichere Speicherung, kryptografische Operationen)
• Welche Angreiferannahme gilt? (Remote-Angriff über Netzwerk, lokaler Zugriff über Service-Port, physischer Zugriff auf Flash)
• Welche Recovery ist erforderlich? (Rollback-Schutz, Fail-Safe-Update, Manufacturing/Provisioning)

Erst danach lohnt sich die technische Aufteilung. Wenn Sie „alles, was irgendwie wichtig ist“ in Secure packen, wird der Secure-Code zu groß, schwer zu prüfen und verliert den Vorteil der kleinen Angriffsfläche. Ziel ist eine minimale Secure World mit klaren, stabilen Schnittstellen.

Secure World: Was gehört hinein, was besser nicht?

Ein bewährtes Muster ist, Secure World als „Sicherheitskern“ zu definieren, der wenige, gut kontrollierte Services anbietet:

• Key Store und Kryptografie-Services: Schlüssel generieren, speichern, verwenden (ohne Ausleitung in Non-Secure).
• Secure Boot/Boot Policy: Verifikation von Firmware und Policy-Entscheidungen (z. B. Anti-Rollback).
• Secure Storage: geschützte Speicherung von Secrets, Countern, Nonces und Gerätezustand.
• Attestation: Nachweis gegenüber Backend, dass die Firmware unverändert und das Gerät „echt“ ist.
• Secure Firmware Update (kritische Teile): Verifikation, Entschlüsselung, Slot-Management (je nach Design).

Nicht empfehlenswert in Secure World sind große, komplexe Komponenten wie vollständige Netzwerk-Stacks, Dateisysteme, umfangreiche UI oder selten genutzte Treiberlandschaften – alles, was die Codebasis groß macht und typische Exploit-Flächen erhöht.

Non-Secure World: Wo sie bleibt und warum das gut ist

Non-Secure ist nicht „unsicher“, sondern der Bereich, der regelmäßig erweitert wird und daher zwangsläufig mehr Komplexität trägt. Genau deshalb ist es sinnvoll, diese Welt als „Feature-Layer“ zu behandeln:

• Kommunikation: TCP/IP, MQTT, HTTP, BLE/WLAN-Stacks, Protokollparser.
• Anwendungslogik: Gerätesteuerung, Regelungen, UI, Telemetrie, Diagnostik.
• Update-Transport: Download, Übertragung, Puffern – aber Verifikation/Schlüsselverwendung idealerweise Secure.

Der entscheidende Punkt: Non-Secure darf Secure Services nutzen, aber nicht umgekehrt. Das verhindert, dass Secure-Code durch Komplexität „nach unten“ gezogen wird.

Memory Partitioning: Flash, SRAM und Peripherie sauber trennen

TrustZone-Isolation wird technisch über Speicher- und Peripherie-Zuordnung erreicht. In STM32-Projekten bedeutet das typischerweise:

• Secure Flash: Bootloader, Secure Services, Trust Anchors.
• Non-Secure Flash: Hauptanwendung und Features.
• Secure SRAM: Stack/Heap für Secure Services, Key-Material, temporäre Kryptopuffer.
• Non-Secure SRAM: reguläre Laufzeitdaten, Netzwerkpuffer, UI-Objekte.

Für die Planung hilft eine einfache Größenabschätzung. Wenn Ihr Gerät F Byte Flash hat und Sie S Byte für Secure reservieren, bleibt für Non-Secure:

$F_{\mathrm{NS}}=F–S$

Analog gilt das für SRAM. Diese Rechnung ist banal, aber praktisch: Secure wird schnell größer als geplant, wenn zu viele Funktionen hineinwandern. Eine harte Budgetierung zwingt zu sauberer Schnittstellendefinition.

Secure Gateways und APIs: Der wichtigste Designpunkt im Alltag

Die Trennung lebt von den Eintrittspunkten: Welche Funktionen darf Non-Secure aufrufen, welche Daten darf es übergeben, welche Ergebnisse dürfen zurückgegeben werden? Eine gute Secure-API hat folgende Eigenschaften:

• Schmale, stabile Oberfläche: wenige Funktionen, klar versioniert.
• Keine Secrets als Parameter: Schlüssel bleiben Secure; Non-Secure übergibt nur Handles oder Daten.
• Input-Validierung: Secure prüft alle Eingaben aus Non-Secure strikt (Längen, Bereiche, Zustände).
• Fehlerbehandlung: eindeutig, ohne Leaks (keine Detailinfos, die Angreifern helfen).

Ein Beispiel: Statt „encrypt(data, key)“ exportieren Sie „encrypt_with_device_key(data)“. Dadurch kann Non-Secure nie den Schlüssel beeinflussen oder ausleiten, und Secure kontrolliert die Policy (z. B. erlaubte Algorithmen, Nonce-Regeln, Rate-Limits).

Secure Boot, TrustZone und Firmware Updates: Zusammenspiel in der Praxis

TrustZone entfaltet die größte Wirkung, wenn sie mit einem sicheren Boot- und Update-Konzept kombiniert wird. Ein robustes Muster ist:

• Immutable Root of Trust: ROM oder minimaler Secure Bootloader als Startpunkt.
• Secure Verifikation: Signaturprüfung, Policy, Anti-Rollback in Secure.
• Non-Secure Transport: Download/Übertragung im Non-Secure Code, weil dort die Protokollkomplexität liegt.
• Secure Installation: Entschlüsselung/Authentifizierung/Slot-Switch in Secure.

So bleibt die „gefährliche“ Komplexität (Netzwerk) außerhalb des Kernvertrauensbereichs, während die Entscheidung „darf das Gerät dieses Image ausführen?“ in Secure bleibt. Als Einstieg in das Secure-Boot-Prinzip eignet sich Secure Boot, um die Chain-of-Trust-Idee zu verankern.

Kryptografie in Secure World: Schlüssel bleiben drin, Ergebnisse gehen raus

Ein häufiger Fehlstart ist, TrustZone zu aktivieren, aber Schlüssel weiterhin in der Non-Secure App zu verwalten. Das schwächt das gesamte Modell. Besser ist:

• Schlüsselgenerierung in Secure: RNG und Key-Erzeugung ausschließlich im Secure-State.
• Schlüssel-Handles statt Key-Bytes: Non-Secure bekommt nur Referenzen.
• AEAD bevorzugen: Verschlüsselung und Integrität kombiniert, um Manipulation zu verhindern.

Für das Konzept „verschlüsseln und authentifizieren“ ist Authenticated Encryption eine gute Grundlage. Für viele STM32-Projekte ist außerdem mbed TLS als Referenzbibliothek hilfreich, weil sie sich sowohl für Software-Krypto als auch für hardwarebeschleunigte Pfade und PSA-APIs eignet.

Peripherie-Isolation: Nicht jeder Bus gehört in Non-Secure

Neben Speicher ist Peripherie ein kritischer Punkt. In vielen Designs ist es sinnvoll, bestimmte Hardware exklusiv Secure zuzuordnen, insbesondere wenn sie Secrets beeinflussen oder Sicherheitszustände ändern kann:

• Krypto-Engine und RNG: idealerweise Secure-only, damit Non-Secure keine Schlüsseloperationen missbraucht.
• Flash-Controller/Option-Bytes: Zugriffe, die Security-Policy ändern, gehören in Secure.
• Debug/Provisioning-Pfade: sollten klar kontrolliert und im Feld eingeschränkt sein.
• Kommunikationsinterfaces: können Non-Secure sein, aber Schlüsselmaterial darf nicht über sie „durchrutschen“.

Eine gute Praxis ist, Non-Secure Treiber so zu bauen, dass sie „dumme Transportlayer“ sind, während Secure Services die sensiblen Entscheidungen treffen (z. B. „darf diese Verbindung Zertifikate nutzen?“).

RTOS und TrustZone: Trennung von Tasks und Services

TrustZone funktioniert sowohl ohne als auch mit RTOS. Mit RTOS entstehen zusätzliche Architekturoptionen:

• Secure als Service-Task: Secure enthält wenige Tasks, die über definierte Gateways angesprochen werden.
• Non-Secure als Feature-Tasks: Netzwerk, UI, Storage laufen in Non-Secure Tasks und nutzen Secure APIs.
• Prioritäten und Latenz: Secure Services sollten so designt sein, dass sie deterministisch bleiben (kurze, überprüfbare Pfade).

Wichtig ist, Secure nicht zu einer „Super-Task“ zu machen, die überall eingreift. Das führt häufig zu Deadlocks, komplexem Timing und einer aufgeblähten Trusted Computing Base (TCB).

Secure Storage: Zähler, Nonces und Konfiguration sicher ablegen

Viele Security-Designs scheitern an Details wie Nonce-Wiederverwendung oder fehlendem Anti-Rollback, weil Zustände nicht sicher und dauerhaft gespeichert werden. TrustZone hilft, diese Zustände im Secure-State zu verwalten.

• Monotone Counter: für Anti-Rollback und eindeutige Nonces (persistiert, manipulationsresistent).
• Secure Config: Policies (z. B. erlaubte Key-IDs, minimale Firmware-Versionen) im Secure Bereich.
• Integritätsschutz: gespeicherte Daten signieren oder MACen, um Flash-Manipulation zu erkennen.

Ein praxistaugliches Muster ist ein signiertes Manifest für Firmware und Policies: Non-Secure kann es transportieren, aber Secure verifiziert und entscheidet.

Typische Fehler bei STM32 TrustZone und wie Sie sie vermeiden

• Secure World wird zu groß: zu viele Funktionen, zu viele Treiber, zu viel „Bequemlichkeit“. Besser: Secure minimal, klarer Service-Kern.
• Schlüssel landen trotzdem in Non-Secure: etwa aus Debug-Gründen oder wegen schneller Prototypen. Besser: Handles, Secure-only Key-Ops.
• Unsaubere Secure APIs: zu viele Parameter, fehlende Input-Validierung. Besser: strikte Längenprüfungen, einfache Typen, klare Fehlercodes.
• Zu viel Vertrauen in Verschlüsselung: ohne Integrität/Authentifizierung entstehen manipulierbare Datenflüsse. Besser: AEAD oder HMAC.
• Rollback nicht bedacht: alte, signierte Firmware bleibt installierbar. Besser: monotone Versionen und Secure Counter.
• Debug/Service im Feld offen: physischer Zugriff wird zum Shortcut. Besser: definierter Service-Mode, restriktive Policies, Logging.

Validierung und Tests: Isolation muss messbar sein

TrustZone ist erst dann „wirksam“, wenn Sie nachweisen können, dass Non-Secure nicht auf Secure Ressourcen zugreifen kann und dass Secure Services korrekt auf Missbrauch reagieren. Sinnvolle Tests sind:

• Negative Access Tests: Non-Secure versucht, Secure SRAM/Flash zu lesen oder zu schreiben → muss scheitern.
• Fuzzing von Secure APIs: zufällige/fehlerhafte Eingaben → Secure muss robust ablehnen, ohne Absturz.
• Rollback-Tests: ältere Firmware installieren → Secure Policy muss verhindern.
• Key-Leak-Tests: sicherstellen, dass Schlüssel nie im Non-Secure RAM auftauchen (z. B. durch Memory-Pattern-Checks).
• Power-Loss-Tests: Update/Counter-Writes mit Reset unterbrechen → System muss konsistent bleiben.

Im Alltag ist außerdem wichtig, dass Sie den Secure-Teil als „kleines Produkt im Produkt“ behandeln: eigener Code-Review, eigene Sicherheitsrichtlinien, separate CI-Checks und klare Zuständigkeiten.

Outbound-Ressourcen für den Einstieg und die Vertiefung

• Arm TrustZone – Architekturüberblick
• Arm PSA Certified – Root of Trust und Secure Services
• Secure Boot – Chain of Trust Grundlagen
• Authenticated Encryption – Verschlüsselung mit Integrität
• mbed TLS – Referenz für Krypto und PSA-Integration
• STM32CubeIDE – Entwicklung und Debugging
• STM32CubeMX – Konfiguration von TrustZone und Peripherie

IoT-PCB-Design, Mikrocontroller-Programmierung & Firmware-Entwicklung

PCB Design • Arduino • Embedded Systems • Firmware

Ich biete professionelle Entwicklung von IoT-Hardware, einschließlich PCB-Design, Arduino- und Mikrocontroller-Programmierung sowie Firmware-Entwicklung. Die Lösungen werden zuverlässig, effizient und anwendungsorientiert umgesetzt – von der Konzeptphase bis zum funktionsfähigen Prototyp.

Diese Dienstleistung richtet sich an Unternehmen, Start-ups, Entwickler und Produktteams, die maßgeschneiderte Embedded- und IoT-Lösungen benötigen. Finden Sie mich auf Fiverr.

Leistungsumfang:

• IoT-PCB-Design & Schaltplanerstellung

• Leiterplattenlayout (mehrlagig, produktionstauglich)

• Arduino- & Mikrocontroller-Programmierung (z. B. ESP32, STM32, ATmega)

• Firmware-Entwicklung für Embedded Systems

• Sensor- & Aktor-Integration

• Kommunikation: Wi-Fi, Bluetooth, MQTT, I²C, SPI, UART

• Optimierung für Leistung, Stabilität & Energieeffizienz

Lieferumfang:

• Schaltpläne & PCB-Layouts

• Gerber- & Produktionsdaten

• Quellcode & Firmware

• Dokumentation & Support zur Integration

Arbeitsweise:Strukturiert • Zuverlässig • Hardware-nah • Produktorientiert

CTA:
Planen Sie ein IoT- oder Embedded-System-Projekt?
Kontaktieren Sie mich gerne für eine technische Abstimmung oder ein unverbindliches Angebot. Finden Sie mich auf Fiverr.