CASE STUDY / 01 · FIRMWARE SECURITY

Trust the update.
Before it runs.

Post-quantum firmware authentication on NXP i.MX93, connected to a desktop workflow for signing and key handling.

Explore the implementation ↓Play firmware demo ↗

Role: Bachelor thesis student
Context: NXP Semiconductors / HAW Hamburg
Period: Oct 2024 – Jan 2025
Focus: SPHINCS+ · LMS · i.MX93
Python · PySide6 · SQLite

Illustrative semiconductor on a circuit board. — Illustrative artwork · Not a photograph of the thesis hardware

Authenticity before execution.

A firmware update changes the software a device will execute. The engineering problem is to authenticate that firmware, then understand the cost and integration implications of post-quantum signatures on an embedded platform.

My thesis combined a SPHINCS+ authentication implementation, a comparison of SPHINCS+ and LMS on i.MX93, and a usable signing application.

From the signing workflow to the device.

The desktop application handles the signing workflow; the embedded side authenticates firmware signatures. The diagram summarizes those responsibilities, rather than reproducing the board layout.

Desktop workflow

Python / PySide6

Signing and key handling

SQLite

Application data

Firmware + signature

NXP i.MX93

Authenticate firmware

SPHINCS+

Conceptual responsibilities from the thesis implementation. SPHINCS+ and LMS were also benchmarked on the target platform.

Implementation, evaluation, tooling.

Firmware authentication
Implemented SPHINCS+ firmware-signature authentication as part of the secure-update mechanism.
Embedded evaluation
Benchmarked SPHINCS+ and LMS on NXP i.MX93 and evaluated performance and integration aspects.
A signing application
Built an object-oriented Python/PySide6 application backed by SQLite for cryptographic key handling and firmware signing.

Same update. Three different outcomes.

The related browser demo explains authentication, rejection and recovery. It runs real SHA-256 and ECDSA P-256 checks; A/B slots, trial boot and health confirmation are modeled. It does not execute the thesis’s post-quantum schemes.

Three outcomes. One verification process.
Scenario	Decisive check	Final modeled state
Successful updatePlay successful update →	Signature, policy and payload pass. The modeled health check confirms B.	Active B Confirmed B Sequence floor 8
Tampered firmwarePlay tampering scenario →	The manifest signature passes. One changed payload byte causes a digest mismatch; B never boots.	Active A Confirmed A Sequence floor 7
Boot recoveryPlay boot recovery →	Cryptographic checks pass. B fails the modeled health check; reset restores confirmed A.	Active A Confirmed A Sequence floor 7

Expected demo outcomes, not thesis benchmark results. Every run starts with A active and confirmed, and a sequence floor of 7.

Open the player →Inspect demo source ↗

Technical background & references

Protocol background for the explanation; these references are not evidence of the thesis’s benchmark results.

Discuss the engineering.

Get in touch ↗

Trust the update.Before it runs.