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.