Garantir la fiabilité dans la conception de processeurs : Bonnes pratiques pour des CI sécurisés et fiables

Les circuits intégrés (CI) modernes fournissent les capacités de calcul et de contrôle système pour traiter d'énormes quantités de données, prendre des décisions critiques pour la sécurité en temps réel et protéger les données sensibles. Concevoir un circuit intégré spécifique (ASIC) ou un système sur puce (SoC) à base de FPGA partir de zéro serait prohibitif en coût et en temps. De nombreuses fonctions critiques sont implémentées via des propriétés intellectuelles (IP) tierces. Les cœurs de processeur, par exemple, proviennent d'organisations spécialisées et offrent une fonction programmable logicielle via leur architecture de jeu d'instructions (ISA), qui définit l'interface matériel-logiciel. Les architectures de processeur open source offrent une opportunité d'examen approfondi et d'assurance sécurité rigoureuse dans des systèmes déjà confrontés à un environnement de menaces fluide. Cet article décrit une approche pour l'assurance sécurité des IP et SoC basée sur l'ISA open source RISC-V.

Inventée à l'Université de Californie et gérée par la fondation RISC-V à but non lucratif, RISC-V est la première ISA open source à devenir un choix industriel véritablement viable pour une large gamme d'applications.

RISC-V est une ISA open source inventée à l'Université de Californie et gérée par la fondation RISC-V, une organisation à but non lucratif comptant plus de 300 membres fondée en 2015. RISC-V est la première ISA open source à devenir un choix industriel véritablement viable pour une large gamme d'applications. L'écosystème d'outils, logiciels et d'expertise est robuste et croît régulièrement. De nombreux individus et organisations ont déjà donné des IPs matérielles open source implémentant l'ISA RISC-V. Le groupe OpenHW, par exemple, vise à rendre la perspective tant attendue de matériel open source — particulièrement les cœurs de processeur — pour puces à haut volume une réalité.

L'essor de RISC-V a de multiples raisons. Conçue dès le départ avec l'extensibilité personnalisée à l'esprit, RISC-V permet un nouveau niveau d'optimisation matérielle pour des charges de travail spécifiques. La loi de Moore ralentit, et la personnalisation devient cruciale pour maintenir le niveau d'amélioration des performances que les avancées technologiques de fabrication ne peuvent plus fournir. De plus, l'architecture RISC-V est exempte de coûts de licence et de redevances, permettant à plus d'entreprises de développer des produits innovants et abordables. Beaucoup se passe dans l'IoT et les wearables avec capacités d'IA, par exemple.

Les intégrateurs SoC utilisent souvent des IPs de processeur RISC-V open source ou tierces. Ces conceptions et leurs chaînes d'outils associées peuvent être augmentées d'instructions personnalisées. Un environnement de vérification de haute qualité livré avec l'IP et des tests système additionnels peuvent donner une certaine confiance que l'IP n'a pas de bugs critiques. Malheureusement, pour de nombreuses applications, cela ne suffit pas, et d'autres risques sérieux doivent être considérés.

Vulnérabilités et chevaux de Troie

Traditionnellement, les vulnérabilités de sécurité dans les systèmes électroniques ont été associées aux problèmes au niveau système et logiciel. Plus récemment, les IPs matérielles, notamment les processeurs, sont devenues une préoccupation centrale (voir Fig. 1). Les implémentations de processeur utilisent des microarchitectures à pipeline et incluent souvent des fonctionnalités d'optimisation performance et énergie. La complexité augmente le risque de manquer non seulement des bugs fonctionnels mais aussi des vulnérabilités de sécurité. Les chercheurs en sécurité qui ont découvert les attaques Meltdown et Spectre début 2018 ont démontré que les fonctionnalités d'optimisation de performance dans les processeurs peuvent être détournées à des fins néfastes. Depuis, de nombreuses autres vulnérabilités dans les processeurs haut de gamme et bas de gamme ont été découvertes. Les canaux auxiliaires et attaques d'exécution transitoire peuvent violer des enclaves sécurisées et permettre à des applications malveillantes de fuiter des données confidentielles ou même de prendre le contrôle du système. Et contrairement au logiciel, les problèmes matériels ne peuvent pas être facilement corrigés par des mises à jour over-the-air. Adresser un problème matériel par logiciel cause souvent une dégradation sévère de performance.

L'architecture RISC-V possède de nombreuses fonctionnalités soutenant l'implémentation de systèmes embarqués sécurisés. La spécification de privilèges définit quatre modes de privilège (machine, superviseur, hyperviseur et utilisateur), par exemple. Les instructions personnalisées et extensions ISA en cours de ratification, comme l'extension cryptographique, fournissent des capacités de sécurité supplémentaires. Les concepteurs peuvent implémenter plusieurs enclaves sécurisées pour isoler les applications et prévenir la fuite de données sensibles. Cependant, les fonctionnalités micro-architecturales RTL peuvent encore résulter en vulnérabilités de sécurité. Ces risques ne peuvent pas être entièrement adressés au niveau ISA. Une nouvelle approche en exploration est l'utilisation d'une ISA augmentée (aISA) pour définir des aspects de l'exécution d'instruction au niveau micro-architectural et, par exemple, contrôler l'état de tampons ou registres non visibles au niveau ISA. Des bugs fonctionnels RTL pourraient encore compromettre toutes ces fonctionnalités de sécurité.

Un risque moins probable mais d'une sévérité bien plus élevée est la présence de logique malveillante ou de chevaux de Troie matériels dans le cœur RISC-V. Un cheval de Troie matériel est une fonction logique conçue délibérément pour être furtive, qui s'active dans des circonstances très rares connues seulement de l'attaquant. Une séquence spécifique d'événements de données et de contrôle qui ne se produirait pas pendant l'exploitation du système dans ses cas d'usage cibles déclenche la logique du cheval de Troie, qui livre alors une charge utile dommageable, comme la fuite d'un secret ou la corruption critique du comportement système. Les intégrations SoC utilisant des cœurs RISC-V open source ou tierces ne peuvent plus ignorer ce risque.

S'assurer qu'un processeur fait ce qu'il est censé faire est difficile, mais s'assurer qu'il ne fait rien de ce qu'il n'est pas censé faire est une tâche encore plus ardue qui reste largement non adressée. Les systèmes critiques pour la sécurité et ceux où la protection de la vie privée des données est primordiale ont besoin de solutions efficaces et de haute qualité adressant le risque de vulnérabilités de sécurité et de chevaux de Troie.

Figure 1 : La base de données CVE-MITRE a enregistré 6488 vulnérabilités en 2015, dont 43% classables comme vulnérabilités matérielles assistées par logiciel. En 2018 et 2019, les chercheurs ont découvert et rapporté de nombreuses vulnérabilités dans les processeurs, incluant Meltdown, Spectre, Foreshadow, ZombieLoad, RIDL et Fallout. (Source : DARPA et OneSpin)

Assurance matérielle intelligente

Assurer la confiance et la sécurité des IPs RISC-V nécessite des solutions techniques innovantes et efficaces, complémentaires aux approches de correction fonctionnelle, ciblant principalement les cas d'usage prévus de l'IP (voir Fig. 2). Les fournisseurs d'IP sont responsables de l'application de processus de vérification de confiance et sécurité à l'état de l'art, tandis que les intégrateurs d'IP devraient avoir accès à des solutions d'assurance indépendantes déployables rapidement et sans connaissance approfondie des détails d'implémentation de l'IP.

Les méthodes formelles peuvent analyser les fonctions matérielles exhaustivement et délivrer la preuve que l'IP ou le SoC correspond précisément à un comportement attendu, souvent capturé en assertions SystemVerilog. La vérification formelle matérielle via des model checkers commerciaux a connu une adoption large cette dernière décennie. Typiquement, fournisseurs d'IP et intégrateurs SoC comptent des experts en vérification formelle dans leurs rangs, cherchant à minimiser le risque de manquer des bugs fonctionnels. Bien que certaines tâches de vérification formelle bien définies puissent être automatisées via des Apps, en général, un effort d'ingénierie significatif est nécessaire pour capturer le comportement attendu de l'IP en assertions. De plus, il n'y a aucune garantie qu'assez d'assertions aient été écrites. Des fonctions non documentées ou des lacunes involontaires dans l'ensemble des assertions pourraient mener à une fonctionnalité IP non vérifiée.

La nature open source de RISC-V permet le développement de solutions d'assurance indépendantes, pré-packagées. La solution de vérification d'intégrité RISC-V de OneSpin, par exemple, s'applique à une large gamme de microarchitectures. Elle inclut des modèles de l'ISA RISC-V et de l'ISA privilégiée qui sont extensibles et peuvent accommoder des instructions personnalisées. Un aspect crucial de cette solution est qu'elle repose sur le processus GapFreeVerification™ de OneSpin, qui délivre une preuve rigoureuse que l'ensemble des assertions modélisant l'ISA RISC-V est complet et exempt de lacunes. Cet aspect est d'une importance capitale quand la détection de chevaux de Troie matériels ou de logique non documentée est un objectif crucial. La solution permet aux intégrateurs SoC avec une expertise limitée sur RISC-V et l'implémentation RTL sous examen de gagner en confiance dans la qualité et la fiabilité de l'IP. Les développeurs d'IP peuvent l'utiliser pour détecter faiblesses de sécurité et bugs fonctionnels avant la release.

Figure 2 : La vérification de correction fonctionnelle donne confiance qu'une implémentation de processeur se comporte comme spécifié et satisfait les exigences des utilisateurs finaux. La vérification de confiance et sécurité, elle, donne confiance que le processeur n'a pas de fonctions non documentées, canaux auxiliaires imprévus, chevaux de Troie matériels ou autres vulnérabilités exploitables par des acteurs malveillants. (Source : OneSpin)

Est-ce que ça marche ?

Le processus d'assurance d'intégrité RISC-V décrit dans la section précédente a été appliqué avec succès à plusieurs conceptions RTL. Edaptive Computing, une entreprise qui intègre des solutions innovantes pour optimiser, assurer et automatiser rapidement des systèmes de systèmes et processus pour divers clients du Département de la Défense américain et du secteur commercial, a appliqué le processus au RocketCore, par exemple. Le RocketCore est un cœur RISC-V 64 bits open source, prouvé en silicium, avec un système de mémoire virtuelle 39 bits. Il a un pipeline à 5 étages, single-issue, in-order, avec achèvement out-of-order pour les instructions à latence longue comme la division. Il inclut les fonctionnalités avancées de prédiction de branchement et de rejeu d'instruction.

La solution de vérification d'intégrité RISC-V a été appliquée à la conception avec toutes les instructions, niveaux de privilège, interruptions et mécanismes d'exception, et 8 problèmes ont été détectés (voir Fig. 3). Des informations supplémentaires sur 3 d'entre eux sont rapportées ci-dessous.

Cas limite de division

Un bug de cas limite profond associé à l'achèvement out-of-order de l'instruction de division. Ce problème aurait pu causer un programme logiciel utilisant la division à calculer des résultats incorrects et mener à un mauvais comportement système. Le problème n'apparaît que sous une combinaison de circonstances rares, c'est pourquoi les efforts de vérification précédents l'avaient manqué.

Rejeu d'instruction illégale

Ce n'est pas un bug de cas limite. Rejouer une instruction illégale peut gaspiller des cycles de traitement, mais si cela n'arrive que dans de rares situations, l'impact performance est négligeable. Cependant, il y a d'autres aspects à considérer. Le rejeu d'instruction peut causer des requêtes mémoire inutiles. Ces requêtes peuvent avoir des effets de bord exploitables dans des attaques par canaux auxiliaires. Par conséquent, ce comportement doit être soit éliminé, soit clairement compris et documenté.

Instruction non documentée

Une instruction non standard, non documentée, appelée CEASE, qui arrête le cœur, a été détectée. En effet, le RocketCore RISC-V pouvait faire quelque chose qu'il n'était pas censé faire. Les fonctions cachées non documentées ne sont pas acceptables quand la confiance et la sécurité sont un souci, même si elles concernent des cas d'usage jugés non pertinents pour l'application finale.

L'étude de cas RocketCore est présentée en détail dans l'article GOMACTech 2019 intitulé Complete Formal Verification of RISC-V Processor IPs for Trojan-Free Trusted ICs. Pour obtenir une copie, visitez onespin.com/resources/white-papers.

Figure 3 : Liste des problèmes détectés par la solution de vérification d'intégrité RISC-V de OneSpin et rapportés dans le projet GitHub RocketCore. (Source : OneSpin)

Quelle suite ?

Le processus d'assurance RISC-V présenté dans cet article détecte les scénarios pouvant affecter la sécurité, et dévoile systématiquement les fonctions non documentées et chevaux de Troie matériels impactant le comportement du processeur, quelle que soit leur rareté et furtivité. Cependant, les canaux auxiliaires ne sont pas systématiquement détectés. La détection exhaustive de tous les canaux auxiliaires potentiels nécessite une solution dédiée avec technologie appropriée. Il existe déjà des prototypes adressant ce défi. Pour plus d'informations, visitez onespin.com/resources/technical-articles et lisez l'article EE Times Side-Channel Attacks on Embedded Processors.

Les cœurs de processeur sont des IPs cruciales dans les systèmes embarqués. Cependant, un SoC typique intègre de nombreuses autres IPs qui pourraient aussi contenir des chevaux de Troie matériels. Contrairement aux cœurs RISC-V, des solutions d'assurance de confiance indépendantes pourraient ne pas être facilement disponibles. Dans ce cas, il serait précieux d'avoir un processus d'évaluation de fiabilité automatisé, à faible effort, applicable à toute IP. Un processus n'incluant pas un modèle de confiance de l'IP ne peut pas garantir l'absence de cheval de Troie. Cependant, il est possible d'identifier des motifs de code inhabituels et suspects et des signatures de chevaux de Troie connues, ainsi que des faiblesses exploitables dans les étapes de développement ultérieures à des fins néfastes. Un article sur ce sujet intitulé An Automated Pre-Silicon IP Trustworthiness Assessment for Hardware Assurance, écrit par des ingénieurs d'AEROSPACE Corporation et OneSpin, sera présenté à la conférence GOMACTech 2020.