Source: ANSSI (position paper technique, 1 octobre 2025). Le document expose le fonctionnement du Confidential Computing (TEE + attestation), ses limites de sécurité et d’usage, et formule des recommandations aux utilisateurs et aux fournisseurs.

🔐 Contexte et portée

  • Le Confidential Computing protège les données « en cours d’usage » via des Trusted Execution Environments (TEE) et la remote attestation.
  • Il réduit la surface d’attaque (TCB plus petit) et complète le chiffrement au repos/en transit, mais souffre de vulnérabilités, limitations et absence de certifications.
  • ANSSI indique que la technologie n’est pas suffisante pour sécuriser un système de bout en bout ni pour satisfaire la section 19.6 de SecNumCloud 3.2.

⚠️ Modèle de menace et limites majeures

  • Face à un administrateur hostile menant des attaques actives ciblées, le Confidential Computing n’assure ni intégrité ni confidentialité suffisantes. Éviter l’infrastructure mutualisée non fiable et privilégier le matériel dédié si nécessaire.
  • Les attaques physiques et celles visant la chaîne d’approvisionnement (fabricant) sont explicitement hors périmètre.
  • L’écosystème manque de piles logicielles matures intégrant attestation et livraison de secrets; l’usage sécurisé est complexe et modifie profondément l’architecture et le déploiement des workloads.
  • Les « services confidentiels » proposés par certains CSP restent inattestables par l’utilisateur et doivent être considérés comme de la défense en profondeur côté fournisseur.

🧩 Mécanismes, modèles TEE et attestation

  • Deux modèles: TEE par processus (ex. Intel SGX) et TEE par VM (ex. AMD SEV-SNP, Intel TDX, Arm CCA). Les cVM sont plus faciles à adopter, mais l’outillage process-based est plus mûr.
  • L’intégrité du TEE (Manufacturer TCB) est généralement vérifiable via attestation signée par le fabricant, mais reste dépendante de la robustesse cryptographique et de la non-divulgation des clés.
  • L’intégrité du code (User-provided TCB) est critique et plus difficile: l’attestation de toute la chaîne de démarrage (firmware VM, bootloader, kernel, userspace) est actuellement incomplète dans les offres cVM (firmware/vTPM contrôlés par le CSP, personnalisation limitée, mesures partielles, arrêt de la vérification à l’OS).
  • Les enclaves process-based permettent un TCB plus réduit, mais l’usage de library OS et frameworks tiers élargit le TCB et le risque supply-chain.
  • La provision de secrets doit être liée cryptographiquement à l’attestation (ex. RA-TLS) et effectuée uniquement après validation du Manufacturer TCB et du User-provided TCB.

🔒 Durcissement et menaces techniques

  • Les workloads doivent être durcis contre un hyperviseur hostile: traiter toutes les entrées (drivers PCI, ACPI, interrupts, PIO/MMIO, appels hôte→invité) comme non fiables; durcir firmware initial et kernel.
  • Des attaques d’intégrité ont exploité des interruptions malveillantes pour perturber le contrôle d’exécution des cVM; des enclaves sont vulnérables à des interfaces non fiables et injections de signaux/exceptions.
  • Des attaques de confidentialité via canaux auxiliaires (single-stepping, compteurs de performance, patterns de pages/interruptions) restent difficiles à mitiger et parfois nécessitent des migrations matérielles.
  • Malgré ces faiblesses, le chiffrement mémoire apporte une défense en profondeur utile (ex. contre cold-boot, fuites mémoire, malware privilégié), sous réserve de mises à jour firmware/microcode rapides en cas de vulnérabilités.

🛠️ Recommandations clés

  • Pour les utilisateurs: activer les cVM comme défense en profondeur; ne pas compter sur la techno si le CSP est non fiable; définir précisément le TCB, attester toute la chaîne (fabricant, image, éléments CSP comme firmware/vTPM), lier la livraison de secrets à l’attestation, et déployer les mitigations connues. Prendre en compte des compromis de présentations/complexité/performance.
  • Pour les fournisseurs: permettre l’attestation complète de la chaîne de boot (firmware ouvert, mesures kernel/initrd/params/rootfs, personnalisation ou builds reproductibles), fournir des outils de construction/déploiement/lifecycle et de gestion des secrets, promouvoir l’évaluation de sécurité, et adopter des protocoles standard liant attestation, vérification du TCB et provisioning.

Conclusion: Il s’agit d’un position paper technique dont l’objectif principal est de clarifier les risques résiduels du Confidential Computing et de fournir des lignes directrices pour un usage plus sûr par les utilisateurs et les fournisseurs.

🔗 Source originale : https://cyber.gouv.fr/en/publications/technical-position-paper-confidential-computing