Fuzzing pour valider la sécurité SoC. Innovation dans la vérification

Le fuzzing est à la vérification logicielle ce que la randomisation est à la vérification matérielle. Une approche de fuzzing peut-elle améliorer les tests de sécurité matérielle ? Paul Cunningham (GM, Verification at Cadence), Raúl Camposano (Silicon Catalyst, entrepreneur, ancien CTO de Synopsys) et moi continuons notre série sur les idées de recherche. Comme toujours, les commentaires sont les bienvenus.

L'innovation

Le choix de ce mois-ci est HyperFuzzing pour la validation de la sécurité SoC. Les auteurs ont présenté cet article à l'ICCAD 2020. Ils sont de l'IIT Kanpur.

Il s'agit d'une approche intrigante du fuzzing, adaptée spécifiquement à la conception moderne des SoC. Il s'appuie sur hyper-propriété vérification dans les simulations dynamiques. Ces hyper-propriétés raisonnent sur les comportements ensembles de traces, une approche bien adaptée au contrôle de sécurité. Les auteurs proposent comme exemples des contrôles de flux d'informations (les données privilégiées ne peuvent pas fuir de A à B, par exemple) et des contrôles de non-interférence (les actions contradictoires ne doivent pas interférer avec le flux de calculs). La sécurité est ensuite vérifiée en comparant des faisceaux de traces de simulation avec et sans falsification.

La falsification dans cette approche peut modéliser différents types de vulnérabilités à des sources non fiables. En randomisant les instructions du micrologiciel, écrivez des instructions d'un composant vers le NoC ou des retournements de bits dans une mémoire. Les auteurs proposent également plusieurs nouveaux paramètres de couverture. Ceux-ci sont conçus pour guider les itérations vers la falsification autour des cas les plus influencés par les exécutions de falsification précédentes.

Leur cas de test est un SoC petit mais représentatif (détails dans GitHub) en exécutant des tests de micrologiciel sur des blocs cryptographiques, en vérifiant la non-interférence et d'autres vulnérabilités. Ils exécutent également un démarrage sécurisé avec vérification des blocs de données. Ils ont trouvé plusieurs violations de sécurité dans les blocs de chiffrement, sauf lorsque le bloc inclut la protection ECC.

le point de vue de Paul

La vérification de la sécurité est un sujet tellement important, et il y a beaucoup de travail en cours ici, tant dans le milieu universitaire que dans l'industrie. Cet article associe joliment une couverture aléatoire basée sur les mutations avec des "hyper-propriétés" sur des ensembles de traces de simulation pour créer une solution innovante à la fois évolutive et efficace pour démontrer les failles de sécurité.

Certaines propriétés de sécurité ne peuvent être formellement définies que sur un ensemble de traces de simulation. Par exemple, « non-interférence » signifie qu'un attaquant ne peut pas interférer avec certains calculs protégés dans une conception. Pour démontrer l'interférence, vous devez comparer deux traces, identiques dans le stimulus d'entrée, à l'exception de la présence de certaines actions de l'attaquant dans une trace. Si des calculs protégés dans la trace attaquée diffèrent de ceux de la trace dorée, il y a alors eu interférence.

Les auteurs créent leur propre langage spécial pour les assertions sur plusieurs traces et l'utilisent pour formuler des propriétés de sécurité pour la non-interférence et la confidentialité. Ils créent un flux personnalisé pour falsifier de manière aléatoire les simulations et vérifier leurs propriétés de sécurité entre les simulations falsifiées et non falsifiées. Leur algorithme de falsification aléatoire dispose également d'une élégante heuristique d'apprentissage basée sur la couverture pour le guider afin de trouver plus efficacement les failles de sécurité.

L'idée d'assertions sur plusieurs simulations est très puissante. Je me demande s'il serait possible d'étendre proprement SystemVerilog pour prendre en charge ce type d'assertions. Cela pourrait ouvrir la porte à des extensions natives convaincantes de la simulation commerciale et des outils formels. Une autre possibilité pourrait être d'étendre le nouveau Portable Stimulus Standard (PSS) pour inclure des assertions qui s'étendent sur plusieurs tests générés.

Ce document est une lecture facile et agréable, même si je souhaite avoir plus de détails sur les résultats. Les auteurs affirment que leur solution trouve des failles de sécurité dans leur cas de test SoC open source, mais il n'y a aucun détail sur ce que sont ces failles ou sur la façon dont leur approche se compare à d'autres approches de la littérature qui pourraient être appliquées pour trouver les mêmes failles.

Le point de vue de Raul

Je vais d'abord examiner cela sous l'angle de la maturité technologique. J'aime l'idée en général, une approche très intéressante du grade pour la sécurité dans une conception. Cela dit, chaque conception nécessite que les concepteurs fournissent des tests de départ, des falsifications et des spécifications de sécurité dans un nouveau langage d'assertion. Pour moi, cela limite fermement l'approche au domaine académique pour l'instant. Idéal pour les dissertations et les articles, pas encore proche de quelque chose qui pourrait faire le saut vers une application commerciale.

Je mettrai mon chapeau d'investisseur pour le deuxième défi. La sécurité est un sujet important, cela ne fait aucun doute. Mais en dehors de quelques domaines que nous connaissons déjà - l'aérospatiale, la défense, les systèmes de paiement et les processeurs/serveurs par exemple. Ce n'est toujours pas un problème existentiel pour la plupart des équipementiers et des fabricants de composants. Ils sont prêts à cocher une case si on s'y attend généralement. Mais seulement si l'impact sur le coût ou le délai de mise sur le marché est faible. Parce que leurs clients ne paieront généralement pas plus pour la sécurité. Ce qui laisse la sécurité de la plupart des marchés toujours dépendante de l'IP clé en main, comme les racines matérielles de confiance et les applications faciles à utiliser. Les solutions conditionnées de l'une de ces manières seront investissables, sinon pas tellement.

Mon avis

Paul et Raúl ont couvert la plupart de ce que j'aurais pu suggérer. J'aime l'idée de Paul d'étendre la SVA, au moins pour encourager l'expérimentation avec des hyper-propriétés. Cela doit ouvrir une nouvelle classe de tests intéressants, conduisant éventuellement à de nouvelles méthodes de vérification groupées.

Partagez cet article via: Source : https://semiwiki.com/eda/299391-fuzzing-to-validate-soc-security-innovation-in-verification/