Guide du développeur pour TEE

Qu’est-ce que TEE ? Le modèle de sécurité TEE ? Les vulnérabilités courantes de TEE et leur guide de bonnes pratiques de sécurité.

Titre original: “Securing TEE Apps: Guide du développeur”

Écrit par : prateek, roshan, siddhartha & linguine (Marlin), krane (Asula)

Compilation: Shew, GodRealmX de la grotte céleste

Depuis qu’Apple a annoncé le lancement de son cloud privé et que NVIDIA propose des calculs confidentiels dans ses GPU, l’environnement d’exécution de confiance (TEE) est devenu de plus en plus populaire. Leur garantie de confidentialité contribue à la protection des données des utilisateurs (y compris les clés privées), tandis que leur isolation garantit que l’exécution des programmes déployés dessus ne peut pas être 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 dans le domaine de la Crypto x IA soient construits en utilisant des TEE.

Comme toute nouvelle technologie, le TEE traverse une période d’expérimentation optimiste. Ce document vise à fournir aux développeurs et aux lecteurs en général un guide conceptuel de base pour comprendre ce qu’est le TEE, son modèle de sécurité, les vulnérabilités courantes et les meilleures pratiques de sécurité pour utiliser le TEE. (Remarque : afin de faciliter la compréhension du texte, nous avons délibérément remplacé les termes TEE par des équivalents plus simples).

Qu’est-ce que TEE

TEE is an isolated environment for processors or data centers, where programs can run without any interference from the rest of the system. In order to prevent TEE from being interfered with by other parts, we need a series of designs, mainly including strict access control, that is, controlling the access of other parts of the system to the programs and data within TEE. Currently, TEE is ubiquitous in mobile phones, servers, PCs, and cloud environments, making it very accessible and reasonably priced.

Le contenu ci-dessus peut sembler flou et abstrait, en fait, les différentes façons dont les serveurs et les fournisseurs de cloud mettent en œuvre TEE sont différentes, mais leur objectif fondamental est d’éviter que TEE ne soit perturbé par d’autres programmes.

La plupart des lecteurs utilisent probablement des informations biométriques pour se connecter à leurs appareils, comme déverrouiller leur téléphone avec leurs empreintes digitales. Mais comment pouvons-nous nous assurer que les applications malveillantes, les sites web ou les systèmes d’exploitation jailbreakés ne peuvent pas accéder à ces informations biométriques et les voler ? En réalité, en plus de crypter les données, les circuits dans les appareils TEE ne permettent tout simplement à aucun programme d’accéder à la zone de mémoire et de processeur occupée par les données sensibles.

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

Modèle de sécurité

Malheureusement, il existe de nombreux types d’implémentations 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 plus largement utilisés et disposent d’outils de développement complets. Ces systèmes susmentionnés sont également les systèmes TEE 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, le développeur empaquète le code dans un fichier d’image Enclave (EIF) qui peut être exécuté dans le TEE.
3. EIF est hébergé sur un serveur avec un système TEE. Dans certains cas, les développeurs peuvent héberger l’EIF sur un ordinateur personnel avec TEE pour fournir des services externes.
4. Les utilisateurs peuvent interagir avec l’application via une interface prédéfinie.

Il est évident qu’il y a 3 risques potentiels ici :

• **Développeurs : **Quel est le rôle du code de préparation EIF ? Le code EIF peut ne pas correspondre à la logique métier annoncée par le projet, il pourrait voler les données personnelles des utilisateurs.
• Serveur : Le fichier EIF du TEE est-il conforme aux attentes en termes d’exécution ? Ou bien est-ce que l’EIF est réellement exécuté à l’intérieur du TEE ? Le serveur peut également exécuter d’autres programmes à l’intérieur du TEE.
• Fournisseur: La conception de TEE de TEE est-elle sécurisée ? Y a-t-il une porte dérobée qui divulgue toutes les données internes de TEE au fournisseur ?

Heureusement, les TEE actuels disposent désormais de solutions pour éliminer les risques mentionnés, à savoir la construction reproductible (Reproducible Builds) et les attestations à distance (Remote Atteststations).

Alors, 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, des bibliothèques ou des frameworks externes, et ces fichiers de dépendance peuvent également présenter des risques. Maintenant, des solutions telles que npm utilisent le hachage de code correspondant au fichier de dépendance comme identifiant unique. Lorsque npm constate qu’un fichier de dépendance diffère de la valeur de hachage enregistrée, il peut considérer que ce fichier de dépendance a été modifié.

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

Nix est un outil courant pour les builds reproductibles. Lorsque le code source du programme est accessible au public, n’importe qui peut inspecter le code pour s’assurer que le développeur n’a rien inséré qui sorte de l’ordinaire, 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 de code que le produit déployé par l’équipe de projet en production/hachage. 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 du 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 (véritable TEE de version xx).

La possibilité de reconstruire et de prouver à distance permet à tout utilisateur de connaître le code réellement exécuté à l’intérieur de l’Enclave d’exécution sécurisée (TEE) et les informations sur la version de la plateforme TEE, empêchant ainsi les développeurs ou les serveurs de se comporter de manière malveillante.

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 directement falsifier la preuve à distance. Par conséquent, si le fournisseur est considéré comme un vecteur d’attaque potentiel, il est préférable de ne pas dépendre uniquement de TEE, mais de les combiner avec ZK ou un protocole de consensus.

Le charme de TEE

Selon nous, les caractéristiques particulièrement populaires de TEE, en particulier en ce qui concerne le déploiement convivial de l’agent d’IA, sont principalement les suivantes :

• Performance: TEE can run the LLM model with similar performance and cost as regular servers. zkML, on the other hand, requires a significant amount of computational power to generate zk proofs for the LLM.
• Prise en charge du GPU : NVIDIA propose une prise en charge du calcul TEE dans sa dernière série de GPU (Hopper, Blackwell, etc.)
• Exactitude: Les LLMs sont non déterministes; entrer le même mot-clé plusieurs fois donnera des résultats différents. Par conséquent, plusieurs nœuds (y compris les observateurs essayant 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 fait que les LLM fonctionnant dans un TEE ne peuvent pas être manipulés par des acteurs malveillants, le programme à l’intérieur du TEE fonctionnant toujours comme prévu, ce qui rend le TEE plus adapté à garantir la fiabilité des résultats de raisonnement des LLM que opML ou un consensus
• Confidentialité : Les données dans TEE ne sont pas visibles pour les programmes externes. Par conséquent, les clés privées générées ou reçues dans TEE sont toujours sécurisées. Cette fonctionnalité peut garantir aux utilisateurs que tout message signé avec cette clé provient d’un programme interne à 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 provient de TEE et répond aux conditions de signature préalablement définies
• Connectivité : Les programmes exécutés dans TEE peuvent accéder en toute sécurité à Internet grâce à certains outils (sans révéler les requêtes ou les réponses aux serveurs exécutés dans 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 les calculs vers des fournisseurs de modèles de confiance mais propriétaires.
• Droits d’écriture : Contrairement au schéma zk, le code exécuté dans un environnement TEE peut construire des messages (qu’il s’agisse de tweets ou de transactions) et les envoyer via des API et des RPC.
• Convivial pour les développeurs : les cadres et SDK associés à TEE permettent aux gens d’écrire du code dans n’importe quel langage et de déployer facilement des programmes dans TEE, tout comme dans un serveur cloud

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

TEE n’est pas une balle d’argent

Les programmes exécutés dans TEE sont toujours vulnérables à une série d’attaques et d’erreurs. Tout comme les contrats intelligents, ils sont sujets à divers problèmes. Pour simplifier, nous classons les vulnérabilités potentielles comme suit :

• Négligence du développeur
• Vulnérabilité d’exécution
• Défauts de conception de l’architecture
• Problèmes d’exploitation

Négligence des développeurs

Que ce soit intentionnel ou non, les développeurs peuvent affaiblir la sécurité des programmes dans TEE en utilisant du code intentionnel ou non. 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ème de mesure du code : Même si le code est public, s’il n’est pas reconstruit par un tiers pour vérifier les valeurs de mesure du code dans la preuve à distance, puis vérifié en fonction de la mesure du code fournie dans la preuve à distance, c’est similaire à recevoir une preuve zk mais ne pas la vérifier. Code non sécurisé : même si vous prenez soin de générer et de gérer correctement les clés dans le TEE, la logique contenue dans le code peut faire fuiter les clés dans le TEE lors d’un appel externe. De plus, le code peut contenir des portes dérobées ou des vulnérabilités. Par rapport au développement back-end traditionnel, il nécessite un niveau élevé de développement logiciel et de processus d’audit, similaire 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 importante pour l’intégrité de TEE.

Vulnérabilité d’exécution

Quelle que soit la prudence d’un développeur, il peut être la proie d’une vulnérabilité d’exécution. Les développeurs doivent examiner attentivement si l’un des éléments suivants affectera les garanties de sécurité de leur projet :

Code dynamique : il n’est pas toujours possible de garder tout le code transparent. Parfois, le cas d’utilisation lui-même nécessite l’exécution dynamique d’un code opaque chargé dans le TEE au moment de l’exécution. Un tel code peut facilement divulguer des secrets ou casser des invariants, et cela doit être évité avec beaucoup de précautions.

• 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 causer des catastrophes. Par exemple, dans le cas d’utilisation de l’agent IA, une dépendance excessive aux services LLM, tels que Claude.
• Communication insecure et instable : Le TEE doit fonctionner à l’intérieur d’un serveur contenant les composants TEE. Du point de vue de la sécurité, le serveur exécutant le TEE est en réalité un intermédiaire parfait entre le TEE et les interactions externes (MitM). Le serveur peut non seulement surveiller les connexions externes du TEE et afficher le contenu en cours d’envoi, mais il peut également examiner des adresses IP spécifiques, limiter les connexions et injecter des paquets de données dans les connexions, dans le but de tromper une partie en la faisant croire qu’elle provient de xx.
• Par exemple, dans TEE, un moteur de correspondance capable de traiter des transactions chiffrées ne peut pas garantir un classement équitable (résistance au MEV), car le routeur / passerelle / hôte peut toujours les abandonner, les retarder ou les traiter en priorité en fonction de l’adresse IP source des paquets de données.

Défauts d’architecture

Il convient de faire preuve de prudence avec la pile technologique utilisée par les applications TEE. Lors de la création d’une 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 is often in conflict 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. Tout le monde peut lancer un TEE et prendre le contrôle des participants inactifs du système, rendant les applications à l’intérieur du TEE portables. **Le plus grand défi ici est la portabilité des clés. Certains systèmes TEE ont des mécanismes de dérivation de clés, mais une fois que vous utilisez le mécanisme de dérivation de clés à l’intérieur du TEE, les autres serveurs ne peuvent pas générer de clés à l’intérieur du programme TEE externe, **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 d’IA dans un environnement 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 peut être un tiers externe ou une plateforme de gestion des clés, et non le TEE lui-même.

Problème opérationnel

Enfin, mais pas le moins important, il y a quelques points pratiques à considérer en ce qui concerne la façon de faire fonctionner un serveur exécutant un programme TEE.

• Version de la plateforme non sécurisée : La plateforme TEE reçoit occasionnellement des mises à jour de sécurité, qui se reflètent dans la version de la plateforme dans la preuve distante. Si votre TEE ne fonctionne pas sur une version sécurisée de la plateforme, les pirates informatiques pourraient voler les clés de votre TEE en exploitant les 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 être non sécurisé demain.
• Pas de sécurité physique : Même si vous faites de votre mieux, 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 sur lequel 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 offre une garantie de sécurité physique.

Construire un programme TEE sécurisé

Nous divisons nos recommandations en plusieurs points :

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

1. La solution la plus sûre : aucune dépendance externe

Créer des applications extrêmement sécurisées peut impliquer l’élimination des dépendances externes telles que les entrées externes, les API ou les services, réduisant ainsi la surface d’attaque. Cette méthode garantit que l’application fonctionne de manière autonome, sans interaction externe susceptible de compromettre son intégrité ou sa sécurité. Bien que cette approche puisse limiter la diversité des fonctionnalités du programme, elle peut offrir un niveau de sécurité très élevé.

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

2. Les mesures préventives nécessaires prises

Que l’application ait ou non des dépendances externes, le contenu suivant est obligatoire!

Considérez l’application TEE comme un smart contrat, pas comme 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, les tests et la mise à jour des contrats intelligents. Comme les contrats intelligents, le TEE fonctionne dans un environnement hautement sensible et immuable, où les erreurs ou les comportements imprévus peuvent entraîner des conséquences graves, y compris la perte totale de fonds. Un audit complet, 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.

Audit the code and check the build pipeline

La sécurité d’une application dépend non seulement du code lui-même, mais également des outils utilisés lors du processus de construction. Un pipeline de construction sécurisé est essentiel pour prévenir les vulnérabilités. TEE garantit uniquement que le code fourni s’exécutera conformément au processus 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 tester et d’auditer rigoureusement le code pour éliminer les erreurs et prévenir les fuites d’informations inutiles. De plus, la reproductibilité de la construction joue un rôle crucial, en particulier lorsque le code est développé par une partie et utilisé par une autre. La reproductibilité de la construction permet à quiconque de vérifier si le programme exécuté à l’intérieur de TEE correspond au code source d’origine, garantissant ainsi la transparence et la confiance. Sans reproductibilité de la construction, il est presque impossible de déterminer exactement ce que contient le programme exécuté à l’intérieur de TEE, ce qui compromet 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 auditées ou vérifiées

Lorsque vous manipulez des données sensibles dans un programme TEE, n’utilisez 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 peuvent exposer des clés et compromettre la sécurité de l’application. Privilégiez les dépendances bien contrôlées et axées sur la sécurité afin de préserver la confidentialité et l’intégrité de vos données.

Vérifiez toujours la preuve provenant de TEE

Les utilisateurs qui interagissent avec TEE doivent vérifier la preuve ou le mécanisme de vérification à distance généré par TEE pour assurer une interaction sécurisée et fiable. Sans ces vérifications, il est possible que le serveur manipule la réponse, ce qui rend impossible de distinguer les sorties TEE réelles des données altérées. La preuve à distance fournit une preuve clé pour les bibliothèques de code et les configurations en cours d’exécution dans TEE, nous permettant de déterminer si les programmes exécutés à l’intérieur de TEE sont conformes aux attentes.

Les certificats spécifiques peuvent être vérifiés sur la chaîne (IntelSGX, AWSNitro) avec une vérification hors chaîne utilisant des preuves ZK (IntelSGX, AWSNitro), ou peuvent être vérifiés par l’utilisateur lui-même ou par des services d’hébergement (tels que t16z ou MarlinHub).

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

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

Assurez-vous d’exécuter toujours l’interaction entre l’utilisateur et TEE via un canal sécurisé

Le serveur sur lequel réside le TEE n’est pas approuvé par nature. Le serveur peut intercepter et modifier la communication. Dans certains cas, il peut être acceptable pour le serveur de lire les données sans les modifier, tandis que dans d’autres, il peut ne pas être conseillé de lire les données même si cela n’est pas souhaitable. Pour atténuer ces risques, il est essentiel de disposer d’un canal chiffré sécurisé de bout en bout entre l’utilisateur et le TEE. À tout le moins, assurez-vous que le message contient une signature pour vérifier son authenticité et son origine. De plus, les utilisateurs doivent toujours vérifier que le TEE donne une attestation à distance pour vérifier qu’ils communiquent avec le bon TEE. Cela garantit l’intégrité et la confidentialité de la communication. **

Par exemple, Oyster peut prendre en charge la délivrance 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.

Sachez que la mémoire TEE est transitoire

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 devenir définitivement inaccessibles, ce qui peut entraîner des difficultés financières ou opérationnelles.

Un réseau de calcul multipartite (MPC) avec un système de stockage décentralisé tel que IPFS peut être utilisé 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é lorsque nécessaire. Les données chiffré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 confie les transactions correspondantes à différents serveurs MPC, signe les serveurs MPC pour agréger et signer les transactions, puis les envoie finalement à la chaîne. 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 de sacrifier l’expérience des développeurs pour essayer de réduire autant que possible les dépendances périphériques. Par exemple, Dstack est livré avec un noyau minimal basé sur Yocto, contenant uniquement les modules nécessaires au fonctionnement de Dstack. Il peut même être utile d’utiliser des technologies obsolètes telles que SGX (au-dessus de TDX), car ces technologies ne nécessitent pas le chargement d’un chargeur d’amorçage ou d’un système d’exploitation en tant que partie intégrante de l’Environnement d’exécution sécurisé (TEE).

Isolation physique

En isolant physiquement TEE des interventions humaines possibles, on peut renforcer davantage la sécurité de TEE. Bien que l’on puisse garantir la sécurité physique en hébergeant les serveurs TEE dans des centres de données et chez des fournisseurs de cloud, des projets tels que Spacecoin explorent une alternative plutôt intéressante : l’espace. Le document SpaceTEE s’appuie sur des mesures de sécurité telles que la mesure de l’inertie après le lancement pour vérifier si les satellites dévient du trajet prévu lors de leur entrée en orbite.

Multiprovider

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 de 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 vulnérabilité dans une seule implémentation de TEE ne mette pas en péril 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 de TEE dans des situations non déterministes, elle offre également des avantages significatifs tels que l’isolation des défaillances, la redondance et la validation croisée, ce qui en fait un choix judicieux pour les applications nécessitant une garantie de fiabilité.

Regard vers l’avenir

TEE est clairement devenu un domaine très excitant. Comme mentionné précédemment, la présence omniprésente de l’IA et son accès continu aux données sensibles des utilisateurs signifient que des grandes entreprises technologiques telles qu’Apple et NVIDIA intègrent désormais le TEE dans leurs produits et le proposent en tant que partie intégrante de ces derniers.

D’autre part, la communauté crypto a toujours été très soucieuse de la sécurité. Alors que les développeurs tentent de faire évoluer les applications et les cas d’utilisation on-chain, nous avons vu les TEE devenir populaires en tant que solution offrant le bon compromis entre les fonctionnalités et les hypothèses de confiance. Bien que les TEE ne soient pas aussi peu fiables qu’une solution ZK complète, nous prévoyons qu’ils seront la première voie à faire converger lentement les offres des entreprises Web3 et des grandes entreprises technologiques.