A Deductive System for Contract Satisfaction Proofs

✨

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

Each language version is independently generated for its own context, not a direct translation.

🛡️ Le Grand Jeu de l'Espionnage : Comment prouver qu'un ordinateur ne trahit pas ses secrets

Imaginez que vous êtes un chef d'entreprise (le logiciel) qui utilise un ordinateur partagé dans le cloud (le matériel). Vous avez des secrets (vos données bancaires, vos emails privés). Le problème, c'est que l'ordinateur, même s'il fait bien son travail, laisse échapper de petits indices involontaires : le bruit du ventilateur, la chaleur, ou le temps que met le processeur à faire une tâche. C'est ce qu'on appelle une fuite par canal auxiliaire (side-channel).

Pour se protéger, les experts inventent des Contrats.

Le Contrat est une promesse écrite par le vendeur du matériel : "Je garantis que, peu importe ce que vous faites, je ne laisserai jamais fuir plus d'informations que ce que j'ai écrit ici."
Le Défi : Comment prouver que la promesse est vraie ? C'est comme essayer de prouver qu'un coffre-fort est inviolable sans avoir à le casser à chaque fois.

Jusqu'à présent, on essayait de vérifier ces contrats de deux façons :

En les testant (comme un testeur de voiture qui roule des milliers de kilomètres) : ça peut rater des défauts cachés.
En faisant des calculs à la main (sur du papier) : c'est long, complexe, et les humains font des erreurs.

C'est là que cette nouvelle recherche intervient.

🕵️‍♂️ L'Analogie du Duo de Détectives

Imaginez que vous avez deux détectives qui doivent surveiller la même scène de crime, mais avec des lunettes différentes :

Le Détective "Contrat" (le modèle théorique) : Il voit la scène de manière simplifiée, comme un dessin animé. Il ne voit que les grandes lignes.
Le Détective "Matériel" (le vrai processeur) : Il voit tout, en ultra-haute définition, avec des détails microscopiques (les caches, les prédictions de branches, etc.).

Le but du jeu : Prouver que si les deux détectives voient la même chose dans le dessin animé (le contrat), alors ils verront aussi la même chose (ou moins) dans la réalité (le matériel).

Le problème : Le détective "Matériel" est très rapide et parfois il fait des devinettes (il anticipe la suite avant d'être sûr). Le détective "Contrat" est plus lent et méthodique. Ils ne marchent pas toujours au même rythme. C'est comme essayer de comparer deux danseurs : l'un fait des pas de géant, l'autre des pas de fourmi. Comment prouver qu'ils dansent la même chorégraphie ?

🧩 La Solution : Le Système de Preuve "Pas à Pas"

Les auteurs de l'article ont créé un nouveau système de logique (un "système déductif") pour aider les humains à prouver cette égalité, assistés par un ordinateur intelligent (un "assistant de preuve" appelé Rocq).

Voici comment ils y arrivent, avec une analogie simple :

1. La Bisimulation Relative (Le jeu de miroir)

Au lieu de comparer les deux détectives ligne par ligne (ce qui est impossible car ils vont à des vitesses différentes), ils utilisent une technique appelée bisimulation relative.

Imaginez que vous avez un miroir magique.

Si le détective "Contrat" avance d'un pas, le miroir peut lui permettre de sauter plusieurs pas d'un coup pour rattraper le retard.
Si le détective "Matériel" fait une prédiction erronée (il avance dans le mauvais sens), le miroir peut lui dire : "Attends, on va revenir en arrière, c'est comme si tu n'avais pas bougé."

Le système permet de construire un pont entre les deux mondes, pas à pas, en acceptant que l'un avance plus vite que l'autre, tant qu'ils finissent par se retrouver au même endroit avec les mêmes informations.

2. La Preuve "En Construction" (Co-induction)

Avant, il fallait deviner tout le pont d'un coup avant de commencer à construire. C'était très dur.
Ici, les auteurs utilisent une méthode appelée co-induction paramétrée.

Analogie : Imaginez que vous construisez un pont suspendu. Au lieu de devoir avoir toutes les câbles prêts avant de commencer, vous posez une première planche. Puis, grâce à une règle magique, vous pouvez dire : "Si je peux poser la prochaine planche en utilisant celle-ci, alors le pont est solide."
Vous construisez la preuve au fur et à mesure, en ajoutant des petits morceaux de logique (des invariants) quand vous en avez besoin, plutôt que de tout prévoir au début.

3. Les "Trucs de Magicien" (Up-To Techniques)

Parfois, la preuve devient trop lourde. Les auteurs ont ajouté des "raccourcis" sûrs.

Symétrie : Si A est égal à B, alors B est égal à A. On peut inverser les rôles pour simplifier.
Transitivité : Si A mène à B, et B mène à C, alors A mène à C. On peut sauter des étapes intermédiaires.
Ces astuces permettent de simplifier énormément les calculs, comme utiliser un raccourci dans une carte GPS pour éviter les embouteillages.

🎓 Ce qu'ils ont prouvé (Les Cas Pratiques)

Pour montrer que leur système fonctionne, ils l'ont utilisé pour vérifier deux scénarios très complexes de sécurité informatique :

Le scénario "Mauvaise Prédiction" (Always-Mispredict) :
- Le problème : Les processeurs modernes devinent quelle branche d'un code prendre (comme un GPS qui devine le chemin). S'ils se trompent, ils laissent des traces.
- La solution du contrat : Le contrat dit : "Peu importe ce que le processeur devine, je vais simuler qu'il se trompe toujours et qu'il explore les deux chemins."
- Le résultat : Ils ont prouvé mathématiquement que cette stratégie de "fausse prédiction" couvre bien toutes les possibilités réelles du processeur.
Le scénario "Exécution Désordonnée" (Out-of-Order) :
- Le problème : Les processeurs exécutent les tâches dans le désordre pour aller plus vite (comme un chef qui prépare le dessert pendant que le plat mijote).
- La solution du contrat : Le contrat dit : "Imagine que tout se passe dans l'ordre, ligne par ligne."
- Le résultat : Ils ont prouvé que même si le processeur fait le désordre, cela ne crée pas de fuites d'information supplémentaires par rapport à l'ordre strict.

🚀 En Résumé

Cette recherche est comme un nouveau manuel de construction de ponts pour les ingénieurs de sécurité.

Avant : On essayait de deviner la structure du pont à la main (trop long) ou on le testait en le secouant (pas assez fiable).
Maintenant : On a un assistant qui permet de construire la preuve de solidité brique par brique, en acceptant que les deux côtés du pont (le contrat et le matériel) ne soient pas parfaitement alignés à chaque instant, mais qu'ils finissent par se rejoindre en toute sécurité.

Cela permet de créer des processeurs plus sûrs, avec la certitude mathématique qu'ils ne trahiront pas nos secrets, même face aux espions les plus malins.

Each language version is independently generated for its own context, not a direct translation.

1. Problématique : La Satisfaction de Contrats Matériel-Logiciel

Le papier aborde le défi de la vérification de la sécurité des programmes contre les attaques par canaux auxiliaires (side-channels), telles que Meltdown et Spectre. Ces attaques exploitent les fuites d'informations dans la microarchitecture du processeur (caches, prédicteurs de branches, etc.).

Pour sécuriser le logiciel sans avoir besoin de connaître les détails microarchitecturaux complexes, la communauté utilise des contrats matériel-logiciel. Un contrat est une spécification abstraite du comportement de fuite d'un CPU au niveau de l'architecture d'ensemble des instructions (ISA).

Le principe : Si un programme ne fuit pas d'informations selon le contrat, il ne devrait pas en fuir sur le matériel réel.
La condition de validité : Pour que cette approche soit correcte, le matériel doit satisfaire le contrat. Cela signifie que le contrat doit être une sur-approximation sûre des fuites réelles du matériel. Formellement, si deux exécutions de programme produisent le même comportement de fuite selon le contrat, elles doivent aussi produire le même comportement de fuite sur le matériel (même si les états initiaux diffèrent sur les données secrètes).

Le défi principal : Prouver cette propriété de satisfaction est complexe car elle implique un raisonnement relationnel sur quatre traces d'exécution simultanées (deux traces de contrat et deux traces de matériel). De plus, ces traces évoluent de manière asynchrone (une étape de contrat peut correspondre à plusieurs étapes de matériel et vice-versa), ce qui rend les preuves manuelles longues et les méthodes de model-checking automatisées difficiles à appliquer sans invariants complexes prédéfinis.

2. Méthodologie : Égalité de Traces Relatives et Bisimulation Relative

Les auteurs proposent une approche alternative basée sur les assistants de preuve interactifs (spécifiquement Rocq, anciennement Coq). Leur méthodologie repose sur trois piliers conceptuels :

A. Égalité de Traces Relatives (Relative Trace Equality)

Ils identifient que la satisfaction de contrat est un cas particulier d'un problème plus général : prouver qu'une égalité de traces implique une autre égalité de traces ( $Trace_C = Trace_C' \implies Trace_H = Trace_H'$ ).

B. Bisimulation Relative (Relative Bisimulation)

Pour résoudre ce problème, ils introduisent une nouvelle notion de bisimulation relative, définie comme un point fixe mixte (alternance de points fixes minimaux et maximaux) sur un système de transition d'états à 4-ary (quatre états : deux de contrat, deux de matériel).

Contrairement aux approches classiques qui nécessitent de deviner une relation de simulation complexe a priori, leur définition permet de construire l'invariant relationnel incrémentalement pendant la preuve.
La définition gère l'asynchronicité : les étapes de contrat peuvent être traitées de manière inductive (pour "dérouler" l'hypothèse de départ), tandis que les étapes de matériel sont traitées de manière co-inductive (pour prouver l'égalité des traces infinies).

C. Système Déductif et Co-induction Paramétrée

Pour rendre ces preuves praticables dans un assistant de preuve, les auteurs développent un système déductif basé sur la co-induction paramétrée (Paco).

Ils introduisent des quintuplés de preuve ( $R \vdash \dots$ ) qui représentent l'état d'une preuve en cours, où $R$ est une hypothèse de co-induction (un invariant partiel) en cours de construction.
Le système offre des règles de raisonnement modulaires :
- C-Step / H-Step : Pour avancer dans les exécutions de contrat ou de matériel.
- C-Leak / H-Leak : Pour conclure si les fuites sont différentes ou égales.
- Invariant / Cycle : Pour accumuler de nouveaux états dans l'hypothèse de preuve et fermer les cycles.
- Up-To Techniques : Des règles avancées permettant d'exploiter la symétrie, la transitivité et l'équivalence de fuites pour simplifier drastiquement les preuves sans compromettre la correction.

3. Contributions Clés

Théorie Fondamentale : Définition formelle de la bisimulation relative comme caractérisation exacte (complète et sûre) de l'égalité de traces relatives. C'est la première fois qu'une telle technique est formalisée pour ce contexte spécifique.
Système Déductif : Création d'un système de preuve interactif complet en Rocq, permettant de prouver la satisfaction de contrats sans fournir la relation de simulation complète au départ. Le système construit l'invariant à la volée.
Techniques "Up-To" : Intégration de techniques de simplification de preuves (symétrie, transitivité, équivalence de fuites) directement dans le système déductif, rendant les preuves modulaires et gérables.
Formalisation et Validation :
- Le système entier est formalisé dans Rocq.
- Deux études de cas complexes ont été menées pour valider des contrats réels (inspirés du contrat CT-SPEC) :
  - Contrat "Toujours-Mauvaise-Prédiction" (Always-Mispredict) : Prouve qu'un matériel avec prédiction de branches spéculative satisfait un contrat qui exécute systématiquement les deux branches (modélisant Spectre).
  - Contrat "Séquentiel" : Prouve qu'un matériel exécutant des instructions hors ordre (out-of-order) satisfait un contrat qui exécute les instructions séquentiellement.

4. Résultats

Correction et Complétude : Les auteurs ont prouvé mathématiquement que leur système déductif est à la fois sain (sound) et complet pour l'égalité de traces relatives.
Preuves Mécanisées : Ils ont réussi à mécaniser des preuves de satisfaction de contrats qui, dans la littérature précédente, nécessitaient des rapports techniques de 25 pages de raisonnement papier dense. Ces preuves sont désormais vérifiées par l'ordinateur.
Efficacité : L'utilisation des techniques "Up-To" a permis de réduire la complexité des preuves en évitant la redondance et en permettant de raisonner sur des états équivalents plutôt que strictement identiques.

5. Signification et Impact

Ce travail est significatif pour plusieurs raisons :

Passage du "Papier" au "Machine" : Il comble le fossé entre les preuves de sécurité matérielles complexes (souvent non vérifiées ou partiellement vérifiées) et la vérification formelle rigoureuse.
Nouvelle Approche pour les Hyperpropriétés : Il offre une méthode générique pour prouver des propriétés relationnelles (hyperpropriétés) impliquant des systèmes asynchrones, applicable au-delà des contrats matériel-logiciel (ex: compilation sécurisée, non-interférence spéculative).
Réduction de la Charge Cognitive : En permettant de construire les invariants incrémentalement et en utilisant des techniques de simplification, le système rend la vérification de la sécurité des processeurs modernes (avec spéculation et réordonnancement) accessible aux ingénieurs utilisant des assistants de preuve.
Fondation pour l'Avenir : L'article ouvre la voie à des logiques de programme plus abstraites pour les contrats et suggère des pistes pour gérer la non-déterminisme et la spéculation imbriquée dans le futur.

En résumé, cet article présente un cadre théorique et pratique robuste pour vérifier formellement que les microarchitectures modernes respectent les abstractions de sécurité promises par les contrats, renforçant ainsi la confiance dans les défenses contre les attaques par canaux auxiliaires.