Final year project, ESP32-WROOM + microSD module, sends readings from a greenhouse to Hermetry over MQTT/TLS. Works.
My supervisor asked why the token is compiled into the firmware and suggested I move all the “security stuff” (token, CA bundle, WiFi credentials) to a file on the SD card so the same binary can go on every board and I just swap cards. Sounds neat. But then a friend said that keeping secrets on removable storage is about the worst thing you can do.
I also read that Hermetry supports X.509 client certs and I was thinking of going that way and keeping the cert and key on the card too. So two questions really:
- is it actually bad to keep credentials on external memory, and why
- can I use my own X.509 cert with Hermetry?
I’d like to understand the reasoning, not just “don’t”, because I need to write it up in the report.
Your friend is right in general. Anyone with 10 seconds alone in the greenhouse walks away with the card and your device’s identity.
But if it’s in flash they can read the flash too, no? I don’t see the difference honestly.
Difference is effort. Pulling a card is zero skill. Dumping flash is easy on an ESP32 too, unless flash encryption is on. With flash encryption + NVS encryption, a dump gives you garbage.
Did a review of a similar design for a contractor last year, so here’s the reasoning for the report.
Separate public stuff from secret stuff. The CA bundle is public; the server certificate is a public one and you verify it with a normal CA bundle, so keeping that on the card is fine. WiFi password and the device token are secrets, they identify this exact device.
Secrets on removable media fail on two counts: removing them leaves no trace, and the card usually gets copied into other boards (“just clone the card”), and then you have several devices sharing one credential. Hermetry allows one session per device, so two boards with the same token keep kicking each other off, and you’d see takeover in the device’s Log tab.
On X.509: for your own boards it’s not available. Client certificates must come from Hermetry’s device certificate authority, and uploading your own CA for third-party devices is not offered; that path is for licensed devices that generate their key and send a CSR themselves. Your ESP32 uses an access token or MQTT basic.
What I’d do on an ESP32:
1. Same binary for every board is fine. Put the token in NVS at provisioning (a small serial command on first boot), not on the card.
2. Turn on flash encryption and NVS encryption, so a flash dump does not give up the token.
3. Card only for data logging and the CA bundle.
4. In Hermetry, one device and one token per board; rotate the secret if a board goes missing. That ends its sessions at once.
The certificate limitation is on Device certificates, last section.
Really helpful, thank you. Supervisor accepted “public CA on card, secrets in encrypted NVS”. The X.509 bit saved me a week, I had already started generating a CA with openssl. Funny enough I had cloned the card for a second board last week and the data was patchy, it was exactly the takeover thing.
ok the “zero skill vs some skill” framing makes sense, thanks.
- You must be logged in to reply to this topic.
Join the conversation
Sign in to ask and answer, like helpful posts and mark the reply that solved your problem. Every contribution earns points and levels.