Passwort-Management am STM32: Daten im internen Flash sichern

Passwort-Management am STM32: Daten im internen Flash sichern klingt zunächst nach einer einfachen Aufgabe: Ein Passwort oder PIN soll gespeichert werden, damit sich Nutzer später authentifizieren können. In der Praxis ist genau das eine der häufigsten Ursachen für Sicherheitslücken in Embedded-Projekten. Der Grund: Mikrocontroller wie ein STM32 arbeiten unter anderen Rahmenbedingungen als Server oder PCs. Flash-Speicher kann nur seitenweise gelöscht werden, Schreibzyklen sind begrenzt, und Debug-Schnittstellen oder physischer Zugriff auf das Gerät sind oft realistische Angriffswege. Gleichzeitig erwarten Anwender eine stabile Bedienung: Passwörter sollen zuverlässig funktionieren, Updates dürfen keine Daten zerstören und ein Stromausfall darf das Gerät nicht „bricken“. In diesem Artikel lernen Sie, wie Sie Passwörter, PINs und Zugangsdaten auf STM32-Controllern so verwalten, dass sie sowohl praktisch als auch sicher sind. Der Fokus liegt auf dem Schutz sensibler Daten im internen Flash: von sicheren Hashverfahren und Key-Derivation über Verschlüsselung, Integritätsprüfung und Wear-Leveling bis hin zu Schutzmaßnahmen wie Read-Out Protection (RDP) und – wenn verfügbar – TrustZone. Ziel ist ein Ansatz, der sich in echten Produkten umsetzen lässt, ohne unnötige Komplexität, aber mit klarer Sicherheitssystematik.

Warum „Passwort im Flash speichern“ gefährlich ist

Der naheliegendste Ansatz ist, ein Passwort im Klartext in einer Flash-Seite abzulegen und beim Login zu vergleichen. Das ist aus Security-Sicht problematisch, weil Flash-Inhalte häufig ausgelesen werden können – etwa über Debug (SWD/JTAG), über Bootloader-Interfaces oder bei physischem Zugriff auf die Leiterplatte. Selbst wenn Sie Debug im Feld deaktivieren, bleibt ein Restrisiko durch invasive Methoden oder Service-Fehlkonfigurationen.

• Klartext ist ein Totalausfall: Wer ausliest, hat das Passwort sofort.
• Einfaches Hashing ohne Salt: Erlaubt Offline-Angriffe über Wörterbücher und Rainbow Tables.
• Schwache PINs: 4–6 Ziffern sind bruteforcbar, wenn keine Sperrmechanismen existieren.
• Fehlende Integrität: Angreifer könnten Flash-Inhalte manipulieren (z. B. Passwort zurücksetzen).

Als praxisnahe Referenz für sichere Passwortspeicherung ist der OWASP-Leitfaden sehr nützlich, weil er konkrete Empfehlungen zu Hashing, Salt und Key-Derivation gibt: OWASP Password Storage Cheat Sheet.

Bedrohungsmodell im Embedded-Kontext: Was muss wirklich geschützt werden?

Bevor Sie Mechanismen auswählen, definieren Sie Ihr Bedrohungsmodell. Für STM32-basierte Produkte sind diese Szenarien häufig:

• Remote-Angriff: Zugang über Netzwerk/Bus/Service-Schnittstelle, ohne physischen Zugriff.
• Lokaler Angriff: Zugriff auf serielle Konsole, Wartungsport, Gehäuseöffnung.
• Physischer Angriff: Zugriff auf Debug-Pins, Flash-Auslesen, Hardware-Manipulation.
• Missbrauch im Feld: Nutzer probiert PINs systematisch, um Zugang zu erzwingen.

Aus dem Bedrohungsmodell ergibt sich, ob Sie primär Schutz gegen Online-Rate-Angriffe (Sperrlogik) benötigen oder ob der Fokus auf Offline-Schutz (ausgelesener Flash) liegt. In vielen Produkten ist beides relevant.

Grundstrategie: Hash statt Klartext, plus Salt und Key-Derivation

Für echte Passwörter (nicht nur kurze PINs) ist der Standardansatz: Sie speichern nicht das Passwort, sondern einen abgeleiteten Prüfwert, der mit Salt und einem langsamen Verfahren erzeugt wurde. Das Ziel ist, Offline-Angriffe zu verteuern: Selbst wenn jemand den Flash ausliest, ist das Erraten des Passworts teuer.

• Salt: Zufallswert pro Gerät oder pro Account, der im Flash gespeichert wird.
• Key-Derivation: z. B. PBKDF2, scrypt oder Argon2 (Argon2 ist oft schwerer im MCU-Umfeld, PBKDF2 verbreiteter).
• Iteration/Work Factor: so wählen, dass Login noch benutzbar bleibt, aber Brute Force teuer wird.

NIST beschreibt in seinen Digital-Identity-Richtlinien wichtige Grundsätze rund um Passwörter und Verifier (inklusive Rate-Limits und Schutz gegen Offline-Angriffe): NIST SP 800-63B.

Entropie grob einschätzen (für PINs und Passwörter)

Für PINs und Passwörter hilft es, den Suchraum zu verstehen. Bei einer PIN mit n Stellen und Basis b (z. B. 10 für Ziffern) gibt es b^n Kombinationen. Die Entropie in Bit kann näherungsweise so berechnet werden:

$H=n\cdot {\log }_2\left(b\right)$

Eine 4-stellige PIN hat nur 10.000 Möglichkeiten – das ist ohne Rate-Limit schnell durchprobiert. Bei PINs sind daher Sperrmechanismen und Fehlversuchs-Zähler meist wichtiger als „super starke“ Hashverfahren.

PINs und kurze Codes: Rate-Limiting ist Pflicht

Wenn Ihr Produkt eine PIN (z. B. 4–8 Stellen) nutzt, sollten Sie den Schwerpunkt anders setzen als bei langen Passwörtern. Der Suchraum ist klein; ein Angreifer kann online bruteforcen, wenn Sie es zulassen. Daher brauchen Sie:

• Fehlversuchs-Zähler: Zählt falsche Eingaben persistent (im Flash oder Backup-Register, je nach Risiko).
• Sperrzeiten: exponentielles Backoff oder feste Lockout-Zeit nach X Fehlversuchen.
• Reset-sicher: Schutz dagegen, dass durch Power-Cycling der Zähler zurückgesetzt wird.
• Optional: Admin-Reset-Prozess: definierter Recovery-Mechanismus (z. B. signiertes Service-Token).

Ohne persistenten Zähler ist ein PIN-System in vielen realen Szenarien nur eine Komfortfunktion, aber keine echte Sicherheitskontrolle.

Verschlüsselung im Flash: Wann sie sinnvoll ist – und wann nicht

Hashing schützt Passwörter, aber manchmal müssen Sie Secrets im Klartext wiederherstellen, z. B. WLAN-PSK, API-Tokens oder Client-Zertifikate. Diese Daten können nicht nur gehasht werden, weil Sie sie im Betrieb benötigen. In diesem Fall ist Verschlüsselung plus Integrität sinnvoll.

• Verschlüsseln, wenn Klartext benötigt wird: Tokens, Schlüssel, Konfiguration mit Geheimnisanteil.
• Nicht verschlüsseln „um Passwörter zu speichern“: Nutzerpasswörter sollten idealerweise gehasht werden, nicht reversibel gespeichert.
• Immer Integrität mitdenken: Verwenden Sie AEAD (z. B. AES-GCM/CCM) oder MAC (z. B. HMAC), damit Manipulation erkannt wird.

Ein kompaktes Konzept zu Authenticated Encryption (AEAD) finden Sie hier: Authenticated Encryption.

Der Knackpunkt: Woher kommt der Schlüssel zur Flash-Verschlüsselung?

Verschlüsselung ist nur so gut wie das Schlüsselmanagement. Wenn der Schlüssel im gleichen Flash in Klartext liegt, hat ein Angreifer mit Flash-Readout beides: Ciphertext und Key. Damit ist die Verschlüsselung wirkungslos. Für STM32-Projekte sind diese Ansätze üblich:

• Geräteindividueller Schlüssel aus Secure Storage: Wenn die STM32-Familie geschützten Speicher oder TrustZone bietet, sollte der Schlüssel dort liegen.
• Schlüsselableitung aus Hardware-IDs: Nur bedingt empfehlenswert. Unique IDs sind nicht geheim und ersetzen keine echte Secret-Quelle, können aber als Zusatz (z. B. „Associated Data“) dienen.
• Externer Secure Element: Für hohe Schutzbedarfe ist ein Secure Element oft der sauberste Weg, weil der Schlüssel den Chip nie verlässt.
• Provisioning in der Produktion: Ein per Gerät eingespieltes Secret, kombiniert mit Debug-Lock und RDP, ist in vielen Industrieprodukten praktikabel.

Wenn Ihr STM32 Hardware-Krypto unterstützt (AES, Hash, RNG), ist das hilfreich für Performance und korrekte Implementierung. Dennoch bleibt die Kernfrage: „Wo liegt das Secret?“ Ohne ein sinnvolles Secret-Handling ist Verschlüsselung oft eher „Security-Theater“.

Interner Flash als Datenspeicher: Seiten, Löschzyklen und atomare Updates

STM32-Flash hat typische Einschränkungen: Löschen geht seitenweise (Page/Sector), Schreiben erfolgt in Wort-/Doppelwort-Größen (modellabhängig), und die Anzahl der Löschzyklen ist begrenzt. Daraus folgen Designregeln für Passwort- und Secret-Speicherung:

• Separate Flash-Seite reservieren: Legen Sie Konfig/Secrets nicht zwischen Programmcode ab.
• Wear-Leveling oder Journal: Vermeiden Sie ständiges Löschen derselben Seite (z. B. bei Fehlversuchs-Zähler).
• Atomare Updates: Nutzen Sie „Write-then-commit“, damit Stromausfall keinen inkonsistenten Zustand erzeugt.
• Versionierung und CRC/MAC: Erkennen Sie unvollständige oder manipulierte Datensätze.

Ein praxistaugliches Schema ist ein Append-only Journal innerhalb einer Seite: Jeder neue Eintrag wird ans Ende geschrieben. Ist die Seite voll, wird eine neue Seite aktiviert und die alte gelöscht. So reduzieren Sie Löschzyklen und haben eine natürliche Recovery-Logik.

Datenformat im Flash: Klar definieren und robust validieren

Ein typisches Datensatzformat für „Passwort/Secrets“ im Flash enthält:

• Magic/Marker: Erkennen, ob ein Eintrag gültig ist.
• Version: Für spätere Migration bei Firmware-Updates.
• Salt/Nonce: Für Passwort-Hash oder AEAD-Verschlüsselung.
• Payload: Hash oder verschlüsseltes Secret.
• Integrität: CRC für Zufallsfehler oder besser MAC/AEAD-Tag für Manipulationsschutz.

Validieren Sie beim Lesen konsequent: Länge, Version, erwartete Felder und Integrität. Verlassen Sie sich nicht auf „es wird schon passen“ – Flash-Bitfehler und unterbrochene Schreibvorgänge sind in realen Geräten normal.

Passwort-Hashing auf dem STM32: Praxisempfehlungen

Für Embedded-Projekte ist es wichtig, Aufwand und Sicherheit auszubalancieren. Ein mögliches Vorgehen:

• Für Passwörter: PBKDF2-HMAC-SHA256 mit pro Gerät oder pro Nutzer generiertem Salt und einem Work Factor, der noch akzeptable Login-Zeiten bietet.
• Für PINs: Hashing ja, aber Schwerpunkt auf Rate-Limits und persistenten Fehlversuchs-Zähler.
• Für kurze Secrets (Tokens): Verschlüsselung mit AEAD, Schlüssel aus geschützter Quelle.

Wenn Sie PBKDF2 nutzen, wählen Sie die Iterationszahl nicht „aus dem Bauch“, sondern messen Sie auf Ihrer Zielhardware. Ein grobes Zeitmodell lässt sich so ausdrücken: Wenn eine Hashrunde t_r Sekunden dauert und Sie i Iterationen nutzen, ergibt sich näherungsweise:

$t\approx i\cdot t_r$

Damit können Sie ein Ziel setzen (z. B. 100–300 ms pro Login-Versuch) und den Work Factor entsprechend kalibrieren.

Schutz vor Auslesen: RDP, Debug-Strategie und Realismus

Selbst das beste Passwort- oder Secret-Design kann scheitern, wenn Angreifer den Flash einfach auslesen. Daher ist ein Mindestmaß an Härtung nötig:

• Debug im Feld deaktivieren: SWD-Pins nicht zugänglich machen, Option Bytes entsprechend setzen.
• Read-Out Protection (RDP): Aktivieren Sie RDP passend zum Produktlebenszyklus (Servicefähigkeit vs. maximaler Schutz).
• Kein Vertrauen in „Obskurität“: Testpads, Boot-Pins und Programmierschnittstellen sind oft auffindbar.

RDP reduziert die Wahrscheinlichkeit trivialer Readout-Angriffe deutlich, ist aber kein absoluter Schutz gegen hochbudgetierte, invasive Methoden. Deshalb ist die Kombination aus RDP, sicherem Speicherdesign und optionaler Verschlüsselung entscheidend.

TrustZone und Secure Services: Wenn Ihr STM32 das unterstützt

Bei TrustZone-fähigen STM32 (Cortex-M33) können Sie Security-Logik besser kapseln: Der Secure-Bereich verwaltet Schlüssel, führt Hashing/AEAD aus und gibt an die Non-Secure Anwendung nur Ergebnisse zurück. Dadurch müssen Secrets nicht im großen Anwendungscode liegen, der typischerweise die größere Angriffsfläche hat (Netzwerk, Parser, UI).

• Secure World: Key Store, Krypto-Operationen, Policy (z. B. Fehlversuchslogik).
• Non-Secure World: UI, Kommunikation, Funktionslogik.
• Secure Gateways: schmale, validierte API statt direktem Speicherzugriff.

Für das Architekturverständnis bietet Arm eine gute Übersicht: Arm TrustZone.

Fehlversuchs-Zähler sicher speichern: Flash-Journaling statt „eine Zahl überschreiben“

Ein häufiger Fehler ist, den Fehlversuchs-Zähler als einzelne Variable im Flash zu speichern und bei jedem Versuch zu überschreiben. Das führt zu unnötigen Löschzyklen und ist empfindlich gegen Stromausfälle. Besser:

• Append-only Einträge: Jeder Fehlversuch erzeugt einen kleinen Datensatz am Ende der Seite.
• Komprimierung bei Bedarf: Wenn die Seite voll ist, schreiben Sie einen konsolidierten Zustand in eine neue Seite.
• Integritätscheck: CRC oder besser MAC, um Manipulation zu erkennen.

Damit erreichen Sie sowohl bessere Haltbarkeit (weniger Erase-Zyklen) als auch robustes Recovery nach Reset.

Secure Reset und Recovery: Was tun, wenn das Passwort vergessen wurde?

Ein „Passwort vergessen“-Fall ist im Embedded-Umfeld nicht nur ein UX-Thema, sondern ein Sicherheitsproblem. Ein Reset-Jumper, der das Passwort löscht, ist praktisch, kann aber als Angriffspfad missbraucht werden. Deshalb sollten Sie Recovery bewusst designen:

• Service-Token statt Reset-Pin: Ein signiertes Service-Token (z. B. über UART/USB) ist oft sicherer als ein Hardware-Pin.
• Physischer Zugriff als Policy: Wenn Recovery nur mit Gehäuseöffnung möglich ist, dokumentieren Sie das als Sicherheitsannahme.
• Auditierbare Aktionen: Reset-Vorgänge und Servicezugriffe sollten protokollierbar sein (wenn das Produkt es erlaubt).

Für Systeme mit hohen Anforderungen ist es üblich, Recovery nur in einer definierten Service-Prozedur zu erlauben, die den Sicherheitszustand nicht unbemerkt verändert.

Typische Fehler im Passwort-Management auf STM32

• Passwort im Klartext: selbst „verschleiert“ ist es trivial extrahierbar.
• Kein Salt, schneller Hash: offline bruteforcbar in kurzer Zeit.
• Keine Rate-Limits bei PINs: online bruteforcbar durch wiederholte Versuche.
• Verschlüsselung ohne Integrität: Daten können manipuliert werden, ohne dass es auffällt.
• Schlüssel im gleichen Flash: Verschlüsselung wird wertlos, wenn Key mit ausgelesen wird.
• Keine Stromausfall-Resilienz: Update/Write bricht ab, Daten werden inkonsistent.

Outbound-Ressourcen für Best Practices und Normen

• OWASP Password Storage Cheat Sheet für Salt und Key-Derivation
• NIST SP 800-63B für Richtlinien zu Authenticatoren und Rate-Limits
• Authenticated Encryption (AEAD) als Basis für Verschlüsselung mit Integrität
• Arm TrustZone als Konzept für Isolation sicherheitskritischer Funktionen

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.