Les frameworks des smart contracts confidentiels

Les smart contracts confidentiels sont un concept assez récent que l’on rencontre principalement dans les groupes de recherche à des conditions bien contrôlées ou sous une forme conceptualisée dans les publications scientifiques. Cette technologie n’est pas encore mûre et beaucoup de problèmes doivent être résolus avant que les smart contracts confidentiels puissent être déployés. Ceci rend l’annonce de Microsoft Azure sur la phase bêta de son projet d’Azure Confidential Ledger (ACL), faite il y a quelques mois, très intéressante. ACL est une implémentation de Microsoft pour les smart contracts confidentiels basés sur son Confidential Consortium Framework (CCF, ancien framework Coco) qui exploite les garanties de confidentialité et de sécurité des environnements d’exécution de confiance (TEE, trusted execution environments). Dans cet article, je vais comparer la plateforme ACL aux solutions existant dans Hyperledger Fabric, notamment Hyperledger Fabric Private Chaincode (HFPC), et à TZ4Fabric qui est le prototype développé par l’équipe de la chaire des systèmes complexes de l’Université de Neuchâtel. Une introduction aux smart contracts confidentiels, HFPC et TZ4Fabric, a déjà été faite dans ma dernière contribution « Les smart contracts confidentiels pour l’industrie 4.0 ».

Le CCF est l’approche de recherche de Microsoft de proposer un framework open source pour la blockchain se servant de la technologie des TEEs pour exécuter les smart contracts en les protégeant des cyberattaques et des systèmes compromis. Hyperledger Fabric, contrairement au CCF, est un système open source modulaire et extensible, sans support de base pour les smart contracts confidentiels. Ce sont les extensions HFPC, respectivement TZ4Fabric, qui ajoutent ce support nécessaire aux smart contracts confidentiels. Similaire à HFPC, le CCF dispose d’un support pour Intel SGX, un TEE que l’on trouve dans des ordinateurs de bureau et portables ou même dans le cloud. TZ4Fabric dispose d’un support pour ARM TrustZone qui cible plutôt les objets connectés et appareils mobiles et envisage le cloud dans un futur proche. Pour pouvoir utiliser les TEEs, il est nécessaire d’utiliser des protocoles de consensus finis pour éviter certains types de cyberattaques. C’est la raison pour laquelle le CCF, HFPC et TZ4Fabric établissent une blockchain privée avec accès autorisé afin d’avoir un nombre limité de nœuds participants qui soient fiables. Les frameworks atteignent un consensus fini par différentes approches.

Le CCF parvient à obtenir un consensus fini en exigeant que les transactions soient déterminées dans le protocole de consensus et propose un quorum comme règle de gouvernance. De plus, pour empêcher les cyberattaques, l’ensemble des nœuds participants opèrent dans le TEE (à savoir le protocole de consensus, le registre, le smart contract, etc.). Ceci est problématique, car il faut sécuriser et faire confiance à une grande quantité de code. De leur côté, HFPC et TZ4Fabric séparent conceptuellement l’exécution du smart contract du nœud dans le TEE et s’en remettent à un service d’ordre fiable ce qui a pour avantage de réduire significativement la taille du code à sécuriser et auquel faire confiance au sein du TEE. La différence principale entre HFPC/TZ4Fabric et CCF réside dans leur architecture : le CCF utilise une architecture classique « order-execute » tandis que HFPC et TZ4Fabric utilisent une architecture « execute-order-validate ». Dans l’architecture classique « order-execute », les nœuds participant à la blockchain se mettent d’abord d’accord sur l’ordre des blocs avant d’exécuter le smart contract et de changer l’état de la blockchain. Pour HFPC/TZ4Fabric ceci veut dire que les transactions sont exécutées de manière spéculative, similairement à l’exécution des instructions dans un microprocesseur moderne afin d’atteindre une meilleure performance. Les programmeurs de smart contracts doivent être conscients des pièges qui jalonnent l’exécution spéculative (souvenez-vous des failles de sécurité Meltdown et Spectre en 2018 qui ont drastiquement changé l’écosystème des microprocesseurs). C’est pour cette raison que HFPC et TZ4Fabric introduisent une barrière comme structure de contrôle pour les smart contracts confidentiels, afin d’assurer que l’état de la blockchain ne soit évalué qu’après ce contrôle. Prenons l’exemple d’enchères : dès que les participants ont fait leurs offres, le smart contract confidentiel crée une barrière pour clore les enchères avant d’évaluer les offres. Sans cette barrière, les cybercriminels pourraient fabriquer des transactions permettant d’extraire l’information confidentielle de l’état de la blockchain à cause de l’exécution spéculative. Il est important de savoir que le fait d’ajouter une barrière après chaque transaction transforme une architecture « execute-order-validate » en architecture « order-execute ».

HFPC et TZ4Fabric utilisent le « Membership Service Provider » qui attribue chaque membre à son organisation pour délivrer des identifiants, authentifier les membres et autoriser l’accès à la blockchain. Un tel service n’est actuellement pas existant pour le CCF, mais un concept de consortium est en train d’être intégré pour permettre la collaboration entre de multiples participants. Dans le CCF, les membres ont toutefois la possibilité de vérifier à tout instant l’intégrité des nœuds, blocs et transactions grâce à un reçu. HFPC a une fonctionnalité similaire, appelée « remote attestation », qui se sert des fonctionnalités déjà présentes sur la plateforme SGX. TZ4Fabric par contre n’offre pas la fonctionnalité de remote attestation, mais dans notre groupe de recherche nous avons un autre travail en cours pour un prototype à part qui implémente la remote attestation pour ARM TrustZone dans le cadre du projet Européen VEDLIoT.

Avec ACL, Microsoft est entré dans une contrée sauvage et inexplorée, mais il reste beaucoup de travail à faire dans ce projet ainsi que dans ceux d’HFPC et de TZ4Fabric, avant d’offrir des fonctionnalités complètes permettant d’opérer des blockchains basées sur des smart contracts confidentiels. Il n’existe pas encore de réseaux blockchain clés en main supportant des smart contracts confidentiels et cela reste pour le moment du domaine du do-it-yourself. ACL en soi est un registre propriétaire accessible en phase bêta et déployé dans un TEE Intel SGX du cloud de Microsoft Azure qui doit être lié avec le CCF pour former une blockchain complète capable d’exécuter les smart contracts confidentiels. En outre, les programmeurs des smart contracts confidentiels doivent être attentifs aux pièges qui se cachent derrière l’architecture de la blockchain sous-jacente. Par exemple, les smart contracts et d’autres éléments du framework doivent être adaptés à l’exécution dans le TEE. Un autre problème des frameworks est l’introduction de restrictions supplémentaires, comme les barrières et les règles de gouvernance. Peut-être qu’il sera possible d’intégrer un jour ces restrictions dans le framework et d’éviter aux programmeurs novices de se heurter à ces problèmes. Néanmoins, en l’état actuel, les programmeurs inexpérimentés ou sans connaissances des problèmes liés aux smart contracts confidentiels risquent de tomber dans le piège. Il reste beaucoup de recherche et de travail à effectuer pour réduire la difficulté des smart contracts confidentiels et les rendre accessibles à un plus grand public.