Close

Firmware 0.9.1: the key gets signed updates, and the builder gets a choice

A project log for EvilKey: I Needed a FIDO2 Key. Then the Maker Brain Took Over.

ESP32-S3 FIDO2 prototype: touch AMOLED, microSD apps, HID scripts, USB/BLE AirMouse and an IMU BLE Gamepad. A key that got carried away.

I originally needed a FIDO2 key. After giving it games and an air mouse, I finally came back to the security work I had been promising. Apparently even feature creep can occasionally finish a task.

Firmware 0.9.1 is out for Waveshare PCB V1.0 and V1.1. This chapter adds signed updates, a separate RESCUE path and an explicit route to HMAC-backed key storage and Secure Boot. There is one decision to make before activating it: whose signing key should this device trust?

Pick the signer before closing the door

If you install the signed firmware from this repository's Releases and activate Secure Boot and HMAC, future compatible firmware must be signed with the same release key. Get those updates from this repository's Releases. Unsigned builds and builds signed with your own or another key will be rejected.

Secure Boot activation is irreversible. Erasing Flash or restoring a backup cannot change that decision.

You can still build your own EvilKey. Start with your own RSA3072 key, configure its custom trust profile and matching bootloader, and build normal firmware plus RESCUE before activation. That device will then need your same private key for future updates and recovery. Creating another key later does not recover the old identity.

Secure Boot checks firmware signatures. HMAC protects device wrapping-key derivation; it does not sign firmware. Activation is an explicit device operation. An ordinary build, boot or update does not burn the protection eFuses, and removing the retained plaintext root-key copy remains a separate verified step.

One place for the builder workflow

EvilKey.cmd now groups Firmware, Manager, Diagnostics/tests and maintenance. Firmware → Keys and trust can generate a missing own key or import an existing one. The workflow configures the matching trust profile and bootloader, builds normal and RESCUE firmware, and prepares FIRST_INSTALL, UPDATE_SD and RESCUE_SD packages.

Numbered choices, Y/N confirmations and file/folder dialogs handle the routine selections. Private keys stay outside the source tree. The menu can create a password-encrypted key backup; keep that backup independently of the PC.

The little apps got attention too

ABI6-NP1 adds resource banks, transactional saves and more native rendering/input tools while retaining ABI v4/v5 apps and existing saves. The release also brings asynchronous USB storage I/O and NVS/PIN/FIDO fixes. In the games tested, average frame rate rose from approximately 19 to 25 FPS. That is the reported result for those games, rather than a guarantee for every app. The separately licensed games are still not part of the public firmware download.

Read the installation path before copying files

An existing compatible signed installation uses the SD update flow: Stage, Activate, Restart and fresh confirmation with the existing PIN. Normal updates preserve credentials, PIN, settings, apps and saves. RESCUE is a separate firmware-repair package.

The signed SD archive is not a drop-in update for an old unsigned 0.8.x layout. The guarded first-install/migration workflow accepts only supported states and refuses unknown layouts. Follow the current guide rather than the ERASE instructions in older logs.

Manager stays at 1.1.6; its existing EXE is unchanged, while the source snapshot and native-project export are aligned. USB Tool example scripts are unchanged too. The photographed case remains the V1 prototype; V1.1 case fit remains unverified. This is still an independent prototype, without a FIDO certification claim.

Firmware 0.9.1 and SDK · Build, trust and installation workflow · Manager · microSD examples

If you were building one, would you use the repository's signed releases or keep your own signing identity?

Discussions