Firmware Update Security

Firmware updates are distributed exclusively through the releases page of github.com/jaffa2970/Crypt-in-BETA. The firmware ships inside the beta package, as firmware\firmware.factory.bin — there is no separate firmware download, and no SDK repository to fetch it from.

The beta firmware is not signed

firmware\firmware.factory.bin is the -dev build, and it carries no Secure Boot v2 signature block — neither in the bootloader nor in the application. That is by construction: beta units have virgin eFuses, Secure Boot v2 is not active on them, and a -dev build skips signing because there would be nothing to verify it against.

So verify it by hash, not by signature. The hashes are in SHA256SUMS.txt, published beside the archive on the release page precisely so you can check the files without trusting the archive. Six OK lines; five is not a pass.

Everything below about signature verification describes production dongles, from the April 2027 launch.

Two independent verifications — on production dongles

On a production dongle a firmware image is checked twice, by two different things, before it can run. Neither check happens on a beta unit: the first has no signature to verify, and the second is disabled because Secure Boot v2 is not burned.

1. The Windows app verifies the signature before flashing. A binary that does not verify against the production key is refused, and nothing is written to the device.
2. Secure Boot v2 verifies again at boot. Even if a binary reaches the flash by another route, the chip refuses to execute it unless it carries a valid signature.

The second check is the one that matters, because it does not depend on our software behaving correctly. The first exists so that a bad download fails on your PC rather than halfway through a write to the dongle.

Downgrade attacks, and why anti-rollback is not implemented

Anti-rollback is not implemented in the firmware. It requires OTA support that the current firmware does not have. We state this openly rather than let it be discovered.

What stands in its place is the distribution model: superseded versions are not published. There is one channel, and it carries one current release. Installing an older signed image means obtaining it from somewhere that is not us, or compromising the lake8.dev production signing key.

That is weaker than a hardware rollback counter, and the difference is worth stating precisely: a counter in eFuse makes a downgrade impossible, while an unpublished binary makes it inconvenient. An attacker who kept a copy of an older release can still flash it on a dongle they physically hold. What they cannot do is decrypt files, because that needs the seed and not the firmware.

Anti-rollback arrives with the firmware update mechanism, before the public launch — but only for chips burned after that point. The check lives in the bootloader, and a chip with Secure Boot in release mode cannot have its bootloader replaced. Production dongles burned today can never gain it. Developer beta units are the exception: their eFuses are not burned, the board is reversible, and the bootloader can be replaced — so anti-rollback can reach them with a future firmware. That is a permanent property of the hardware, not a scheduling decision, and it is the reason this page describes the distribution model rather than pointing at a future firmware feature.

Verifying a release yourself

⚠️ This section does not apply to the beta. The key below is the Secure Boot v2 public key for production firmware — the dongles with burned eFuses that ship from the April 2027 launch. The beta firmware is not signed, with this key or any other, so there is no .sig file to check and the commands below have nothing to verify. For the beta, check the hashes in SHA256SUMS.txt.

The key stays published either way: a public key is public by construction, and having it out here is what lets you check our work later without asking us.

The production public key is published here:

• /keys/cryptin_prod_pubkey.pem — RSA 3072
• SHA-256 of the key file: 99ada6eb43c99944db50cff1868e508f4663a494fc8065351415b1a21ceb3939
• SHA-256 of the SPKI: 8f39db0554cff0bde5a44d528cd62d22975f21f29380539d26a154daca062412

Check that the key you downloaded is the one we published:

openssl pkey -pubin -in cryptin_prod_pubkey.pem -outform DER \
  | openssl dgst -sha256

Then verify a release against it, before flashing anything:

openssl dgst -sha256 -verify cryptin_prod_pubkey.pem \
  -signature cryptin-firmware.bin.sig cryptin-firmware.bin

Publishing the public key is the point of having one: it is what lets you check our work without asking us. The private half never leaves lake8.dev.

Flashing something else

Technically possible, and we are not going to pretend otherwise.

• Unsigned binaries do not run on production dongles. Secure Boot v2 blocks them on Kit Standard and Kit Pro units, whose eFuses are burned at first boot: the chip refuses to execute an image it cannot verify.
• On developer beta units they do. Since 24 August 2026 beta units run the -dev firmware track with eFuses not burned, so the board accepts any firmware and stays reversible — flash something else and it is a standard ESP32-S3 again. The security consequences are set out on the beta page.
• Self-signed binaries can run, but only on a chip whose secure boot key is your own — an ESP32-S3 you burned with your own key, for your own firmware. That is not a Crypt-in production dongle.
• It is unsupported. No warranty, no assistance, no guarantee that the licence server will accept the device. You own the consequences.

On a production dongle none of this reaches your files, because custom firmware does not run in the first place. On a beta dongle it does, and the flash is readable: treat the seed on a beta unit as extractable by anyone holding it.

What holds on both tracks is narrower, and it is the part worth knowing: without the BIP-39 seed, custom firmware cannot decrypt existing .crin containers, because the file keys derive from the seed. See the security model for how the two layers separate.

Reporting a problem

If you find a way to make a dongle run firmware it should not, that is exactly what the Vulnerability Disclosure Policy is for: security@lake8.dev, PGP key at /security.asc.