Hardware-Verschlüsselung (AES/DES) auf STM32-Controllern nutzen

Hardware-Verschlüsselung (AES/DES) auf STM32-Controllern nutzen ist ein praxisnaher Weg, um Embedded-Geräte schneller, energieeffizienter und oft auch robuster gegen typische Implementierungsfehler abzusichern. Statt kryptografische Algorithmen vollständig in Software auszuführen, stellen viele STM32-Familien einen dedizierten Crypto-Block bereit, der Verschlüsselung und Entschlüsselung (und je nach Modell zusätzlich Hash, RNG oder Public-Key-Beschleunigung) hardwareseitig übernimmt. Das bringt klare Vorteile: Höherer Durchsatz bei geringerer CPU-Last, weniger Stromverbrauch pro verschlüsseltem Datenblock und eine konsistentere Laufzeit. Gerade für IoT- und Industrieanwendungen – etwa TLS-Verbindungen, signierte Updates, verschlüsselte Datenlogger oder sichere Funkprotokolle – kann das entscheidend sein. Gleichzeitig gilt: Hardware-Krypto ist kein „Security-Shortcut“. Der Algorithmus ist nur ein Baustein; die Sicherheit steht und fällt mit Schlüsselmanagement, korrekten Betriebsarten (Modes) und sauberem Umgang mit Nonces/IVs. Dieser Artikel erklärt, wie Sie AES- und DES-Hardware in STM32 sinnvoll einsetzen, welche Betriebsarten in modernen Designs üblich sind, wie DMA die Performance weiter steigert und welche typischen Stolperfallen Sie unbedingt vermeiden sollten.

AES und DES im Embedded-Kontext: Was ist sinnvoll, was ist Legacy?

In Embedded-Projekten tauchen AES und DES oft zusammen auf, weil manche Microcontroller-Peripherieblöcke historisch beide unterstützen. In der Praxis sollten Sie die Rolle beider Algorithmen klar trennen:

• AES (Advanced Encryption Standard): moderner Standard, breit eingesetzt (TLS, Datentransport, Speicher). Für neue Designs ist AES praktisch immer die richtige Wahl.
• DES/3DES: historisch wichtig, heute jedoch in vielen Szenarien als veraltet einzustufen. Wenn DES überhaupt vorkommt, dann meist aus Kompatibilitätsgründen (Altanlagen, Legacy-Protokolle).

Für Hintergrundwissen zu AES ist Advanced Encryption Standard (AES) eine gute Basis. Für DES und seine Grenzen ist Data Encryption Standard (DES) hilfreich, um die historische Einordnung und die Gründe für den Wechsel zu modernen Verfahren zu verstehen.

Welche STM32 unterstützen Hardware-Krypto?

Ob AES/DES in Hardware verfügbar ist, hängt stark von der STM32-Serie und sogar vom konkreten Derivat ab. Viele STM32 bieten einen Crypto-Peripherieblock (oft „CRYP“ genannt), der AES (und teils DES/TDES) in mehreren Betriebsarten unterstützt. Zusätzlich gibt es bei manchen Familien Hash-Peripherie (SHA) und einen True Random Number Generator (RNG).

• Einsteiger-/Low-Power-Familien: je nach Modell teils AES/Hash/RNG (häufig bei security-orientierten Linien).
• Performance-Familien: oft Crypto-Acceleration, DMA-Integration und hohe Busbandbreite.
• TrustZone-fähige Familien: kombinieren Hardware-Krypto häufig mit Secure-Storage- und Secure-Boot-Konzepten.

Für die konkrete Auswahl ist es sinnvoll, die Produktseite Ihrer STM32-Variante zu prüfen und nach „Cryptographic accelerator“, „AES“ oder „CRYP“ zu suchen. Als Einstieg in die ST-Toolchain und Middleware eignen sich STM32CubeIDE und die STM32Cube MCU Packages, weil dort die Treiber und Beispiele typischerweise enthalten sind.

Warum Hardware-Verschlüsselung? Performance, Energie und deterministische Laufzeit

Software-AES kann auf modernen Cortex-M-Kernen durchaus schnell sein, vor allem mit optimierten Bibliotheken. Dennoch lohnt Hardware-Krypto häufig aus drei Gründen:

• Durchsatz: Große Datenmengen (Datenlogger, Firmware-Images, Funk-Bursts) lassen sich schneller verarbeiten.
• CPU-Freiraum: Die MCU kann parallel Protokoll-Stacks, Sensorik oder UI abarbeiten.
• Energieeffizienz: Weniger CPU-Zeit pro Block bedeutet oft weniger Energie pro verschlüsseltem Byte.

Ein zusätzlicher Vorteil ist die planbarere Ausführungszeit. Das kann in Echtzeitsystemen wichtig sein, etwa wenn kryptografische Operationen in einem Zeitfenster garantiert fertig werden müssen.

Blockchiffren verstehen: Blockgröße, Schlüssel und Betriebsart

AES und DES sind Blockchiffren. Das heißt: Sie verschlüsseln Daten nicht als beliebig langen Stream, sondern in festen Blöcken. AES arbeitet mit 128-Bit-Blöcken, DES mit 64-Bit-Blöcken. Daraus folgt eine wichtige Konsequenz: Die Betriebsart („Mode of Operation“) entscheidet, wie Sie längere Nachrichten sicher verschlüsseln.

Warum ECB fast immer eine schlechte Idee ist

Der ECB-Modus (Electronic Codebook) verschlüsselt jeden Block unabhängig. Identische Klartextblöcke werden zu identischen Ciphertextblöcken. Das leakt Struktur und ist in den meisten Anwendungen unsicher. Moderne Designs vermeiden ECB, außer in sehr speziellen Fällen (z. B. Verschlüsselung einzelner zufälliger Blöcke ohne Muster).

Als Einstieg in Betriebsarten ist Betriebsmodi von Blockchiffren eine nützliche Übersicht.

Empfohlene Betriebsarten: CBC, CTR und vor allem AEAD

Für Embedded-Systeme sind drei Muster typisch:

• CBC (Cipher Block Chaining): weit verbreitet, benötigt ein IV und Padding. Gut verständlich, aber fehleranfällig, wenn Padding und Integritätsprüfung nicht sauber gemacht werden.
• CTR (Counter Mode): macht AES zur Stream-Chiffre; keine Padding-Probleme, parallelisierbar. Sehr beliebt für Datenströme, erfordert aber strikte Nonce/Counter-Regeln.
• AEAD (z. B. GCM oder CCM): kombiniert Verschlüsselung und Authentifizierung. Für viele IoT- und Security-Anwendungen ist AEAD der Goldstandard, weil „nur verschlüsseln“ nicht reicht.

Wichtig: Verschlüsselung allein schützt nicht vor Manipulation. Angreifer können Ciphertext verändern, was ohne Authentifizierung zu unbemerkten Datenfehlern oder sogar Angriffen führen kann. Für das Konzept ist Authenticated Encryption ein guter Einstieg.

Nonces und IVs: Die häufigste Fehlerquelle

Die sicherste Hardware-AES-Engine nützt nichts, wenn Nonces oder IVs falsch verwendet werden. Besonders im CTR- und GCM/CCM-Kontext gilt: Ein Nonce/IV darf (für einen Schlüssel) nicht wiederverwendet werden. Eine Wiederverwendung kann die Vertraulichkeit vollständig brechen.

• CTR: gleicher Key + gleicher Counter-Start ⇒ XOR-Beziehungen zwischen Klartexten werden sichtbar.
• GCM: Nonce-Wiederverwendung kann Authentifizierung kompromittieren und Inhalte offenlegen.
• CBC: IV muss unvorhersehbar sein; Wiederverwendung kann Muster leaken.

Praxisregel: Generieren Sie Nonces mit einem sicheren RNG oder konstruieren Sie sie deterministisch aus einer monotonen, persistent gespeicherten Nachrichtennummer (z. B. Zähler im Flash) plus Geräte-ID. Wichtig ist die Garantie der Einzigartigkeit.

Schlüsselmanagement auf STM32: Wo Schlüssel leben dürfen

Die Performance der Hardwareverschlüsselung ist nur die halbe Miete. Die andere Hälfte ist Schlüsselmanagement: Wo liegen Schlüssel, wer kann sie auslesen, wie werden sie provisioniert und rotiert?

• Keine Hardcoded Keys in der App: für Prototypen möglich, für Produkte riskant.
• Gerätespezifische Schlüssel: reduzieren den Schaden bei kompromittiertem Einzelgerät.
• Geschützte Speicherbereiche: je nach STM32-Familie stehen Mechanismen wie geschützte Flash-Zonen, TrustZone oder Secure Storage zur Verfügung.
• Debug-Lock und Readout Protection: erschweren triviales Auslesen über SWD/JTAG.

Wenn Sie Secure-Boot-Konzepte mit Hardware-Krypto kombinieren, lohnt sich die Orientierung an standardisierten Security-Frameworks wie Arm PSA Certified, weil dort Root-of-Trust- und Secure-Storage-Ideen klar beschrieben sind.

Hardware-CRYP-Peripherie nutzen: Typische Datenpfade

Auch wenn die Registerdetails je nach STM32 variieren, ist das Grundprinzip ähnlich: Sie konfigurieren Algorithmus und Mode, laden Schlüssel und IV/Nonce, übergeben Datenblöcke und lesen das Ergebnis aus. In performanten Designs wird der Datenfluss über DMA angebunden, sodass die CPU kaum noch Bytes „schaufeln“ muss.

• Polling: einfach für kleine Datenmengen (z. B. kurze Tokens), aber CPU-lastig.
• Interrupt-basiert: besser für mittlere Datenmengen, sauber in RTOS integrierbar.
• DMA: ideal für große Blöcke (Datenlogger, Firmware-Images, Streaming), minimiert CPU-Last.

Ein praxistaugliches Muster ist „Chunking“: Daten werden in Blöcken verarbeitet (z. B. 1–4 kB), damit Speicherverbrauch beherrschbar bleibt und die Latenz in Echtzeit-Anwendungen kontrollierbar ist.

DES/3DES: Wann es noch vorkommt und wie Sie Risiken einordnen

DES ist heute in neuen Systemen selten empfehlenswert, weil die Schlüssellänge zu klein ist. 3DES (TDES) wurde lange als Upgrade genutzt, ist aber in modernen Protokollen zunehmend unerwünscht, unter anderem wegen Performance und Sicherheitsmargen. Dennoch begegnet Ihnen DES/3DES in Legacy-Industrieprotokollen oder proprietären Alt-Systemen.

• Wenn Kompatibilität zwingend ist: isolieren Sie den Legacy-Pfad und vermeiden Sie, dass DES „nebenbei“ für neue Features genutzt wird.
• Transport absichern: selbst wenn Payload DES nutzt, sollte der Transportkanal (z. B. TLS) modern sein.
• Migrationsplan: definieren Sie, wie und wann Legacy-Krypto ersetzt wird.

Integrität und Authentizität: Warum Verschlüsselung allein nicht genügt

Viele Embedded-Projekte verschlüsseln Daten, prüfen aber nicht zuverlässig die Integrität. Das ist gefährlich: Manipulierte Daten können Fehlfunktionen auslösen, die sich wie „Bug“ anfühlen, aber ein Angriff sind. Für Datenpakete (z. B. Funk) und Firmware-Updates gilt deshalb:

• AEAD bevorzugen: GCM/CCM liefern neben dem Ciphertext einen Auth-Tag.
• Alternativ HMAC: wenn AEAD nicht verfügbar ist, kann ein HMAC (mit SHA-256) Integrität liefern.
• Signaturen für Updates: Firmware sollte signiert werden, auch wenn sie verschlüsselt ist.

Für den Überblick zu HMAC ist HMAC eine geeignete Referenz, um die Idee „Keyed Integrity“ sauber einzuordnen.

Praxisbeispiel: Durchsatz und Zeitbudget abschätzen

In Embedded-Designs ist oft entscheidend, ob Verschlüsselung in ein Zeitfenster passt. Wenn Sie Datenmenge B (Bytes) und einen effektiven Durchsatz R (Bytes/s) annehmen, ergibt sich eine grobe Verschlüsselungszeit t:

$t=\frac{B}{R}$

Dieses einfache Modell hilft beim Entwurf: Wenn Sie beispielsweise ein 256-kB-Firmware-Chunk innerhalb weniger Sekunden verarbeiten müssen, entscheiden Hardwarebeschleuniger plus DMA oft darüber, ob das System parallel weiter stabil läuft (UI, Funk, Sensorik) oder „hängt“.

Teststrategie: Korrektheit, Interoperabilität und Fehlerszenarien

Kryptografie muss nicht nur „laufen“, sondern nachweisbar korrekt sein. Eine solide Teststrategie umfasst:

• Known Answer Tests (KAT): AES/DES mit bekannten Testvektoren prüfen (Klartext/Key/IV → Ciphertext).
• Cross-Checks: Hardware-Ergebnis gegen Softwarebibliothek (z. B. mbedTLS) vergleichen.
• Nonce-Policy testen: sicherstellen, dass Nonces nicht wiederverwendet werden (auch nach Reset/Powerloss).
• Fehlerpfade: ungültiger Tag bei AEAD muss zuverlässig zur Verwerfung führen.

Für viele STM32-Projekte ist mbed TLS als Referenz nützlich, weil es sowohl Software-Krypto als auch Integrationspunkte für Hardwarebeschleunigung bietet.

Typische Stolperfallen bei Hardware-Krypto auf STM32

• ECB aus Bequemlichkeit: führt zu Datenlecks durch Muster – vermeiden.
• Nonce/IV-Wiederverwendung: kann Sicherheit komplett brechen – Einzigartigkeit erzwingen.
• Keine Authentifizierung: verschlüsselte, aber manipulierbare Daten – AEAD oder HMAC nutzen.
• Schlüssel im Klartext im Flash: bei physischem Zugriff oder Debug oft extrahierbar – Secure Storage/Provisioning nutzen.
• DMA/Cache-Coherency: bei manchen MCUs müssen Cache-Flush/Invalidate korrekt gehandhabt werden.
• Unsaubere Fehlerbehandlung: bei AEAD muss „Tag mismatch“ zwingend zum Abbruch führen.

Outbound-Ressourcen für vertiefende Informationen

• AES – Grundlagen und Einordnung
• DES – historische Einordnung und Grenzen
• Authenticated Encryption (AEAD) – Konzept und Motivation
• HMAC – Integrität mit geheimem Schlüssel
• mbed TLS – Referenzbibliothek und Interoperabilität
• STM32Cube Packages – Treiber, Beispiele und Middleware

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.