Designing Trustworthy Layered Attestations

Ce papier propose une approche de vérification d'identité par couches, fondée sur des principes de conception et des technologies existantes comme les TPM et SEV-SNP, permettant d'obtenir des attestations fiables avec une surcharge de performance négligeable face à des adversaires sophistiqués.

L'essentiel

Imaginez que vous devez envoyer un colis très précieux (des données sensibles) à un ami qui vit dans un autre pays. Vous ne le connaissez pas vraiment, et vous avez peur qu'il ne soit pas honnête ou qu'il ait été piraté. Comment pouvez-vous être sûr qu'il est digne de confiance avant de lui donner le colis ?

C'est exactement le problème que résout ce papier de recherche. Il parle de l'attestation, un processus où un ordinateur distant prouve qu'il est sain, sûr et qu'il n'a pas été piraté.

Voici l'explication simple, avec des analogies pour mieux comprendre.

1. Le Problème : Le mensonge facile

Dans le monde informatique, un pirate (l'adversaire) peut être très malin. Il peut installer un virus qui se cache si bien que l'ordinateur semble normal, alors qu'il vole tout ce qu'on lui envoie.

• L'ancienne méthode : C'est comme demander à l'ordinateur : "Es-tu en bonne santé ?" et croire sa réponse. Si le pirate a pris le contrôle, l'ordinateur dira "Oui, tout va bien !" même s'il est malade. C'est un mensonge facile.
• La solution du papier : Il faut une preuve en couches (comme un oignon ou une poupée russe). On ne fait pas confiance à une seule chose, mais on vérifie tout, du matériel physique jusqu'au logiciel, étape par étape.

2. Les 5 Règles d'Or (Les Maximes)

Les auteurs ont créé 5 règles simples pour construire un système de confiance inébranlable. Voici comment elles fonctionnent avec des images :

• Règle 1 : Réduire la zone de confiance.

  • Analogie : Imaginez une forteresse. Au lieu de faire confiance à tout le château, vous ne faites confiance qu'à la petite pièce où se trouve le coffre-fort.
  • En pratique : Le système est conçu pour que seul un tout petit nombre de programmes (très simples et vérifiables) aient le droit de toucher aux données importantes. Le reste du système (le "bruit" informatique) est isolé.

• Règle 2 : Les processus éphémères.

  • Analogie : Imaginez un restaurant où le chef change de cuisine après chaque plat. Si un client empoisonne le premier plat, le chef suivant (un nouveau chef) n'est pas contaminé.
  • En pratique : Au lieu d'avoir un programme qui tourne en permanence (et qui pourrait être corrompu pour toujours), on lance un nouveau petit programme pour chaque tâche, puis on le tue. Si un message est piégé, il ne peut pas infecter le prochain.

• Règle 3 : Pas de secrets cachés dans la mémoire.

  • Analogie : Ne laissez pas la clé de votre maison sur le paillasson, même si vous pensez que personne ne la verra. Si un voleur passe brièvement, il peut la prendre et revenir plus tard.
  • En pratique : Les clés secrètes pour signer les preuves ne doivent jamais être stockées dans la mémoire de l'ordinateur principal. Elles doivent être dans un coffre-fort spécial (une puce de sécurité appelée TPM) qui ne les sort que si tout est parfait.

• Règle 4 : La signature doit prouver l'origine.

  • Analogie : Si quelqu'un vous envoie une lettre signée, vous devez être sûr que c'est bien la personne qui l'a signée, et pas un faux-semblant. De plus, la signature doit prouver que la personne n'était pas sous l'emprise d'un sortilège au moment de signer.
  • En pratique : La preuve numérique doit montrer qu'elle a été générée par un logiciel non corrompu, démarré correctement depuis le début.

• Règle 5 : L'ordre des vérifications (La dépendance).

  • Analogie : Pour vérifier si un bâtiment est solide, vous devez d'abord vérifier les fondations, puis les murs, puis le toit. Si vous vérifiez le toit avant les fondations, et que les fondations sont pourries, votre vérification du toit est inutile.
  • En pratique : On vérifie d'abord le matériel (le démarrage), puis le noyau du système (le cœur), et enfin les applications. On ne peut pas faire confiance à une couche supérieure si la couche inférieure est corrompue.

3. L'Expérience Réelle : Le "Filtre de Sécurité"

Les auteurs ont testé leur théorie avec un système réel appelé CDS (Solution Inter-domaine).

• Le scénario : Imaginez un poste de douane entre deux pays. Un pays est très sécurisé (Zone A), l'autre est ouvert (Zone B). Les messages doivent passer de A vers B, mais ils doivent être nettoyés et vérifiés.
• Leur système : Ils ont construit un filtre qui ne laisse passer que les messages qui ont suivi le chemin exact : Entrée -> Nettoyage -> Filtrage -> Sortie.
• Le résultat : Ils ont réussi à prouver que si un pirate essayait de tricher (en modifiant un fichier ou en injectant un virus), le système le détectait immédiatement. Et le plus important ? Cela ne ralentissait presque pas le système (moins de 1,3% de perte de vitesse). C'est comme si vous ajoutiez un garde du corps à votre voiture sans que cela consomme plus d'essence.

4. L'Avenir : L'Ordinateur "Confidentiel"

Le papier explore aussi une nouvelle technologie (comme les puces AMD SEV-SNP).

• L'analogie : Au lieu d'avoir un coffre-fort dans une maison (le TPM), imaginez que vous louez une chambre blindée dans un hôtel. Même le propriétaire de l'hôtel (le fournisseur de cloud) ne peut pas voir ce qui se passe dans votre chambre.
• Cela permet de faire la même chose (vérifier la confiance) mais avec des outils encore plus modernes et sécurisés.

En résumé

Ce papier nous dit : "Ne faites pas confiance aveuglément."
Pour être sûr qu'un ordinateur distant est honnête, il faut :

1. Isoler les parties importantes.
2. Vérifier tout, du matériel au logiciel, dans le bon ordre.
3. Utiliser des clés de sécurité qui ne peuvent être utilisées que si tout est parfait.
4. Ne pas laisser les programmes vivre trop longtemps pour éviter qu'ils ne soient corrompus.

C'est une méthode robuste, testée, et qui ne ralentit pas les ordinateurs, permettant de construire des systèmes où la confiance est mathématiquement prouvée, et non juste espérée.

Résumé technique

Voici un résumé technique détaillé de l'article "Designing Trustworthy Layered Attestations" (Conception d'attestations en couches dignes de confiance), rédigé en français.

1. Le Problème : La fragilité des attestations actuelles

L'attestation à distance consiste à fournir des preuves qu'un système distant est digne de confiance pour une interaction sensible. Bien que déjà utilisée dans le contrôle d'accès réseau et les environnements d'exécution de confiance (TEE), les mécanismes actuels souffrent de deux défauts majeurs :

• Superficialité : Ils se concentrent souvent sur un nombre limité de composants (par exemple, uniquement les malwares en espace utilisateur), laissant la porte ouverte à des attaquants sophistiqués capables d'installer des rootkits pour détourner les mécanismes du noyau (kernel) et éviter la détection.
• Manque de structure : Les tentatives d'attestation complète et en temps réel peuvent être fragiles, produisant des valeurs opaques qui rendent l'évaluation de la confiance difficile lors des mises à jour incrémentielles des composants.

Le défi central est de concevoir un système d'attestation capable de résister à un adversaire capable de corrompre le système d'exploitation (Linux), de modifier les fichiers, d'exécuter des processus non autorisés, et même de réparer temporairement le système pour tromper les vérifications, tout en garantissant que l'infrastructure d'attestation elle-même n'est pas compromise.

2. Méthodologie : Raisonnement adversarial et Maximes de conception

Les auteurs adoptent une approche basée sur le raisonnement adversarial pour concevoir un système résilient. Au lieu de simplement assembler des outils existants, ils définissent d'abord un modèle d'adversaire réaliste mais puissant, puis déduisent les mécanismes nécessaires pour le contrer.

Cette démarche a abouti à l'élaboration de cinq maximes (principes directeurs) pour la conception d'attestations en couches :

1. Maxim 1 (Contrainte des interactions) : Les propriétés attestées ne doivent dépendre que d'un nombre limité, prévisible et mesurable de composants du système. Cela est réalisé via une isolation stricte (ex: SELinux).
2. Maxim 2 (Durée de vie des processus) : Les services de longue durée traitant des entrées non fiables nécessitent une re-mesure en temps réel (runtime remeasurement) pour vérifier leurs invariants. À l'inverse, les processus de courte durée (traitant une seule requête) évitent ce besoin car ils ne persistent pas.
3. Maxim 3 (Indépendance des secrets) : L'attestation ne doit pas dépendre de secrets qui pourraient être divulgués par des corruptions transitoires (éphémères), sous peine de causer un échec d'attestation permanent.
4. Maxim 4 (Preuve d'origine) : Chaque attestation doit démontrer qu'elle provient d'un logiciel d'attestation non corrompu, exécuté sous un démarrage (boot) digne de confiance.
5. Maxim 5 (Dépendances acycliques) : Une relation de dépendance acyclique permet de mesurer les couches inférieures avant les composants qui en dépendent, limitant ainsi la fenêtre d'opportunité pour une corruption rapide.

3. Étude de Cas et Implémentation

Les auteurs ont implémenté et évalué ces principes sur un Cross-Domain Solution (CDS) : un système filtrant et réécrivant des messages entre un réseau restreint et un réseau ouvert.

Architecture du système :

• Matériel : Utilisation d'un module TPM (Trusted Platform Module) comme racine de confiance pour le stockage et le rapport, et d'un démarrage sécurisé via UEFI.
• Logiciel : Linux avec SELinux (pour l'isolation des politiques) et IMA (Integrity Measurement Architecture) pour la mesure d'intégrité des fichiers exécutés.
• Outils de mesure :
  • LKIM (Linux Kernel Integrity Measurement) : Pour la re-mesure en temps réel du noyau Linux et de ses structures de données.
  • Copland/Maestro : Un langage et un outil pour orchestrer les protocoles d'attestation en couches.
• Flux : Le système utilise des processus éphémères (fork/exec) pour chaque message (respectant la Maxim 2) et une architecture en couches où le TPM signe les preuves uniquement si les registres PCR (Platform Configuration Registers) correspondent à un état de démarrage conforme.

Modèle d'adversaire considéré :
L'adversaire peut se connecter en root, modifier des fichiers, corrompre le noyau, et même réparer le noyau rapidement. Cependant, il ne peut pas modifier le matériel (UEFI/TPM) ni être un adversaire "rapide et déclenché par l'attestation" (capable de corrompre et réparer pendant la fenêtre de mesure).

4. Résultats et Évaluation

Analyse Formelle et Empirique :

• Détection d'attaques : L'analyse formelle (utilisant les outils de Rowe et al.) et les tests empiriques ont confirmé que le système détecte les corruptions du noyau, les modifications de politiques SELinux/IMA, et les tentatives de remplacement d'exécutables.
• Performance : La surcharge de performance est négligeable. Les tests montrent une réduction du débit du système CDS d'environ 1,3 % même avec une attestation toutes les 15 secondes. Le temps moyen d'attestation est de 5,48 secondes (dont 92 % pour la mesure LKIM).
• Robustesse : Le système résiste aux attaques par rejeu (replay attacks) grâce à l'utilisation de nonces et garantit que la clé de signature (ASK) n'est utilisable que dans un contexte de démarrage conforme.

Limitations identifiées et Recommandations :
Malgré le succès, les auteurs identifient deux faiblesses dues aux limitations actuelles du noyau Linux et de SELinux, les forçant à compromettre certaines maximes :

1. Cycle de dépendance LKIM/Noyau : LKIM dépend du noyau pour obtenir des informations, mais mesure aussi le noyau. Un noyau corrompu pourrait mentir à LKIM.
   • Recommandation 1 : Exécuter LKIM dans une machine virtuelle séparée (hyperviseur) pour une inspection en lecture seule, éliminant ce cycle.
2. Gestion des secrets pour le TPM : Pour utiliser la clé de signature du TPM, le système doit actuellement stocker un secret (blob de clé ou politique) en mémoire utilisateur, vulnérable à une corruption transitoire du noyau (violation de la Maxim 3).
   • Recommandation 2 : Implémenter les localités TPM (TPM localities) dans le noyau Linux et SELinux pour contrôler strictement quel processus peut envoyer des commandes au TPM, éliminant le besoin de secrets en mémoire.

5. Généralisation et Signification

Pour prouver la robustesse de leurs maximes, les auteurs les appliquent à deux autres contextes :

• Contrôle de documents distribués : Montre comment les maximes s'appliquent à des architectures multi-plateformes avec une autorité de certification décentralisée.
• Calcul confidentiel (Confidential Computing) : L'application des maximes à l'utilisation de AMD SEV-SNP (Secure Encrypted Virtualization). Cela permet de résoudre le problème du cycle LKIM/Noyau en utilisant les niveaux de privilège de la VM pour isoler LKIM du noyau, et de gérer les clés via un vTPM sécurisé par le matériel.

Signification de l'article :
Ce travail démontre qu'il est possible de construire des systèmes d'attestation en couches fiables en combinant judicieusement des technologies existantes (TPM, SELinux, IMA, LKIM) guidées par un raisonnement adversarial rigoureux. Il fournit non seulement une preuve de concept fonctionnelle avec une faible surcharge, mais aussi un cadre théorique (les 5 maximes) et des recommandations concrètes pour l'évolution des systèmes d'exploitation et des architectures matérielles afin de supporter des attestations encore plus robustes face à des adversaires de plus en plus sophistiqués.