Traduit de English par IA ·
Projet de fin d’études, ESP32-WROOM + module microSD, envoie les mesures d’une serre à Hermetry via MQTT/TLS. Ça fonctionne.Mon encadrant a demandé pourquoi le token est compilé dans le firmware et m’a suggéré de déplacer tous les « éléments de sécurité » (token, bundle CA, identifiants WiFi) dans un fichier sur la carte SD, afin que le même binaire puisse être installé sur chaque carte et que je n’aie qu’à changer de carte. Ça semble pratique. Mais un ami m’a dit que stocker des secrets sur un support amovible est l’une des pires choses à faire.J’ai aussi lu qu’Hermetry prend en charge les certificats client X.509 et je pensais opter pour cette solution en gardant aussi le certificat et la clé sur la carte. En fait, j’ai deux questions :
- Est-il vraiment mauvais de conserver des identifiants sur une mémoire externe, et pourquoi ?
- Puis-je utiliser mon propre certificat X.509 avec Hermetry ?
Je veux comprendre le raisonnement, pas seulement entendre « ne le fais pas », car je dois l’expliquer dans mon rapport.
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.
Traduit de English par IA ·
Votre ami a raison en général. Quiconque dispose de 10 secondes seul dans la serre repart avec la carte et l’identité de votre appareil.
Your friend is right in general. Anyone with 10 seconds alone in the greenhouse walks away with the card and your device’s identity.
Traduit de English par IA ·
Mais si c’est en flash, ils peuvent aussi lire la flash, non ? Honnêtement, je ne vois pas la différence.
But if it’s in flash they can read the flash too, no? I don’t see the difference honestly.
Traduit de English par IA ·
La différence réside dans l’effort. Retirer une carte ne demande aucune compétence. Extraire la mémoire flash est aussi facile sur un ESP32, sauf si le chiffrement flash est activé. Avec le chiffrement flash + le chiffrement NVS, un dump ne donne que des données illisibles.
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.
Traduit de English par IA ·
J’ai examiné une conception similaire pour un sous-traitant l’an dernier, voici donc le raisonnement pour le rapport.Séparez les éléments publics des éléments secrets. Le bundle CA est public ; le certificat serveur est un certificat public que l’on vérifie avec un bundle CA normal, donc le conserver sur la carte ne pose pas de problème. Le mot de passe WiFi et le jeton de l’appareil sont des secrets, car ils identifient précisément cet appareil.Les secrets sur un support amovible échouent pour deux raisons : retirer la carte ne laisse aucune trace, et la carte est souvent copiée sur d’autres cartes (« clone simplement la carte »), ce qui fait que plusieurs appareils partagent un même identifiant. Hermetry n’autorise qu’une session par appareil ; deux cartes avec le même jeton se déconnectent donc sans cesse mutuellement, et vous verriez une prise de contrôle dans l’onglet Log de l’appareil.Concernant X.509 : pour vos propres cartes, ce n’est pas disponible. Les certificats clients doivent provenir de l’autorité de certification des appareils de Hermetry, et l’envoi de votre propre CA pour des appareils tiers n’est pas proposé ; cette voie concerne les appareils sous licence qui génèrent leur clé et envoient eux-mêmes une CSR. Votre ESP32 utilise un jeton d’accès ou MQTT basic.Ce que je ferais sur un ESP32 :1. Le même binaire pour chaque carte convient. Placez le jeton dans la NVS lors du provisionnement (une petite commande série au premier démarrage), et non sur la carte.2. Activez le chiffrement de la flash et le chiffrement de la NVS, afin qu’un dump de la flash ne révèle pas le jeton.3. La carte ne sert qu’à l’enregistrement des données et au bundle CA.4. Dans Hermetry, un appareil et un jeton par carte ; changez le secret si une carte disparaît. Cela met immédiatement fin à ses sessions.La limitation concernant les certificats est décrite dans la dernière section de Device certificates.
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.
Traduit de English par IA ·
Vraiment utile, merci. Le superviseur a accepté « CA publique sur la carte, secrets dans la NVS chiffrée ». La partie X.509 m’a fait gagner une semaine, j’avais déjà commencé à générer une CA avec openssl. Drôle de hasard : la semaine dernière, j’avais cloné la carte pour une deuxième carte, et les données étaient incomplètes, c’était exactement le problème de prise de contrôle.
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.
Traduit de English par IA ·
ok, le cadrage « zéro compétence vs quelques compétences » a du sens, merci.
ok the « zero skill vs some skill » framing makes sense, thanks.
- Vous devez être connecté pour répondre à ce sujet.
Rejoignez la discussion
Connectez-vous pour poser et répondre à des questions, aimer les messages utiles et marquer la réponse qui a résolu votre problème. Chaque contribution rapporte des points et des niveaux.