Auteur : Dr. Shunfan(Shelven) Zhou, chercheur principal du réseau Phala et l'un des auteurs du livre blanc Phala, travaille dans la recherche sur la sécurité depuis plus de 7 ans. Il est l'auteur principal de An Ever-evolving Game: Evaluation of Real-world Attacks and Defenses in Ethereum Ecosystem, USENIX Security Symposium 2020 et d'autres articles sur l'analyse de programmes.

Résumé

Le 30 novembre, l'expert en sécurité Andrew Miller a souligné que les vulnérabilités d'Intel SGX avaient causé de grands risques de sécurité pour des projets tels que Secret Network, qui a suscité de nombreuses discussions au sein de la communauté. Intel SGX, l'implémentation la plus largement adoptée de TEE, est également utilisée par les travailleurs hors chaîne de Phala, mais Phala utilise une nouvelle conception de système qui réduit la surface d'attaque et atténue les conséquences des attaques potentielles. Notre équipe de développement considère que les impacts de ces vulnérabilités sur Phala sont contrôlables.

Cet article expliquera aux lecteurs :

• Pourquoi les vulnérabilités ÆPIC Leak et MMIO ont sapé la sécurité de Secret Network
• Les raisons pour lesquelles Phala utilise Secure Enclave (TEE)
• Comment Phala s'assure qu'il ne sera pas compromis par les vulnérabilités SGX
• Futurs mécanismes de sécurité

1. Qu'est-ce qui a causé la vulnérabilité dans Secret Network ?

• Le matériel présentant des vulnérabilités non corrigées ( ÆPIC Leak et MMIO Vulnerabilities , annoncé par Intel le 9 août 2022) a été autorisé à rejoindre le réseau secret et à exploiter des nœuds. L'équipe secrète a gelé l'enregistrement après que le whitehat ait signalé ce problème ;
• La même clé de déchiffrement principale dans Secret Network est partagée entre tous les nœuds.

2. Qu'est-ce que les attaquants pourraient accomplir ?

Comme je cite dehttps://sgx.fail: « Ces vulnérabilités pourraient être utilisées pour extraire la graine de consensus, une clé principale de déchiffrement pour les transactions privées sur le réseau secret. L'exposition de la graine de consensus permettrait la divulgation rétroactive complète de toutes les transactions privées Secret-4 depuis le début de la chaîne.

3. Phala Network est-il affecté par les mêmes vulnérabilités ?

Non. Phala adopte le contrôle d'accès sur l'enregistrement des nœuds (appelé « travailleur » dans Phala) et la gestion de la hiérarchie des clés, dont je parlerai plus tard.

Ressources :

• https://scrt.network/blog/notice-successful-resolution-of-xapic-vulnerability
• https://sgx.fail/

Pourquoi Phala a besoin de Secure Enclave (TEE)

Phala est un cloud de calcul sans autorisation qui permet à tous les ordinateurs de se joindre en tant que travailleurs, donc notre modèle de menace est qu'aucun travailleur n'est approuvé par défaut. Les mauvais acteurs agissant en tant que travailleurs peuvent essayer de :

• consulter les données des utilisateurs ;
• fournir de faux résultats d'exécution ou ne faire aucun calcul ;
• fournir des services de mauvaise qualité comme la réduction des performances du processeur ou le blocage de l'accès au réseau.

Secure Enclave fournit d'importantes promesses de sécurité basées sur le matériel, notamment :

• Confidentialité : toutes les valeurs de la mémoire sont cryptées ;
• Intégrité d'exécution : personne ne peut corrompre la justesse de l'exécution même s'il contrôle le système d'exploitation et l'ordinateur physique ;
• Attestation à distance : les utilisateurs peuvent vérifier à distance le matériel et les logiciels exécutés à l'intérieur de Secure Enclave.

Ces fonctionnalités nous servent de base de confiance pour « emprunter » la puissance informatique des gens. Il convient de noter qu'en tant que cloud de calcul, les valeurs fondamentales de Phala sont l'exécution correcte des programmes des utilisateurs et la confidentialité des données des utilisateurs. Cela différencie Phala des autres projets qui se concentrent uniquement sur la confidentialité.

Phala peut-il utiliser la preuve Zero-Knowledge, le calcul multipartite ou le cryptage entièrement homomorphe en tant que travailleurs ?

La réponse est non, oui et oui puisque ces solutions fonctionnent de différentes manières.

• Dans le cas de ZKP, l'utilisateur effectue sa propre exécution et ne fournit que la preuve en chaîne qu'il a réellement effectué le travail. Ce n'est pas le cas du cloud computing où vous déléguez votre calcul à d'autres ;
• MPC divise les tâches en différentes parties, de sorte qu'aucun des exécuteurs ne peut connaître l'entrée d'origine ou la sortie finale ;
• FHE permet aux exécuteurs de calculer directement avec le texte chiffré, de sorte qu'ils ne peuvent pas connaître les données des utilisateurs.

Contrôle d'accès lors de l'enregistrement des travailleurs

Rejoindre Phala en tant que travailleur implique deux prérequis :

• Les travailleurs doivent fournir du matériel avec prise en charge de Secure Enclave. Actuellement, nous ne prenons en charge qu'Intel SGX, mais notre enquête sur AMD-SEV a montré qu'il est également compatible avec notre système actuel ;
• Les travailleurs exécutent des programmes non modifiés construits par Phala, y compris le nœud Phala et le pRuntime hors chaîne (abréviation de Phala Runtime) .

• Informations sur le matériel
• Si pRuntime s'exécute dans SGX ;
• Les vulnérabilités connues étant donné la version actuelle du matériel et du micrologiciel. Sur cette base, la blockchain Phala rejettera le matériel avec des vulnérabilités sur liste noire et attribuera à chaque travailleur un niveau de confiance .
• Informations sur le logiciel
• Le hachage du binaire du programme, qui permet de s'assurer que le pRuntime n'est pas modifié ;
• La disposition initiale de la mémoire du programme, de sorte que son état initial est déterminé.

De plus, notre Supply-end Tokenomic encourage un service de haute qualité de la part des travailleurs. Cela sort du cadre de cet article, mais vous pouvez en savoir plus sur notre page Tokenomics liée ci-dessus.

Gestion de la hiérarchie des clés

La première hiérarchie clé au monde pour le système hybride blockchain-TEE a été proposée par le document Ekiden en 2019 et sert de base au projet Oasis. En tant que cloud de calcul, Phala améliore cette conception pour la rendre viable pour un réseau d'environ 100 000 nœuds. Nous introduisons également un nouveau mécanisme comme la rotation des clés pour améliorer encore la robustesse du cloud.

Avant d'approfondir les détails de notre gestion des clés contractuelles, il est important que les lecteurs sachent que chaque entité de notre système possède sa propre clé d'identité. Chaque utilisateur a son compte, et chaque travailleur et gatekeeper (qui sont élus par les travailleurs) a sa propre paire sr25519 WorkerKey , qui est générée à l'intérieur de pRuntime (donc aussi dans SGX) et la clé privée ne quitte jamais le SGX. La clé d'identité est utilisée pour :

• Identifier le message d'une entité avec signature ;
• Établissez un canal de communication crypté entre les utilisateurs, les travailleurs et les contrôleurs d'accès avec l'accord de clé ECDH . Par défaut, toute communication entre toutes les entités est cryptée dans Phala.

• Les gardiens sont des travailleurs de haut niveau de confiance : ils sont immunisés contre toutes les vulnérabilités SGX connues ;
• Contrairement aux travailleurs normaux, les terminaux des gatekeepers ne sont pas publics et vous ne pouvez pas leur déployer de contrats. Cela réduit l'accès à distance aux contrôleurs d'accès ;
• Des montants de mise accrus sont exigés des gardiens pour décourager les mauvais comportements de leurs opérateurs.

Enfin, lorsqu'un contrat est déployé sur un cluster, il est déployé sur tous les travailleurs de ce cluster. Ces travailleurs suivront le processus déterministe et dériveront le ClusterKey pour obtenir le même ContractKey. Les ContractKeys sont uniques pour différents contrats.

Quelles sont les vulnérabilités en cas de fuite de certaines clés ?

• Si une WorkerKey est divulguée, les attaquants peuvent déchiffrer tous les messages qui lui sont envoyés, tels que la ClusterKey de son cluster, qui peut être utilisée pour accéder aux ContractKeys de ce cluster. Les attaquants pourraient même se faire passer pour un travailleur pour fournir de faux résultats aux utilisateurs. Une telle activité malveillante peut être détectée en comparant les résultats de plusieurs travailleurs, puis la chaîne réduirait le travailleur compromis et confisquerait le PHA jalonné de ce travailleur ;
• Si une ContractKey est divulguée, les attaquants peuvent déchiffrer les états et toutes les entrées historiques de ce contrat ;
• Si une clé de cluster est divulguée, les attaquants peuvent connaître les informations ci-dessus de tous les contrats de ce cluster ;
• Si la MasterKey est divulguée, toutes les données historiques sont divulguées.

• Phala a mis en place la rotation des clés pour les gatekeepers, ce qui signifie qu'avec l'autorisation du Conseil, les gatekeepers peuvent mettre à jour la MasterKey, puis en conséquence les ClusterKeys et ContractKeys.
• Ainsi, lorsque le pire des cas se produit, nous allons d'abord enregistrer les nouveaux gatekeepers avec le matériel le plus récent, désenregistrer tous les anciens (car ils sont susceptibles d'être vulnérables) et passer à une nouvelle MasterKey.

1. Utiliser le calcul multipartite pour gérer MasterKey

2. Activer l'actualisation des devis RA

Étant donné que Phat Contract n'est actuellement pas pris en charge sur le réseau principal, les travailleurs n'ont besoin de soumettre les devis RA qu'une seule fois lors de leur inscription. Lorsque Phat Contract sera publié, nous activerons une actualisation régulière des devis RA afin que les travailleurs vulnérables soient réduits une fois que de nouvelles vulnérabilités sont signalées et que les travailleurs n'appliquent pas les correctifs.

Enfin, je tiens à remercier Andrew Miller et l'équipe de recherche sur la sécurité, y compris Christina Garman, Daniel Genkin, Stephan van Schaik et d'autres pour leur contribution au domaine de la sécurité. Comme l'a dit Andrew, l'objectif de son équipe est d'aider à améliorer la sécurité et à réduire le nombre d'accidents de sécurité. J'ai sincèrement hâte d'avoir des discussions plus approfondies avec des chercheurs en sécurité afin de consolider l'infrastructure sans confiance pour le monde Web3.