FALLSTUDIE / 01 · FIRMWARE-SICHERHEIT
Dem Update vertrauen.
Bevor es läuft.
Postquanten-Authentifizierung von Firmware auf dem NXP i.MX93, verbunden mit einer Desktop-Anwendung zum Signieren und zur Schlüsselverwaltung.
- Rolle
- Bachelorand
- Kontext
- NXP Semiconductors / HAW Hamburg
- Zeitraum
- Okt. 2024 – Jan. 2025
- Schwerpunkt
- SPHINCS+ · LMS · i.MX93
Python · PySide6 · SQLite

Authentizität vor der Ausführung.
Ein Firmware-Update verändert die Software, die ein Gerät ausführen wird. Die technische Aufgabe besteht darin, diese Firmware zu authentifizieren und den Aufwand sowie die Integration von Postquanten-Signaturen auf einer eingebetteten Plattform zu bewerten.
Meine Thesis verband eine SPHINCS+-Authentifizierung, einen Vergleich von SPHINCS+ und LMS auf dem i.MX93 und eine bedienbare Signieranwendung.
Vom Signierablauf zum Gerät.
Die Desktop-Anwendung übernimmt den Signierablauf; die eingebettete Seite authentifiziert Firmware-Signaturen. Die Darstellung zeigt diese Aufgaben, nicht den Aufbau der Platine.
Desktop-Ablauf
Signieren und Schlüsselverwaltung
Anwendungsdaten
Firmware authentifizieren
SPHINCS+
Implementierung, Bewertung, Werkzeuge.
Firmware-Authentifizierung
SPHINCS+-Authentifizierung von Firmware-Signaturen als Teil des sicheren Update-Mechanismus implementiert.
Bewertung auf der Zielplattform
SPHINCS+ und LMS auf dem NXP i.MX93 vermessen sowie Leistungs- und Integrationsaspekte bewertet.
Eine Signieranwendung
Eine objektorientierte Python/PySide6-Anwendung mit SQLite für kryptografische Schlüsselverwaltung und Firmware-Signierung entwickelt.
Ein Update. Drei unterschiedliche Ergebnisse.
Die zugehörige Browser-Demo erklärt Authentifizierung, Ablehnung und Wiederherstellung. Sie führt echte SHA-256- und ECDSA-P-256-Prüfungen aus; A/B-Slots, Teststart und Funktionsbestätigung sind modelliert. Die Postquanten-Verfahren der Thesis werden nicht ausgeführt.
| Szenario | Entscheidende Prüfung | Modellierter Endzustand |
|---|---|---|
| Erfolgreiches UpdateErfolgreiches Update starten → | Signatur, Richtlinie und Datei bestehen die Prüfung. Der modellierte Funktionstest bestätigt B. |
|
| Manipulierte FirmwareManipulation abspielen → | Die Manifest-Signatur ist gültig. Ein verändertes Datei-Byte passt nicht zum Hash; B wird nicht gestartet. |
|
| Boot-WiederherstellungWiederherstellung abspielen → | Die kryptografischen Prüfungen bestehen. B scheitert am modellierten Funktionstest; ein Neustart stellt das bestätigte A wieder her. |
|
Erwartete Demo-Ergebnisse, keine Benchmark-Ergebnisse der Thesis. Jeder Lauf beginnt mit aktivem und bestätigtem Slot A sowie Sequenz-Mindestwert 7.
Technischer Hintergrund & Quellen
- IETF RFC 9124 · Firmware manifests
- NIST FIPS 205 · SLH-DSA
- NIST SP 800-208 · LMS / XMSS
- MCUboot · Trial boot & recovery
Protokollhintergrund zur Erläuterung; diese Quellen belegen nicht die Benchmark-Ergebnisse der Thesis.