Firmware Update Security

Firmware updates are distributed exclusively through the releases page of github.com/lake8dev/cryptin-sdk, signed with the lake8.dev production key. That repository opens at the developer beta on 30 September 2026 and does not exist yet, which is why this is not a link.

Two independent verifications

A firmware image is checked twice, by two different things, before it can run:

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. Dongles burned today, beta units included, can never gain it. 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

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. Secure Boot v2 blocks them on every Crypt-in dongle — beta units and launch units alike, because the eFuses are burned when the firmware is flashed: the chip refuses to execute an image it cannot verify.
• 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 dongle, and it is not what a beta tester ends up with: flashing Crypt-in burns the lake8.dev key.
• It is unsupported. No warranty, no assistance, no guarantee that the licence server will accept the device. You own the consequences.

None of this reaches your files. Custom firmware without the BIP-39 seed cannot decrypt existing .crin containers, because the file keys derive from the seed and not from anything the dongle hands over. 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.