Article

[DOSSIER] La blockchain et ses vulnérabilités

Publié le 4 mai 2018

Dans cet article du dossier blockchain de la revue REE, 6 experts proposent un panorama des questions de sécurité des technologies blockchain, en partant des algorithmes sous-jacents à la gestion des données jusqu’à traiter la blockchain dans un contexte d’utilisation plus large en incluant également les recommandations issues des organismes de standardisation.

Wafa Ben Jaballah, Chercheur chez Thales ; Nicolas Chalvin, VP IoT Solutions & Services chez Gemalto ; Sebastien Keller, Chef de projet R&T chez Thales ; Mourad Faher, Expert normalisation chez Gemalto ; Fabio Pianese, Responsable de l’équipe de recherche en Réseaux, Protocoles et Systèmes chez Nokia Bell Labs ; Sara Tucci, Chef de Laboratoire chez CEA, Institut LIST

Introduction

Les blockchains ont comme objectif premier la sécurisation des données dans un registre partagé, c’est-à-dire assurer l’intégrité et la disponibilité des données échangées dans un environnent multi-acteur. La sécurisation d’une blockchain commence par son « cœur » constitué des algorithmes de consensus qui permettent aux nœuds du réseau de maintenir de manière cohérente et sans faille le registre distribué. Dans un réseau public ces algorithmes s’appuient sur des mécanismes automatiques de rémunération qui peuvent s’avérer très fragiles et exploitables par des attaquants.

Juste en dessus de cette couche algorithmique, les smart contracts, ou chaincodes, ou contrats intelligents, sont souvent déployés dans la blockchain. C’est grâce à ces chaincodes qu’il est possible de créer des règles d’écriture et lecture dans le registre, comme par exemple des validations ou des calculs sur les données. Les chaincodes, eux aussi, peuvent être source de vulnérabilités potentielles.

Enfin, il ne faut pas oublier que la blockchain est souvent intégrée dans un système plus large, en interaction avec des composantes extérieures (des capteurs, des bases de données, des interfaces utilisateurs, etc.). Il faut donc garantir une sécurité de bout en bout qui inclut les flux des données et actions vers la blockchain (par exemple l’appel d’un « chaincode ») et éventuellement les actions prises sur la base du contenu enregistré dans la blockchain.

Téléchargez gratuitement le Livre Blanc : Blockchain, Myth or Reality, du Pôle Systematic ici.

Garantir la sécurité de la blockchain

Les algorithmes de consensus

La tension entre sécurité et scalabilité : le théorème CAP

Le stockage d’information dans un système distribué quelconque, et donc aussi dans une blockchain, est sujet à des limitations fondamentales, connues sous le nom de « théorème CAP » : il est impossible de garantir à la fois la cohérence (C) et la disponibilité (A) des données au fil du temps dans un réseau partitionable (P). Les propriétés de sécurité que les blockchains souhaitent assurer sur un réseau dont on se méfie car non sécurisé (engageant donc cohérence et résistance aux partitions) sont obtenues aux dépens de la disponibilité d’une information récente qui a été objet d’accord, ou « consensus », par l’ensemble du système.

Dans une blockchain, faute d’une autorité centrale qui détermine l’état correct, le consensus est déterminé de façon distribuée par application de techniques probabilistes (telles que PoW) pour l’élection d’un nœud, qui sera responsable pendant un temps limité de l’évolution de l’état du système (typiquement, pour la durée d’un seul bloc). La nature probabiliste de cette sélection donne également lieu à la création de divergences (ou « forks ») dans l’histoire de l’état, qui doivent être résolues de façon univoque pour qu’un consensus stable soit rapidement achevé. Par exemple, les systèmes utilisant PoW considèrent la longueur de la chaine pour décider : la chaine la plus longue, qui correspond aux transactions validées (avec haute probabilité) par la majorité de la capacité de calcul du système, définit à tout moment l’état du consensus. La convergence de ce procèssus nécessite un temps de latence important : ce dernier ne peut pas être réduit au-delà d’un certain seuil en accélérant la fréquence de génération des blocs, car cela engendrerait une augmentation de l’occurrence des forks. Cette limitation fondamentale découle du théorème CAP et constitue donc un obstacle à la scalabilité des blockchains.

Compte tenu de ces limitations, on peut constater que la recherche de mécanismes alternatifs à la PoW et nouvelles stratégies de sélection est en plein essor (cf. PoeT, Ghost, etc. ), toutefois la relation entre sécurité et scalabilité dans des réseaux ouverts est loin d’être comprise d’un point de vue théorique. Entretemps des solutions optimisant les liens de confiance qui vont naturellement s’établir dans le réseau, émergent. C’est l’idée des side-channels : “des autoroutes” à haute vitesse entre deux participants qui se reconnaissent un certain niveau de confiance et qui interagissent avec la blockchain uniquement à la création et à la clôture du side channel.

La blockchain comme infrastructure mutualisée: les incitations et la résilience

Un système distribué tel qu’une blockchain publique demande la participation d’un grand nombre d’acteurs pour fournir des propriétés de sécurité adéquates à la sauvegarde de l’intégrité des données conservées par le registre (ledger). On a vu (voir l’article sur le panorama des applications) que l’utilisation de PoW en tant que mécanisme de sécurisation d’une blockchain telle que Bitcoin résulte en une consommation énergétique importante, dont le coût est absorbé entièrement par les mineurs. Il est donc nécessaire de récompenser les mineurs pour le travail accompli en les incitant à exécuter les calculs sur lesquels la sécurité de la blockchain repose. Mais comment ?

Les blockchains publiques supportant des crypto-monnaies octroient une récompense aux mineurs qui trouvent une solution valable aux puzzles PoW. Ce système est en principe très intéressant car il compense l’effort fourni par le mineur avec une récompense proportionnée à sa contribution (fair share). Il a aussi le but d’introduire dans le système une quantité de crypto-monnaie totale connue à un rythme contrôlé, favorisant une croissance harmonieuse de la base des usagers et du nombre des mineurs au cours du temps. Une deuxième modalité de récompense est assurée par les transaction fees, dont chaque usager qui génère une transaction doit s’acquitter au bénéfice du mineur qui l’accepte et enregistre dans un bloc. Ce deuxième mécanisme est censé prendre le relais du financement des mineurs quand la blockchain aura atteint une dimension importante et arrêté de générer de la cryptomonnaie.

Pourtant, dans la pratique, plusieurs attaques existent qui manipulent directement ou indirectement le mécanisme de récompense, donnant d’injustes avantages aux mineurs de large taille aux frais des petits mineurs. Si la sécurité de Bitcoin était censée initialement être compromise par une attaque de type « 50%+1 », on reconnait aujourd’hui que la taille critique (en termes de puissance de calcul) d’un acteur malveillant qui souhaiterait manipuler le système d’incitation en sa faveur pourrait être bien moins large : on estime ce seuil critique pour lancer une attaque connue comme « selfish mining » à 30% ou moins [3]. D’autres travaux concluent que tout arbitrage dont les mineurs jouissent, tel que le choix des transactions qui rentrent dans un bloc de la blockchain, permet de manipuler le comportement des autres mineurs [4]. Et comme la valeur intrinsèque d’une unité de crypto-monnaie est difficile à estimer et sujette à une forte spéculation, tout phénomène de ‘bulle’ de prix de marché risque à la fois d’intensifier l’engagement des mineurs, en augmentant la consommation totale d’énergie, et de décourager l’utilisation de la cryptomonnaie pour exécuter des transactions légitimes, que ce soit par des frais élevés [5, 6] ou par une volatilité des prix accrue. Ceci tout en attisant la vigueur des attaques contre le système, qui risquent à tout moment de pulvériser la confiance des utilisateurs et des mineurs si une faille sérieuse au niveau des algorithmes ou des protocoles était soudainement exploitée.

Ces conclusions nous font réfléchir sur les risques de sécurité des blockchains publiques et sur les limites de la résilience des cryptomonnaies en tant que systèmes distribués d’un nouveau genre, évoluant dans un contexte économique complexe, étant cible d’attaques à l’échelle mondiale et dépendant absolument, pour leur survie, de la confiance d’une population hétérogène d’acteurs techniques, politiques et économiques aux intérêts mutuellement incompatibles. La recherche de modèles d’incitation alternatifs pour les blockchains publiques est donc en plein effervescence pour les applications industrielles aux ambitions plus contenues. Une piste intéressante est représentée par des modèles économiques spécifiques à l’application elle-même qui, en combinaison avec les incitations pour d’autres activités que le mining, pourrait mener à des déploiements de blockchains publiques durables et résilientes.

Les chaincodes

Les smarts contractes,  ou chaincodes sont des programmes informatiques exécutés dans la blokchain. Leur particularité est d’être immuables une fois déployés. En effet un “smart contract” une fois inséré dans un bloc ne pourra plus être modifié ni supprimé, devenant la “loi” pour la communauté qui l’utilise (code-is-law). Cette propriété engendre des problèmes de sécurité importants, car un smart contract mal codé pourrait être vulnérable à des attaques informatiques. Cela a été le cas pour le célèbre “theDAO” qui a été attaqué en causant la perte d’un somme de crytpomonnaie considérable. Si la correction des smart contracts est donc un verrou majeur, il est important de souligner que la plupart des attaques ont été causées par des bogues ou des vulnérabilités de la plate-forme d’exécution [7]. La question de la sécurité des smart contracts est d’autant plus importante que les applications industrielles seront encodées sous formes de nombreux smart-contracts. La question de la sécurité des plateformes disponibles aujourd’hui, pour la plupart en open-source, reste ouverte. Pour aller au-delà d’une preuve de concept, il sera opportun de considérer le développement des smart contracts avec des précautions similaires à celles que l’on prend pour le développement des codes critiques.  Une plateforme pour des applications critiques aurait d’un point de vue technique besoin d’un langage d’entrée vérifiable ainsi que d’une chaîne de compilation prouvée et d’un environnement d’exécution sécurisé. Du point de vue de la gouvernance, il est important de noter qu’une telle plateforme aurait vocation à être partagée par une communauté.  Elle aurait besoin donc de règles pour la gestion du logiciel (règles de codage, debugging, test, vérification, etc.) qui doivent être connues et partagées par les utilisateurs.  Ces mêmes règles pourraient être gerées par des smart contract sécurisés menant à des communautés open-source organisés par des DAO.

La blockchain et le monde autour : comment sécuriser les interactions ?

La technologie blockchain est un « simple » composant d’un système, d’une application, ou  d’un service, tout comme une base de données dans une application métier. Elle fournit des propriétés de sécurité, mais les vulnérabilités et les risques doivent également être évalués…

Découvrez le Groupe Thématique Confiance Numérique, Sécurité & Défense du Pôle Systematic Paris-Region

Tel que décrit par le groupe Sécurité du comité ISO TC307, il existe plusieurs propriétés de sécurité fournies par les systèmes blockhain, appelés dans le contexte de l’ISO TC307 DLTs (Distributed Ledger Technologies). Ce qui suit est une liste de ces propriétés de sécurité. Certaines d’entre elles sont des propriétés de sécurité communes à toutes les applications basées sur DLT tandis que d’autres sont facultatives et dépendent de la nature de l’application. Cette liste est provisoire et est susceptible de changer :

  • Intégrité : les enregistrements dans le ledger sont protégés contre toute modification après leur création. Aussi connu comme l’immutabilité ou la résistance à l’altération.
  • Authenticité: toute personne (ou un ensemble certifié d’entités) peut vérifier l’entité qui crée une transaction enregistrée dans le registre.
  • Confidentialité : les enregistrements dans le registre ne peuvent être consultés que par une entité autorisée.
  • Ordre des événements : l’ordre des enregistrements dans le ledger ne peut pas être modifié.
  • Disponibilité : les transactions enregistrées dans le ledger et la fonctionnalité pour enregistrer et récupérer les données sont toujours disponibles pour les utilisateurs.
  • Résilience : le système DLT continue de fonctionner comme prévu en cas d’échecs et d’autres incidents. C’est une sorte d’exigence de disponibilité.
  • « Trusted-server less » : même s’il n’y a pas d’entité / serveur de confiance, la Blockchain / DLT continue de fonctionner comme prévu.
  • Assurance à long terme : certains cas d’utilisation (par exemple les registres fonciers) impliquent un maintien à long terme du grand livre et un transfert en toute sécurité de ses dossiers à un autre système en cas de déclassement.

Les risques liés aux composants qui interagissent avec une blockchain telles que des personnes physiques ou morales qui utilisent des interfaces, des applications, des objets intelligents comme des compteurs électriques ou des capteurs, sont multiples. Il faut par exemple que tous ces composants aient un identifiant unique et sécurisé sur la blokchain afind’éviter toute usurpation d’identité, et de pouvoir associer une responsabilité à une action dans la blockchain.

Les risques liés aux données doivent également être analysés. Comment s’assurer par exemple qu’une transaction soumise au système sera bien validée et qu’il n’y a pas eu d’altération des données par un smart contact, ou le système lui-même ? L’intégrité des données injectées et manipulées est un point clef de la blockchain. Comment respecter des cas d’usage ou des régulations en place qui exigent une confidentialité des données, comme les données personnelles ?

Du point de vue de la norme ISO, les risques et les vulnérabilités des systèmes DLT comprennent des risques et vulnérabilités communs aux systèmes d’information tels que :

  1. Mauvaise gestion de l’information (altération / suppression / destruction non autorisée /divulgation, etc.).
  2. Vulnérabilités de mise en œuvre (y compris les mécanismes cryptographiques, vulnérabilités de mise en œuvre, fuites d’informations au moment de l’exécution, etc.).
  3. Mauvaise gestion des mécanismes cryptographiques (y compris l’utilisation d’algorithmes faibles, la divulgation clé)
  4. Mauvaise gestion des privilèges de l’utilisateur

Il existe également des vulnérabilités spécifiques pour différents types de DLT. Une liste en est fournie à l’Annexe E du rapport technique « Distributed Ledger Technology: Security and Privacy » produit par TC307/WG2.

A noter que l’authentification des acteurs, des ressources accessibles ainsi que l’implémentation des politiques d’accès est un point clè qui sera detaillé par la suite.

L’accès contrôlé aux ressources

Quand une unique organisation veut contrôler l’accès à ses ressources, elle met en place un système d’authentification et d’autorisation centralisé. Lorsque plusieurs organisations veulent partager entre elles des ressources, le problème de la gestion de l’ensemble des identités et des règles de contrôle d’accès partagées se pose. Traditionnellement, ce problème est traité en confiant cette gestion à un unique acteur (interne ou externe) de sécurité ou en utilisant des mécanismes de fédération d’identité. Mais ces mécanismes nécessitent la mise en œuvre de relations de confiance souvent difficiles voire impossible entre ces organisations. Une autre façon de résoudre ce problème est d’utiliser la Blockchain elle-même pour gérer les identités et les règles de contrôle d’accès aux ressources.

Un contrôle d’accès basé sur la blockchain permet d’établir la confiance entre des organisations différentes et de partager de l’information tout en conservant le contrôle de cette information sans pour autant recourir à un unique acteur de sécurité. L’information partagée peut alors être les attributs d’identité pour les utilisateurs et les règles d’accès pour gérer les autorisations sur les ressources. Pour prendre en compte l’hétérogénéité des utilisateurs et des ressources, il apparait pertinent de gérer les autorisations au moyen de l’approche ABAC[1], cette approche utilise des règles prenant en compte les attributs de l’utilisateur demandant l’accès ainsi que l’environnement lié à la requête (lieu, date, heure, etc., …). Elle offre ainsi une grande flexibilité pour gérer finement les accès et prendre en compte des utilisateurs et des ressources dynamiquement, c’est-à-dire qui n’auraient pas été pré-déclarées auparavant (seuls leurs attributs sont utilisés).

Afin d’établir un mécanisme de contrôle d’accès via BlockChain pour les applications énergétiques,  il faut définir les deux étapes suivantes :

  • La première étape consiste à enregistrer chaque nouvel acteur (utilisateur ou ressource) dans la BlockChain via des contrats intelligents.
  • La deuxième étape concerne la demande d’accès à la ressource elle-même, gérée par la Blockchain.

Dans la première étape, chaque acteur, géré par la BlockChain, doit créer ou établir un contrat intelligent pour s’enregistrer. Dans ce contrat intelligent, plusieurs informations seront spécifiées à savoir l’identité de l’acteur (par exemple le fournisseur d’énergie), ses attributs (au sens ABAC) et les règles d’accès dans le cas d’une ressource, ainsi qu’une signature numérique afin de s’assurer de l’authenticité des données dans ce contrat intelligent. Cette étape nécessite la création d’une transaction à chaque fois qu’un acteur doit rejoindre le réseau ou mettra à jour ses informations d’identité. Dans la deuxième étape, l’entité se voit autoriser l’accès une fois vérifiés ses attributs et les règles d’accès. En termes de coût en termes de transactions, seulement la première étape nécessite la création d’une transaction; alors que la deuxième étape ne n’en nécessite aucune.

Ce mécanisme bénéficie  des avantages combinés de la technologie BlockChain et de l’approche ABAC : premièrement,  les entités n’ont pas besoin de se connaître et leur confiance est établie au moyen de la blockchain, deuxièmement, il fournit une autorisation précise et offre une méthode très flexible pour fournir un accès basé sur l’évaluation des attributs.

La blockchain et sa gouvernance : quelles recommandations des organismes de standardisation ?

L’objectif principal de la gouvernance dans les réseaux blockchain est d’améliorer la confiance entre les différents membres d’une blockchain. Bien que les blockchains soient souvent qualifiées de «réseaux sans confiance» en raison du fait que les transactions sont gérées par le système, en réalité, la confiance est un facteur critique dans le succès d’une blockchain. Au lieu de faire confiance aux lois et aux institutions, les utilisateurs doivent faire confiance aux parties prenantes, aux programmeurs et à ceux qui sont techniquement qualifiés pour vérifier le code de la blockchain et des smart contracts. Il faut donc s’assurer que les utilisateurs et les fournisseurs de services blockchain sont d’accord sur les termes et conditions. Une blockchain sans gouvernance est peu susceptible d’atteindre ses objectifs commerciaux à long terme. Il faut être capable de répondre efficacement aux menaces.

L’ISO, l’organisme international de normalisation, a créé en 2016 un Comité Technique pour standardiser les technologies de la blockchain [2] dont un sous-groupe sur la gouvernance (SG06). Les principales missions de ce sous-groupe sont entre autre de répondre à des questions comme :

  • Les rôles et les droits de gouvernance pour différentes entités dans chaque état d’un système blockchain.
  • Le cycle de vie de la blockchain vue en tant que système multicouches comportant de manière ascendante une couche matérielle “infrastructure” soutenant une couche de données, sur laquelle s’appuie une couche “business” qui sous-tend une couche “orchestration”.
  • Le risque et la conformité dans les systèmes DLT autorisé et permissif.
  • Une liste d’exigences minimales qui garantit une interopérabilité entre des systèmes blockchain.

La gouvernance devra traiter de manière agnostique le système complexe et multidisciplinaire de la blockchain sans interférence avec des choix technologiques prédéterminés. En effet certaines technologies existantes comme par exemple le Cloud, pourraient avoir tendance par nature à considérer la blockchain comme une simple « customisation » du Cloud, réutilisant ainsi le Cloud pour gérer le livre des comptes, le smart contract et le stockage des données “off-chain”, contredisant ainsi le paradigme de la blockchain présumant la décentralisation et l’absence de tiers de confiance. La gouvernance devra au contraire, par ses préconisations  organisationnelles, légales, économiques et techniques, servir d’aide à la décision pour un choix pertinent de moyens de déploiement. Elle doit fournir à la fois :

  • un instrument pour les décideurs, leur montrant quand et comment la blockchain est la solution appropriée lorsque d’autres technologies préexistantes pourraient donner le sentiment de réaliser les mêmes objectifs, et
  • les éléments de base d’une approche d’audit permettant de qualifier les traitements de données effectués par la blockchain (qualité de transactions, références “off-chain”, analyse formelle du déroulement du smart contract, interrelations entre chaines distinctes), d’en vérifier la cohérence logique, par-delà le simple souci d’intégrité.

La gouvernance permet ainsi de dresser la charte du projet utilisant la blockchain.

La gouvernance devra également, selon son champ d’application, tenir compte des Régulations (ex. GDPR, ePrivacy, AML4D, NIS, eIDAS) et des aspects juridictionnels en vigueur susceptibles d’ entraver significativement le deploiement de la blockchain.

Comme la blockchain est synonyme de décentralisation, la gouvernance devra aussi éclairer les précautions d’usage lorsque les identités décentralisées sont mises œuvre; il s’agit ici d’identités d’objets connectés, de leurs propriétaires en tant que personnes physiques ou morales, ou de données personnelles d’identification pointées par ou enregistrées avec les transactions.

Enfin, un des aspects clé de la gouvernance est de décortiquer le choix de la preuve qui, largement dévoyée par le choix originel du Bitcoin (minage par preuve de travail ou “PoW”), peut en fait recouvrir une diversité de modèles de preuve. Ces modèles, qui devront a minima être moins énergivores, devront être analysés à l’aune de la gouvernance pour en évaluer la fiabilité (en matière de responsabilités des parties prenantes), le temps d’exécution (rapidité de validation des transactions), les risques de collusions (entre valideurs), et la nature de la rémunération en incitation virtuelle par crypto-monnaie quand celle-ci intervient.

Le sous-groupe SG06 au sein du comité ISO TC307 a entrepris de traiter de toutes ces questions de gouvernance et délivrera sa proposition en mai 2018 pour démarrer un projet de norme. Au niveau européen, un nouveau groupe de discussion (EU Focus Group on blockchain) a été établi très récemment sous l’égide du CEN/CENELEC et recommande la gouvernance dans ses termes de référence.

Conclusions

La blockchain favorisera la mise en œuvre de nouvelles applications décentralisées en permettant une collaboration entre acteurs qui, en principe, ne se font pas confiance. Toutefois, pour le déploiement à grande échelle de telles applications, des questions de R&D et de gouvernance restent à traiter, comme indiqué dans cet article. La spécificité de la technologie et des sujets à traiter montre que ce n’est que grâce à l’effort conjoint des scientifiques, des développeurs, des organismes de normalisation et des acteurs industriels que l’on pourra dans quelques années réaliser un déploiement industriel de la blockchain.

 

Les auteurs

Sara Tucci-Piergiovanni est chef du laboratoire systèmes d’Information de Confiance, Intelligents et Auto-organiants (LICIA),  expert senior et coordinateur du programme Block-Chain du Commissariat à l’Energie Atomique et Energies Alternatives, Institut CEA LIST, Saclay, France. Elle est une experte internationale dans le domaine des systèmes critiques distribués, à ce titre elle publie régulièrement dans des conférences internationales et des revues de premier plan dans le domaine. Elle a également coordonné et dirigé plusieurs projets industriels axés sur l’ingénierie système.

Wafa Ben Jaballah est chercheur en sécurité à THALES dans le laboratoire Cyber Sécurité. Ses thématiques de recherches sont liées à la sécurité des systèmes distribués, sécurité IoT et véhicules connectés. Elle est docteur de l’université de Bordeaux sur la sécurité des réseaux de capteurs et véhiculaires. Après sa thèse, elle a fait un post-doctorat au Laboratoire Bordelais de Recherche en Informatique sur la sécurité des algorithmes distribués avec l’équipe Algorithmique Distribuée, puis  l’équipe sécurité réseaux d’Orange Labs pour travailler sur la sécurité des applications Web.

Sébastien Keller est docteur en Génie électrique de l’université de Nancy. A la suite de son doctorat, il a intégré le groupe Thales où il a travaillé en développement logiciel et en sécurité informatique pendant près de 15 ans. Aujourd’hui, il gère des thématiques de R&D autour de l’IoT et  la Blockchain dans le laboratoire de Cyber Sécurité de Thales depuis 5 ans.

Mourad Faher intervient comme Expert en Normalisation auprès de la Société Gemalto depuis 18 ans, et a exercé des fonctions d’ingénieur développement auparavant notamment dans les domaines client/server, services mobiles, STK (SIMtoolkit). Il est éditeur et coéditeur de plusieurs standards ISO (SC17 WG4), CEN/CENELEC (TC224) et GlobalPlatform (Privacy Framework) dans le secteur des cartes à circuits intégrés servant à l’identité numérique, la sécurité, la protection des données personnelles (privacy) et les services.  Participant aux travaux du comité technique ISO TC307 en charge de la normalisation de la blockchain, il y a initié la création d’un nouveau groupe de travail sur la Gouvernance (SG06).

Nicolas Chalvin occupe actuellement le poste de VP IoT Solutions & Services. Il est en charge de la définition et de l’implémentation de la stratégie de l’offre Services et Produits pour les segments de marché « Industriel IoT » chez Gemalto. Travaillant pour Gemalto depuis plus de 15 ans, il a occupé différents postes Marketing dans le domaine « Machine To Machine » et des Télécoms, notamment comme Directeur Marketing opérationnel pour l’Europe. Nicolas Chalvin est titulaire d’un diplôme d’ingénieur de Polytech Grenoble et d’un Master en Gestion des Entreprises de l’IAE de Grenoble.

Fabio Pianese est responsable de l’équipe de recherche en Réseaux, Protocoles et Systèmes chez Nokia Bell Labs, Paris-Saclay. Il est titulaire d’un doctorat de recherche en sciences (informatique) de l’Université de Nice – Sophia Antipolis, ancien étudiant EURECOM et ingénieur diplômé du Politecnico di Torino. Il est membre IEEE et membre associé du LINCS (Laboratory of Information, Networking and Communication Sciences) à Paris. Ses intérêts de recherche incluent les réseaux et systèmes informatiques, l’algorithmique distribuée et la sécurité des réseaux.

 

Références :

  1. V. C. Hu, D. R. Kuhn and D. F. Ferraiolo, “Attribute-Based Access Control,” in Computer, vol. 48, no. 2, pp. 85-88, Feb. 2015.
  2.  ISO/TC 307 – Blockchain and distributed ledger technologies – https://www.iso.org/committee/6266604.html
  3. Aggelos Kiayias Elias Koutsoupias Maria Kyropoulou Yiannis Tselekounis. Blockchain Mining Games. Proceedings of the 2016 ACM Conference on Economics and Computation, EC ’16, Maastricht, The Netherlands, July 24-28, 2016
  4. Carlsten, M., Kalodner, H., Weinberg, S.M., Narayanan, A.: On the instability of bitcoin without the block reward. In: Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security. pp. 154–167. ACM (2016)
  5. F. Pianese, M. Signorini, and S. Sarkar “Small Transactions with Sustainable Incentives” under submission in the 1st Blockchains and Smart Contracts workshop (BSC), co-located with NTMS 2018
  6. Önder Gürcan, Antonella Del Pozzo, Sara Tucci-Piergiovanni.  On the Bitcoin Limitations to Deliver Fairness to Users. In: Panetto H. et al. (eds) On the Move to Meaningful Internet Systems. OTM 2017 Conferences. OTM 2017. Lecture Notes in Computer Science, vol 10573. Springer.
  7. N. Atzei, M. Bartoletti, and T. Cimoli. A survey of attacks on ethereum smart contracts sok. In Conference on Principles of Security and Trust – Volume 10204, New York, USA, 2017.

Retrouvez 3 articles du dossier blockchain en ligne ci-dessous :

Retrouvez l’intégralité du dossier : Blockchain et ses applications au domaine de l’énergie dans la revue REE du mois de mai 2018.