Granite: A Modular Methodology for Foundational Verification of Hardware-Software Leakage Contracts
Granite introduit une méthodologie modulaire et fondamentale qui vérifie à la fois la correction fonctionnelle et l'absence de fuites des processeurs RTL en établissant une équivalence de traces avec des contrats de fuite d'ISA déterministes, permettant ainsi la composition de preuves matérielles et logicielles pour éliminer les spécifications intermédiaires de la base de confiance informatique.
Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète
Imaginez que vous construisez une voiture de course ultra-rapide. Vous voulez qu'elle soit incroyablement agile, alors vous ajoutez des turbocompresseurs, une direction prédictive et un système qui devine quel virage vous allez prendre ensuite. Mais il y a un piège : si le moteur de la voiture produit un « clac » spécifique uniquement lorsque vous tournez à gauche, un espion sournois écoutant sur le bord de la route pourrait déduire l'intégralité de votre itinère rien qu'en entendant ce bruit. Dans le monde des puces informatiques, cela s'appelle un « canal auxiliaire de synchronisation » (timing side channel). Pendant des années, les programmeurs ont tenté d'écrire du code qui prend exactement le même temps, peu importe les données secrètes qu'il manipule, comme un espion essayant de traverser un couloir sans faire de bruit. Mais à mesure que les puces sont devenues plus rapides et plus intelligentes, elles ont commencé à produire des bruits minuscules et imprévisibles — comme une pause soudaine pour vérifier un miroir ou une accélération brutale — qui révèlent accidentellement des secrets. Ce document traite de l'idée terrifiante selon laquelle, même si votre code est parfait, le matériel lui-même pourrait laisser fuiter vos secrets à travers le rythme même de son battement de cœur.
Les chercheurs derrière ce travail, nommés Granite, ont construit une nouvelle façon de prouver mathématiquement qu'une puce informatique garde ses secrets en sécurité. Ils ne se sont pas contentés de deviner ou de faire des tests ; ils ont créé un argument mathématique rigoureux, étape par étape, qui relie les règles de haut niveau sur la façon dont un ordinateur doit se comporter (l'« Architecture de Jeu d'Instructions » ou ISA) jusqu'aux fils et transistors minuscules (le « RTL »). Leur principale conclusion est une méthode pour prouver que la synchronisation d'une puce est déterminée uniquement par des éléments autorisés à être publics, comme le bouton sur lequel on a appuyé, et jamais par les données secrètes qu'elle traite, comme un mot de passe ou une clé de chiffrement. Ils excluent explicitement l'idée que l'on puisse simplement faire confiance à une puce parce qu'elle semble correcte ou parce qu'elle a passé des tests standards ; ils démontrent que sans ce type spécifique de preuve, des fuites cachées sont presque garanties d'exister. Ils ne font pas que suggérer que cela fonctionne ; ils l'ont formellement prouvé pour une conception de processeur qui a été synthétisée avec succès pour un FPGA, bien qu'elle n'ait pas encore été intégrée dans un système complet sur puce (SoC) pour des tests post-synthèse.
La grande histoire du détective des puces
Considérez un processeur informatique comme une cuisine animée et chaotique dans un restaurant haut de gamme. Les chefs (le matériel) préparent des repas (exécutent des programmes) pour les clients. L'« Architecture de Jeu d'Instructions » (ISA) est le menu et le livre de recettes. Elle dit à la cuisine : « Si vous recevez une commande de burger, vous devez finalement servir un burger. » Mais le menu ne dit pas combien de temps il faut pour faire le burger, ni quand le chef saisit le couteau.
Dans l'ancien temps, les chefs devaient être en « temps constant ». Cela signifiait qu'ils devaient couper les légumes exactement à la même vitesse, qu'un client commande une salade ou un steak, afin qu'un espion observant par la fenêtre ne puisse pas deviner ce qui est cuisiné par le rythme du hachage. Mais ensuite, la cuisine est devenue trop rapide. Les chefs ont commencé à utiliser la « spéculation » — ils devinaient ce que le client voulait et commençaient à hacher des oignons avant même que la commande ne soit confirmée. Ce jeu de devinettes a créé de nouveaux bruits accidentels : le temps nécessaire pour réaliser une erreur, ou le temps pour saisir une épice spécifique, commençait à fuiter des informations. Un espion pouvait écouter la cuisine et déduire : « Ah, le chef a hésité pendant 0,0001 seconde ; il devait cuisiner quelque chose avec des oignons secrets ! »
Entrez en scène Granite, l'inspecteur de cuisine ultime. Granite ne se contente pas de surveiller les chefs ; il réécrit les règles de la cuisine pour s'assurer qu'aucun secret ne puisse s'échapper par le rythme du hachage.
La magie du « Chef de l'Ombre »
Le génie de Granite réside dans un tour astucieux impliquant un « Chef de l'Ombre ». Imaginez que vous avez le vrai chef, qui connaît toutes les recettes secrètes (les données secrètes). Vous avez aussi un chef de l'ombre qui est aveuglé et ne connaît que les parties publiques de la commande (les données publiques).
La méthode de Granite dit : « Nous allons prouver que le vrai chef et le chef de l'ombre se déplacent en parfaite synchronisation. » Si le vrai chef met 5 secondes pour hacher un oignon parce que l'oignon était gros, le chef de l'ombre doit également mettre exactement 5 secondes, même s'il ne sait pas que l'oignon était gros. Le rythme du chef de l'ombre est dicté uniquement par la commande publique. Si le rythme du vrai chef dépend un jour d'un secret (comme le type d'oignon), les deux chefs perdront leur synchronisation, et la preuve échouera.
Pour faire fonctionner cela, Granite introduit un « Driver » (Conducteur) et un « Witness » (Témoin).
- Le Driver est comme un métronome qui n'écoute que la commande publique. Il décide quand la cuisine doit avancer, garantissant que le rythme des actions de la cuisine est dicté uniquement par ce que le client veut que l'on sache, et non par les ingrédients secrets.
- Le Witness est un substitut pour les parties désordonnées et imprévisibles de la cuisine (comme un délai aléatoire parce qu'une poêle est chaude). Le Witness dit : « D'accord, nous ne nous soucions pas de savoir exactement ce qui se passe ici, tant que cela ne dépend pas du secret. »
En prouvant que la vraie cuisine se comporte exactement comme une cuisine dirigée par le Driver et le Witness, Granite prouve que le rythme de la cuisine (la synchronisation) ne peut absolument pas révéler les ingrédients secrets.
Le puzzle modulaire
L'une des parties les plus difficiles pour vérifier une cuisine entière est qu'elle est trop grande pour être examinée d'un seul coup. Granite résout cela en divisant la cuisine en petites stations indépendantes : la station de hachage, la station de grillade, la station de dressage.
Granite prouve que chaque station est sûre individuellement. Par exemple, la station « Multiplicateur » (qui fait des calculs) est vérifiée pour s'assurer que si elle met plus de temps à multiplier deux nombres, c'est uniquement parce que les nombres étaient zéro (ce qui est autorisé à être connu), et non à cause d'une valeur secrète. Une fois que chaque station est prouvée sûre, Granite les assemble comme des briques Lego. Parce que la preuve est « modulaire », si vous remplacez la station de grillade par une plus rapide, vous n'avez pas besoin de revérifier toute la cuisine ; vous vérifiez simplement la nouvelle station, et l'ensemble du système reste sûr.
Le verdict final
Les chercheurs n'ont pas seulement parlé de cela ; ils ont conçu un processeur et ont exécuté leur preuve dessus. Ils ont pris un morceau de logiciel qui était déjà connu pour être à « temps constant » (un programme cryptographique appelé Salsa20) et ont prouvé que lorsqu'il s'exécute sur leur conception de processeur, il ne fuit absolument aucun secret par la synchronisation.
C'est un événement majeur car cela change ce que vous devez considérer comme digne de confiance. Habituellement, vous devez faire confiance à un contrat complexe entre le logiciel et le matériel. Granite montre que si vous connectez la preuve matérielle de leur travail avec une preuve logicielle vérifiée, le contrat matériel-logiciel lui-même peut être éliminé de la liste de confiance. Cependant, la preuve repose toujours sur quelques composants de base, tels que la définition formelle du contrat du Jeu d'Instructions et l'outil qui traduit le code en description de matériel, qui restent dans la « Base de Confiance » (Trusted Computing Base). Ils ont même trouvé un bug dans leur propre conception : ils ont réalisé que l'écriture dans certains commutateurs de contrôle (CSR) pouvait fuiter des informations, et ils l'ont corrigé avant que la preuve ne soit terminée.
En résumé, Granite est une nouvelle façon de construire des puces informatiques qui sont mathématiquement garanties pour garder leurs secrets, même lorsqu'elles sont rapides, qu'elles anticipent et qu'elles font du bruit. Cela transforme la cuisine chaotique et bruyante de l'informatique moderne en une forteresse silencieuse capable de garder des secrets, prouvant que l'on peut avoir à la fois la vitesse et la sécurité.
Noyé(e) sous les articles dans votre domaine ?
Recevez des digests quotidiens des articles les plus récents correspondant à vos mots-clés de recherche — avec des résumés techniques, dans votre langue.