Site icon bintorosoft.com

STM32 TrustZone: Isolation von sicherheitskritischen Anwendungen

Red Snapper

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:

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.

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:

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:

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:

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:

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:

FNS = 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:

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:

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:

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:

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:

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.

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

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:

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

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:

Lieferumfang:

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.

 

Exit mobile version