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.

Proposition de citation : Göttel Christian, Les frameworks des smart contracts confidentiels, Blog du LexTech Institute, 16.11.2021

Confidential smart contracts are still a relatively new concept and can primarily be found under well controlled conditions in laboratories or under conceptualized form in research papers. The maturity of this enhanced technology is still questionable and many problems remain to be resolved, which makes confidential smart contracts rare to find in the wild. This makes Microsoft Azure‘s announcement of a preview of their Azure Confidential Ledger (ACL) earlier this year all the more interesting. ACL is Microsoft’s implementation of confidential smart contracts using their Confidential Consortium Framework (CCF, formerly known as Coco framework) to exploit the confidentiality and security guarantees of trusted execution environments (TEE). In this article, I will be taking a closer look at the ACL platform and compare it to existing solutions for Hyperledger Fabric, namely Hyperledger Fabric Private Chaincode (HFPC) and the prototype developed at the complex systems research group of the University of Neuchâtel, TZ4Fabric. For an overview on confidential smart contracts, HFPC, and TZ4Fabric, please read my previous blog entry on « Confidential Smart Contracts for the Industry 4.0« .

CCF is Microsoft’s research attempt to propose an open source blockchain framework leveraging TEE technology to execute smart contracts shielded from attackers and compromised systems. Hyperledger Fabric, contrary to CCF, is a modular and extensible open source system which does not provide support for confidential smart contracts out of the box. It is the HFPC, respectively TZ4Fabric, extension which provides the necessary support for confidential smart contracts. Like HFPC, CCF provides support for the Intel SGX[fn:8], a TEE commercially available in desktops and laptops or in cloud data centers. TZ4Fabric provides support for ARM TrustZone, a TEE targeting primarily IoT and mobile devices with ambitions for cloud data centers. In order to make use of TEEs, consensus protocols with finality guarantee have to be used to avoid certain types of malicious attacks. Therefore, CCF, HFPC, and TZ4Fabric establish a permissioned blockchain network to have a bounded number of participating and trusted nodes. Different approaches are taken by the frameworks to achieve consensus with finality guarantee.

On the one hand CCF achieves consensus with finality by requiring transactions to be committed in its consensus protocol and proposes a quorum as governance rule. Furthermore, to prevent malicious attacks, the entire node (i.e., consensus protocol, ledger, smart contract and more) are being executed inside the TEE. This is problematic because a large code base needs to be trusted and secured. On the other hand, HFPC and TZ4Fabric separate conceptually the smart contract execution from the node into the TEE and rely on a trusted ordering service resulting in a much smaller trusted computing base (trusted code executed inside a TEE). The main difference between HFPC/TZ4Fabric and CCF are their architectures. CCF uses a classical order-execute architecture while HFPC/TZ4Fabric use an execute-order-validate architecture. In the classical order-execute architecture, participating nodes in the blockchain network agree first on the order of blocks before executing the smart contract and changing the state of the blockchain. For HFPC/TZ4Fabric, this means that transactions are executed in a speculatively similar way to modern microprocessors to improve performance. However, speculative execution has a couple of pitfalls programmer of smart contracts need to be aware of (remember the speculative execution vulnerabilities Meltdown and Spectre from 2019 which have drastically changed the microprocessor ecosystem). For this reason, HFPC/TZ4Fabric make use of a barrier in confidential smart contracts, which ensures that the blockchain state is only evaluated after the barrier. Imagine, for example, an auction. As soon as all participants have placed their bets, the confidential smart contract will issue a barrier to close the auction before evaluating the bets. Without this barrier, a malicious attacker could craft transactions to extract confidential information from the blockchain state due to the speculative execution. It should be noticed that placing a barrier after each transaction would essentially transform the execute-order-validate architecture into an order-execute architecture.

HFPC and TZ4Fabric make use of the membership service provider that maps members to their organization in order to issue credentials, authenticate members and authorize access to the blockchain network. Such a service is currently not available in CCF, but a consortium concept is being established to allow collaboration of multiple parties. However, in CCF, members have the ability to verify at any time the integrity of nodes, blocks, and transactions using receipts. HFPC has a similar capability named “remote attestation”, which leverages functionalities already available on the SGX platform. TZ4Fabric currently does not provide remote attestation, but in our research group we have ongoing work for a different prototype to provide remote attestation in ARM TrustZone within the European project VEDLIoT.

Microsoft’s ACL has set a foot into the wild, but ACL as well as HFPC and TZ4Fabric still have to take a major leap to provide a complete set of functionalities for operating blockchain networks with confidential smart contracts. Off-the-shelf blockchain networks with support for confidential smart contracts are not yet available and remain for the moment a do-it-yourself undertaking. ACL by itself is a proprietary ledger available as preview that runs inside a TEE of Microsoft’s Azure cloud and must be coupled with CCF in order to form a complete blockchain network capable to run confidential smart contracts. Furthermore, confidential smart contract programmers must be aware of the many pitfalls that hide behind the architecture of the underlying blockchain network. For example, smart contracts and other elements of the framework need to be ported into the TEE. Another issue of the frameworks is the introduction of additional restrictions, such as barriers and governance rules. Maybe it will be possible in the future to integrate them into the framework and hide them from unexperienced programmers. Nevertheless, in their current state, programmers that are new to or unaware of these issues with confidential smart contracts are likely to fall into the trap. A lot of research and work remains to be done to lower the entry level to confidential smart contracts and make them more easily accessible to a wider audience.

Suggested citation: Göttel Christian, Confidential Smart Contracts in the Wild, Blog of the LexTech Institute, 16 November 2021

Les frameworks des smart contracts confidentiels

Share

Confidential Smart Contracts in the Wild

Share