Contexte et portée des TEEs
Les environnements d’exécution sécurisés (TEE) comme Intel SGX, AMD SEV‑SNP ou Nitro sont présentés comme des zones isolées où le code et les données restent invisibles au système d’exploitation hôte. Cette isolation repose sur du matériel dédié, des clés d’attestation et des mécanismes de vérification à distance. Les fournisseurs misent sur la performance et la compatibilité, mais la complexité des architectures CPU modernes introduit des canaux latéraux et des interactions matérielles difficiles à contrôler.
Vulnérabilités de l’attestation et attaques physiques
Depuis 2018, plusieurs incidents montrent que l’attestation n’est pas infaillible. L’attaque Foreshadow a permis à un système d’exploitation malveillant de récupérer la clé d’attestation SGX, marquant la première compromission de ce mécanisme. En 2020, SGAxe a reproduit le vol de clé, mais en exigeant un accès ring‑0, ce qui montre que le privilège d’administrateur suffit à briser la chaîne de confiance. L’anomalie ÆPIC Leak (2022) a exploité un bug microarchitectural pour extraire la même clé depuis le noyau hôte. Plus récemment, BadRAM2 (2024) a démontré qu’un administrateur avec un accès physique limité pouvait reprogrammer la puce SPD d’une barrette DDR4, falsifier le rapport d’attestation d’un VM AMD SEV‑SNP et faire accepter une VM compromise comme légitime, sans exfiltration de clé. Les attaques WireTap.fail, TEE.fail, Battering RAM et DDDrop (2025‑2026) ont étendu ce principe aux bus DDR4/DDR5, permettant d’interposer du matériel entre le processeur et la mémoire pour injecter ou masquer des écritures, puis usurper les attestations SGX ou TDX. Ces scénarios invalident l’hypothèse selon laquelle un vérificateur accepte n’importe quel processeur Intel en bon état ; la falsification d’attestation devient alors possible à grande échelle.
Défaillances logicielles et problèmes de liveness
Outre les attaques matérielles, des bugs dans le code enclavé ont conduit à des fuites de données. L’exemple de l’enclave de découverte de contacts de Signal illustre comment une faille de sécurité mémoire a permis à l’hôte de lire le contenu interne de l’enclave. Les problèmes de liveness, c’est‑à‑dire l’incapacité à garantir la disponibilité d’une enclave, sont également documentés. En 2018, la révocation des certificats SGX suite aux vulnérabilités Spectre/Meltdown a paralysé de nombreuses enclaves. En 2022, le rapport SGX.fail a mis en évidence la lenteur des mises à jour du TCB, laissant des plateformes « hors‑date » pendant des mois, ce qui expose les services dépendants à des attaques de déni de service. Un autre incident, l’échec d’attestation TPM sur les plateformes AMD (2022), a montré que des joueurs en ligne pouvaient être exclus de tournois à cash en raison d’une incapacité à établir une chaîne d’attestation fiable.
Implications pour le déploiement
Ces faits imposent une réévaluation des modèles de menace. Même si un acteur exclut les attaques physiques, le fait que l’attestation puisse être falsifiée par un processeur légitime rend la confiance sur le seul certificat du fabricant insuffisante. La mitigation la plus efficace consiste à restreindre les vérificateurs aux certificats PCK spécifiques à l’organisation, ce qui implique la gestion d’une PKI interne et augmente la surface d’erreur opérationnelle. Par ailleurs, placer des secrets critiques directement dans une enclave devient risqué tant que les vecteurs d’interposition matérielle et les bugs de code ne sont pas éliminés. Les concepteurs doivent envisager des couches de défense supplémentaires, comme le chiffrement de bout en bout hors du TEE, ou le recours à des architectures alternatives comme Sanctum, qui offrent une isolation plus stricte au prix d’une performance réduite. En l’absence de garanties solides, la recommandation la plus prudente reste de limiter les données sensibles aux TEEs et de préparer des plans de continuité en cas de compromission.
