Clés WireGuard sur ESP32 : par appareil ou une seule intégrée ?

Le croquis place la clé privée WireGuard dans un tableau de caractères, et le tunnel fonctionne, d’où la question qui revient sans cesse. La décision à prendre n’est pas « est-ce sûr » mais « laquelle des trois conditions s’applique à ce déploiement ». Les voici : qui peut tenir physiquement l’appareil, ce que donne une lecture de la flash sur votre pièce, et si la flotte partage une clé ou en porte une chacune. Répondez-y et la conception suit, car chaque condition change le coût d’une clé divulguée, pas le fait qu’elle puisse l’être.

Ce que la clé autorise

WireGuard authentifie les pairs par clé publique. Le serveur associe la clé publique de chaque pair à une adresse et à une AllowedIPs liste, donc c’est la clé privée qui permet à un client d’émettre du trafic depuis cette adresse.

La même entrée décide des destinations que l’appareil peut atteindre, donc une clé divulguée expose le réseau derrière le tunnel ainsi que l’adresse du tunnel.

Première condition : qui peut tenir l’appareil

Si l’unité vit dans une armoire fermée et que personne hors de votre équipe ne la manipule, l’exposition est surtout une question de distribution du firmware. Si elle est expédiée à des clients, placée dans un véhicule ou revient sous garantie, la possession physique est l’authentifiant et le secret du binaire est secondaire. Celui qui tient l’appareil n’a pas besoin de lire la clé, car le firmware en cours lui ouvrira le tunnel. C’est pourquoi la réponse côté serveur doit inclure la révocation et une durée de vie bornée, pas seulement une image protégée.

Tranchez cette condition avant les deux autres, car elle fixe le budget des deux.

Deuxième condition : ce que donne une lecture de la flash

Quiconque peut lire l’image de la flash récupère une clé stockée en clair, que ce soit par une connexion de débogage, un fichier de mise à jour, une sauvegarde ou une unité retournée. Le chiffrement de la flash augmente le coût d’un vidage direct, et la documentation ESP-IDF décrit ce que la fonction couvre pour une pièce et une configuration données. Il ne rend pas la clé inextractible sous tous les modèles d’attaque, et il ne fait rien pour le cas de l’appareil en main. Traitez-le comme une couche qui change le coût, pas comme la réponse.

Lisez la documentation de la plateforme pour votre puce et votre configuration exactes avant d’affirmer une propriété en revue de conception.

Troisième condition : réutilisation sur toute la flotte

Une clé pour une série de production signifie que chaque unité partage une identité. Le serveur ne peut pas les distinguer dans les journaux, ne peut pas en révoquer une sans révoquer toutes, et ne peut pas distinguer un clone d’un original. Les clés par appareil règlent les trois, au prix d’une étape d’enrôlement et d’une correspondance entre numéro de série et clé publique. Cette correspondance est l’actif qui transforme la révocation en changement d’une ligne au lieu d’un reflashage de toute la flotte.

Si la flotte compte cinq unités sur un établi, partager une clé peut être un compromis raisonnable. Si elle en compte cinq cents sur le terrain, ce n’est pas un compromis du tout.

Le schéma d’enrôlement qui rend les clés par appareil praticables

Générez la paire de clés sur l’appareil au premier démarrage, gardez la moitié privée dans un stockage non volatil protégé et n’envoyez que la clé publique à un service d’enrôlement qui attribue une adresse et écrit l’entrée de pair. Authentifiez la réponse d’enrôlement, sinon un attaquant du réseau local peut enregistrer sa propre clé sur votre compte. N’imprimez jamais la clé privée sur la console série pendant le provisionnement. Notez le numéro de série de l’appareil à côté de la clé publique, pour qu’une unité perdue corresponde exactement à une entrée de pair.

C’est un petit service, et c’est la différence entre une flotte que vous pouvez auditer et une flotte que vous ne pouvez que reflasher.

Temps, points de terminaison et la décision

L’exemple synchronise l’heure avant de démarrer le tunnel, et cela compte au-delà de TLS : les poignées de main WireGuard portent un horodatage pour la protection contre la relecture, donc un appareil qui démarre avec une mauvaise horloge peut voir ses poignées de main rejetées. Le point de terminaison est un nom d’hôte, ce qui place le DNS dans le chemin de confiance même si la clé publique du serveur authentifie toujours le pair. Une mauvaise adresse gaspille des tentatives et révèle quand l’appareil est en ligne. Réglez les deux avant de discuter de la clé.

Décidez ensuite : une clé partagée seulement tant que la possession est maîtrisée et la flotte petite, des clés par appareil dès que l’un des deux cesse d’être vrai.