Blockchain et sécurité - La blockchain et ses vulnérabilités, comment aller au-delà ?

12/05/2018
OAI : oai:www.see.asso.fr:1301:2018-2:22884
contenu protégé  Document accessible sous conditions - vous devez vous connecter ou vous enregistrer pour accéder à ou acquérir ce document.
Prix : 10,00 € TVA 20,0% comprise (8,33 € hors TVA) - Accès libre pour les ayants-droit
 

Résumé

Blockchain et sécurité - La blockchain et ses vulnérabilités, comment aller au-delà ?

Métriques

2
0
219.37 Ko
 application/pdf
bitcache://eaeecc82e9892f5af05bedb2baa1645714f144f5

Licence

Creative Commons Aucune (Tous droits réservés)
<resource  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                xmlns="http://datacite.org/schema/kernel-4"
                xsi:schemaLocation="http://datacite.org/schema/kernel-4 http://schema.datacite.org/meta/kernel-4/metadata.xsd">
        <identifier identifierType="DOI">10.23723/1301:2018-2/22884</identifier><creators><creator><creatorName>Sara Tucci</creatorName></creator><creator><creatorName>Wafa Ben Jaballah</creatorName></creator><creator><creatorName>Nicolas Chalvin</creatorName></creator><creator><creatorName>Sebastien Keller</creatorName></creator><creator><creatorName>Mourad Faher</creatorName></creator><creator><creatorName>Fabio Pianese</creatorName></creator></creators><titles>
            <title>Blockchain et sécurité - La blockchain et ses vulnérabilités, comment aller au-delà ?</title></titles>
        <publisher>SEE</publisher>
        <publicationYear>2018</publicationYear>
        <resourceType resourceTypeGeneral="Text">Text</resourceType><dates>
	    <date dateType="Created">Sat 12 May 2018</date>
	    <date dateType="Updated">Sun 15 Jul 2018</date>
            <date dateType="Submitted">Mon 20 Aug 2018</date>
	</dates>
        <alternateIdentifiers>
	    <alternateIdentifier alternateIdentifierType="bitstream">eaeecc82e9892f5af05bedb2baa1645714f144f5</alternateIdentifier>
	</alternateIdentifiers>
        <formats>
	    <format>application/pdf</format>
	</formats>
	<version>37948</version>
        <descriptions>
            <description descriptionType="Abstract"></description>
        </descriptions>
    </resource>
.

REE N°2/2018 Z87 LA BLOCKCHAIN ET L’ÉNERGIE DOSSIER 1 Introduction Les blockchains ont comme objectif premier la sécurisation des données dans un registre partagé, c’est-à-dire d’assurer l’intégrité et la disponibilité des données échangées dans un envi- ronnent 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 dis- tribué. Dans un réseau public ces algo- rithmes s’appuient sur des mécanismes automatiques de rémunération qui peuvent s’avérer très fragiles et exploi- tables par des attaquants. Juste en-dessus de cette couche algorithmique, des smart contracts, ou chaincodes, ou contrats intelligents, sont souvent déployés dans la block- chain. C’est grâce à ces chaincodes qu’il est possible de créer des règles d’écriture et de lecture dans le registre, comme par exemple des validations ou des calculs sur les données. Les chain- codes, eux aussi, peuvent être sources 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 Blockchain et cybersécurité La blockchain et ses vulnérabilités, comment aller au-delà ? Wafa Ben Jaballah1 , Nicolas Chalvin2 , Sebastien Keller3 , Mourad Faher4 , Fabio Pianese5 , Sara Tucci6 1 Chercheur – Thales, 2 VP IoT Solutions & Services – Gemalto, 3 Chef de projet R&T – Thales, 4 Expert normalisation – Gemalto, 5 Responsable de l’équipe de recherche en Réseaux, Protocoles et Systèmes – Nokia Bell Labs, 6 Chef de Laboratoire – CEA, Institut LIST This article presents the technical locks to imple- ment so that the blockchain can guarantee a level of security adapted to industrial applications. Indeed, if the blockchain represents an original solution to the ques- tion of securing data in an open environment — and its most famous implementation, Bitcoin, continues to flourish — many questions remain open, as to its intrinsic operation (mechanisms of consensus, incentives, chaincodes, etc.) and its interaction with the environment (sensors, data- bases, user interfaces, etc.). Particular attention will be paid to research topics that re- main open by presenting the recommendations of standar- dization bodies. ABSTRACT Cet article présente les verrous techniques à poser en matière de cybersécurité pour que la blockchain puisse garantir un niveau de sécurité adapté aux applications industrielles. En effet si la blockchain repré- sente une solution originale à la question de la sécurisation des données dans un environnent ouvert – et sa concrétisa- tion la plus célèbre, Bitcoin, continue de prospérer – beau- coup de questions restent ouvertes, quant à son fonction- nement intrinsèque (mécanismes de consensus, incitations, chaincodes, etc.) et de son interaction avec l’environnement (capteurs, bases de données, interfaces utilisateurs, etc.). Une attention particulière sera accordée aux thèmes de recherche qui restent ouverts en présentant également les recommandations des organismes de normalisation. RÉSUMÉ Figure 1 : Le système blockchain organisé en couches : consensus, chaincodes et interaction avec l’environnement. 88 ZREE N°2/2018 LA BLOCKCHAIN ET L’ÉNERGIE DOSSIER 1 garantir la sécurité de bout en bout, ce 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. Dans cet article, on présente un pa- norama des questions de sécurité des technologies blockchain en considérant le système blockchain organisé en dif- férentes couches (figure 1). On partira donc des algorithmes sous-jacents à la gestion des données jusqu’à traiter la blockchain dans un contexte d’utilisation plus large en incluant également les re- commandations issues des organismes de standardisation. 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 dispo- nibilité 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 tech- niques probabilistes (telles que PoW) permettant l’élection d’un nœud, qui sera responsable, pendant un temps li- mité, 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 lieu à la création de di- vergences (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 chaîne pour décider : la chaîne la plus longue, qui correspond aux transactions validées (avec haute probabilité) par la majorité de la capa- cité de calcul du système, définit à tout moment l’état du consensus. La conver- gence de ce processus nécessite un temps de latence important : ce dernier ne peut pas être réduit au-delà d’un cer- tain seuil en accélérant la fréquence de génération des blocs, car cela engendre- rait 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 de 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 op- timisant les liens de confiance qui vont naturellement s’établir dans le réseau, émergent. C’est l’idée des side-chan- nels : “des autoroutes” à haute vitesse entre deux participants qui se recon- naissent 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 infrastruc- ture mutualisée : les incitations et la résilience Un système distribué tel qu’une block- chain 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 le panorama des applications de Gilles Deleuze et Sara Tucci) que l’utilisa- tion de PoW en tant que mécanisme de sécurisation d’une blockchain telle que Bitcoin se traduit par 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 suppor- tant des cryptomonnaies octroient une récompense aux mineurs qui trouvent une solution valable aux puzzles PoW. Ce système est en principe très intéres- sant car il compense l’effort fourni par le mineur sous forme d’une récompense proportionnée à sa contribution (fair share). Il a aussi pour but d’introduire dans le système une quantité de cryp- tomonnaie totale connue à un rythme contrôlé, favorisant ainsi 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 tran- saction fees, dont chaque usager qui génère une transaction doit s’acquitter, au bénéfice du mineur qui accepte cette transaction et l’enregistre dans un bloc. Ce deuxième mécanisme est censé prendre le relais du financement des mi- neurs 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 direc- tement 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 reconnaît aujourd’hui que la taille critique (en termes de puissance REE N°2/2018 Z 89 Blockchain et cybersécurité de calcul) d’un acteur malveillant qui souhaiterait manipuler le système d’in- citation 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 arbi- trage 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 intrin- sèque d’une unité de cryptomonnaie est difficile à estimer et sujette à une forte spéculation (figure 2), tout phénomène de « bulle » de prix de marché risque à la fois d’intensifier l’engagement des mineurs, en augmentant la consomma- tion 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 ni- veau des algorithmes ou des protocoles était soudainement exploitée. Ces conclusions nous font réfléchir sur les risques de sécurité des block- chains 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 écono- mique complexe, étant cibles d’attaques à l’échelle mondiale et dépendant abso- lument, pour leur survie, de la confiance d’une population hétérogène d’acteurs techniques, politiques et économiques aux intérêts mutuellement incompa- tibles. La recherche de modèles d’inci- tation alternatifs pour les blockchains publiques est donc en pleine efferves- cence 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 combi- naison avec les incitations pour d’autres activités que le mining, pourrait mener à des déploiements de blockchains pu- bliques durables et résilientes. Les chaincodes Les smarts contracts ou chaincodes sont des programmes informatiques exécutés dans la blockchain. Leur par- ticularité 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 informa- tiques. Cela a été le cas pour le célèbre “theDAO” qui a été attaqué en causant la perte d’une somme de cryptomon- naie considérable. Si la correction des smart contracts est donc un verrou ma- jeur, 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 ques- tion de la sécurité des smart contracts est d’autant plus importante que les applications industrielles seront enco- dées sous forme de nombreux smart- contracts. La question de la sécurité des plates-formes, disponibles aujourd’hui pour la plupart en open-source, reste ouverte. Pour aller au-delà d’une preuve de concept, il sera opportun de consi- dérer le développement des smart contracts avec des précautions simi- Figure 2 : Prix moyen du marché sur les principaux échanges de bitcoins, en USD – Source : Blockchain.info. 90 ZREE N°2/2018 LA BLOCKCHAIN ET L’ÉNERGIE DOSSIER 1 laires à celles que l’on prend pour le développement des codes critiques. Une plate-forme pour des applications critiques aurait d’un point de vue tech- nique besoin d’un langage d’entrée vérifiable ainsi que d’une chaîne de compilation prouvée et d’un environne- ment d’exécution sécurisé. Du point de vue de la gouvernance, il est important de noter qu’une telle plate-forme aurait vocation à être partagée par une com- munauté. Elle aurait donc besoin de règles pour la gestion du logiciel (règles de codage, debugging, test, vérification, etc.) qui doivent être connues et par- tagées par les utilisateurs. Ces mêmes règles pourraient être gérées par des smart contracts sécurisés menant à des communautés open-source organisées 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 offre des proprié- tés de sécurité, mais les vulnérabilités et les risques doivent également être éva- lués. Tel que décrit par le groupe Sécurité du comité ISO TC307, il existe plu- sieurs propriétés de sécurité fournies par les systèmes blockchain, appelées, 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 suscep- tible de changer : s intégrité : les enregistrements dans le registre (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 ; s 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 ; s confidentialité : les enregistrements dans le registre ne peuvent être consul- tés que par une entité autorisée ; s ordre des événements : l’ordre des enregistrements dans le registre ne peut pas être modifié ; s disponibilité : les transactions enre- gistrées dans le registre et la fonction- nalité pour enregistrer et récupérer les données sont toujours disponibles pour les utilisateurs ; s 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é ; s “Trusted-server less” : même s’il n’y a pas d’entité/serveur de confiance, la blockchain/DLT continue de fonction- ner comme prévu. s assurance à long terme : certains cas d’utilisation (par exemple les registres fonciers) impliquent un maintien à long terme du registre 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 mo- rales qui utilisent des interfaces, des ap- plications, des objets intelligents comme des compteurs électriques ou des cap- teurs, sont multiples. Il faut par exemple que tous ces composants aient un identi- fiant unique et sécurisé sur la blockchain afin d’é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 transac- tion soumise au système sera bien vali- dée et qu’il n’y a pas eu d’altération des données par un smart contract ou par 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égu- lations en place qui exigent une confi- dentialité des données, comme les données personnelles ? Du point de vue de la norme ISO, les risques et les vulnérabilités des sys- tèmes DLT comprennent des risques et vulnérabilités communs aux systèmes d’information tels que : 1. mauvaise gestion de l’information (al- tération/suppression/destruction non autorisée/divulgation, etc.) ; 2. vulnérabilités de mise en œuvre (y compris les mécanismes cryptogra- phiques, les fuites d’informations au moment de l’exécution, etc.). 3. mauvaise gestion des mécanismes cryptographiques (y compris l’utilisa- tion d’algorithmes faibles, la divulga- tion de 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 dans l’annexe E du rapport technique “Distributed Ledger Technology: Security and Privacy” pro- duit 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 détaillé 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’authentifica- tion et d’autorisation centralisé. Lorsque plusieurs organisations veulent partager entre elles des ressources, le problème de la gestion de l’ensemble des iden- tité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 de sécuri- REE N°2/2018 Z 91 Blockchain et cybersécurité té (interne ou externe) ou en utilisant des mécanismes de fédération d’iden- tité. Mais ces mécanismes nécessitent la mise en œuvre de relations de confiance souvent difficiles, voire im- possibles, 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 block- chain permet d’établir la confiance entre des organisations différentes et de par- tager 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 apparaît pertinent de gérer les autori- sations au moyen de l’approche ABAC. Cette approche [1] utilise des règles prenant en compte les attributs de l’utili- sateur demandant l’accès ainsi que l’en- vironnement 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 attri- buts sont utilisés). Afin d’établir un mécanisme de con- trôle d’accès via la blockchain pour les applications énergétiques (figure 3), il faut définir les deux étapes suivantes : s LAPREMIÒREÏTAPECONSISTEÌENREGIS- trer chaque nouvel acteur (utilisateur ou ressource) dans la blockchain via des contrats intelligents ; s LA DEUXIÒME ÏTAPE CONCERNE LA DE- mande d’accès à la ressource elle- même, gérée par la blockchain. Dans la première étape, chaque ac- teur, géré par la blockchain, doit créer ou établir un contrat intelligent pour s’enregistrer. Dans ce contrat intelligent, plusieurs informations seront spéci- fié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, ain- si 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 informa- tions 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’ac- cès. En termes de coût de transaction, seule la première étape nécessite la création d’une transaction ; alors que la deuxième étape n’en nécessite aucune. Ce mécanisme bénéficie des avan- tages combinés de la technologie blockchain et de l’approche ABAC : pre- mièrement, les entités n’ont pas besoin de se connaître et leur confiance est établie au moyen de la blockchain, deu- xièmement, il fournit une autorisation précise et offre une méthode très flexible pour fournir un accès basé sur l’évalua- tion des attributs. La blockchain et sa gouver- nance : quelles recomman- dations 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 Figure 3 : Utilisateurs et ressources dans les applications énergétiques. 92 ZREE N°2/2018 LA BLOCKCHAIN ET L’ÉNERGIE DOSSIER 1 aux lois et aux institutions, les utilisateurs doivent faire confiance aux parties pre- nantes, aux programmeurs et à ceux qui sont techniquement qualifiés pour véri- fier 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 gou- vernance est peu susceptible d’atteindre ses objectifs commerciaux à long terme. Il faut être capable de répondre efficace- ment aux menaces. L’ISO a créé en 2016 un comité technique pour standardiser les tech- nologies de la blockchain [2] dont un sous-groupe se préoccupe de la gouver- nance (SG06). Les principales missions de ce sous-groupe sont entre autres de répondre aux questions suivantes : s LESRÙLESETLESDROITSDEGOUVERNANCE pour différentes entités dans chaque état d’un système blockchain ; s LECYCLEDEVIEDELABLOCKCHAINVUEEN tant que système multicouches com- portant de manière ascendante une couche matérielle « infrastructure » soutenant une couche de données, sur laquelle s’appuie une couche “bu- siness” qui elle-même sous-tend une couche « orchestration » ; s LERISQUEETLACONFORMITÏDANSLESSYS- tèmes DLT autorisés et permissifs ; s UNE LISTE DEXIGENCES MINIMALES QUI garantit une interopérabilité entre des systèmes blockchain. La gouvernance devra traiter de ma- nière agnostique le système complexe et multidisciplinaire de la blockchain sans interférence avec des choix tech- nologiques prédéterminés. En effet cer- taines technologies existantes comme par exemple le cloud, pourraient avoir tendance par nature à considérer la blockchain comme une simple custo- misation 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 LES AUTEURS Sara Tucci dirige actuellement le Laboratoire Systèmes d’information de confiance, intelligents, auto-organisants (LICIA) au CEA List. Titulaire d’un Master of Science puis d’un PhD en Computer Engineering à l’université La Sapienza de Rome, elle a rejoint le CEA List en 2009 en tant qu’ingénieur de recherches dans le domaine de l’architecture des systèmes embarqués distribués. En 2015, elle devient responsable programmes du département System et Software Enginee- ring où elle crée une équipe spécialisée sur la blockchain, devenue en 2017 le LICIA dont elle prend la responsabilité. Elle est l’auteur de nombreuses publica- tions. 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. Avant de rejoindre Thales, elle était ingénieur de recherche à Orange Labs. Wafa 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 informa- tique, sur la sécurité des systèmes distribués 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ével- oppement logiciel et en sécurité informatique pendant près de 15 ans. Depuis cinq ans, il gère des thématiques de R&D autour de l’IoT et la blockchain dans le laboratoire de cybersécurité de Thales. Mourad Faher intervient comme expert en normalisation auprès de la Société Gemalto depuis 18 ans. Il a auparavant exercé des fonctions d’ingénieur déve- loppement 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 don- nées personnelles 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 le poste de VP IoT Solutions & services chez Gemalto, en charge de la définition et de l’implémentation de la stratégie de l’offre Services et produits pour le segment de marché « Industriel IoT ». Il a occupé différents postes marketing dans les domaines Machine to Machine et Télécoms, notam- ment 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 informatiques 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, Networ- king 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. REE N°2/2018 Z 93 Blockchain et cybersécurité 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 orga- nisationnelles, 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 : s UN INSTRUMENT POUR LES DÏCIDEURS leur montrant quand et comment la blockchain est la solution appropriée lorsque d’autres technologies préexis- tantes pourraient donner le sentiment de réaliser les mêmes objectifs ; s LESÏLÏMENTSDEBASEDUNEAPPROCHE d’audit permettant de qualifier les traitements de données effectués par la blockchain (qualité de transac- tions, références off-chain, analyse formelle du déroulement du smart contract, interrelations entre chaînes distinctes), d’en vérifier la cohérence logique, par-delà le simple souci d’in- té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 (par ex. GDPR, ePrivacy, AML4D, NIS, eIDAS) et des aspects juridictionnels en vigueur sus- ceptibles d’entraver significativement le déploiement de la blockchain. Comme la blockchain est synonyme de décentralisation, la gouvernance de- vra 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’ob- jets connectés, de leurs propriétaires en tant que personnes physiques ou morales, ou de données personnelles d’identification pointées par ou enregis- trées avec les transactions. Enfin, un des aspects-clés de la gou- vernance 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 gouver- nance pour en évaluer la fiabilité (en matière de responsabilités des parties prenantes), le temps d’exécution (rapi- dité de validation des transactions), les risques de collusions entre valideurs et la nature de la rémunération en incita- tion virtuelle par cryptomonnaie quand celle-ci intervient. Le sous-groupe SG06 au sein du co- mité 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 inclut la gouvernance dans ses termes de ré- férence. Conclusions La blockchain favorisera la mise en œuvre de nouvelles applications décen- tralisées en permettant une collabora- tion 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 nor- malisation et des acteurs industriels que l’on pourra dans quelques années réaliser un déploiement industriel de la blockchain. 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 distri- buted ledger technologies – https:// www.iso.org/committee/6266604.html [3] Aggelos Kiayias Elias Koutsoupias Maria Kyropoulou Yiannis Tselekounis. BlockchainMiningGames.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”, Proc. of 1st Blockchains and Smart Contracts workshop (BSC), co-located with NTMS 2018. [6] Önder Gürcan, Antonella Del Pozzo, Sara Tucci-Piergiovanni. On the Bit- coin Limitations to Deliver Fairness to Users. In: Panetto H. et al. (eds) On the Move to Meaningful Internet Systems. OTM 2017 Conferences. OTM2017.LectureNotesinComputer 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.