Skip to content
Free public beta until December 4, 2026: every course is open, no card needed. After that, the first chapter of each course stays free and full access is a one-time $39 ($19 for up to 100 founding members chosen for helpful feedback). Your progress is kept. How the beta works

Every place a secret can live

In the image, in plain or encrypted NVS, behind the DS peripheral, in a secure element, or on the server as a slow hash. What a stolen copy would cost decides which.

Start with one question: what could someone do with a copy of this secret? Then pick the cheapest place that stops that.

  • Never in the firmware image. Anything compiled in is on every unit and in every update file. Secrets are per device, provisioned at setup or at the factory.
  • A clone costs little (a classroom node on a test broker) → a per-device credential in plain NVS, scoped by the broker's ACL so a stolen one reaches one device's topics.
  • A clone costs a site's data or control → the DS peripheral (the key can be used, never read) or encrypted NVS, with secure boot.
  • A clone costs someone's safety or property → a secure element, with secure boot and flash encryption.
  • On the server, a user's password is never stored at all: only a slow, salted hash.

Whatever the choice, how it gets there matters as much (provisioning in the field or at the factory), and so does how one device's secret is revoked without touching the others.

On the device, from weakest to strongest

Three attackers (a cable, a lab, replaced firmware) against four places.

See section →
ESP-IDF scrambling the stored-settings partition with a key the chip protects.
See section →
A unit inside some ESP32s that signs with a key the CPU never sees.
See section →
A separate small chip that makes and keeps a device's private key and signs with it, so the key never leaves.
See section →
Flash contents stored AES-XTS-encrypted under a per-chip key in a read-protected eFuse block, decrypted transparently by hardware.

Term

eFuse

See section →
One-time-programmable bits inside the ESP32; once burned they can't be changed, and key blocks can be made unreadable.

What keeps an attacker's firmware from using it

A key that can be used but not read stops cloning, not misuse from the same chip; secure boot stops the misuse.

See section →
The chip runs only code signed by a key whose digest is burned into eFuse (Secure Boot v2 on ESP32).
See section →
The part trusted without a check because nothing runs before it and it can't be changed: ROM plus burned eFuses.

How the secret gets there

The user's network password, entered once, stored in NVS, never in the sketch.

A key pair made on the device, a CSR, and a certificate back.

The same at line speed, with the CA's key in an HSM and the counts reconciled.

See section →
A station that writes factory-made keys into devices and must never keep them.

On the server and in transit

Users' passwords as slow, salted hashes; devices and apps holding tokens.

See section →
A deliberately slow, salted way of turning a password into a stored value, so stolen values are hard to crack.

Term

salt

See section →
Random bytes stored with each password hash so two equal passwords never hash the same.
See section →
A string a client sends with each request to prove it has logged in; whoever holds it is let in.

Section

MQTT over TLS

Without TLS, a password in CONNECT travels as plain bytes.

When one leaks

Term

revocation

See section →
Withdrawing a device's credential before it expires, so the next connection with it is refused.

Example

gh-c3 is stolen: delete its line from the password file and send the broker a SIGHUP; no other device is touched.
See section →
Everything an attacker can reach once one device or credential is compromised.