Source: https://medium.com/phala-network/should-we-kick-hardware-out-of-blockchain-5d300596a811
Traducteur: @D3V3LIN
Devrions-nous virer le Hardware de la Blockchain?
Vous pouvez penser que la blockchain n’a que peu à voir avec le Hardware (le matériel informatique). Après tout, de Bitcoin à Etherum, les blockchains sont toutes définies par logiciel. La solution basée sur le hardware est généralement plus centralisée. Cependant, dans le monde de la blockchain préservant la vie privée, en combinant soigneusement les logiciels et le hardware, nous pourrions concevoir une solution avec le meilleur équilibre entre l’extensibilité (scalability) et la confidentialité, tout en la gardant sans confiance.
Confidentialité de la blockchain basée sur TEE
Phala Network met en œuvre un smart contract confidentiel. Il diffère des contrats traditionnels parce que les contrats s’exécutent à l’intérieur d’une enclave hardware spéciale dans le CPU (TEE : Trusted Execution Environment). Le programme exécuté à l’intérieur de TEE est hautement isolé du reste du monde. Une attaque malveillante ne peut ni lire les données dans la mémoire sans autorisation, ni manipuler le programme pour produire un comportement involontaire.
Dans Phala Network, nous appelons le programme de soutien exécuté à l’intérieur de TEE « pRuntime ». pRuntime est l’environnement d’exécution qui maintient le protocole de base de TEE miner et Gatekeeper à l’intérieur de TEE. Il gère l’attestation à distance de TEE, l’enregistrement on-chain, la gestion des clés et l’exécution confidentielle du contrat.
Mais comment convaincre un utilisateur que le smart contract s’exécute à l’intérieur de pRuntime, et pas un émulateur qui ne fournit aucune sécurité des données ? Voici le concept de base : Attestation à distance (Remote attestation).
Attestation à distance (Remote Attestation)
« Une application qui héberge une enclave peut également demander à l’enclave de produire un rapport, puis de transmettre ce rapport à un service de plate-forme pour produire un type d’informations d’identification qui reflète l’état de l’enclave et de la plate-forme. Ces informations d’identification est connue sous le nom de devis (quote). Ce devis peut ensuite être transmis aux entités hors de la plate-forme, et vérifié … »
L’attestation à distance est la clé pour assurer la sécurité d’un système TEE. Le devis établi par Intel, prouve qu’un certain code (mesuré par le hachage du code), éventuellement avec quelques données personnalisées générées par le code, s’exécute à l’intérieur d’une enclave Intel SGX authentique et à jour.
Provisionnement secret
L’attestation à distance est un bloc de construction basique pour les smart contracts confidentiels. Mais il n’est pas très utile si nous ne pouvons pas établir un canal de communication sécurisé de bout en bout entre une tierce partie et TEE. Intel SGX fournit également un protocole d’approvisionnement secret pour résoudre le problème avec élégance.
En adoptant le protocole d’approvisionnement secret, une chaîne de confiance de l’utilisateur vers pRuntime peut être établie :
-
La blockchain détient le hachage du code pRuntime canonique
-
pRuntime exécute le protocole d’attestation à distance, obtient un rapport avec les données : hachage du code attesté (pRuntime lui-même) ; et la clé publique d’une paire de clé d’identité éphémère.
-
Le rapport RA est soumis à la blockchain et validé on-chain.
-
La blockchain compare le hachage du rapport RA (cela sous-entend : le participant est un pRuntime canonique dans TEE)
-
La clé d’identité publique est enregistrée sur la blockchain (cela sous-entend : seul le pRuntime actuel a le contrôle sur cette clé d’identité)
Par conséquent, tant qu’un message est signé par la clé d’identité, il doit être produit par le pRuntime enregistré. Les utilisateurs peuvent en outre établir une connexion de type TLS à un pRuntime avec sa clé publique enregistrée.
Pour communiquer avec TEE, l’utilisateur peut obtenir la clé publique d’un certain pRuntime à partir de la blockchain (à partir de l’enregistrement TEE). Ensuite, l’utilisateur peut utiliser la clé publique de son susbtrate account pour exécuter un protocole Diffie-Hellman. Il délivre une clé secrète pour la communication entre l’utilisateur et le pRuntime.
Comme l’a établi la chaîne de confiance, elle implique également que la clé d’identité est suffisante pour représenter uniquement l’identité du pRuntime. Ainsi, une seule attestation à distance peut protéger toute la communication future avec le pRuntime, sous l’hypothèse qu’il n’y ait eu aucune violation du hardware TEE (cela sera abordé plus tard).
Qu’en est-il des mises à niveau ?
La mise à niveau (upgrade) on-chain est une exigence essentielle car elle réduit considérablement les risques de sécurité exposés par upgrade « hard-fork ». Le Substrate prend en charge, par nature (native), la mise à niveau d’exécution on-chain. Cela est réalisé par la palette de gouvernance on-chain. Du côté de TEE, le temps d’exécution est également évolutif.
Lors de la mise à niveau pRuntime, nous devons soumettre le hachage de la nouvelle version pRuntime à la blockchain. Ensuite, la communauté peut examiner le code, discuter et voter pour la mise à niveau par un processus de gouvernance on-chain similaire à Substrate.
Les Gatekeepers et les Mineurs doivent mettre à niveau pRuntime une fois qu’une nouvelle version est acceptée on-chain. Les mineurs ont plus facile parce qu’ils peuvent simplement arrêter de miner, faire la mise à niveau et reprendre le minage. Cela est possible parce que les Mineurs ne sont pas tenus d’être toujours online. Les Gatekeepers ont des exigences de disponibilité élevées. Donc, soit ils exécutent un autre client TEE avec la version la plus récente, et attendent un changement naturel de Gatekeepers durant la prochaine période électorale, soit ils effectuent un vidage du cryptage d’urgence des états (emergency encryption dump of the states), et le récupére à la nouvelle pRuntime.
Bien qu’il y ait des risques de vider les états (states), cela s’avère toujours utile en cas d’urgence. SGX fournit une fonction « seal to enclave », qui peut produire un chiffrement qui ne peut être décrypté que par la même enclave.
Pour atténuer les risques pour les exploits de sécurité hardware, les clés dans Gatekeepers sont distribuées par un système de partage secret Shamir, ce qui signifie que même si le sceau de sécurité est brisé, l’hôte ne peut toujours pas obtenir les clés d’origine sans collusion massive.
Attaque et défense
Notre modèle de gestion de la menace suppose en partie que l’on peut faire confiance au fabricant TEE. C’est raisonnable. Tout d’abord, ils ne savent pas comment leur hardware sera utilisé et ne peuvent donc planifier l’attaque à l’avance, réduisant les risques. Deuxièmement, si elles sont affectées par des attaques zero-day, les autres applications en cours d’exécution sur ce CPU sont généralement sujettes au risque.
Bien que nous ayons émis l’hypothèse ci-dessus, nous constatons que les exploits hardwares réels venir du passé. Heureusement, les vulnérabilités peuvent généralement être atténuées de plusieurs façons.
Il est courant de penser que les vulnérabilités des logiciels sont corrigées alors que les vulnérabilités du hardware ne le sont pas. Ce n’est pas toujours le cas. Le CPU peut être corrigé par des mises à jour de microcode. Avec 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, qui a été résolue par une mise à niveau du microcode suivie d’une rotation de la clé de groupe. Après la rotation et la révocation des clés, tous les périphériques obsolètes sont rejetés par l’attestation à distance.
Vous pourriez alors vous demander que faire si quelqu’un trouve encore une vulnérabilité hardware zero-day? Supposons que la vulnérabilité nécessite un accès physique pour l’exploiter, les mineurs auraient la possibilité de voler des données du contrat confidentiel. Dans ce cas, on peut ajouter de l’aléatoirité pour atténuer le risque. La blockchain peut attribuer au hasard certains mineurs aux contrats confidentiels durant une période. Les mineurs sont mélangés durant chacune ces périodes. Tant que la tierce partie malveillante n’a pas le contrôle sur un grand nombre de mineurs, le coût pour faire une telle attaque sera significativement élevé parce qu’elle nécessite un contrôle massif durant un temps relativement long.
Dans le pire des cas où l’enclave est entièrement fissurée, exposant les données confidentielles à la disposition de l’attaquant et 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 la conception que les contrats confidentiels peuvent nécessiter une ou plusieurs réplications.
Le numéro de réplication n’affecte pas la façon dont le contrat est exécuté car toutes les entrées proviennent de la blockchain et sont donc déterministes. Toutefois, si plusieurs répliques existent, plusieurs TEE tenteront de renvoyer les états dans la blockchain. Dans ce cas, il y aura un simple processus de vote on-chain. Nous avons besoin d’une majorité simple pour « finaliser » les états.
En exécutant des réplications, on revient à un modèle de sécurité similaire à celui d’un validateur Polkadot. L’attaquant doit contrôler un nombre suffisant de mineurs pour briser l’exactitude du contrat, même si l’hypothèse de sécurité de SGX est rompue.
Résumé
Dans le passé, les blockchains n’étaient que des logiciels. Le manque de confidentialité est depuis longtemps devenu une limitation pour l’adoption de masse. Avec l’aide d’un hardware et d’un protocole soigneusement conçu, nous démontrons qu’il est possible de construire une blockchain sécurisée, extensible (scalable) et confidentielle.
Calendrier Phala
-
SoonCampagne Testnet (et un petit jeu secret) -
6.28AMA (Ask Me Anything) avec un autre projet célèbre -
7.5-7.6Présence à la semaine de la blockchain à Hangzhou conjointement tenue par le gouvernement de Hangzhou et 8bit.
A propos de Phala
Une blockchain smart contract confidentielle ‘substrate-based’ sur laquelle vous pouvez développer des applications blockchain préservant la confidentialité et ‘privacy-first’. Membre initial du ‘Substrate Builders Program’. Récipiendaire de subvention de la Fondation Web3.