Guide du développeur pour TEE

Auteurs : prateek, roshan, siddhartha & linguine (Marlin), krane (Asula)Compilation : Shew, 仙壤GodREALM

Depuis l’annonce par Apple de son cloud privé et de l’offre par NVIDIA de calculs confidentiels dans ses GPU, l’environnement d’exécution fiable (TEE) est de plus en plus populaire. Leur garantie de confidentialité contribue à protéger les données des utilisateurs (y compris les clés privées) et leur isolation garantit que l’exécution des programmes déployés dessus ne sera pas altérée, que ce soit par des humains, d’autres programmes ou des systèmes d’exploitation. Il n’est donc pas surprenant que de nombreux produits Crypto x AI utilisent largement le TEE pour leur construction.

Comme toute nouvelle technologie, le TEE traverse une période expérimentale optimiste. Dans cet article, nous espérons fournir aux développeurs et aux lecteurs généraux un guide conceptuel de base pour leur permettre de comprendre ce qu’est le TEE, le modèle de sécurité du TEE, les vulnérabilités courantes et les meilleures pratiques pour une utilisation sécurisée du TEE. * (Remarque *: afin de rendre le texte plus compréhensible, nous avons délibérément remplacé les termes TEE par des mots équivalents plus simples).

Qu’est-ce que TEE

TEE est un environnement isolé dans un processeur ou un centre de données où les programmes peuvent s’exécuter sans aucune interférence du reste du système. Pour éviter les interférences des autres parties avec le TEE, nous avons besoin d’une série de conceptions, notamment un contrôle d’accès strict, qui contrôle l’accès des autres parties du système aux programmes et aux données du TEE. Actuellement, le TEE est omniprésent dans les téléphones, les serveurs, les PC et les environnements cloud, il est donc très accessible et abordable.

Le contenu ci-dessus peut sembler vague et abstrait, mais en réalité, différentes façons de mettre en œuvre TEE sont utilisées par différents serveurs et fournisseurs de cloud, mais l’objectif fondamental est d’éviter les interférences d’autres programmes avec TEE.

La plupart des lecteurs peuvent utiliser des informations de reconnaissance biologique pour se connecter à des appareils, comme déverrouiller un téléphone avec une empreinte digitale. Mais comment pouvons-nous nous assurer que les applications malveillantes, les sites Web ou les systèmes d’exploitation de jailbreak ne peuvent pas accéder et voler ces informations de reconnaissance biologique? En fait, en plus de crypter les données, les circuits dans le TEE empêchent fondamentalement l’accès à la mémoire et à la zone de traitement occupées par les données sensibles par tout programme.

Le portefeuille matériel est un autre exemple de scénario d’application TEE. Le portefeuille matériel est connecté à l’ordinateur et communique avec lui dans un environnement isolé, mais l’ordinateur ne peut pas accéder directement aux mots de passe stockés dans le portefeuille matériel. Dans les deux cas mentionnés ci-dessus, les utilisateurs font confiance au fabricant de l’appareil pour concevoir correctement la puce et fournir des mises à jour logicielles appropriées afin d’empêcher l’exportation ou la visualisation de données confidentielles à l’intérieur de la TEE.

Modèle de sécurité

Malheureusement, il existe de nombreux types d’implémentation TEE, et ces différentes implémentations (IntelSGX, IntelTDX, AMDSEV, AWSNitroEnclaves, ARMTrustZone) nécessitent toutes une modélisation et une analyse de sécurité indépendantes. Dans le reste de cet article, nous discuterons principalement d’IntelSGX, de TDX et d’AWSNitro, car ces systèmes TEE sont largement utilisés et disposent d’outils de développement complets. Ces systèmes susmentionnés sont également les plus couramment utilisés dans le Web3.

En général, le flux de travail des applications déployées dans TEE est le suivant :

1. Les “développeurs” ont écrit du code, qui peut être open source ou non.
2. Ensuite, les développeurs emballent le code dans un fichier d’image Enclave (EIF) qui peut être exécuté dans TEE.
3. EIF est hébergé sur un serveur équipé d’un système TEE. Dans certains cas, les développeurs peuvent héberger l’EIF sur un ordinateur personnel équipé d’un TEE pour fournir des services externes.
4. Les utilisateurs peuvent interagir avec l’application via une interface prédéfinie.

Manifestement, il y a 3 risques potentiels ici :

• Développeurs : Quel est l’objectif de préparer le code EIF ? Le code EIF peut ne pas correspondre à la logique métier promue par le projet, et il pourrait même voler les données privées des utilisateurs.
• Serveur : Le serveur TEE fonctionne-t-il avec le fichier EIF comme prévu ? Ou l’EIF est-il réellement exécuté à l’intérieur du TEE ? Le serveur pourrait également exécuter d’autres programmes à l’intérieur du TEE
• Fournisseur : Est-ce que la conception du TEE est sécurisée ? Est-ce qu’il y a une porte dérobée qui expose toutes les données du TEE au fournisseur ?

Il est heureux de constater que les TEE actuels disposent d’une solution pour éliminer les risques susmentionnés, à savoir des builds reproductibles(Reproducible Builds) et des attestations à distance(Remote Atteststations).

Qu’est-ce que la construction reproductible ? Le développement de logiciels modernes nécessite souvent l’importation de nombreuses dépendances, telles que des outils externes, des bibliothèques ou des frameworks, etc., et ces fichiers de dépendances peuvent également présenter des risques. Maintenant, des solutions telles que npm utilisent le hachage de code correspondant au fichier de dépendances comme identifiant unique. Lorsque npm découvre qu’un fichier de dépendances ne correspond pas à la valeur de hachage enregistrée, il peut considérer que ce fichier de dépendances a été modifié.

La construction reproductible peut être considérée comme un ensemble de normes visant à obtenir une valeur de hachage cohérente dès que tout code est exécuté sur n’importe quel appareil, à condition de suivre un processus de construction prédéfini. Bien sûr, nous pouvons également utiliser des produits autres que le hachage comme identificateur dans la pratique, que nous appelons ici mesure de code (code measurement).

Nix est un outil courant pour les builds reproductibles. Lorsque le code source du programme est exposé, n’importe qui peut inspecter le code pour s’assurer que le développeur n’a rien inséré d’inhabituel, et n’importe qui peut construire le code à l’aide de Nix pour vérifier si le produit construit a les mêmes métriques/hachage de code que le produit déployé par l’équipe de projet en production. Mais comment connaître les métriques de code d’un programme dans le TEE ? Cela nous amène au concept appelé « preuve à distance ». **

Preuve à distance est un message de signature provenant de la plateforme TEE (partie de confiance), contenant des mesures de code du programme, la version de la plateforme TEE, etc. La preuve à distance permet à un observateur externe de savoir qu’un programme s’exécute dans un endroit sécurisé inaccessible à quiconque (vrai TEE de version xx).

La reproductibilité et la preuve à distance permettent à tous les utilisateurs de connaître le code réel exécuté à l’intérieur de l’Enclave de Confiance (TEE) et les informations sur la version de la plateforme TEE, afin de prévenir les comportements malveillants des développeurs ou des serveurs.

Cependant, dans le cas de TEE, il est toujours nécessaire de faire confiance à son fournisseur. Si le fournisseur de TEE agit de manière malveillante, il peut falsifier directement la preuve à distance. Par conséquent, si le fournisseur est considéré comme un vecteur d’attaque possible, il est préférable de ne pas dépendre uniquement de TEE et de les combiner avec ZK ou un protocole de consensus.

L’attrait de TEE

Selon nous, les caractéristiques particulièrement populaires de TEE, en particulier pour le déploiement des agents d’IA, sont principalement les suivantes :

• Performance: TEE can run the LLM model with performance and cost similar to regular servers. zkML, on the other hand, requires a large amount of computing power to generate zk proofs for LLM.
• Prise en charge GPU : NVIDIA fournit une prise en charge de calcul TEE dans sa dernière série de GPU (Hopper, Blackwell, etc.)
• Exactitude : Les LLM sont non déterministes ; plusieurs entrées du même mot-clé donneront des résultats différents. Par conséquent, plusieurs nœuds (y compris les observateurs qui tentent de créer une preuve de fraude) peuvent ne jamais parvenir à un consensus sur les résultats de LLM. Dans ce scénario, nous pouvons faire confiance au LLM exécuté dans le TEE, qui ne peut pas être manipulé par des acteurs malveillants. Le programme à l’intérieur du TEE fonctionne toujours comme il a été écrit, ce qui rend le TEE plus adapté que l’opML ou le consensus pour garantir la fiabilité des résultats de raisonnement de LLM.
• Confidentialité : Les données dans TEE ne sont pas visibles pour les programmes externes. Ainsi, les clés privées générées ou reçues dans TEE sont toujours sécurisées. Cette fonctionnalité peut être utilisée pour garantir aux utilisateurs que tout message signé par cette clé provient du programme interne de TEE. Les utilisateurs peuvent en toute confiance confier leurs clés privées à TEE, définir certaines conditions de signature et vérifier que la signature provenant de TEE correspond aux conditions de signature préalablement définies.
• Connectivité : Avec certains outils, les programmes exécutés dans TEE peuvent accéder en toute sécurité à Internet (sans révéler les requêtes ou réponses au serveur exécutant TEE, tout en garantissant la récupération correcte des données pour les tiers). Cela est très utile pour récupérer des informations à partir d’API tierces, et peut être utilisé pour externaliser le calcul à des fournisseurs de modèles de confiance mais propriétaires.
• Permissions d’écriture : Contrairement au schéma zk, le code exécuté dans l’Environnement d’exécution sécurisé (TEE) peut construire des messages (qu’il s’agisse de tweets ou de transactions) et les envoyer via l’API et le réseau RPC.
• Convivialité pour les développeurs : Les cadres et les SDK associés à TEE permettent aux gens d’écrire du code dans n’importe quelle langue et de déployer facilement des programmes dans TEE, comme dans un serveur cloud.

Qu’il soit bon ou mauvais, il est actuellement difficile de trouver des alternatives à de nombreux cas d’utilisation de TEE. Nous croyons que l’introduction de TEE étend davantage l’espace de développement des applications sur la chaîne, ce qui peut stimuler l’émergence de nouveaux scénarios d’application.

TEE n’est pas une balle en argent

Les programmes exécutés dans un environnement d’exécution sécurisé (TEE) peuvent toujours être soumis à une série d’attaques et d’erreurs. Tout comme les contrats intelligents, ils peuvent rencontrer divers problèmes. Pour simplifier, nous classifions les vulnérabilités potentielles de la manière suivante :

• Développeur négligent
• Vulnérabilités d’exécution
• Défauts de conception d’architecture
• Problèmes d’exploitation

Développeurs négligents

Que ce soit intentionnel ou non, les développeurs peuvent affaiblir les garanties de sécurité des programmes dans le TEE par du code intentionnel ou non intentionnel. Cela inclut :

• Code opaque : Le modèle de sécurité du TEE dépend de la vérifiabilité externe. La transparence du code est cruciale pour la vérification par des tiers externes.
• Problèmes de mesure du code : Même si le code est public, si personne ne reconstruit le code et ne vérifie les mesures du code dans la preuve à distance, puis ne les vérifie en fonction des mesures du code fournies dans la preuve à distance. Cela équivaut à recevoir une preuve zk mais ne pas la vérifier.
• Code non sécurisé : Même si vous générez et gérez soigneusement les clés dans un environnement d’exécution sécurisé (TEE), la logique incluse dans le code peut potentiellement divulguer les clés de l’intérieur du TEE lors de l’appel externe. De plus, le code peut contenir des portes dérobées ou des vulnérabilités. Comparé au développement traditionnel côté serveur, cela nécessite des normes élevées en matière de développement et d’audit logiciel, similaires au développement de contrats intelligents.
• Attaque de la chaîne d’approvisionnement : Le développement de logiciels modernes utilise une grande quantité de code tiers. Les attaques de la chaîne d’approvisionnement représentent une menace majeure pour l’intégrité de la TEE.

Vulnérabilité d’exécution

Même les développeurs les plus prudents peuvent devenir des victimes de failles à l’exécution. Les développeurs doivent réfléchir attentivement à tout élément qui pourrait compromettre la sécurité de leur projet :

• Code dynamique: Il n’est pas toujours possible de rendre tout le code transparent. Parfois, le cas d’utilisation lui-même nécessite l’exécution dynamique du code opaque chargé dans TEE à l’exécution. Ce type de code est facilement susceptible de divulguer des informations confidentielles ou de compromettre des invariants, il est donc nécessaire de faire très attention pour éviter cette situation.
• Données dynamiques : La plupart des applications utilisent des API externes et d’autres sources de données pendant leur exécution. Le modèle de sécurité s’étend à ces sources de données, qui sont au même niveau que les oracles dans la DeFi. Des données incorrectes ou obsolètes peuvent entraîner des catastrophes. Par exemple, dans le cas d’utilisation de l’Agent IA, une dépendance excessive aux services LLM, tels que Claude, pourrait être préjudiciable.
• Communications non sécurisées et instables : TEE doit fonctionner à l’intérieur d’un serveur contenant des composants TEE. Du point de vue de la sécurité, le serveur exécutant le TEE est en fait un intermédiaire parfait entre le TEE et les interactions externes (MitM). Le serveur peut non seulement espionner les connexions externes du TEE et voir le contenu envoyé, mais aussi inspecter des adresses IP spécifiques, limiter les connexions et injecter des paquets de données dans les connexions afin de tromper une partie pour la faire croire qu’ils proviennent de xx.

Par exemple, un moteur de correspondance fonctionnant dans un environnement d’exécution sécurisé (TEE) est capable de traiter des transactions cryptographiques. Cependant, ce moteur ne peut pas garantir un ordre de traitement équitable (résistant aux attaques MEV) car les routeurs, les passerelles ou les hôtes peuvent toujours rejeter, retarder ou traiter en priorité les paquets en fonction de l’adresse IP source.

Défauts d’architecture

La pile technologique utilisée par l’application TEE doit être utilisée avec prudence. Lors de la construction de l’application TEE, les problèmes suivants peuvent survenir :

• Applications with a larger attack surface: The attack surface of an application refers to the number of code modules that need to be completely secure. Code with a larger attack surface is very difficult to audit and may hide bugs or exploitable vulnerabilities. This often conflicts with the experience of developers. For example, compared to TEE programs that do not rely on Docker, TEE programs that rely on Docker have a much larger attack surface. Enclaves that rely on mature operating systems have a larger attack surface compared to TEE programs that use the lightest operating systems.
• Portabilité et activité : Dans Web3, les applications doivent être résistantes à la censure. N’importe qui peut lancer un TEE et prendre le contrôle des participants inactifs du système, rendant ainsi les applications à l’intérieur du TEE portables. Le plus grand défi ici réside dans la portabilité des clés. Certains systèmes TEE ont des mécanismes de dérivation de clés, mais une fois que ces mécanismes sont utilisés à l’intérieur du TEE, les autres serveurs ne peuvent pas générer localement les clés des programmes externes au TEE, ce qui limite généralement les programmes TEE à une seule machine, ce qui n’est pas suffisant pour assurer la portabilité.
• Racine de confiance non sécurisée : Par exemple, lors de l’exécution de l’Agent IA dans un TEE, comment vérifier si une adresse donnée appartient à cet Agent ? Si cela n’est pas soigneusement conçu, la véritable racine de confiance pourrait être une entité tierce externe ou une plateforme de garde de clés, et non le TEE lui-même.

Problèmes d’exploitation

Enfin, mais non moins important, il y a quelques points pratiques à considérer en ce qui concerne le fonctionnement réel d’un serveur exécutant un programme TEE :

• Versions de plateforme non sécurisées : La plateforme TEE reçoit occasionnellement des mises à jour de sécurité, ces mises à jour se reflètent dans les versions de plateforme dans la preuve à distance. Si votre TEE ne fonctionne pas sur une version sécurisée de la plateforme, les pirates peuvent voler les clés de votre TEE à l’aide de vecteurs d’attaque connus. Le pire, c’est que votre TEE peut fonctionner sur une version sécurisée de la plateforme aujourd’hui, mais peut devenir non sécurisé demain.
• Aucune sécurité physique : Bien que vous ayez fait de votre mieux, le TEE peut être vulnérable aux attaques par canaux auxiliaires, ce qui nécessite généralement un accès physique et un contrôle du serveur où se trouve le TEE. Par conséquent, la sécurité physique est une couche de défense en profondeur importante. Un concept connexe est la preuve en nuage, où vous pouvez prouver que le TEE s’exécute dans un centre de données cloud et que cette plateforme cloud bénéficie d’une garantie de sécurité physique.

Construire des programmes TEE sécurisés

Nous divisons nos conseils en plusieurs points :

• La solution la plus sûre
• Mesures préventives nécessaires
• Recommandation basée sur le cas d’utilisation

1. La solution la plus sécurisée: sans dépendances externes

La création d’applications hautement sécurisées peut impliquer l’élimination des dépendances externes, telles que les entrées externes, les API ou les services, afin de réduire les surfaces d’attaque. Cette approche garantit que l’application fonctionne de manière autonome, sans interaction externe qui pourrait compromettre son intégrité ou sa sécurité. Bien que cette stratégie puisse limiter la diversité des fonctionnalités du programme, elle peut offrir un niveau élevé de sécurité.

Si le modèle est exécuté localement, pour la plupart des cas d’utilisation de CryptoxAI, ce niveau de sécurité peut être atteint.

2. Mesures de précaution nécessaires

Que l’application ait ou non des dépendances externes, les éléments suivants sont obligatoires !

Considérez l’application TEE comme un smart contract, pas une application backend; maintenez une fréquence de mise à jour plus faible, testez rigoureusement.

La construction d’un programme TEE doit être aussi rigoureuse que l’écriture, le test et la mise à jour de contrats intelligents. Comme les contrats intelligents, le TEE s’exécute dans un environnement hautement sensible et inviolable, où les erreurs ou les comportements inattendus peuvent entraîner des conséquences graves, y compris la perte totale de fonds. Un audit approfondi, des tests approfondis et des mises à jour minimales et soigneusement auditées sont essentiels pour garantir l’intégrité et la fiabilité des applications basées sur le TEE.

Vérifiez le code d’audit et examinez le pipeline de construction

La sécurité d’une application dépend non seulement du code lui-même, mais aussi des outils utilisés dans le processus de construction. Un pipeline de construction sécurisé est crucial pour prévenir les failles. TEE garantit seulement que le code fourni s’exécutera comme prévu, mais ne peut pas corriger les défauts introduits lors du processus de construction.

Pour réduire les risques, il est nécessaire de procéder à des tests et à des audits rigoureux du code afin d’éliminer les erreurs et d’empêcher toute divulgation d’informations inutile. De plus, la reproductibilité joue un rôle crucial, en particulier lorsque le code est développé par une partie et utilisé par une autre. La reproductibilité permet à quiconque de vérifier si le programme exécuté à l’intérieur de l’Enclave d’Exécution Sécurisée correspond au code source d’origine, garantissant ainsi transparence et confiance. Sans reproductibilité, il est presque impossible de déterminer exactement ce que contient le programme exécuté à l’intérieur de l’Enclave d’Exécution Sécurisée, mettant ainsi en péril la sécurité de l’application.

Par exemple, le code source de DeepWorm (un projet qui exécute un modèle de simulation cérébrale de ver dans TEE) est entièrement ouvert. Les programmes exécutés dans TEE sont construits de manière reproductible à l’aide de pipelines Nix.

Utiliser des bibliothèques vérifiées ou vérifiées

Lors du traitement des données sensibles dans les programmes TEE, veuillez n’utiliser que des bibliothèques auditées pour la gestion des clés et le traitement des données privées. Les bibliothèques non auditées pourraient exposer les clés et compromettre la sécurité de l’application. Il est préférable de privilégier les dépendances examinées de manière approfondie et axées sur la sécurité afin de maintenir la confidentialité et l’intégrité des données.

Vérification continue de la preuve provenant de TEE

Les utilisateurs qui interagissent avec TEE doivent valider la preuve à distance ou le mécanisme de vérification généré par TEE pour garantir une interaction sûre et fiable. Sans ces vérifications, le serveur pourrait manipuler les réponses, ce qui rendrait impossible de distinguer les sorties réelles de TEE des données altérées. La preuve à distance fournit une preuve cruciale pour les bibliothèques de code et la configuration exécutées dans TEE, nous permettant ainsi de déterminer si le programme exécuté à l’intérieur de TEE est conforme aux attentes.

La preuve spécifique peut être vérifiée sur la chaîne (IntelSGX, AWSNitro), vérifiée hors chaîne avec une preuve ZK (IntelSGX, AWSNitro), ou vérifiée par l’utilisateur lui-même ou un service de garde (tel que t16z ou MarlinHub).

3. Recommandations basées sur les cas d’utilisation

En fonction du cas d’utilisation et de la structure de l’application, les conseils suivants peuvent vous aider à rendre votre application plus sécurisée.

Assurez-vous d’exécuter toujours les interactions entre l’utilisateur et TEE sur un canal sécurisé

Les serveurs sur lesquels se trouvent les TEE ne sont pas de confiance. Les serveurs peuvent intercepter et modifier les communications. Dans certains cas, il peut être acceptable pour le serveur de lire les données sans les modifier, tandis que dans d’autres cas, même la lecture des données peut être indésirable. Pour réduire ces risques, il est essentiel d’établir un canal de communication sécurisé de bout en bout entre l’utilisateur et le TEE. Au minimum, assurez-vous que les messages contiennent une signature pour vérifier leur authenticité et leur provenance. De plus, il est important que les utilisateurs vérifient toujours la preuve à distance fournie par le TEE pour s’assurer qu’ils communiquent avec le bon TEE. Cela garantit l’intégrité et la confidentialité des communications.

Par exemple, Oyster prend en charge l’émission sécurisée de TLS en utilisant des enregistrements CAA et RFC8657. De plus, il propose un protocole TLS natif appelé Scallop, qui ne dépend pas de WebPKI.

La mémoire TEE est volatile

La mémoire TEE est volatile, ce qui signifie que lorsque le TEE est fermé, son contenu (y compris les clés de chiffrement) est perdu. Sans un mécanisme de sauvegarde sécurisé pour ces informations, les données critiques peuvent être définitivement inaccessibles, ce qui peut entraîner des difficultés financières ou opérationnelles.

Les réseaux de calcul multipartite (MPC) avec des systèmes de stockage décentralisés tels que IPFS peuvent être utilisés comme solution à ce problème. Le réseau MPC divise la clé en plusieurs nœuds, garantissant qu’aucun nœud individuel ne détient la clé complète, tout en permettant au réseau de reconstruire la clé au besoin. Les données cryptées avec cette clé peuvent être stockées en toute sécurité sur IPFS.

Si nécessaire, le réseau MPC peut fournir des clés à un nouveau serveur TEE exécutant la même image, à condition que certaines conditions soient remplies. Cette approche garantit l’élasticité et une sécurité robuste, permettant ainsi l’accessibilité et la confidentialité des données, même dans un environnement non fiable.

Il existe une autre solution, à savoir que TEE envoie les transactions associées à des serveurs MPC différents pour signature, regroupe les signatures des serveurs MPC et publie enfin les transactions. Cette méthode est beaucoup moins flexible et ne peut pas être utilisée pour stocker des clés API, des mots de passe ou des données arbitraires (sans service de stockage tiers de confiance).

Réduire la surface d’attaque

Pour les cas d’utilisation critiques en matière de sécurité, il vaut la peine d’essayer de réduire au minimum les dépendances externes au maximum, même au prix de sacrifier l’expérience des développeurs. Par exemple, Dstack est livré avec un noyau minimal basé sur Yocto, contenant uniquement les modules nécessaires au fonctionnement de Dstack. Il pourrait même être utile d’utiliser des technologies plus anciennes comme SGX (au-delà de TDX), car cette technologie ne nécessite pas de chargeur d’amorçage ou de système d’exploitation pour faire partie d’un TEE.

Isolation physique

La sécurité de TEE peut être renforcée en isolant physiquement TEE des interventions humaines potentielles. Bien que nous puissions croire que les centres de données peuvent offrir une sécurité physique en hébergeant des serveurs TEE, des projets tels que Spacecoin explorent une solution alternative assez intéressante - l’espace. Le document de SpaceTEE s’appuie sur des mesures de sécurité telles que la mesure des moments d’inertie après le lancement pour vérifier si les satellites dévient des attentes lorsqu’ils entrent en orbite.

Les multiples préuves

Tout comme Ethereum s’appuie sur plusieurs implémentations de clients pour réduire les risques de bugs affectant l’ensemble du réseau, multiprovers utilise différentes solutions d’implémentation TEE pour renforcer la sécurité et la résilience. En exécutant les mêmes étapes de calcul sur plusieurs plateformes TEE, la validation multiple garantit qu’une faille dans une implémentation TEE ne compromettra pas l’ensemble de l’application. Bien que cette méthode exige que le processus de calcul soit déterministe, ou qu’un consensus soit défini entre les différentes solutions d’implémentation TEE dans des situations de non-déterminisme, elle offre également des avantages significatifs tels que l’isolation des défaillances, la redondance et la vérification croisée, ce qui en fait un bon choix pour les applications nécessitant une garantie de fiabilité.

Regarder vers l’avenir

TEE has clearly become an exciting field. As mentioned earlier, the ubiquity of AI and its continuous access to user-sensitive data means that large technology companies such as Apple and NVIDIA are using TEE in their products and offering it as part of their offerings.

D’un autre côté, la communauté cryptographique attache une grande importance à la sécurité. Alors que les développeurs cherchent à étendre les applications et les cas d’utilisation sur la chaîne, nous avons vu l’Environnement d’Exécution Fiable (TEE) gagner en popularité en tant que solution offrant un compromis adéquat entre fonctionnalités et hypothèses de confiance. Bien que le TEE ne soit pas aussi minimaliste que la solution ZK complète en termes de confiance minimale, nous nous attendons à ce qu’il devienne progressivement la voie choisie par les entreprises Web3 et les grandes entreprises technologiques pour intégrer leurs produits.