Sécuriser une puce n’est plus une question de vérification finale ou de certification jointe au produit avant sa commercialisation, mais un processus qui s’étend de la conception au déploiement et à la surveillance. C’est la principale conclusion d’une discussion à huis clos organisée par Semiconductor Engineering pendant la Design Automation Conference, à laquelle ont participé des experts d’Arteris, Cadence, Keysight EDA, Rambus, Siemens EDA, Synaptics et Synopsys. Cet article s’appuie sur des extraits de cette discussion, animée par Ann Mutschler.
La surface d’attaque s’étend avec la généralisation de l’intelligence artificielle, des chiplets, des systèmes définis par logiciel, des FPGA et des systèmes connectés. Le risque ne se limite donc pas à un défaut physique du circuit ou à une attaque contre la puce elle-même ; il peut commencer par le réseau, les logiciels embarqués ou une couche programmable, puis exploiter une vulnérabilité pour accéder au système ou le mettre hors service.
De la certification à l’utilisation réelle
Yathiendra Vunnam, de Cadence, a indiqué que de nombreux clients adoptent une défense multicouche, en utilisant des mécanismes tels qu’IPsec et MACsec à différents niveaux du modèle OSI afin de répondre aux besoins en matière de performances et de calcul. Il a toutefois également expliqué que certaines entreprises se concentrent sur la certification parce qu’elle les aide à vendre le produit, puis réduisent l’ensemble des protections nécessaires pour parvenir à une conception plus petite, moins coûteuse et réutilisable.
Le problème, selon Scott Best de Rambus, est que disposer d’une technologie de protection ne prouve pas qu’elle est correctement mise en œuvre. Le client peut demander une protection contre les attaques par canaux auxiliaires, les attaques par injection de fautes ou une technologie PUF, puis considérer ces éléments comme des cases cochées dans une liste d’exigences, sans préciser comment les intégrer et les utiliser dans le système final. Il en va de même pour le respect de cadres tels que le CRA et l’ISO 26262, ou pour l’obtention du niveau CSIP Level 3 auprès de Keysight ou d’un concurrent.
Cela ne signifie pas que les certifications ou les normes sont dépourvues de valeur, mais qu’elles ne constituent pas à elles seules une preuve suffisante de la sécurité du produit dans les conditions réelles d’exploitation. L’écart mis en avant par les participants réside dans la différence entre l’existence théorique d’un mécanisme de sécurité et sa capacité à fonctionner lorsqu’il est intégré au reste du matériel, des logiciels et des réseaux.
La visibilité commence par la liste des composants
Alexander Petr, de Keysight EDA, a déclaré que les systèmes modernes sont construits sur des niveaux superposés : une puce, puis un boîtier, une carte, un système et enfin un écosystème connecté comprenant des centres de données et de vastes réseaux. À mesure qu’un nombre croissant de fonctions migrent vers les logiciels embarqués, savoir ce qui entre dans le produit devient une condition pour suivre les risques.
Cela comprend la création d’une liste des logiciels correspondant aux composants matériels, ou ce que Petr a décrit comme l’importance d’une Software Bill of Materials for hardware, ainsi que le suivi des vulnérabilités et la surveillance après le déploiement. La difficulté augmente avec les logiciels open source, car il a évoqué les tentatives d’acteurs malveillants de s’infiltrer dans les communautés open source et d’y injecter des portes dérobées. En outre, découvrir une vulnérabilité zero-day ne suffit pas ; l’entreprise doit d’abord savoir si son système utilise le composant affecté, puis si elle est capable de le corriger ou de mettre en place une défense appropriée.
L’architecture en chiplets ajoute un autre défi. La possibilité d’assembler des unités provenant de sources différentes peut réduire les coûts, car chaque bloc n’a pas nécessairement besoin d’utiliser les nœuds les plus avancés, mais elle soulève une question pratique : comment le concepteur vérifie-t-il la sécurité de chaque chiplet et comment garantit-il que l’unité la moins sûre ne met pas l’ensemble du système en danger ?
La réglementation sensibilise, mais ne garantit pas les pratiques
Les participants ont convenu que les réglementations, notamment la loi européenne sur la cyberrésilience CRA, ont renforcé la sensibilisation et incité certaines entreprises à investir dans des racines de confiance et des protections intégrées. Chris Giles, de Siemens EDA, a déclaré que l’existence de la loi ne suffit pas, car son application sera nécessaire pour transformer les exigences en investissement continu. Les participants ont indiqué que l’échéance liée aux semi-conducteurs est fixée au 11 septembre 2026, tandis que des questions subsistent quant aux informations qui devront être divulguées et à la manière dont cela sera appliqué en pratique.
Mohit Arora, de Synaptics, a également indiqué que les sanctions pourraient atteindre 4 % du chiffre d’affaires annuel, tandis que Reed Hinkel, de Synopsys, a estimé que ce type de pression a commencé à inciter des entreprises jusque-là hésitantes à placer une racine de confiance importante sur la puce ou à adopter des initiatives de l’Open Compute Project telles que Caliptra. La discussion a toutefois montré que l’impact des réglementations sur les pratiques n’est pas encore tranché ; Giles a déclaré que le CRA est très présent dans les échanges, mais qu’il n’était pas certain qu’il ait modifié les pratiques, tandis que Petr a souligné qu’aucune amende n’avait été infligée au moment de la discussion.
Qu’est-ce qui change concrètement ?
La transformation nécessaire ne consiste pas seulement à acheter des outils ou de la propriété intellectuelle de sécurité supplémentaires, mais à répartir la responsabilité entre les équipes de conception, de logiciels, de gestion des produits et d’exploitation. Plus la valeur du service fourni par le produit est élevée, plus le coût d’une défaillance de sécurité et de la responsabilité qui en découle augmente. Hinkel a donc estimé que les promesses de services à forte valeur ajoutée doivent s’accompagner d’une capacité réelle à respecter les accords de niveau de service et à répondre aux vulnérabilités.
Les incitations commerciales et militaires apparaissent également dans la discussion. Les produits bénéficiant de la confiance des utilisateurs peuvent justifier un investissement accru dans la sécurité, tandis que les besoins du département de la Défense des États-Unis et de ses fournisseurs, notamment Boeing et Airbus comme cela a été mentionné dans la discussion, stimulent une partie des investissements dans ce domaine. Cela n’élimine toutefois pas les contraintes : la sécurité est toujours en concurrence avec les coûts et le calendrier de lancement, et la certification peut rester plus facile à mesurer que la qualité du déploiement et de la surveillance.
Concernant la cryptographie post-quantique, Hinkel a expliqué que le défi ne se limite pas au matériel ou au firmware, mais s’étend aux accélérateurs de cryptographie à clé publique PKA, qui ont historiquement été construits sur des couches successives difficiles à mettre à jour et à étendre. Selon la discussion, les produits doivent prendre en charge les nouveaux algorithmes dans un délai de trois ans, tandis que la suppression des anciens algorithmes s’inscrit dans un horizon de cinq ans. Cela indique que la préparation à la cryptographie post-quantique nécessite une réorganisation de l’architecture, et pas simplement l’ajout d’un algorithme à une conception existante.
La principale leçon pour le lecteur technique est que la sécurité démontrable doit couvrir ce qui se trouve à l’intérieur du produit, la manière dont les éléments ont été intégrés et la façon dont ils seront surveillés après la vente. La certification reste un point de contrôle dans ce processus, et non un substitut. Les détails de l’application des réglementations, les limites de la divulgation des vulnérabilités et la capacité des entreprises à traiter les produits déjà présents sur le marché restent des questions ouvertes que la source n’a pas tranchées.