En octobre, le terme «TEE (Trusted Execution Environment)» a commencé à apparaître fréquemment dans les flux X. Cela m'a surpris car TEE a traditionnellement été un sujet de niche, principalement discuté dans le milieu universitaire de la sécurité des systèmes. En tant que personne ayant effectué des recherches dans un laboratoire de sécurité des systèmes, j'ai été heureux de voir ce développement. Cependant, j'étais curieux de savoir pourquoi TEE attirait soudainement l'attention dans l'espace Web3. J'ai également remarqué un manque de contenu accessible expliquant les concepts de TEE au grand public, ce qui m'a motivé à écrire cet article.

TEE est un concept complexe qui peut être difficile à comprendre pleinement sans une formation en informatique. Par conséquent, cet article commence par des concepts de base de TEE, explique pourquoi Web3 souhaite utiliser TEE, puis aborde les projets Web3 actuels mettant en œuvre TEE et ses limites.

En résumé, cet article abordera les sujets suivants :

• Une introduction aux concepts de TEE et un bref aperçu des TEE modernes
• Divers cas de mise en œuvre TEE au sein de l'écosystème Web3
• Limitations de TEE et perspectives personnelles sur ces limitations
• L'avenir de TEE dans l'écosystème Web3

1. Qu'est-ce que TEE?

Je crois que la plupart des lecteurs n'ont peut-être pas les connaissances nécessaires pour comprendre exactement ce qu'est TEE. Étant donné que TEE est un concept assez complexe lorsqu'il est exploré en profondeur, je vais essayer de l'expliquer le plus simplement possible.

Concepts de base

La plupart des serveurs Web2 gèrent l'accès aux données via des paramètres d'autorisation. Cependant, cette approche étant purement basée sur des logiciels, elle devient essentiellement inefficace si des privilèges de niveau supérieur sont obtenus. Par exemple, si un attaquant acquiert des privilèges au niveau du noyau dans le système d'exploitation du serveur, il peut potentiellement accéder à toutes les données contrôlées par des autorisations sur le serveur, y compris les clés de chiffrement. Dans de tels scénarios extrêmes, il n'y a pratiquement aucun moyen d'empêcher le vol de données par des méthodes basées uniquement sur des logiciels. TEE, ou environnement d'exécution de confiance, tente de résoudre fondamentalement ce problème grâce à la sécurité basée sur le matériel. Les TEE sont souvent appelés "informatique confidentielle", mais il s'agit d'un concept plus large qui inclut des mécanismes de calcul garantissant la confidentialité des données des utilisateurs, tels que ZK, MPC et FHE.

source: Jujutsu Kaisen

Pour utiliser une analogie simple, TEE agit comme une zone chiffrée dans la mémoire. Toutes les données à l'intérieur du TEE sont chiffrées, rendant impossible l'accès aux données brutes depuis l'extérieur. Même le noyau du système d'exploitation ne peut pas le lire ou le modifier sous sa forme d'origine. Ainsi, même si un attaquant acquiert des privilèges d'administrateur sur le serveur, il ne peut pas décrypter les données à l'intérieur du TEE. Cette zone chiffrée est souvent appelée une "enclave".

La création d'une enclave et le traitement des données qui s'y trouvent nécessitent des ensembles d'instructions spécifiques, similaires aux opcodes. Ces instructions utilisent des clés de chiffrement stockées dans des zones protégées par du matériel pour effectuer des calculs sur les données dans l'enclave. Comme le TEE est un module de sécurité au niveau matériel, son implémentation varie en fonction du fournisseur de puce CPU. Par exemple, Intel prend en charge SGX, AMD prend en charge SEV et ARM prend en charge TrustZone. D'un point de vue plus large, ces implémentations partagent le concept de "protéger la mémoire par le biais du chiffrement au niveau matériel".

1.1. Comment les TEE protègent les données

Commençons d'abord par examiner le fonctionnement des TEE les plus courants - Intel SGX, AMD SEV et ARM TrustZone - puis introduisons des mises en œuvre plus récentes de TEE.

1.1.1. OG TEEs

Intel SGX

SGX crée et accède aux enclaves au niveau du processus. L'image suivante fournit une représentation claire de la façon dont fonctionne un programme activé par SGX.

source: https://sgx101.gitbook.io/sgx101/sgx-bootstrap/enclave/interaction-between-pse-and-application-enclaves

Pendant le développement, les développeurs doivent distinguer entre le code non fiable et le code fiable. Les variables ou fonctions qui nécessitent une protection par l'enclave sont désignées comme du code fiable, tandis que les autres opérations sont catégorisées comme du code non fiable. Lorsque du code non fiable a besoin d'entrer des données dans du code fiable, ou lorsque du code fiable doit interagir avec du code non fiable, des appels système spéciaux appelés ECALL et OCALL sont utilisés.

source : https://www.intel.com/content/www/us/fr/developer/articles/training/intel-software-guard-extensions-tutorial-part-7-refining-the-enclave.html

Si les utilisateurs ont besoin d'interagir directement avec des données dans l'enclave - par exemple, fournir une entrée ou recevoir une sortie - ils peuvent communiquer via des canaux sécurisés établis à l'aide de protocoles tels que SSL.

AMD SEV

Contrairement à SGX, qui crée des enclaves au niveau du processus, SEV les crée au niveau de la machine virtuelle. La mémoire allouée aux machines virtuelles est chiffrée et gérée à l’aide de clés indépendantes, ce qui protège les données du système d’exploitation du serveur ou d’autres machines virtuelles. Bien que les machines virtuelles soient généralement considérées comme sécurisées en raison de leur isolement en bac à sable, les vulnérabilités qui compromettent cet isolement ne peuvent pas être complètement exclues. Le SEV est conçu pour assurer la sécurité dans de tels scénarios.

SEV génère des clés de chiffrement via un processeur de sécurité physiquement séparé de l'UC lors de la création de la MV. Ces clés sont ensuite utilisées pour chiffrer la mémoire de la MV. Le diagramme suivant illustre la différence entre SGX et SEV.

source: 10.1109/SRDS.2018.00042

SGX exige que les développeurs divisent explicitement le code en segments non fiables et fiables. En revanche, SEV chiffre l'ensemble de la mémoire de la machine virtuelle, demandant relativement moins d'efforts aux développeurs en termes d'implémentation.

ARM TrustZone

Contrairement à Intel et AMD, qui produisent principalement des CPU pour les ordinateurs de bureau et les serveurs, ARM conçoit des chipsets pour des systèmes légers tels que les appareils mobiles et embarqués. Par conséquent, leur implémentation de l'Enclave Sécurisée est légèrement différente de la SGX ou de la SEV utilisée dans les architectures de plus haut niveau.

TrustZone divise le système en un monde sécurisé et un monde normal au niveau matériel. Les développeurs utilisant TrustZone doivent implémenter des fonctions critiques en matière de sécurité dans le monde sécurisé, tandis que les fonctions générales s'exécutent dans le monde normal. Les transitions entre ces deux mondes se font par le biais d'appels système spéciaux appelés appels de moniteur sécurisé, similaires à SGX.

Une distinction clé est que l'enclave de TrustZone s'étend au-delà du seul CPU ou de la mémoire ; elle englobe l'ensemble du système, y compris le bus système, les périphériques et les contrôleurs d'interruption. Apple utilise également une TEE appelée Secure Enclave dans ses produits, qui est très similaire à TrustZone à un niveau élevé.

1.1.2. TEE avancées

Comme nous le verrons plus tard, de nombreux TEE d'origine, y compris Intel SGX, ont rencontré des vulnérabilités de canaux latéraux et des défis de développement en raison de problèmes structurels. Pour résoudre ces problèmes, les fournisseurs ont publié des versions améliorées. Avec la demande croissante de calcul sécurisé en nuage, des plateformes telles que AWS/Azure/GCP ont commencé à proposer leurs propres services TEE. Récemment, le concept de TEE a été étendu aux GPU également. Certains cas d'utilisation Web3 mettent désormais en œuvre ces TEE avancés, je vais donc les expliquer brièvement.

TEE cloud : AWS Nitro, Azure Confidential Computing, Google Cloud Confidential Computing

Avec la demande croissante de services de cloud computing, les fournisseurs ont commencé à développer leurs propres solutions TEE. Nitro d'AWS est un environnement informatique d'enclave qui fonctionne aux côtés des instances EC2. Il réalise une séparation physique de l'environnement informatique en utilisant une puce de sécurité Nitro dédiée pour l'attestation et la gestion des clés. L'hyperviseur Nitro protège les zones de mémoire de l'enclave grâce aux fonctions fournies par la puce, protégeant efficacement contre les attaques à la fois des utilisateurs et des fournisseurs de cloud.

Azure prend en charge plusieurs spécifications TEE, notamment Intel SGX, AMD SEV-SNP et son propre isolation basée sur la virtualisation. Cette flexibilité dans la sélection de l'environnement matériel offre aux utilisateurs plus d'options, mais peut augmenter la surface d'attaque lorsque l'utilisateur utilise plusieurs TEE.

Google Cloud propose des services de calcul confidentiels qui utilisent des environnements d'exécution de confiance (TEE), en se concentrant sur les charges de travail AI/ML. Bien que différents d'AWS Nitro, Google Cloud, tout comme Azure, offre une isolation basée sur la virtualisation en utilisant l'infrastructure TEE existante. Les principaux différenciateurs incluent la prise en charge des accélérateurs CPU tels que Intel AMX pour gérer les tâches intensives AI/ML, et le calcul confidentiel basé sur GPU grâce à NVIDIA, qui sera détaillé ultérieurement.

ARM CCA

ARM CCA, sorti fin 2021, est adapté aux environnements cloud, contrairement à TrustZone, qui a été conçu pour des environnements embarqués ou mobiles uniques. TrustZone gère statiquement des régions de mémoire sécurisées pré-désignées, tandis que CCA facilite la création dynamique de Realms (enclaves sécurisées). Cela permet plusieurs environnements isolés au sein d'une seule configuration physique.

CCA peut être assimilé à une version ARM d'Intel SGX, bien qu'avec des différences notables. Alors que SGX a des limitations de mémoire, CCA offre une allocation de mémoire flexible. De plus, CCA utilise une approche de sécurité fondamentalement différente en cryptant toute la mémoire physique, et pas seulement les régions d'enclave désignées comme le fait SGX.

Intel TDX

Intel a introduit TDX, une technologie qui chiffre la mémoire au niveau de la machine virtuelle, similaire à SEV d'AMD. Cette version prend en compte les commentaires sur les limitations de SGX(v1), notamment la limite de taille de l'enclave de 256 Mo et la complexité accrue du développement due à la création d'enclave au niveau du processus. La principale différence avec SEV est que TDX fait partiellement confiance au système d'exploitation, en particulier à l'hyperviseur, pour la gestion des ressources de la machine virtuelle. De plus, il existe des différences dans les mécanismes de chiffrement pour chaque machine virtuelle.

AMD SEV-SNP

SEV-SNP améliore la sécurité du modèle SEV existant. Le SEV original reposait sur un modèle de confiance qui laissait des vulnérabilités, permettant aux hyperviseurs de modifier la cartographie de la mémoire. SEV-SNP résout ce problème en ajoutant un gestionnaire matériel pour suivre les états de la mémoire, empêchant de telles modifications.

De plus, cela permet aux utilisateurs d'effectuer une attestation à distance directement, minimisant ainsi les points de confiance. SEV-SNP a également introduit une table de mappage inversée pour surveiller les états et la propriété des pages de mémoire, offrant une défense contre les modèles d'attaques hyperviseur malveillants.

GPU TEE: Calcul confidentiel NVIDIA

Le développement des TEE a traditionnellement été axé sur les CPU en raison de sa dépendance vis-à-vis des fournisseurs de matériel. Cependant, la nécessité de gérer des calculs complexes tels que la formation sécurisée de l'IA et la protection des données de formation a souligné la nécessité d'un TEE GPU. En réponse, NVIDIA a introduit des fonctionnalités de calcul confidentiel sur le GPU H100 en 2023.

NVIDIA Confidential Computing offre des instances de GPU chiffrées et gérées de manière indépendante, garantissant une sécurité de bout en bout lorsqu'elles sont combinées avec CPU TEE. Actuellement, cela est réalisé en intégrant AMD SEV-SNP ou Intel TDX pour créer des pipelines de calcul confidentiel.

1.2. Comment faire confiance à TEE ?

Lors de l'examen des projets Web3, vous verrez souvent des revendications de gouvernance communautaire grâce aux téléchargements de code sur GitHub. Mais comment peut-on vérifier que le programme déployé sur le serveur correspond réellement au code GitHub ?

La blockchain offre un environnement dans lequel les contrats intelligents sont toujours publics et immuables en raison d'un consensus continu. En revanche, les serveurs typiques de Web2 permettent aux administrateurs de mettre à jour les programmes à tout moment. Pour vérifier l'authenticité, les utilisateurs doivent comparer les valeurs de hachage des binaires construits à partir de programmes open-source sur des plateformes comme GitHub ou vérifier l'intégrité via les signatures des développeurs.

Le même principe s'applique aux programmes au sein des enclaves TEE. Pour que les utilisateurs fassent entièrement confiance aux programmes déployés sur le serveur, ils doivent vérifier (attester) que le code et les données au sein de l'enclave restent inchangés. Dans le cas de SGX, il communique avec l'IAS (Intel Attestation Service) en utilisant une clé stockée dans une enclave spéciale. L'IAS vérifie l'intégrité de l'enclave et de ses données internes, puis renvoie les résultats aux utilisateurs. En résumé, TEE nécessite une communication avec les serveurs d'attestation fournis par le fournisseur de matériel pour assurer l'intégrité de l'enclave.

2. TEE sur Web3

Pourquoi TEE sur Web3?

TEE peut sembler inconnu du grand public, car ses connaissances sont généralement limitées à des domaines spécialisés. Cependant, l'émergence de TEE s'aligne bien avec les principes de Web3. La prémisse fondamentale de l'utilisation de TEE est "ne faire confiance à personne". Lorsqu'il est correctement mis en œuvre, TEE peut protéger les données utilisateur du déploieur du programme, du propriétaire du serveur physique et même du noyau OS.

Alors que les projets actuels de blockchain ont atteint une décentralisation structurelle significative, beaucoup reposent encore sur des environnements de serveur hors chaîne tels que des séquenceurs, des relais hors chaîne et des bots de gardien. Les protocoles qui ont besoin de traiter des informations sensibles des utilisateurs, comme les données KYC ou biométriques, ou ceux qui visent à prendre en charge des transactions privées, sont confrontés au défi de nécessiter une confiance envers les fournisseurs de services. Ces problèmes peuvent être considérablement atténués grâce au traitement des données au sein de zones sécurisées.

Par conséquent, TEE a gagné en popularité au cours de la dernière moitié de cette année, s'alignant sur des thèmes liés à l'IA tels que la confidentialité des données et les agents IA de confiance. Cependant, les tentatives d'intégrer TEE dans l'écosystème Web3 existaient bien avant cela. Dans cet article, nous présenterons des projets dans divers domaines qui ont appliqué TEE dans l'écosystème Web3, au-delà du seul secteur de l'IA.

2.1. Coprocesseur confidentiel

Marlin

Marlin est un protocole de calcul vérifiable conçu pour offrir un environnement de calcul sécurisé en utilisant la technologie TEE ou ZK. L'un de leurs principaux objectifs est de développer un web décentralisé. Marlin gère deux sous-réseaux : Oyster et Kalypso, et Oyster fonctionne comme le protocole de coprocesseur basé sur TEE.

1) Oyster CVM

Oyster CVM (Oyster for convenience) agit en tant que marché pair à pair de TEE. Les utilisateurs achètent des environnements de calcul AWS Nitro Enclave via le marché hors chaîne d'Oyster et déploient leurs images de programme là-bas. Voici une structure abstraite d'Oyster :

source : https://docs.marlin.org/oyster/protocol/cvm/workflow/

Oyster présente une structure très similaire à Akash. Dans Oyster, le rôle de la blockchain est de vérifier si chaque environnement de calcul TEE fonctionne correctement, et cela se fait via des observateurs appelés Fournisseurs. Les Fournisseurs vérifient en continu la disponibilité des Enclaves en temps réel et rapportent leurs conclusions au réseau Oyster. Ils misent $PONDLes jetons sont exposés au risque de réduction s'ils se livrent à des activités malveillantes. De plus, un réseau décentralisé d'entités, appelé «auditeurs», existe pour superviser la réduction des fournisseurs. À chaque époque, les auditeurs se voient attribuer leurs tâches et envoient des demandes d'audit aux enclaves qui sont choisies au hasard par une graine générée à l'intérieur d'une enclave.

Cependant, Oyster a implémenté un contrat appelé NitroProver qui vérifie les résultats de l’attestation à distance sur la chaîne, ce qui permet aux utilisateurs de vérifier l’intégrité de leur TEE acheté sur la chaîne.

Les instances déployées par l'utilisateur peuvent être accessibles à la fois via des contrats intelligents et des API Web2. Les résultats de calcul peuvent être intégrés aux contrats en les présentant comme des oracles. Comme le montre le tableau de bord, cette fonctionnalité convient non seulement aux contrats intelligents, mais aussi à la décentralisation des services Web2.

Tout comme Akash, Oyster est susceptible de subir des prises de contrôle d'instance potentielles par des attaquants s'il existe des vulnérabilités dans le marché hors chaîne. Dans de tels scénarios, bien que les données de l'enclave puissent rester sécurisées, les données brutes stockées en dehors de l'enclave et les privilèges d'opération de service pourraient être compromis. En cas de données sensibles, qui sont stockées dans une mémoire non fiable mais qui ne doivent pas être exposées, les développeurs doivent chiffrer ces données et les stocker séparément. Marlin fournit actuellement un stockage externe avec une clé persistante basée sur MPC pour gérer ces cas.

2) Oyster Serverless

Alors que Oyster CVM fonctionne comme un marché P2P TEE, Oyster Serverless ressemble à AWS Lambda (ou Function-as-a-Service) avec TEE. En utilisant Oyster Serverless, les utilisateurs peuvent exécuter des fonctions sans louer d'instances, en payant à la demande.

Le flux d'exécution d'Oyster Serverless serait le suivant :

1. Les utilisateurs créent des demandes au contrat de relais
2. Le serveur de passerelle hors chaîne observe les demandes des utilisateurs via l'événement
3. Le serveur passerelle relaie la demande de l'utilisateur vers le protocole de passerelle.
4. Le protocole gateway crée et attribue un travail au protocole sans serveur, en fonction de la demande de l'utilisateur
5. Les serveurs d'exécution écoutent les tâches assignées au protocole Serverless, exécutent la tâche et soumettent une réponse
6. La réponse - le résultat de la demande de l'utilisateur - est transmise séquentiellement à l'utilisateur

Avec Oyster Serverless, les utilisateurs peuvent envoyer des requêtes d’API web2 ou des appels de contrats intelligents via un contrat intelligent, tout en garantissant l’intégrité de l’exécution via TEE. Les utilisateurs peuvent également s’abonner sans serveur pour une exécution périodique, ce qui serait particulièrement utile pour les récupérateurs d’oracles.

Réseau Phala

Phala, dont nous avons déjà parlé dans notre article AI X Crypto, s’est considérablement concentré sur les coprocesseurs d’IA.

La conception de base du réseau Phala comprend des Workers et des gatekeepers. Les Workers fonctionnent comme des nœuds normaux qui exécutent des calculs pour les clients. Les gatekeepers, quant à eux, gèrent les clés qui permettent aux Workers de décrypter et de calculer des valeurs d'état chiffrées. Les Workers gèrent des valeurs d'état de contrat chiffrées via Intel SGX, ce qui nécessite des clés des gatekeepers pour lire ou écrire ces valeurs.

source: https://docs.phala.network/tech-specs/blockchain

Phala a élargi son offre en prenant en charge les SDK pour les machines virtuelles confidentielles dans les environnements Intel TDX. Récemment, en collaboration avec Flashbot, ils ont lancé Dstack. Ce produit dispose d'une API d'attestation à distance pour vérifier l'état opérationnel de plusieurs images de conteneurs Docker déployées dans des machines virtuelles confidentielles. L'attestation à distance via Dstack garantit la transparence via une plate-forme dédiée.Explorateur.

Un autre développement significatif est leur produit Confidential AI Inference, introduit en réponse à la récente vague de projets d'IA. Phala Network prend désormais en charge le calcul confidentiel Nvidia relativement nouveau, visant à améliorer les services d'inférence en IA en utilisant ZK/FHE. Cette technologie était auparavant confrontée à des défis en raison d'une forte surcharge, limitant sa praticité.

source: https://docs.phala.network/overview/phala-network/confidential-ai-inference

L'image illustre la structure du système d'inférence AI confidentiel de Phala Network. Ce système utilise des environnements d'exécution de confiance (TEEs) au niveau des machines virtuelles tels que Intel TDX et AMD SEV pour déployer des modèles d'IA. Il effectue des inférences d'IA via la confidentialité de calcul de Nvidia et transmet en toute sécurité les résultats à l'enclave CPU. Cette méthode peut entraîner des frais généraux importants par rapport aux modèles réguliers, car elle implique deux rounds de calcul d'enclave. Néanmoins, il est prévu qu'elle apporte des améliorations substantielles des performances par rapport aux méthodes d'inférence TEE existantes qui reposent entièrement sur les performances du CPU. Selon lepapierpublié par Phala Network, l'overhead d'inférence LLM basé sur Llama3 a été mesuré à environ 6 à 8%.

Autres

Dans le domaine AI X Crypto, d’autres exemples d’utilisation de TEE en tant que coprocesseurs incluent iExec RLC, PIN AI et Super Protocol. iExec RLC et PIN AI se concentrent respectivement sur la protection des modèles d’IA et des données d’entraînement par le biais de TEE. Super Protocol s’apprête à lancer une place de marché pour le trading d’environnements informatiques TEE, similaire à Marlin. Cependant, les informations techniques détaillées sur ces projets ne sont pas encore accessibles au public. Nous fournirons des mises à jour après le lancement de leurs produits.

2.2. Contrats intelligents sécurisés

Oasis (Préc. Rose)

Oasis, anciennement connu sous le nom de Rose, est une blockchain de couche 1 conçue pour protéger la confidentialité des utilisateurs lors des transactions en exécutant son client d'exécution dans une enclave SGX. Bien qu'il soit une chaîne relativement mature, Oasis a mis en œuvre de manière innovante la prise en charge multi-VM dans sa couche d'exécution.

La couche d'exécution, appelée Paratime, comprend trois composants: Cipher, une VM confidentielle basée sur WASM; Sapphire, une VM confidentielle basée sur EVM; et Emerald, une VM compatible avec EVM standard. Oasis protège fondamentalement les contrats intelligents et leurs processus de calcul contre des modifications arbitraires par les nœuds, en veillant à ce que le client d'exécution fonctionne dans une enclave TEE. Cette structure est illustrée dans le diagramme ci-joint.

source: https://docs.oasis.io/general/oasis-network/

Lorsque les utilisateurs envoient des transactions, ils chiffrent les données de transaction à l'aide d'une clé éphémère générée par le gestionnaire de clés du nœud Oasis au sein de l'enclave et les transmettent au module de calcul. Le module de calcul reçoit la clé privée de la clé éphémère du gestionnaire de clés, l'utilise pour décrypter les données dans l'enclave, exécute le contrat intelligent et modifie les valeurs d'état du nœud. Comme les résultats de l'exécution de la transaction sont également livrés aux utilisateurs sous forme chiffrée, ni le serveur exploitant le client du nœud Oasis ni les entités externes ne peuvent observer le contenu de la transaction.

Oasis met en avant sa force dans la facilitation de la création de DApps qui gèrent des informations personnelles sensibles sur des blockchains publiques, en utilisant son Confidential Paratime. Cette fonctionnalité permet le développement de services nécessitant une vérification d'identité, tels que SocialFi, le prêt de crédit, les services d'intégration CEX et les services basés sur la réputation. Ces applications peuvent recevoir et vérifier de manière sécurisée les informations biométriques ou KYC des utilisateurs au sein d'une enclave sécurisée.

Réseau Secret

Secret Network est une chaîne de couche 1 au sein de l'écosystème Cosmos et est l'une des plus anciennes blockchains basées sur TEE. Elle utilise les enclaves Intel SGX pour crypter les valeurs d'état de la chaîne, ce qui permet des transactions privées pour ses utilisateurs.

Dans Secret Network, chaque contrat dispose d’une clé secrète unique stockée dans l’enclave de chaque nœud. Lorsque les utilisateurs appellent des contrats via des transactions chiffrées avec des clés publiques, les nœuds déchiffrent les données de transaction dans le TEE pour interagir avec les valeurs d’état du contrat. Ces valeurs d’état modifiées sont ensuite enregistrées dans des blocs, qui restent chiffrées.

Le contrat lui-même peut être partagé avec des entités externes sous forme de bytecode ou de code source. Cependant, le réseau garantit la confidentialité des transactions des utilisateurs en empêchant l'observation directe des données de transaction envoyées par l'utilisateur et en bloquant l'observation externe ou la manipulation des valeurs d'état de contrat actuelles.

Étant donné que toutes les valeurs d’état des contrats intelligents sont chiffrées, leur affichage nécessite un déchiffrement. Secret Network résout ce problème en introduisant des clés d’affichage. Ces clés lient des mots de passe utilisateur spécifiques aux contrats, ce qui permet uniquement aux utilisateurs autorisés d’observer les valeurs d’état du contrat.

Clique, Protocole Quex

Contrairement aux L1 basés sur TEE introduits précédemment, Clique et Quex Protocol offrent une infrastructure qui permet aux DApps générales de déléguer des calculs privés à un environnement TEE hors chaîne. Ces résultats peuvent être utilisés au niveau des contrats intelligents. Ils sont notamment utilisés pour les mécanismes de distribution d’incitations vérifiables, les carnets d’ordres off-chain, les oracles et la protection des données KYC.

2.3. Système de preuve de validité

Certaines chaînes ZK L2 utilisent des systèmes à preuves multiples pour résoudre l'instabilité inhérente des preuves à connaissance nulle, incorporant souvent des preuves TEE. Les mécanismes modernes de preuve à connaissance nulle ne sont pas encore suffisamment matures pour être entièrement fiables en termes de sécurité, et les bugs liés à la cohérence dans les circuits ZK nécessitent des efforts considérables pour être corrigés en cas d'incidents. Par précaution, les chaînes utilisant des preuves ZK ou des ZK-EVM adoptent des preuves TEE pour détecter les bugs potentiels en réexécutant les blocs via des machines virtuelles locales dans des enclaves. Actuellement, les L2 utilisant des systèmes de preuves multiples, y compris TEE, sont Taiko, Scroll et Ternoa. Examinons brièvement leurs motivations pour utiliser des systèmes de preuves multiples et leurs structures.

Taiko

Taiko est actuellement le chaînon rollup le plus en vue (prévu) Basé. Une chaîne rollup délègue le séquençage aux proposants de blocs Ethereum sans conserver un séquenceur centralisé séparé. Selon le diagramme de Taiko du Basé Rollup, les chercheurs L2 composent des bundles de transactions et les livrent à L1 sous forme de lots. Les proposants de blocs L1 reconstruisent ensuite ceux-ci, ainsi que les transactions L1, pour générer des blocs L1 et capturer le MEV.

source: https://docs.taiko.xyz/core-concepts/multi-proofs/

Dans Taiko, TEE est utilisé non pas pendant l'étape de composition des blocs mais à l'étape de génération de preuve, ce que nous expliquerons. Taiko, avec sa structure décentralisée, ne nécessite pas de vérification des dysfonctionnements du séquenceur. Cependant, si des bugs se trouvent dans le code client du nœud L2, une configuration entièrement décentralisée ne peut pas les gérer rapidement. Cela nécessite des preuves de validité de haut niveau pour garantir la sécurité, ce qui entraîne une conception de défi plus complexe par rapport à d'autres rollups.

Les blocs de Taiko passent par trois étapes de confirmation : proposée, prouvée et vérifiée. Un bloc est considéré comme proposé lorsque sa validité est vérifiée par le contrat L1 de Taiko (contrat rollup). Il atteint l'état prouvé lorsqu'il est vérifié par des prouveurs parallèles, et l'état vérifié lorsque son bloc parent a été prouvé. Pour vérifier les blocs, Taiko utilise trois types de preuves : la preuve TEE basée sur SGX V2, la preuve ZK basée sur Succinct/RiscZero et la preuve Guardian, qui repose sur un multisig centralisé.

Taiko utilise un modèle de contestation pour la vérification des blocs, établissant une hiérarchie des niveaux de sécurité parmi les Provers: TEE, ZK, ZK+TEE et Guardian. Cette configuration permet aux challengers de gagner des récompenses plus importantes lorsqu'ils identifient des preuves incorrectes générées par des modèles de niveau supérieur. Les preuves requises pour chaque bloc sont attribuées de manière aléatoire avec les pondérations suivantes: 5% pour SGX+ZKP, 20% pour ZKP et le reste en utilisant SGX. Cela garantit que les ZK provers peuvent toujours obtenir des récompenses plus élevées lors de défis réussis.

Les lecteurs peuvent se demander comment les proueurs SGX génèrent et vérifient les preuves. Le rôle principal des proueurs SGX est de démontrer que les blocs de Taiko ont été générés par calcul standard. Ces proueurs génèrent des preuves de changements de valeur d'état et vérifient l'environnement à l'aide des résultats de la réexécution des blocs via une machine virtuelle locale dans l'environnement TEE, ainsi que des résultats d'attestation d'enclave.

Contrairement à la génération de preuve ZK, qui implique des coûts computationnels importants, la génération de preuve basée sur TEE vérifie l'intégrité computationnelle à un coût beaucoup plus bas, sous des hypothèses de sécurité similaires. La vérification de ces preuves implique des vérifications simples, telles que s'assurer que la signature ECDSA utilisée dans la preuve correspond à la signature du prouveur.

En conclusion, les preuves de validité basées sur TEE peuvent être considérées comme une méthode de vérification de l’intégrité de la chaîne en générant des preuves avec des niveaux de sécurité légèrement inférieurs mais à un coût considérablement inférieur à celui des preuves ZK.

SCROLL

Scroll est un rollup notable qui adopte un système multi-preuve. Il collabore avec Automata, une couche d'attestation qui sera introduite ultérieurement, pour générer à la fois des preuves ZK et des preuves TEE pour tous les blocs. Cette collaboration active un système de résolution des conflits entre les deux preuves.

source:https://scroll.io/blog/scaling-security

Scroll prévoit de prendre en charge différents environnements matériels (actuellement seulement SGX), y compris Intel SGX, AMD SEV et AWS Nitro, pour minimiser les dépendances matérielles. Ils abordent les problèmes de sécurité potentiels dans TEE en collectant des preuves provenant d'environnements divers à l'aide de signatures de seuil.

Ternoa

Ternoa privilégie la détection des actions malveillantes par des entités centralisées de niveau 2 plutôt que de résoudre les bugs de l'exécution elle-même. Contrairement à Taiko ou Scroll, qui utilisent des prouveurs TEE pour compléter les preuves ZK existantes, Ternoa utilise des Observateurs dans des environnements basés sur TEE. Ces Observateurs détectent les actions malveillantes des séquenceurs et validateurs de niveau 2, en se concentrant sur des domaines qui ne peuvent pas être évalués uniquement à partir des données de transaction. Des exemples comprennent des nœuds RPC censurant des transactions en fonction de l'adresse IP, des séquenceurs modifiant les algorithmes de séquençage ou ne soumettant volontairement pas de données groupées.

Ternoa exploite un réseau L2 distinct appelé Integrity Verification Chain (IVC) pour les tâches de vérification relatives aux entités rollup. Le fournisseur de la structure de rollup soumet la dernière image du séquenceur à l'IVC. Lorsqu'un nouveau rollup demande le déploiement, l'IVC renvoie des images de service stockées dans TEE. Après le déploiement, les Observateurs vérifient régulièrement si le rollup déployé utilise l'image du séquenceur tel qu'il est prévu. Ils soumettent ensuite des preuves d'intégrité, incorporant leurs résultats de vérification et des rapports d'attestation de leur environnement TEE, pour confirmer l'intégrité de la chaîne.

2.3. Sécurité d’Ethereum

2.3.1. Décentralisation du constructeur de blocs

Flashbots BuilderNet

Flashbots, largement reconnu comme un fournisseur de solutions MEV, a constamment exploré l’application des environnements d’exécution de confiance (TEE) dans la technologie blockchain. Parmi les efforts de recherche notables, citons :

• Investigation de l'exécution de Geth au sein d'un Enclave SGX et de ses limitations
• Mise en œuvre d'un constructeur de blocs basé sur SGX
• Construction d'une chaîne de coprocesseurs TEE basée sur l'exécution REVM dans une enclave SGX, complétée par une couche de vérification Automata

Dans cet article, nous allons brièvement présenter le rôle actuel de Flashbots et discuter de BuilderNet, une initiative récente visant à décentraliser la construction de blocs. Flashbots a annoncé des plans de migration complets pour leur solution existante via BuilderNet.

Ethereum utilise un modèle de séparation des rôles de proposant et de constructeur. Ce système divise la création de blocs en deux rôles - 1) Les constructeurs : Responsables de la création de blocs et de l'extraction de la MEV 2) Les proposants : Signent et propagent les blocs créés par les constructeurs pour décentraliser les profits de la MEV. Cette structure a conduit à la collusion de certaines applications décentralisées avec les constructeurs hors chaîne pour capturer des profits de la MEV substantiels. En conséquence, quelques constructeurs, tels que Beaverbuild et Titan Builder, créent monopolistiquement plus de 90 % des blocs Ethereum. Dans les cas graves, ces constructeurs peuvent censurer des transactions arbitraires. Par exemple, les transactions réglementées, comme celles de Tornado Cash, sont activement censurées par les principaux constructeurs.

BuilderNet aborde ces problèmes en améliorant la confidentialité des transactions et en réduisant les obstacles à la participation des constructeurs de blocs. Sa structure peut être résumée de manière générale comme suit:

source: https://buildernet.org/docs/architecture

Les nœuds constructeurs, qui reçoivent les transactions des utilisateurs (Orderflow), sont gérés par différents opérateurs de nœuds. Chacun exploite des instances constructrices open source dans des environnements Intel TDX. Les utilisateurs peuvent vérifier librement l'environnement TEE de chaque opérateur et envoyer des transactions chiffrées. Les opérateurs partagent ensuite leur orderflow reçu, soumettent des blocs au relais MEV-boost et distribuent les récompenses en bloc aux chercheurs et aux autres personnes impliquées dans la création de blocs suite à une soumission réussie.

Cette structure offre plusieurs avantages en matière de décentralisation :

• Vérifiabilité: Chaque instance de Builder fonctionne au sein d'un TEE, permettant aux utilisateurs de vérifier que les Builders n'ont pas censuré les transactions ou modifié arbitrairement les clients. La politique de distribution des récompenses pour les contributeurs à la création de blocs est également transparente au sein du TEE.
• Résistance à la censure : Dans BuilderNet, les nœuds builder sont gérés par plusieurs opérateurs, chacun ayant des politiques réglementaires différentes. Cette diversité signifie qu'ils choisissent différentes transactions à exclure. Même si certains opérateurs censurent des transactions, d'autres peuvent toujours les sélectionner. Théoriquement, s'il y a au moins un builder qui ne censure pas, les transactions des utilisateurs peuvent être incluses dans les blocs. BuilderNet offre également une solution aux problèmes de censure de L2, montrant que les L2 peuvent atteindre une résistance à la censure plus élevée que les séquenceurs uniques en externalisant la construction des blocs à BuilderNet. (Dans ce cas, le niveau de résistance à la censure peut être affecté par des composants supplémentaires qui filtrent les transactions avant le séquenceur, par exemple un pare-feu)
• Décentralisation : Les constructeurs de blocs actuels sont confrontés à une dépendance à l'égard de l'infrastructure centralisée. BuilderNet vise à résoudre ce problème en intégrant divers constructeurs, à commencer par Beaverbuild. À mesure que d'autres constructeurs de blocs rejoignent BuilderNet, la structure PBS d'Ethereum connaîtra une décentralisation accrue. À l'heure actuelle, seuls Beaverbuild, Flashbots et Nethermind font partie de BuilderNet. Les autres constructeurs ont besoin d'une autorisation pour rejoindre, mais il est prévu de rendre le déploiement des opérateurs sans autorisation et d'éliminer complètement l'infrastructure centralisée à l'avenir.

2.3.2. Protection du validateur

Puffer Finance

Puffer Finance a introduit un outil Secure Signer conçu pour réduire le risque de pénalités des validateurs Ethereum en raison d'erreurs ou de bugs du client. Cet outil utilise un signataire basé sur SGX Enclave pour une sécurité accrue.

source: https://docs.puffer.fi/technology/secure-signer/

Le signataire sécurisé fonctionne en générant et en stockant des clés de validation BLS dans l’enclave SGX, en y accédant uniquement lorsque cela est nécessaire. Sa logique est simple : en plus de la sécurité fournie par le Trusted Execution Environment (TEE), il peut détecter les erreurs du validateur ou les actions malveillantes. Pour ce faire, il faut s’assurer que les créneaux horaires ont été strictement augmentés avant de signer des blocs ou des épreuves. Puffer Finance souligne que cette configuration permet aux validateurs d’atteindre des niveaux de sécurité comparables à ceux des portefeuilles matériels, surpassant les protections typiques offertes par les solutions logicielles.

2.4. Décentralisation du séquenceur L2

Unichain

Unichain, la chaîne de couche 2 (L2) d'Uniswap prévue pour être lancée au premier trimestre de l'année prochaine, a partagé ses plans dans leur livre blanc pour décentraliser les mécanismes de construction de blocs L2 en utilisant des environnements d'exécution de confiance (TEE). Bien que les spécifications techniques détaillées restent non publiées, voici un résumé de leurs principales propositions:

• Séparation entre le constructeur de séquenceur : Pour améliorer les structures rollup existantes où le séquençage et la génération de blocs L2 sont gérés par des séquenceurs centralisés, Unichain a collaboré avec Flashbots. Ce partenariat vise à séparer les séquenceurs L2 des constructeurs de blocs. Les constructeurs de blocs d'Unichain fonctionneront en utilisant un code open-source dans Intel TDX, garantissant la transparence en publiant publiquement les résultats d'attestation pour l'exécution.
• Flashblock: Unichain identifie les limitations de la scalabilité avec le processus de préconfirmation actuel fourni par les séquenceurs rollup, tels que la sérialisation et la génération de la racine d'état. Pour y remédier, ils prévoient d'introduire des « Flashblocks », permettant aux utilisateurs de recevoir des blocs en attente immédiatement après l'ordonnancement des transactions par le biais des constructeurs TEE. Ils soulignent que le séquençage dans TEE garantira que l'ordonnancement des transactions est basé uniquement sur les frais de priorité et le moment de soumission, sans interférence du séquenceur, ce qui permettra une préconfirmation plus rapide.

De plus, Unichain a l'intention de développer diverses fonctionnalités basées sur TEE, notamment une mempool chiffrée, des transactions programmées et des contrats intelligents protégés par TEE.

2.5. RPC privé

Automates

Alors que la blockchain a atteint une décentralisation considérable dans ses aspects architecturaux, de nombreux éléments n'ont toujours pas une résistance à la censure suffisante en raison de leur dépendance vis-à-vis des opérateurs de serveurs. Automata vise à fournir des solutions qui minimisent la dépendance vis-à-vis des opérateurs de serveurs et l'exposition des données dans l'architecture de la blockchain basée sur TEE. Les mises en œuvre notables d'Automata comprennent des logiciels open source.SGX Proveret Vérificateur,Compilation TEEqui vérifie les correspondances entre les exécutables déployés dans TEE et le code source, etConstructeur TEEqui ajoute la confidentialité aux mécanismes de construction de blocs grâce à la mempool et au constructeur de blocs basés sur TEE. De plus, Automata permet que le résultat d'attestation à distance de TEE soit publié sur la chaîne, ce qui permet une vérification publique et une intégration dans les contrats intelligents.

Automata exploite actuellement 1RPC, un service RPC basé sur TEE conçu pour protéger les informations d'identification des soumetteurs de transactions, telles que les détails IP et de périphérique, via des enclaves sécurisées. Automata met en évidence le risque que, avec la commercialisation de UserOp due au développement de l'abstraction de compte, les services RPC pourraient déduire des motifs UserOp pour des utilisateurs spécifiques via l'intégration de l'IA, compromettant potentiellement la confidentialité. La structure de 1RPC est simple. Il établit des connexions sécurisées avec les utilisateurs, reçoit des transactions (UserOp) dans le TEE et les traite avec du code déployé dans l'enclave. Cependant, 1RPC ne protège que les métadonnées UserOp. Les parties réelles impliquées et le contenu de la transaction restent exposés lors de l'interaction avec l'Entrypoint sur la chaîne. Une approche plus fondamentale pour assurer la confidentialité des transactions consisterait à protéger les couches de la mempool et du bloc constructeur avec TEE. Cela pourrait être réalisé en intégrant le TEE Builder d'Automata.

2.6. Agents d'IA

source: https://x.com/tee_hee_he

Ce qui a finalement conduit à la renommée de la métadonnée TEE dans web3 était l'agent d'IA Twitter basé sur le TEE. Beaucoup de gens ont probablement rencontré TEE pour la première fois lorsqu'un agent d'IA nommé @tee_hee_heest apparu sur X fin octobre et a lancé son memecoin sur Ethereum.@tee_hee_he est un agent d’IA développé conjointement par Nous Research et le projet Teleport de Flashbots. Il a émergé en réponse aux inquiétudes selon lesquelles les comptes d’agents d’IA en vogue à l’époque ne pouvaient pas prouver qu’ils relayaient réellement les résultats générés par les modèles d’IA. Les développeurs ont conçu un modèle qui minimise l’intervention des entités centralisées dans des processus tels que la configuration du compte Twitter, la création d’un portefeuille cryptographique et le relais des résultats du modèle d’IA.

source: @tee_hee_he/setting-your-pet-rock-free-3e7895201f46"">https://medium.com/@tee_hee_he/setting-your-pet-rock-free-3e7895201f46

Ils ont déployé l'agent AI dans un environnement Intel TDX, générant des mots de passe de compte X par e-mail et des jetons OAuth pour accéder à Twitter via une simulation de navigateur, puis ont supprimé toutes les options de récupération.

Récemment, TEE a été utilisé dans un contexte similaire pour AI-Pool, où @123skelylevée de fonds réussie. Actuellement, après le déploiement de leurs contrats et la publication de leurs adresses, les jetons mèmes IA sont généralement acquis par des robots snipers techniquement supérieurs, qui sécurisent la majeure partie de la liquidité et manipulent les prix. AI-Pool tente de résoudre ce problème en permettant à l'IA d'effectuer un type de prévente.

source :https://x.com/0xCygaar/status/1871421277832954055

Un autre cas intéressant est celui de DeepWorm, un agent d’IA doté d’un réseau bioneuronal qui simule le cerveau d’un ver. À l’instar des autres agents d’IA, DeepWorm télécharge l’image d’enclave de son cerveau de ver sur Marlin Network pour protéger son modèle et assurer la vérifiabilité de son fonctionnement.

source: https://x.com/deepwormxyz/status/1867190794354078135

Depuis @tee_hee_heEn rendant open source tout le code requis pour le déploiement, le déploiement d'agents d'IA TEE fiables et non trompeurs est devenu assez facile. Récemment, Phala Network a déployé Eliza de a16z dans TEE. Comme l'a souligné a16z dans son rapport sur les perspectives du marché de la cryptographie 2025, le marché des agents d'IA basés sur TEE devrait servir d'infrastructure essentielle sur le marché futur des memecoins des agents d'IA.

2.7. Jeu social

Azuki Bobu

Azuki, un projet renommé d'Ethereum NFT, a collaboré avec Flashbots en octobre dernier pour organiser un événement social unique.

source: https://x.com/Azuki/status/1841906534151864557

Cela impliquait de déléguer les autorisations de téléchargement de compte Twitter à Flashbots et Bobu, qui ont ensuite publié des tweets simultanément, semblables à une foule éclair. L'événement a été un succès, comme le montre l'image ci-dessous.

source: https://collective.flashbots.net/t/tee-enabled-social-games-an-experiment-with-bobu-s-magic-show/3963

Conçue par Flashbots et Azuki, la structure de l’événement était la suivante :

1. Générez des clés privées et des certificats TLS, ainsi que des clés privées Ethereum, dans Gramin-SGX.
2. Les utilisateurs ont créé des jetons OAuth avec des autorisations limitées pour publier un seul tweet et les ont soumis au TEE de Flashbots via TLS.
3. Un contrat a été créé sur Arbitrum pour gérer les certificats des utilisateurs, empêchant les doubles dépenses et mettant en œuvre des sorties d'événements lors de la publication de tweets par les utilisateurs.

Azuki s’est assuré de la fiabilité du processus d’événement en publiant l’image Docker de l’Enclave sur Docker Hub. Ils ont également téléchargé des scripts de vérification du journal de transparence des certificats et des résultats d’attestation à distance pour l’environnement TEE sur GitHub. Bien que Flashbots ait identifié les dépendances aux nœuds RPC et blockchain comme des risques restants, ceux-ci pourraient être atténués par l’utilisation de TEE RPC ou de rollups basés sur TEE comme Unichain.

Bien que le projet n'ait pas réalisé de percée technique, il est remarquable pour avoir organisé un événement social fiable en utilisant uniquement une pile TEE.

3. Sécurité de TEE

TEE offre une sécurité beaucoup plus élevée par rapport aux solutions logicielles classiques car il offre une sécurité au niveau matériel que les logiciels ne peuvent pas compromettre directement. Cependant, TEE a été lent à être adoptée dans les produits réels en raison de plusieurs limitations, que nous allons présenter.

1) Mécanisme d'attestation centralisé

Comme mentionné précédemment, les utilisateurs peuvent utiliser des mécanismes d'attestation à distance pour vérifier l'intégrité des enclaves TEE et que les données à l'intérieur des enclaves n'ont pas été modifiées. Cependant, ce processus de vérification dépend inévitablement des serveurs du fabricant de puces. Le degré de confiance varie légèrement selon le fournisseur - SGX/TDX dépend entièrement du serveur d'attestation d'Intel, alors que SEV permet aux propriétaires de VM d'effectuer directement une attestation. Il s'agit d'un problème inhérent à la structure TEE, et les chercheurs en TEE travaillent à le résoudre grâce au développement d'un TEE open-source, que nous mentionnerons plus tard.

2) Attaques par canaux secondaires

TEE ne doit jamais exposer les données stockées dans des enclaves. Cependant, étant donné que TEE ne peut chiffrer les données qu’à l’intérieur d’enclaves, les vulnérabilités peuvent provenir d’attaques exploitant des informations secondaires, et non les données d’origine. Depuis la sortie publique d’Intel SGX en 2015, de nombreuses attaques critiques par canal auxiliaire ont été mises en évidence dans les principales conférences sur la sécurité des systèmes. Vous trouverez ci-dessous des scénarios d’attaque potentiels dans les cas d’utilisation de TEE, classés en fonction de leur impact :

• Fuite de flux de contrôle : des systèmes d'exploitation ou des programmes malveillants peuvent récupérer des données en exploitant les informations disponibles. Par exemple, ils peuvent profiter du fait que l'accès aux données du cache du processeur est beaucoup plus rapide que l'accès aux données de la DRAM. Cela leur permet d'identifier les motifs d'exécution du code d'opération et d'inférer des informations clés du programme, telles que les clés RSA. De plus, une attaque peut se produire lorsqu'un système d'exploitation malveillant restreint l'accès aux pages mémoire, ce qui provoque des erreurs de page dans le code de l'enclave et expose les motifs d'accès à la mémoire. La manipulation du tampon de destination de branchement pour prédire et gérer les branches du code peut également révéler le flux d'exécution du code. De plus, les attaquants peuvent exécuter de manière répétée le code de l'enclave dans des attaques de microscope pour inférer des informations.
• Fuite de données : Les vulnérabilités qui divulguent les données d'Enclave peuvent entraîner des attaques critiques, compromettant potentiellement l'attestation à distance. Notamment, des clés secrètes au sein d'une Enclave ont été divulguées en créant des applications shadow qui émulent le code et les données de l'Enclave, exécutant des attaques ROP sur elles (Dark-ROP). Des vulnérabilités supplémentaires résultent de l'exécution spéculative des programmes par les processeurs Intel pour l'optimisation des performances (Foreshadow). Bien que la mémoire de l'Enclave soit protégée par chiffrement, les données auxquelles accèdent les instructions exécutées de manière spéculative peuvent rester brièvement dans le cache. Cela peut être exploité pour lire les données de l'Enclave par le biais d'attaques de canal latéral du cache.
• Attaques DoS : Pour SGX, lorsque les vérifications d'intégrité de la mémoire détectent une altération, le système s'arrête. Cette vulnérabilité a été exploitée pour des attaques DoS en provoquant délibérément des échecs de vérification d'intégrité. Les attaquants peuvent provoquer l'arrêt du système en accédant de manière répétée à des rangées spécifiques de DRAM pour induire des inversions de bits dans les rangées adjacentes, potentiellement endommageant la mémoire de l'enclave.

Bien que TEE ne soit pas un système qui neutralise tous les vecteurs d'attaque et peut divulguer différents niveaux d'informations en raison de ses caractéristiques fondamentales, ces attaques nécessitent des prérequis solides, tels que le code de l'attaquant et de la victime s'exécutant sur le même cœur de processeur. Cela a conduit certains à le décrire comme le modèle de sécurité du “Man with the Glock”.

source: https://x.com/hdevalence/status/1613247598139428864

Cependant, étant donné que le principe fondamental de l'ETM est «ne faire confiance à personne», je pense que l'ETM devrait être en mesure de protéger les données même au sein de ce modèle afin de remplir pleinement son rôle de module de sécurité.

3) Exploits réels / récents sur TEE

De nombreux bugs ont été découverts dans les implémentations TEE, en particulier dans SGX, et la plupart ont été corrigés avec succès. Cependant, l'architecture matérielle complexe des systèmes TEE signifie que de nouvelles vulnérabilités peuvent apparaître à chaque sortie de matériel. Au-delà de la recherche universitaire, il y a eu des exploits réels affectant des projets Web3, qui nécessitent un examen détaillé.

• Réseau Secret : En tant que l'une des rares victimes d'exploits TEE authentiques, ce projet basé sur SGX a succombé à l'attaque de fuite AËPIC découverte en 2022. L'attaque a ciblé l'ensemble d'instructions AVX (Advanced Vector Extensions) dans les processeurs Intel récents. Elle a exploité des schémas d'exécution spéculative pendant les opérations AVX pour récupérer les clés de chiffrement stockées dans des régions d'enclave. Secret Network utilisait une graine de consensus pour que les validateurs puissent décrypter les transactions privées. L'attaquant a réussi à extraire cette graine, permettant le décryptage de toutes les transactions privées historiques sur le réseau. Plus de détails sur la vulnérabilité sont décrits à sgx.fail.
• Exposition de la clé racine SGX : En août, le chercheur en sécurité Mark Ermolov a annoncé le succès du décryptage de la clé de provisionnement racine et de la clé de scellement racine de SGX, des composants essentiels du modèle de confiance cryptographique de SGX. Ces clés sont généralement protégées par une logique complexe dans un dispositif de contrôleur de fusible physique. Cependant, une vulnérabilité critique a été trouvée où des copies de ces clés sont restées dans des tampons internes pendant les opérations. Bien que la possession de ces deux clés ne compromette pas entièrement SGX, l'obtention de la clé d'enveloppement globale pourrait potentiellement exposer l'ensemble du système SGX à des vulnérabilités. Malgré la suppression de SGX dans les processeurs Intel commerciaux sortis après 2021, il reste un vecteur d'attaque viable car plusieurs projets l'utilisent encore.
• Vulnérabilité AMD SEV-SNP : AMD SEV, une implémentation TEE relativement récente avec une large portée de protection au niveau de la machine virtuelle, a historiquement montré moins de vulnérabilités que SGX. Cependant, l’acceptation d’un article à l’IEEE S&P 2025 discutant de « BadRAM », une vulnérabilité ciblant AMD SEV-SNP, souligne que même les implémentations TEE modernes ne sont pas à l’abri des failles de sécurité. BadRAM exploite les modules de mémoire DDR4 et DDR5 pour créer un alias d’espace d’adressage dans la mémoire physique. En utilisant un Raspberry Pi Pico, qui coûte environ 10 $, les attaquants peuvent modifier les puces mémoire pour tromper le processeur sur la taille de la mémoire physique. Cela contourne efficacement le mécanisme de protection RMP (Reverse Map Table) d’AMD SEV-SNP. Pour plus d’informations sur cette vulnérabilité, consultez la page badram.eu.

Ces cas indiquent qu'une «TEE complètement sécurisée» est inaccessible et que les utilisateurs doivent être conscients des vulnérabilités potentielles avec les nouvelles versions matérielles.

4. Conclusion: L'open source est l'avenir

En novembre, Georgios Konstantopoulos de Paradigm a présenté un cadrepour l'évolution confidentielle du matériel, catégorisant le matériel sécurisé en cinq niveaux distincts:

• Niveau 1: Offre une confidentialité suffisante pour les applications Oracle et Bridge, avec une sécurité dépendant de la chaîne d'approvisionnement. Les exemples incluent SGX.
• Niveau 2 : conserve la sécurité de niveau 1 tout en améliorant l'expérience des développeurs et en prenant en charge des applications avancées telles que la délégation de compte OAuth, comme on peut le voir avec Teleport. Gramine SGX illustre ce niveau.
• Niveau 3 : Étend la sécurité de niveau 1 avec le support GPU, permettant des applications sophistiquées telles que l'apprentissage automatique privé et vérifiable. Intel TDX + Nvidia Confidential Computing représente cette catégorie.
• Niveau 4 : Utilise des ensembles d'instructions open source avec des processus de fabrication vérifiables publiquement, ce qui élimine les dépendances vis-à-vis des fournisseurs de matériel, comme le démontre OpenTEE.
• Niveau 5: Atteint un état idéal où plusieurs OpenTEEs travaillent ensemble par le biais de FHE/MPC, maintenant l'intégrité même si des unités matérielles individuelles sont compromises.

Actuellement, des projets tels que Confidential AI Inference de Phala Network fonctionnent au niveau 3, tandis que la plupart des services restent au niveau 2 en utilisant le cloud TEE ou Intel TDX. Bien que les projets basés sur Web3 TEE devraient finalement progresser vers un matériel de niveau 4, les limitations de performance actuelles rendent cela impraticable. Cependant, avec des VC majeurs tels que Paradigm et des équipes de recherche telles que Flashbots et Nethermind travaillant à la démocratisation de TEE, et compte tenu de l'alignement de TEE avec les principes de Web3, il est susceptible de devenir une infrastructure essentielle pour les projets Web3.

À propos de ChainLight

L'Explorateur de l'écosystème est le rapport de ChainLight présentant une analyse interne des projets en vogue de l'écosystème web3 dans une perspective de sécurité, rédigé par nos analystes de recherche. Dans le but d'aider les chercheurs en sécurité et les développeurs à apprendre, grandir et contribuer collectivement à rendre Web3 plus sûr, nous publions périodiquement notre rapport, gratuitement.

Pour recevoir les dernières recherches et rapports réalisés par des experts primés :

👉 Suivre @ChainLight_io@c4lvin

Établis en 2016, les experts primés de ChainLight fournissent des solutions de sécurité sur mesure pour renforcer votre contrat intelligent et vous aider à prospérer sur la blockchain.

Démenti:

1. Cet article est reproduit à partir de [Chaîne légère]. Tous les droits d'auteur appartiennent à l'auteur original [c4lvin*]. S’il y a des objections à cette réimpression, veuillez contacter le Porte d’apprentissageéquipe et ils s'en occuperont promptement.
2. Clause de non-responsabilité: Les vues et opinions exprimées dans cet article sont uniquement celles de l'auteur et ne constituent pas des conseils en investissement.
3. L’équipe de gate Learn a traduit l’article dans d’autres langues. La copie, la distribution ou le plagiat des articles traduits sont interdits, sauf mention contraire.