Chaque jour, les gens génèrent jusqu'à 402 millions de To de données sensibles. Avec les individus devenant de moins en moins enclins à partager largement leurs données, la demande pour des calculs privés sur ces données augmente de jour en jour. Ces solutions reposent principalement sur l'infrastructure d'Amazon Web Services (AWS), qui détient environ 30 % du marché mondial du cloud computing.
Cependant, AWS présente plusieurs inconvénients, principalement dus à son architecture centralisée. Même avec l'introduction de calculs sécurisés améliorés via AWS Nitro Enclaves, il reste confronté à des défis majeurs en matière d'adoption par les développeurs, ce qui constitue un obstacle profond à la sécurité blockchain et aux applications Web3.
Cet article disséque l’état actuel d’AWS et présente une solution cloud TEE décentralisée qui résout non seulement les lacunes d’AWS, mais surmonte également les limites des autres TEE existants. Mais avant de pouvoir le faire, nous devons explorer pourquoi AWS et ses produits Nitro Enclaves ont atteint une telle visibilité et une telle part de marché, et ce qui se cache derrière ces avancées.
AWS Nitro et TEE
AWS est actuellement la plate-forme de cloud computing la plus populaire, offrant un riche ensemble d’outils. En bref, AWS est essentiellement une infrastructure cloud pour tous les besoins informatiques d’un développeur, y compris les services de calcul, de stockage et de base de données. Comme nous le savons tous, AWS représente environ 30 % de la part de marché de l’infrastructure cloud, ce qui représente un pourcentage assez important. Près de 48 % des ingénieurs logiciels ou des développeurs utilisent AWS d’une manière ou d’une autre, il est donc très demandé.
Avec l'élargissement de la demande et de la clientèle, y compris les grandes institutions financières, les agences gouvernementales et les start-ups qui détiennent des données hautement sensibles, des questions ont été soulevées concernant la sécurité d'AWS et la capacité de ces entités à stocker et à utiliser ces données en toute sécurité grâce à l'informatique confidentielle.
C'est dans ce contexte qu'AWS a eu l'idée d'implémenter TEE sur sa plateforme pour protéger les données en cours d'utilisation, en complément du chiffrement des données au repos et des données en transit.
Cette nouvelle solution intégrée TEE est appelée AWS Nitro Enclaves, elle offre un environnement d'exécution isolé pris en charge par le matériel. Le TEE établit un environnement sécurisé au sein des instances Amazon EC2, éliminant l'accès interactif, le stockage persistant et la connexion réseau externe. Cette isolation réduit au minimum la surface d'attaque en séparant les charges de travail sensibles des instances EC2 parent, de leurs opérateurs et d'autres logiciels.
Cependant, Nitro Enclaves est entièrement créé et géré au sein des services EC2 d'AWS, appartenant à un cadre hautement centralisé. De la création à la résiliation, tous les aspects gérés par l'Enclave sont contrôlés par l'infrastructure d'AWS, étant donné la nature d'AWS en tant que fournisseur de cloud centralisé, cela est essentiellement centralisé.
En résumé, AWS Nitro Enclaves offre une isolation robuste grâce à un environnement d'exécution fiable basé sur du matériel pour protéger les charges de travail sensibles. Cependant, son architecture centralisée introduit certaines limitations et compromis.
Limitations en dehors de la centralisation AWS
En plus des inconvénients de la centralisation où tous les composants et les données dépendent d'un seul système, AWS Nitro Enclaves présentent également davantage de défis et de nouvelles considérations en matière de sécurité. AWS connecte plusieurs cartes Nitro (matériel personnalisé) au CPU pour exécuter des charges de travail TEE, ce qui engendre un double risque de sécurité : le CPU sous-jacent et les cartes Nitro peuvent tous deux présenter des vulnérabilités.
Un problème majeur des Nitro Enclaves est le manque d'un mécanisme de chiffrement de la mémoire bien établi. Contrairement aux solutions intégrées directement dans le CPU, la nature externe de la carte Nitro rend difficile l'assurance d'un chiffrement de bout en bout des données en mémoire. Cette configuration pourrait exposer des informations sensibles à la manipulation lors de l'accès à la mémoire, car le chiffrement dépend de l'interaction entre le CPU et les dispositifs externes.
En outre, les développeurs doivent toujours utiliser Docker pour créer et configurer des Amazon Machine Images (AMI) qui incluent le logiciel Enclave, ce qui peut être difficile pour les personnes qui ne sont pas familiarisées avec la conteneurisation. Ils doivent également utiliser l’interface de ligne de commande AWS et l’interface de ligne de commande Nitro Enclaves pour lancer des instances et gérer des enclaves, naviguer dans l’API Nitro Enclaves et s’intégrer aux services de gestion de clés AWS, ce qui nécessite parfois une compréhension du processus d’attestation cryptographique.
La dépendance de TEE à la carte Nitro a conduit à des preuves non vérifiables, car la mesure de l'intégrité du code provient de la carte Nitro et non du CPU lui-même.
AWS fait confiance aux développeurs et aux administrateurs pour configurer les politiques de gestion des identités et des accès, ce qui peut leur permettre d'accéder à des données sensibles. Leur accès privilégié crée un risque de menace interne, car ils peuvent consulter ou altérer des données.
Examen de l'hypothèse de confiance d'AWS Nitro
Cependant, la plus grande limitation réside dans le fait qu'AWS n'est pas optimisé pour les applications et les écosystèmes décentralisés, et qu'il manque de soutien natif pour les cas d'utilisation Web3 ou les systèmes de gouvernance.
Par exemple, AWS Nitro Enclaves manque de stockage persistant. Bien que cette isolation soit bénéfique pour la sécurité, elle limite des cas d'utilisation tels que les agents IA qui nécessitent de stocker des données utilisateur dans une base de données vectorielle.
La gestion des clés ne s’inscrit pas non plus dans le scénario « Zero Trust ». Bien qu’AWS Key Management Service (KMS) soit disponible, il est conçu pour le Web2 et permet aux administrateurs d’accéder aux clés privées. Cela entre en conflit avec l’exigence du Web3 selon laquelle les clés doivent être entièrement contrôlées par le code et ne doivent être exposées à personne, y compris aux administrateurs.
Nitro Enclaves a résolu le problème de méfiance des développeurs envers le cloud, mais Web3 exige la mise en place de solutions sans confiance entre les utilisateurs, les développeurs et les fournisseurs. L'absence de mise à jour sécurisée du code nécessite une propriété décentralisée similaire à la gouvernance des contrats intelligents, et les développeurs doivent tout construire à partir de zéro, ce qui peut prendre des mois, et si cela est mal mis en œuvre, le code peut présenter des vulnérabilités.
En raison du manque d'accès au réseau, la configuration des services Web est longue et laborieuse, obligeant les développeurs à écrire une quantité importante de code pour adapter les applications et garantir la sécurité cryptographique, ce qui n'est souvent pas parfait.
Pourquoi Web3 a-t-il besoin de TEE ?
Nous utilisons TEE parce que nous ne pouvons pas faire entièrement confiance aux développeurs ou aux administrateurs. Les participants du Web3 ont des philosophies différentes et recherchent des systèmes sans confiance : si quelque chose doit être fiable, il n’a pas l’air très fiable. C’est pourquoi les utilisateurs s’appuient sur les opérateurs de matériel pour inspecter et gérer les applications. Les applications peuvent être détachées pour éviter qu’elles n’interfèrent, ne grattent ou ne modifient des données sensibles lors de l’accès à la mémoire, car le chiffrement repose sur une collaboration fluide entre le processeur et les périphériques externes. Les utilisateurs et les fournisseurs de données doivent disposer de garanties claires et d’une vérification des actions effectuées sur leurs données.
Lors du développement de Phala Network, nous avons été conçus pour combiner les avantages d’AWS avec la sécurité de TEE afin d’éliminer la complexité grâce à la décentralisation tout en améliorant la sécurité. Cette approche est conçue pour répondre aux besoins des cas d’utilisation du Web3. Par conséquent, nous avons mis au point le concept d’un cloud TEE décentralisé qui assure la sécurité et l’intégration des applications décentralisées.
Créer un cloud TEE décentralisé
Pour comprendre le concept de cloud TEE décentralisé, il faut d'abord définir ce qu'est un cloud décentralisé. Alors, qu'est-ce que c'est ?
Le cloud décentralisé est une infrastructure de calcul où le stockage, le traitement et la gestion des données sont répartis sur un réseau de plusieurs nœuds, au lieu d'être centralisés dans un seul serveur central ou un centre de données. Contrairement aux systèmes cloud centralisés traditionnels comme AWS, le cloud décentralisé ne nécessite pas d'entité de contrôle unique, mais repose sur la blockchain pour fonctionner.
Cloud TEE décentralisé
Le cloud TEE décentralisé est une infrastructure de calcul qui combine TEE avec un réseau de nœuds décentralisés pour fournir un calcul sécurisé, privé et vérifiable. Chaque nœud est équipé de TEE pour protéger le code et les données sensibles contre l'accès ou la falsification par les opérateurs de nœuds.
Phala Network est composé d'un réseau de nœuds de travail décentralisés, chaque nœud étant équipé d'un TEE. Ces nœuds exécutent des tâches de calcul pour les utilisateurs en fonction des besoins des clients, telles que l'exécution de contrats intelligents ou le traitement de données sensibles.
Le processus commence lorsque l'utilisateur déploie son application ou sa tâche sur le réseau. Les tâches de calcul s'exécutent dans le TEE de ces nœuds, garantissant que le code et les données restent confidentiels, même les opérateurs de nœuds ne peuvent pas les voir ou les altérer.
Phala utilise des preuves cryptographiques pour vérifier si les calculs effectués dans le TEE ont été correctement exécutés. Les opérateurs de nœuds sont récompensés pour avoir fourni des services honnêtes et sécurisés, maintenant ainsi l'intégrité du réseau grâce à des incitations économiques. Bien que cela semble simple, la mise en œuvre de cette solution est bien plus complexe qu'elle n'y paraît.
Pourquoi est-il si difficile de créer un cloud TEE décentralisé ?
TEE n'est pas en soi centralisé ou décentralisé, son degré de centralisation dépend de la manière dont il est mis en œuvre et déployé dans le système. TEE est une zone d'isolation sécurisée au sein du processeur, conçue pour protéger le code et les données sensibles contre l'accès non autorisé par le système d'exploitation ou d'autres processus sur le même appareil. TEE fonctionne en mode centralisé ou décentralisé, selon l'architecture du système plus large dans lequel il se trouve.
Historiquement, la création d’un système centralisé a été plus simple que la création d’un système décentralisé, qui a été confronté à des défis en termes de mise en œuvre et de communication des nœuds. Avant Phala Cloud, nous avions créé avec succès le Phala Network 1.0 (SGX) entièrement décentralisé. Phala Cloud est maintenant développé avec la même philosophie, bien que cela prenne du temps. Phala est actuellement la seule plateforme qui combine TEE avec une décentralisation complète, contrairement aux fournisseurs centralisés ou aux protocoles partiellement décentralisés.
Les avantages de la décentralisation et de la TEE sont évidents, mais ils ne sont toujours pas suffisants dans le développement de produits. Imaginez qu’Alibaba soit la plus grande plateforme de commerce électronique au monde avec une énorme part de marché. Si un nouveau produit est lancé avec deux fois plus de puissance et un prix inférieur, va-t-il conquérir l’ensemble du marché ? Malheureusement, non, car les gens sont habitués aux produits existants et il y a un biais contre les nouveaux produits, même s’ils sont meilleurs.
C'est l'un des défis auxquels nous sommes confrontés, mais nous ne cherchons pas à doubler nos améliorations, mais plutôt à nous assurer que Phala est dix fois meilleur que la concurrence et facile à utiliser. De plus, comme mentionné précédemment, AWS n'est pas adapté à l'environnement Web3, et nous visons à combler cette lacune pour les applications et les développeurs Web3. Au-delà de cet avantage évident de la décentralisation, nous souhaitons également souligner d'autres différences entre Phala et AWS.
Phala Cloud et AWS
Tout d'abord, la configuration des Nitro Enclaves d'AWS est complexe. Cela implique plusieurs étapes, y compris l'installation de Nitro CLI, la conversion des images Docker en fichiers Enclave et le traitement du transfert de fichiers, ce qui est très chronophage.
En comparaison, Phala permet aux développeurs de déployer et de modifier "instantanément" avec facilité, en migrant les conteneurs Docker existants vers un TEE sécurisé. Avec le SDK Dstack, les développeurs n'ont besoin que de modifications minimes pour convertir les conteneurs Docker en machines virtuelles confidentielles (Confidential VM), et de les déployer via une interface utilisateur Cloud conviviale, tout en prenant en charge les modèles et les fichiers Docker Compose personnalisés.
En matière de sécurité, AWS s’appuie sur la confiance des développeurs et des administrateurs pour configurer correctement les contrôles d’accès et gérer les ressources. Bien qu’AWS utilise TEE pour l’informatique isolée, son infrastructure centralisée nécessite des personnes qui font confiance à AWS et gèrent le système, ce qui peut entraîner l’accès à des données sensibles. Phala utilise un modèle Zero Trust et ne fait confiance à aucune partie par défaut. Les données sensibles restent sécurisées au sein du TEE et sont inaccessibles même aux opérateurs de nœuds, ce qui les rend adaptées aux applications Web3 qui nécessitent des opérations sans confiance.
Du point de vue du produit, AWS sert principalement les entreprises clientes en raison du grand nombre d’entreprises dans l’espace informatique traditionnel. Par conséquent, il ne s’aligne pas totalement sur la proposition de valeur des startups Web3 en termes de produits et de technologie. En revanche, Phala est spécialement conçu pour les applications décentralisées. Il prend en charge nativement les proxys d’IA qui interagissent avec les contrats intelligents blockchain, ainsi que les DApps préservant la confidentialité.
De plus, Phala s'est profondément intégré dans l'écosystème blockchain grâce à des partenariats avec divers protocoles et à l'intégration d'applications décentralisées (DApp) qui souhaitent tirer parti de la sécurité des TEE.
Phala se positionne comme la couche d’exécution de l’IA Web3, permettant aux développeurs de créer, de lancer et de monétiser des agents d’IA capables de comprendre et d’interagir avec les contrats intelligents blockchain en toute sécurité et en toute confidentialité. Nous prenons en charge les plateformes d’IA décentralisées telles que NEAR AI et Sentient en exploitant NVIDIA GPU TEE pour exécuter de grands modèles de langage (LLM) dans un environnement sécurisé, vérifiable et axé sur la confidentialité. Par exemple, notre partenariat avec NOTAI met en évidence l’application de la confiance zéro des agents d’IA, où nous fournissons une protection sans confiance et de la vie privée via TEE et RA Explorer.
Nous soutenons également l'intégration d'applications non liées à l'IA via les Phat Contracts, qui sont des contrats intelligents à faible coût et à faible latence avec un support natif pour les requêtes HTTP.
Cependant, étant donné que de nombreuses équipes de crypto-natifs construisent également des TEE et d'autres méthodes de calcul sécurisé, comment Phala se distingue-t-elle de ces solutions ?
Phala Cloud et la solution TEE
Phala Network se distingue en tant que seule solution cloud TEE entièrement décentralisée, offrant des calculs sécurisés, privés et vérifiables pour les DApps. Contrairement à Oasis Protocol et Secret Network, qui se concentrent sur l'utilisation de TEE pour des contrats intelligents habilités à la confidentialité dans leurs blockchains respectives, Phala propose une plateforme de cloud computing décentralisée pour des calculs hors ligne à travers les réseaux.
Phala est flexible et personnalisable, utilisant une large gamme de matériel TEE, y compris Intel SGX, Intel TDX, AMD SEV et NVIDIA GPU TEE. Le protocole Marlin améliore les performances réseau de Web3, mais ne fournit pas de fonctionnalités de calcul ou de confidentialité, tandis qu'Oasis et Secret fonctionnent dans des écosystèmes blockchain spécifiques. En tant que seule cloud TEE décentralisée avec un large support matériel et des outils pour développeurs comme Dstack, Phala possède des avantages uniques.
Phala se distingue par le fait qu’il offre un cloud TEE décentralisé à usage général, contrairement à Oasis Protocol, Marlin et Secret Network, qui se concentrent sur des cas d’utilisation spécifiques. Phala permet aux développeurs de déployer n’importe quelle application, telle qu’un modèle d’IA, un serveur Web ou une base de données, dans un environnement sécurisé. Cela est rendu possible grâce à Phat Contracts et Phala Cloud, qui prend en charge les déploiements Dockerized et fournit un accès en un clic au CPU et au GPU TEE.
De plus, il existe de nombreuses comparaisons sur lequel est le plus adapté pour des cas d'utilisation spécifiques entre TEE ou le calcul multipartite (MPC). À notre avis, TEE et MPC ne sont pas des concurrents, mais des partenaires complémentaires.
Phala intègre TEE à MPC pour créer un modèle décentralisé Root of Trust (DeRoT), une approche avancée pour sécuriser les applications basées sur TEE. MPC fonctionne au sein du TEE pour réduire le risque de collusion de nœuds, tandis que les preuves de bloc TEE sont soumises avec les preuves MPC pour atténuer les erreurs dans les implémentations de preuves à divulgation nulle de connaissance (ZKP). Ce système d’attestation multiple est encore renforcé par l’obligation pour les nœuds MPC de fonctionner dans le TEE. Le modèle DeRoT utilise TEE, MPC et ZKP pour distribuer la confiance dans le réseau. Cette approche améliore la sécurité des DApps à l’aide de TEE en traitant les menaces potentielles au niveau du matériel ou des nœuds.
La possibilité du cloud TEE décentralisé
Nous rédigerons un article spécifiquement pour explorer ce sujet, car de nombreuses applications fonctionnent déjà sur Phala. Par conséquent, cette partie pourrait être aussi longue que l'ensemble de l'article. Mais nous espérons donner un aperçu des cas d'utilisation potentiels du cloud TEE décentralisé.
Tout d'abord, Phala prend en charge le déploiement de modèles d'IA dans des TEE, garantissant des interactions sécurisées et des opérations autonomes avec le réseau blockchain. Cela inclut des agents d'IA pour améliorer les contrats intelligents et les interactions entre agents. Les développeurs peuvent tirer parti des GPU TEE pour effectuer des calculs d'IA, réalisant ainsi une véritable résistance à la censure et une protection de la vie privée.
Les développeurs peuvent également migrer des applications traditionnelles vers un environnement sécurisé et sans confiance pour améliorer la sécurité. La plateforme permet une analyse de données respectueuse de la vie privée grâce à des outils d'analyse Web3 et traditionnels, qui peuvent analyser des données sans exposer les informations d'un utilisateur unique. De plus, elle peut renforcer la sécurité des calculs DeFi grâce à des fonctionnalités de confidentialité, telles que les positions de trading confidentielles ou le trading en dark pool. Enfin, le cloud TEE décentralisé peut réaliser une protection MEV en transférant la construction de blocs dans le TEE, pour garantir un tri et une exécution équitables.
De nombreux produits intègrent Phala comme partie de leur infrastructure. Nous examinerons dans un autre article comment ces produits utilisent Phala et ce qu'ils tirent de cette intégration.
Conclusion
Les modèles de confiance de Web3 et Web2 présentent des différences fondamentales, ce qui entraîne des limitations pour des plateformes comme AWS. Dans Web3, les données (y compris les tokens qui appartiennent essentiellement aux données) sont véritablement possédées par les utilisateurs, tandis que les développeurs d'applications sont par défaut considérés comme non fiables. Cette méfiance provient du fait que les développeurs peuvent tenter d'accéder à des données utilisateur sans autorisation, de les modifier ou de les voler.
Ce paradigme explique plusieurs pratiques clés dans Web3 :
Le code des contrats intelligents doit être soumis à un examen rigoureux pour éliminer les portes dérobées ou les vulnérabilités.
La propriété (ou le contrôle de gestion) des contrats intelligents est une question clé, les utilisateurs attachant plus d'importance à la transparence qu'à la possibilité pour les développeurs d'avoir un contrôle illimité.
Idéalement, dans un environnement Web3, les développeurs devraient écrire et déployer du code de contrat intelligent, puis abandonner tout contrôle, ne conservant aucun privilège sur l'application.
Contrairement aux contrats intelligents, les TEE peuvent exécuter des principes de propriété et de contrôle similaires dans un éventail de programmes plus large. Cependant, AWS Nitro Enclaves fonctionne dans un cadre Web2, où les développeurs conservent la capacité de se connecter, d'accéder et de modifier des données et des applications. Le TEE de Phala est conçu selon les principes Web3, prenant en charge nativement les contrats intelligents pour gérer les applications basées sur TEE, en conformité avec le modèle de confiance décentralisé.
Le contenu est fourni à titre de référence uniquement, il ne s'agit pas d'une sollicitation ou d'une offre. Aucun conseil en investissement, fiscalité ou juridique n'est fourni. Consultez l'Avertissement pour plus de détails sur les risques.
AWS n'est pas adapté au Web3 : le cloud TEE décentralisé peut améliorer l'efficacité de 10 fois.
Chaque jour, les gens génèrent jusqu'à 402 millions de To de données sensibles. Avec les individus devenant de moins en moins enclins à partager largement leurs données, la demande pour des calculs privés sur ces données augmente de jour en jour. Ces solutions reposent principalement sur l'infrastructure d'Amazon Web Services (AWS), qui détient environ 30 % du marché mondial du cloud computing.
Cependant, AWS présente plusieurs inconvénients, principalement dus à son architecture centralisée. Même avec l'introduction de calculs sécurisés améliorés via AWS Nitro Enclaves, il reste confronté à des défis majeurs en matière d'adoption par les développeurs, ce qui constitue un obstacle profond à la sécurité blockchain et aux applications Web3.
Cet article disséque l’état actuel d’AWS et présente une solution cloud TEE décentralisée qui résout non seulement les lacunes d’AWS, mais surmonte également les limites des autres TEE existants. Mais avant de pouvoir le faire, nous devons explorer pourquoi AWS et ses produits Nitro Enclaves ont atteint une telle visibilité et une telle part de marché, et ce qui se cache derrière ces avancées.
AWS Nitro et TEE
AWS est actuellement la plate-forme de cloud computing la plus populaire, offrant un riche ensemble d’outils. En bref, AWS est essentiellement une infrastructure cloud pour tous les besoins informatiques d’un développeur, y compris les services de calcul, de stockage et de base de données. Comme nous le savons tous, AWS représente environ 30 % de la part de marché de l’infrastructure cloud, ce qui représente un pourcentage assez important. Près de 48 % des ingénieurs logiciels ou des développeurs utilisent AWS d’une manière ou d’une autre, il est donc très demandé.
Avec l'élargissement de la demande et de la clientèle, y compris les grandes institutions financières, les agences gouvernementales et les start-ups qui détiennent des données hautement sensibles, des questions ont été soulevées concernant la sécurité d'AWS et la capacité de ces entités à stocker et à utiliser ces données en toute sécurité grâce à l'informatique confidentielle.
C'est dans ce contexte qu'AWS a eu l'idée d'implémenter TEE sur sa plateforme pour protéger les données en cours d'utilisation, en complément du chiffrement des données au repos et des données en transit.
Cette nouvelle solution intégrée TEE est appelée AWS Nitro Enclaves, elle offre un environnement d'exécution isolé pris en charge par le matériel. Le TEE établit un environnement sécurisé au sein des instances Amazon EC2, éliminant l'accès interactif, le stockage persistant et la connexion réseau externe. Cette isolation réduit au minimum la surface d'attaque en séparant les charges de travail sensibles des instances EC2 parent, de leurs opérateurs et d'autres logiciels.
Cependant, Nitro Enclaves est entièrement créé et géré au sein des services EC2 d'AWS, appartenant à un cadre hautement centralisé. De la création à la résiliation, tous les aspects gérés par l'Enclave sont contrôlés par l'infrastructure d'AWS, étant donné la nature d'AWS en tant que fournisseur de cloud centralisé, cela est essentiellement centralisé.
En résumé, AWS Nitro Enclaves offre une isolation robuste grâce à un environnement d'exécution fiable basé sur du matériel pour protéger les charges de travail sensibles. Cependant, son architecture centralisée introduit certaines limitations et compromis.
Limitations en dehors de la centralisation AWS
En plus des inconvénients de la centralisation où tous les composants et les données dépendent d'un seul système, AWS Nitro Enclaves présentent également davantage de défis et de nouvelles considérations en matière de sécurité. AWS connecte plusieurs cartes Nitro (matériel personnalisé) au CPU pour exécuter des charges de travail TEE, ce qui engendre un double risque de sécurité : le CPU sous-jacent et les cartes Nitro peuvent tous deux présenter des vulnérabilités.
Un problème majeur des Nitro Enclaves est le manque d'un mécanisme de chiffrement de la mémoire bien établi. Contrairement aux solutions intégrées directement dans le CPU, la nature externe de la carte Nitro rend difficile l'assurance d'un chiffrement de bout en bout des données en mémoire. Cette configuration pourrait exposer des informations sensibles à la manipulation lors de l'accès à la mémoire, car le chiffrement dépend de l'interaction entre le CPU et les dispositifs externes.
En outre, les développeurs doivent toujours utiliser Docker pour créer et configurer des Amazon Machine Images (AMI) qui incluent le logiciel Enclave, ce qui peut être difficile pour les personnes qui ne sont pas familiarisées avec la conteneurisation. Ils doivent également utiliser l’interface de ligne de commande AWS et l’interface de ligne de commande Nitro Enclaves pour lancer des instances et gérer des enclaves, naviguer dans l’API Nitro Enclaves et s’intégrer aux services de gestion de clés AWS, ce qui nécessite parfois une compréhension du processus d’attestation cryptographique.
La dépendance de TEE à la carte Nitro a conduit à des preuves non vérifiables, car la mesure de l'intégrité du code provient de la carte Nitro et non du CPU lui-même.
AWS fait confiance aux développeurs et aux administrateurs pour configurer les politiques de gestion des identités et des accès, ce qui peut leur permettre d'accéder à des données sensibles. Leur accès privilégié crée un risque de menace interne, car ils peuvent consulter ou altérer des données.
Examen de l'hypothèse de confiance d'AWS Nitro
Cependant, la plus grande limitation réside dans le fait qu'AWS n'est pas optimisé pour les applications et les écosystèmes décentralisés, et qu'il manque de soutien natif pour les cas d'utilisation Web3 ou les systèmes de gouvernance.
Par exemple, AWS Nitro Enclaves manque de stockage persistant. Bien que cette isolation soit bénéfique pour la sécurité, elle limite des cas d'utilisation tels que les agents IA qui nécessitent de stocker des données utilisateur dans une base de données vectorielle.
La gestion des clés ne s’inscrit pas non plus dans le scénario « Zero Trust ». Bien qu’AWS Key Management Service (KMS) soit disponible, il est conçu pour le Web2 et permet aux administrateurs d’accéder aux clés privées. Cela entre en conflit avec l’exigence du Web3 selon laquelle les clés doivent être entièrement contrôlées par le code et ne doivent être exposées à personne, y compris aux administrateurs.
Nitro Enclaves a résolu le problème de méfiance des développeurs envers le cloud, mais Web3 exige la mise en place de solutions sans confiance entre les utilisateurs, les développeurs et les fournisseurs. L'absence de mise à jour sécurisée du code nécessite une propriété décentralisée similaire à la gouvernance des contrats intelligents, et les développeurs doivent tout construire à partir de zéro, ce qui peut prendre des mois, et si cela est mal mis en œuvre, le code peut présenter des vulnérabilités.
En raison du manque d'accès au réseau, la configuration des services Web est longue et laborieuse, obligeant les développeurs à écrire une quantité importante de code pour adapter les applications et garantir la sécurité cryptographique, ce qui n'est souvent pas parfait.
Pourquoi Web3 a-t-il besoin de TEE ?
Nous utilisons TEE parce que nous ne pouvons pas faire entièrement confiance aux développeurs ou aux administrateurs. Les participants du Web3 ont des philosophies différentes et recherchent des systèmes sans confiance : si quelque chose doit être fiable, il n’a pas l’air très fiable. C’est pourquoi les utilisateurs s’appuient sur les opérateurs de matériel pour inspecter et gérer les applications. Les applications peuvent être détachées pour éviter qu’elles n’interfèrent, ne grattent ou ne modifient des données sensibles lors de l’accès à la mémoire, car le chiffrement repose sur une collaboration fluide entre le processeur et les périphériques externes. Les utilisateurs et les fournisseurs de données doivent disposer de garanties claires et d’une vérification des actions effectuées sur leurs données.
Lors du développement de Phala Network, nous avons été conçus pour combiner les avantages d’AWS avec la sécurité de TEE afin d’éliminer la complexité grâce à la décentralisation tout en améliorant la sécurité. Cette approche est conçue pour répondre aux besoins des cas d’utilisation du Web3. Par conséquent, nous avons mis au point le concept d’un cloud TEE décentralisé qui assure la sécurité et l’intégration des applications décentralisées.
Créer un cloud TEE décentralisé
Pour comprendre le concept de cloud TEE décentralisé, il faut d'abord définir ce qu'est un cloud décentralisé. Alors, qu'est-ce que c'est ?
Le cloud décentralisé est une infrastructure de calcul où le stockage, le traitement et la gestion des données sont répartis sur un réseau de plusieurs nœuds, au lieu d'être centralisés dans un seul serveur central ou un centre de données. Contrairement aux systèmes cloud centralisés traditionnels comme AWS, le cloud décentralisé ne nécessite pas d'entité de contrôle unique, mais repose sur la blockchain pour fonctionner.
Cloud TEE décentralisé
Le cloud TEE décentralisé est une infrastructure de calcul qui combine TEE avec un réseau de nœuds décentralisés pour fournir un calcul sécurisé, privé et vérifiable. Chaque nœud est équipé de TEE pour protéger le code et les données sensibles contre l'accès ou la falsification par les opérateurs de nœuds.
Phala Network est composé d'un réseau de nœuds de travail décentralisés, chaque nœud étant équipé d'un TEE. Ces nœuds exécutent des tâches de calcul pour les utilisateurs en fonction des besoins des clients, telles que l'exécution de contrats intelligents ou le traitement de données sensibles.
Le processus commence lorsque l'utilisateur déploie son application ou sa tâche sur le réseau. Les tâches de calcul s'exécutent dans le TEE de ces nœuds, garantissant que le code et les données restent confidentiels, même les opérateurs de nœuds ne peuvent pas les voir ou les altérer.
Phala utilise des preuves cryptographiques pour vérifier si les calculs effectués dans le TEE ont été correctement exécutés. Les opérateurs de nœuds sont récompensés pour avoir fourni des services honnêtes et sécurisés, maintenant ainsi l'intégrité du réseau grâce à des incitations économiques. Bien que cela semble simple, la mise en œuvre de cette solution est bien plus complexe qu'elle n'y paraît.
Pourquoi est-il si difficile de créer un cloud TEE décentralisé ?
TEE n'est pas en soi centralisé ou décentralisé, son degré de centralisation dépend de la manière dont il est mis en œuvre et déployé dans le système. TEE est une zone d'isolation sécurisée au sein du processeur, conçue pour protéger le code et les données sensibles contre l'accès non autorisé par le système d'exploitation ou d'autres processus sur le même appareil. TEE fonctionne en mode centralisé ou décentralisé, selon l'architecture du système plus large dans lequel il se trouve.
Historiquement, la création d’un système centralisé a été plus simple que la création d’un système décentralisé, qui a été confronté à des défis en termes de mise en œuvre et de communication des nœuds. Avant Phala Cloud, nous avions créé avec succès le Phala Network 1.0 (SGX) entièrement décentralisé. Phala Cloud est maintenant développé avec la même philosophie, bien que cela prenne du temps. Phala est actuellement la seule plateforme qui combine TEE avec une décentralisation complète, contrairement aux fournisseurs centralisés ou aux protocoles partiellement décentralisés.
Les avantages de la décentralisation et de la TEE sont évidents, mais ils ne sont toujours pas suffisants dans le développement de produits. Imaginez qu’Alibaba soit la plus grande plateforme de commerce électronique au monde avec une énorme part de marché. Si un nouveau produit est lancé avec deux fois plus de puissance et un prix inférieur, va-t-il conquérir l’ensemble du marché ? Malheureusement, non, car les gens sont habitués aux produits existants et il y a un biais contre les nouveaux produits, même s’ils sont meilleurs.
C'est l'un des défis auxquels nous sommes confrontés, mais nous ne cherchons pas à doubler nos améliorations, mais plutôt à nous assurer que Phala est dix fois meilleur que la concurrence et facile à utiliser. De plus, comme mentionné précédemment, AWS n'est pas adapté à l'environnement Web3, et nous visons à combler cette lacune pour les applications et les développeurs Web3. Au-delà de cet avantage évident de la décentralisation, nous souhaitons également souligner d'autres différences entre Phala et AWS.
Phala Cloud et AWS
Tout d'abord, la configuration des Nitro Enclaves d'AWS est complexe. Cela implique plusieurs étapes, y compris l'installation de Nitro CLI, la conversion des images Docker en fichiers Enclave et le traitement du transfert de fichiers, ce qui est très chronophage.
En comparaison, Phala permet aux développeurs de déployer et de modifier "instantanément" avec facilité, en migrant les conteneurs Docker existants vers un TEE sécurisé. Avec le SDK Dstack, les développeurs n'ont besoin que de modifications minimes pour convertir les conteneurs Docker en machines virtuelles confidentielles (Confidential VM), et de les déployer via une interface utilisateur Cloud conviviale, tout en prenant en charge les modèles et les fichiers Docker Compose personnalisés.
En matière de sécurité, AWS s’appuie sur la confiance des développeurs et des administrateurs pour configurer correctement les contrôles d’accès et gérer les ressources. Bien qu’AWS utilise TEE pour l’informatique isolée, son infrastructure centralisée nécessite des personnes qui font confiance à AWS et gèrent le système, ce qui peut entraîner l’accès à des données sensibles. Phala utilise un modèle Zero Trust et ne fait confiance à aucune partie par défaut. Les données sensibles restent sécurisées au sein du TEE et sont inaccessibles même aux opérateurs de nœuds, ce qui les rend adaptées aux applications Web3 qui nécessitent des opérations sans confiance.
Du point de vue du produit, AWS sert principalement les entreprises clientes en raison du grand nombre d’entreprises dans l’espace informatique traditionnel. Par conséquent, il ne s’aligne pas totalement sur la proposition de valeur des startups Web3 en termes de produits et de technologie. En revanche, Phala est spécialement conçu pour les applications décentralisées. Il prend en charge nativement les proxys d’IA qui interagissent avec les contrats intelligents blockchain, ainsi que les DApps préservant la confidentialité.
De plus, Phala s'est profondément intégré dans l'écosystème blockchain grâce à des partenariats avec divers protocoles et à l'intégration d'applications décentralisées (DApp) qui souhaitent tirer parti de la sécurité des TEE.
Phala se positionne comme la couche d’exécution de l’IA Web3, permettant aux développeurs de créer, de lancer et de monétiser des agents d’IA capables de comprendre et d’interagir avec les contrats intelligents blockchain en toute sécurité et en toute confidentialité. Nous prenons en charge les plateformes d’IA décentralisées telles que NEAR AI et Sentient en exploitant NVIDIA GPU TEE pour exécuter de grands modèles de langage (LLM) dans un environnement sécurisé, vérifiable et axé sur la confidentialité. Par exemple, notre partenariat avec NOTAI met en évidence l’application de la confiance zéro des agents d’IA, où nous fournissons une protection sans confiance et de la vie privée via TEE et RA Explorer.
Nous soutenons également l'intégration d'applications non liées à l'IA via les Phat Contracts, qui sont des contrats intelligents à faible coût et à faible latence avec un support natif pour les requêtes HTTP.
Cependant, étant donné que de nombreuses équipes de crypto-natifs construisent également des TEE et d'autres méthodes de calcul sécurisé, comment Phala se distingue-t-elle de ces solutions ?
Phala Cloud et la solution TEE
Phala Network se distingue en tant que seule solution cloud TEE entièrement décentralisée, offrant des calculs sécurisés, privés et vérifiables pour les DApps. Contrairement à Oasis Protocol et Secret Network, qui se concentrent sur l'utilisation de TEE pour des contrats intelligents habilités à la confidentialité dans leurs blockchains respectives, Phala propose une plateforme de cloud computing décentralisée pour des calculs hors ligne à travers les réseaux.
Phala est flexible et personnalisable, utilisant une large gamme de matériel TEE, y compris Intel SGX, Intel TDX, AMD SEV et NVIDIA GPU TEE. Le protocole Marlin améliore les performances réseau de Web3, mais ne fournit pas de fonctionnalités de calcul ou de confidentialité, tandis qu'Oasis et Secret fonctionnent dans des écosystèmes blockchain spécifiques. En tant que seule cloud TEE décentralisée avec un large support matériel et des outils pour développeurs comme Dstack, Phala possède des avantages uniques.
Phala se distingue par le fait qu’il offre un cloud TEE décentralisé à usage général, contrairement à Oasis Protocol, Marlin et Secret Network, qui se concentrent sur des cas d’utilisation spécifiques. Phala permet aux développeurs de déployer n’importe quelle application, telle qu’un modèle d’IA, un serveur Web ou une base de données, dans un environnement sécurisé. Cela est rendu possible grâce à Phat Contracts et Phala Cloud, qui prend en charge les déploiements Dockerized et fournit un accès en un clic au CPU et au GPU TEE.
De plus, il existe de nombreuses comparaisons sur lequel est le plus adapté pour des cas d'utilisation spécifiques entre TEE ou le calcul multipartite (MPC). À notre avis, TEE et MPC ne sont pas des concurrents, mais des partenaires complémentaires.
Phala intègre TEE à MPC pour créer un modèle décentralisé Root of Trust (DeRoT), une approche avancée pour sécuriser les applications basées sur TEE. MPC fonctionne au sein du TEE pour réduire le risque de collusion de nœuds, tandis que les preuves de bloc TEE sont soumises avec les preuves MPC pour atténuer les erreurs dans les implémentations de preuves à divulgation nulle de connaissance (ZKP). Ce système d’attestation multiple est encore renforcé par l’obligation pour les nœuds MPC de fonctionner dans le TEE. Le modèle DeRoT utilise TEE, MPC et ZKP pour distribuer la confiance dans le réseau. Cette approche améliore la sécurité des DApps à l’aide de TEE en traitant les menaces potentielles au niveau du matériel ou des nœuds.
La possibilité du cloud TEE décentralisé
Nous rédigerons un article spécifiquement pour explorer ce sujet, car de nombreuses applications fonctionnent déjà sur Phala. Par conséquent, cette partie pourrait être aussi longue que l'ensemble de l'article. Mais nous espérons donner un aperçu des cas d'utilisation potentiels du cloud TEE décentralisé.
Tout d'abord, Phala prend en charge le déploiement de modèles d'IA dans des TEE, garantissant des interactions sécurisées et des opérations autonomes avec le réseau blockchain. Cela inclut des agents d'IA pour améliorer les contrats intelligents et les interactions entre agents. Les développeurs peuvent tirer parti des GPU TEE pour effectuer des calculs d'IA, réalisant ainsi une véritable résistance à la censure et une protection de la vie privée.
Les développeurs peuvent également migrer des applications traditionnelles vers un environnement sécurisé et sans confiance pour améliorer la sécurité. La plateforme permet une analyse de données respectueuse de la vie privée grâce à des outils d'analyse Web3 et traditionnels, qui peuvent analyser des données sans exposer les informations d'un utilisateur unique. De plus, elle peut renforcer la sécurité des calculs DeFi grâce à des fonctionnalités de confidentialité, telles que les positions de trading confidentielles ou le trading en dark pool. Enfin, le cloud TEE décentralisé peut réaliser une protection MEV en transférant la construction de blocs dans le TEE, pour garantir un tri et une exécution équitables.
De nombreux produits intègrent Phala comme partie de leur infrastructure. Nous examinerons dans un autre article comment ces produits utilisent Phala et ce qu'ils tirent de cette intégration.
Conclusion
Les modèles de confiance de Web3 et Web2 présentent des différences fondamentales, ce qui entraîne des limitations pour des plateformes comme AWS. Dans Web3, les données (y compris les tokens qui appartiennent essentiellement aux données) sont véritablement possédées par les utilisateurs, tandis que les développeurs d'applications sont par défaut considérés comme non fiables. Cette méfiance provient du fait que les développeurs peuvent tenter d'accéder à des données utilisateur sans autorisation, de les modifier ou de les voler.
Ce paradigme explique plusieurs pratiques clés dans Web3 :
La propriété (ou le contrôle de gestion) des contrats intelligents est une question clé, les utilisateurs attachant plus d'importance à la transparence qu'à la possibilité pour les développeurs d'avoir un contrôle illimité.
Contrairement aux contrats intelligents, les TEE peuvent exécuter des principes de propriété et de contrôle similaires dans un éventail de programmes plus large. Cependant, AWS Nitro Enclaves fonctionne dans un cadre Web2, où les développeurs conservent la capacité de se connecter, d'accéder et de modifier des données et des applications. Le TEE de Phala est conçu selon les principes Web3, prenant en charge nativement les contrats intelligents pour gérer les applications basées sur TEE, en conformité avec le modèle de confiance décentralisé.