Un élément sécurisé renchérit chaque carte. À partir de quel volume ça se justifie ?

Le composant coûte quelques dizaines de centimes à l'unité, parfois moins en gros volume. Le vrai surcoût n'est pas là : il est dans le routage d'une piste de plus sur le PCB, dans le pilote logiciel à intégrer, et dans la chaîne de personnalisation. Sur un prototype de dix cartes, ça paraît disproportionné. Sur une série, le calcul s'inverse vite, et il dépend surtout de ce que vous protégez : pour un jouet connecté, on peut discuter ; pour un équipement qui ouvre une porte ou relève un compteur facturé, la question ne se pose plus.

On m'a vendu une puce avec un bit de désactivation du JTAG. C'est suffisant pour protéger mes clés ?

Non, et c'est une confusion courante. Verrouiller le port de debug (le JTAG, l'interface qui sert à programmer et inspecter la puce) ferme une porte évidente, mais ça laisse le contenu de la flash en clair pour qui sait la lire autrement : injection de fautes (perturber la puce, par exemple par une impulsion électrique, pour la faire déraper), attaque par canal auxiliaire (déduire la clé en observant la consommation ou les émissions de la puce), lecture directe après dessoudage. Un fusible anti-debug fait partie du durcissement, il ne remplace pas un composant dont la conception garantit que le secret ne franchit jamais la frontière du silicium. Le premier ralentit un curieux, le second arrête quelqu'un d'équipé.

Comment je gère le secret d'usine quand mon assemblage est sous-traité à l'étranger ?

C'est le point aveugle de beaucoup de projets. Si vous envoyez vos clés au façonnier (le sous-traitant qui assemble vos cartes), vous leur faites confiance à eux et à toute leur chaîne. La parade propre, c'est de ne jamais transmettre le secret : l'élément sécurisé génère sa clé privée en interne et ne la sort jamais, le sous-traitant ne manipule qu'une clé publique sans valeur s'il fuite. Vérifiez aussi qui détient l'autorité de certification, l'entité qui émet et peut invalider les certificats d'identité : si c'est le fondeur (le fabricant de la puce), vous dépendez de sa politique de révocation, pas de la vôtre.

Sécuriser la connectivité d'un objet exposé

Une seule carte ouverte sur un établi, et tout un parc devient usurpable. C’est ce que j’ai constaté sur un projet où les mêmes clés dormaient dans la flash de chaque objet : une simple copie brute de la mémoire (un « dump ») suffisait à se faire passer pour n’importe quel équipement du terrain. L’incident résume la vraie singularité de l’IoT. Un objet connecté n’est pas un serveur. Le serveur dort dans une salle climatisée, sous badge et caméra. L’objet, lui, est sur un poteau, dans un local technique partagé, parfois posé sur un rebord de fenêtre. Joignable sur le réseau, et attrapable à la main : c’est cette double exposition qui commande tout ce qui suit.

Sécuriser un objet connecté tient en trois gestes : chiffrer toutes les communications, authentifier dans les deux sens, et ranger les secrets dans un composant qui résiste à l’extraction physique.

Chiffrer toutes les communications

Tout ce qui circule entre l’objet et le serveur passe par du chiffrement, TLS (le protocole qui sécurise déjà les connexions web, le « cadenas » du navigateur) ou un équivalent adapté à la cible. Mesures, commandes, identifiants : sans cette couche, ces données voyagent en clair, et qui se trouve sur le chemin réseau les lit ou les réécrit sans laisser de trace. Le chiffrement ferme lecture et falsification du même geste.

On me sort encore l’argument de l’objet contraint : « TLS, c’est trop lourd pour notre micro, on économise les ressources ». Sur un Cortex-M moderne (la famille de microcontrôleurs la plus répandue dans l’embarqué), quelques kilo-octets de RAM en plus font tourner une pile allégée. L’économie est dérisoire ; la porte qu’elle laisse ouverte, beaucoup moins.

Authentifier dans les deux sens

C’est le point qu’on comprend de travers le plus souvent. Les deux parties doivent prouver qui elles sont.

L’objet vérifie le serveur. Il s’assure de parler au vrai serveur, pas à un imposteur qui lui glisserait de faux ordres ou, pire, un faux firmware en détournant le canal de mise à jour embarqué.
Le serveur vérifie l’objet grâce à son identité individuelle, pour reconnaître un membre légitime de la flotte plutôt qu’une carte clonée qui injecte de fausses données.

Une authentification à sens unique, comme sur un site web où seul le serveur se présente, laisse l’objet exposé à un serveur usurpé. Ici, les deux directions comptent autant l’une que l’autre.

Protéger les secrets dans le matériel

Voilà la spécificité qui n’existe pas pour un serveur en salle fermée. L’objet est physiquement à portée. Un attaquant peut en acheter un, le voler, l’ouvrir, tenter d’en extraire clés et certificats. Quand ces secrets dorment en clair dans la mémoire, un dump de flash les récupère en quelques minutes, et avec eux l’objet s’usurpe à volonté.

La parade tient dans un élément sécurisé dédié, un petit composant conçu pour que les secrets ne sortent jamais, même sous le microscope. Je reviens au projet du début : les clés y étaient identiques sur toute la flotte, posées dans la flash principale « le temps de la phase pilote ». Le pilote a duré deux ans avant de partir en série. Des clés individuelles par objet auraient réglé l’affaire : ouvrir une carte ne compromet alors qu’elle seule, et on la révoque sans toucher au reste. Reste ensuite à calibrer le niveau de protection selon ce que l’objet pilote, parce qu’un capteur de température et une serrure connectée ne jouent pas dans la même catégorie.

L’esprit

Un objet non sécurisé n’est pas qu’un objet vulnérable : c’est une porte d’entrée vers vos données, votre infrastructure, parfois jusqu’au réseau de vos clients à travers le vôtre. Chiffrer les échanges, authentifier des deux côtés, mettre les secrets hors de portée d’une extraction physique : ces mesures se posent à la conception, dans le schéma et le choix du composant. Jamais en rustine une fois les objets sur le terrain.

Ce que ce socle ne couvre pas

Autant être honnête sur le périmètre. Ce socle ferme la connectivité ; il ne protège pas l’objet contre lui-même. Une faille dans votre code applicatif, une mise à jour mal signée, un capteur que l’on trompe par le monde physique plutôt que par le réseau : tout cela passe à travers ces trois protections sans les heurter. Elles supposent aussi une discipline qui tient dans la durée, un suivi des certificats, des correctifs poussés pendant toute la vie du produit, parfois dix ans. C’est la part qu’on ne voit pas au moment de la conception et qui décide pourtant si l’objet reste défendable une fois oublié sur son poteau.