Devrions-nous sortir le matériel de Blockchain?
Vous pensez peut-être que la blockchain n’a rien à voir avec le matériel. Enfin, de Bitcoin à Etherum, tous les réseaux blockchain sont définis par logiciel. Une solution matérielle est généralement plus centralisée. Cependant, dans un monde de blockchains préservant la confidentialité, avec une combinaison judicieuse de logiciels et de matériel, nous pourrions concevoir une solution avec le meilleur équilibre entre évolutivité et confidentialité tout en restant sans confiance.
La confidentialité du réseau Blockchain basée sur TEE
Phala Network est un contrat intelligent confidentiel. Il diffère des contrats traditionnels car les contrats sont exécutés au sein d’un composant matériel spécial dans le CPU, c’est à dire. Environnement d’exécution fiable. Le programme exécuté dans TEE est très isolé du reste du monde. Une attaque malveillante ne peut pas lire les données en mémoire ou manipuler un programme sans autorisation pour produire un comportement indésirable.
Dans Phala Network, la prise en charge d’un programme s’exécutant dans TEE est appelée “pRuntime”. pRuntime est un environnement d’exécution qui maintient le protocole de base d’exploration de données TEE et Gatekeeper dans TEE. Il gère l’authentification à distance TEE, l’enregistrement de la chaîne, la gestion des clés et l’exécution confidentielle des contrats.
Mais comment convaincre l’utilisateur que le contrat intelligent fonctionne dans pRuntime et non dans un émulateur qui n’assure aucune sécurité des données? Voici le concept de base: l’authentification à distance.
Authentification à distance
“Une application hébergeant l’enclave peut également demander à l’enclave de produire un rapport, puis de le transmettre au service de la plateforme pour créer un type de justificatif qui reflète l’état de l’enclave et de la plateforme. Cette information d’identification est connue sous le nom de citation. Ce montant peut ensuite être transmis à des entités hors plateforme et vérifié…”
L’authentification à distance est la clé pour garantir la sécurité du système TEE. Cité par Intel, il prouve qu’un certain code (mesuré par un hachage de code), éventuellement avec des données personnalisées générées par le code, est exécuté dans une enclave Intel SGX d’origine moderne.
Approvisionnement secret
L’étalonnage à distance des services est un bloc de base pour les contrats intelligents confidentiels. Mais ce n’est pas très utile si nous ne pouvons pas établir un canal de communication sécurisé complet entre les participants TEE. Intel SGX propose également un protocole de préparation secret pour un dépannage élégant.
En adoptant le protocole d’approvisionnement secret, une chaîne de confiance peut être établie de l’utilisateur à pRuntime:
1. Blockchain a un code pRuntime canonique de hachage
2. pRuntime démarre le protocole d’attestation à distance, obtient un rapport avec les données: hachage du code attesté (pRuntime lui-même); et la clé publique de la paire éphémère de clés d’identité
3. Le rapport RA est soumis à la blockchain et confirmé sur la chaîne
4. Blockchain compare le hachage du rapport RA (implique: le participant est un travail canonique dans TEE)
5. Une clé d’identité publique est enregistrée sur la blockchain (implique: seul le pRuntime actuel a le contrôle sur cette clé d’identité)
Par conséquent, tant que le message est signé avec une clé d’identité, il doit être produit par un pRuntime enregistré. Les utilisateurs peuvent en outre établir une connexion de type TLS sur pRuntime avec sa clé publique enregistrée.
Pour communiquer avec le TEE, l’utilisateur peut obtenir une clé publique d’un certain temps de fonctionnement à partir de la blockchain (à partir de l’enregistrement TEE). L’utilisateur peut alors utiliser la clé publique de son compte substrat pour exécuter le protocole Diffie-Hellman. Exécute une clé secrète pour la communication entre l’utilisateur et pRuntime.
Lorsqu’une chaîne de confiance est établie, cela signifie également que la clé d’identité est suffisante pour représenter de manière unique l’identité du temps. Ainsi, une authentification à distance peut protéger toutes les communications futures avec pRuntime, à condition qu’il n’y ait pas de brèche matérielle TEE (ce qui sera discuté plus tard).
Que diriez-vous d’une mise à niveau?
La mise à niveau sur une chaîne est une exigence cruciale car elle réduit considérablement les risques de sécurité exposés à une mise à niveau Hard Fork. Le substrat prend à l’origine en charge le temps de mise à niveau sur la chaîne. Cela rend la palette de contrôle sur la chaîne. Du côté TEE, le temps d’exécution est également évolutif.
Lors de la mise à jour de pRuntime, nous devrions envoyer un bloc pour pulvériser la nouvelle version de pRuntime. La communauté peut ensuite revoir le code, discuter et voter pour la mise à niveau via un processus de gestion de chaîne similaire à Substrate.
Les gardiens et les mineurs doivent mettre à jour pRuntime lorsqu’une nouvelle version est acceptée sur la chaîne. Les mineurs sont plus légers car ils peuvent simplement arrêter l’exploitation minière, améliorer et continuer l’exploitation minière. Cela est possible car les mineurs n’ont pas toujours besoin d’être en ligne. Les gardes de porte ont des exigences de haute disponibilité. Ainsi, ils exécutent un autre client TEE avec une version plus récente et attendent la transition du tuteur naturel lors de la prochaine période électorale, ou exécutent des décharges d’urgence pour crypter l’état et le récupérer dans le nouveau runtime.
Bien qu’il existe des risques de destruction de l’état, il est toujours utile en cas d’urgence. SGX propose une fonction «sceller pour enclave», qui peut produire un code qui ne peut être déchiffré que dans la même enclave.
Pour atténuer les risques liés à l’exploitation de la sécurité du matériel, les clés des Gatekeepers sont distribuées via le schéma de partage de données secrètes de Shamir, ce qui signifie que même si le verrou est cassé, l’hôte ne peut toujours pas obtenir les clés d’origine sans un accord massif.
Attaque et defense
Notre modèle de menace suppose en partie que le fabricant TEE peut faire confiance. Ceci est raisonnable. Premièrement, ils ne savent pas comment leur matériel sera utilisé et ne peuvent donc planifier une attaque qu’à l’avance, ce qui réduit les risques. Deuxièmement, si elles sont affectées par des attaques zero-day, les autres applications exécutées sur ce processeur sont généralement à risque.
Bien que nous ayons l’hypothèse ci-dessus, nous voyons que les interventions matérielles réelles appartiennent au passé. Heureusement, les vulnérabilités peuvent généralement être atténuées de plusieurs manières.
Il est courant de penser que les vulnérabilités logicielles peuvent être corrigées, contrairement aux vulnérabilités matérielles. Ce n’est pas toujours le cas. Le CPU peut être réparé en mettant à jour le microcode. Grâce à la conception spéciale de l’architecture Intel SGX, la plupart des vulnérabilités peuvent être corrigées. Récemment, il y a eu une attaque appelée SGAxe, corrigée par une mise à niveau du microcode suivie d’une rotation des clés de groupe. Après avoir tourné et rappelé la clé, les vérificateurs à distance rejettent tous les appareils obsolètes.
Mais vous vous demandez peut-être, que se passe-t-il si quelqu’un pense toujours que le matériel zero-day est vulnérable? En supposant que la vulnérabilité nécessite une approche physique pour l’exploiter, les mineurs pourront voler les données d’un contrat confidentiel. Dans ce cas, vous pouvez appliquer le caractère aléatoire pour atténuer. La blockchain peut accidentellement assigner certains mineurs à des contrats confidentiels sur une période de temps. Les mineurs se mélangent à chacune de ces périodes. Tant que le côté malveillant n’a aucun contrôle sur un grand nombre de mineurs, le coût d’une telle attaque sera substantiel car elle nécessite un contrôle de masse sur une période de temps relativement longue.
Dans le pire des cas, lorsque l’enclave est complètement brisée en exposant les informations confidentielles disponibles à l’attaquant et en permettant à l’attaquant de manipuler arbitrairement l’exécution, nous ne voulons toujours pas renoncer à l’exactitude du contrat confidentiel. Par conséquent, nous avons une conception selon laquelle les contrats confidentiels peuvent nécessiter une ou plusieurs réplications.
Le nombre de réplications n’affecte pas la façon dont le contrat est exécuté car toutes les entrées proviennent de la blockchain et donc déterministes. Cependant, s’il y a plus d’une réplique, plusieurs TEE essaieront de renvoyer les états à la blockchain. Dans ce cas, il y aura un processus de vote en chaîne simple. Nous avons besoin d’une majorité simple pour “finaliser” la situation.
Par réplication, nous sommes revenus au modèle de sécurité de Polkadot comme un validateur. Un attaquant doit contrôler une quantité suffisante de mineurs pour enfreindre l’exactitude, même si l’hypothèse de sécurité SGX est rompue.
Résumé
Dans le passé, les blockchains n’étaient que des logiciels. Le manque de confidentialité est depuis longtemps une contrainte à l’adoption massive. Avec l’aide de matériel et d’un protocole soigneusement conçu, nous avons montré qu’il est possible de construire une blockchain sécurisée, évolutive et confidentielle qui stocke des données.
Calendrier Phala
· Campagne Testnet à venir (et petit jeu secret)
· 6.28 AMA avec un autre projet bien connu
· 7.5–7.6 Assistez à la semaine de la blockchain de Hangzhou organisée conjointement par le gouvernement de Hangzhou et 8bit.
À propos du réseau Phala
Contrats intelligents privés confidentiels basés sur la plateforme de blockchain Substrate qui permet le développement d’applications principalement destinées à préserver la confidentialité et la confidentialité des données des utilisateurs.Membre du programme Substrate Builders et bénéficiaire du soutien de Web3 Foundation.
