Sécuriser l' Internet des Objets avec la Blockchain et le hashage

 

Je souhaitais écrire cet article sur les moyens de sécuriser l’Internet des Objets avec la blockchain et le hashage de données. L’objectif est de montrer comment déployer des solutions clés en main pour les fabricants et les entreprises utilisant des objets connectés (banques, assureurs, services à la personne…), les opérateurs télécoms …

 

For English Speakers - Google Translation

 

Pour sécuriser complètement un objet connecté ou une plateforme, il y a trois étapes : prévenir et réduire les risques de hacking d’un objet, le détecter et empêcher / réduire les conséquences d’un hacking (sur l’appareil et en termes de propagation).

(If you want to see this article in English click here)

 

J’avais parlé de la partie prévention dans l’article suivant : Sécuriser l'IoT après l'attaque DDos par des objets connectés sur Twitter, Netflix, Amazon via le service DNS Dyn qui relate aussi les mesures telles que Privacy by Design et Security by Default.

 

Cet article décrit la partie détection d’un hacking (dès lors qu’il y a une modification). Il faudra compléter par des moyens pour détecter des hacking sans modification. Dès lors qu’une attaque est détectée, on peut à distance bloquer ou réduire les fonctionnalités de l’appareil, alerter…

 

Il y a trois éléments à sécuriser dans la chaîne reliant un objet connecté à une plateforme digitale en utilisant la blockchain et les techniques de hashage.

 

1.     Sécuriser l’intégrité d’un objet connecté (pas de hacking de celui-ci)

2.     Sécuriser l’envoi de données d’un objet connecté vers une plateforme

3.     Sécuriser la réception de données provenant d’une plateforme vers un objet connecté

 

J'aborde aussi d'autres notions comme le hashage des données, le Hard Fork d'Ethereum,

 

Il y a un grand nombre d'usages possibles pour la Blockchain dans l'Internet des Objets  :

 

Le plus évident est de permettre la création de plateformes décentralisées et collaboratives pour partager ses biens connectés avec des coûts de transactions très réduits ne nécessitant pas d'intermédiaire (hors création de la blockchain).

 

En effet, en connectant un produit, on facilite son partage, car on peut donner / retirer son accès/usage via des clés virtuelles (comme InBlue de Valeo ou les serrures connectées d'Opendoors de Somfy, ex-Okidokeys ...).

 

D’autre part, en plus de gérer l’accès, on a des informations sur l'usage, la localisation, facteurs, cela permet d’accroître la confiance d’un propriétaire d’un bien envers des utilisateurs potentiels (grosso modo, il sait ce qu’il sera fait de ses objets dans le respect bien sûr de la confidentialité des données personnelles). En plus de sa maison via une serrure connectée et des solutions de Smart Home, sa voiture via des clés virtuelles reconnues par le véhicule connecté, tous les objets qu'on utilise qu'occasionnellement, comme des perceuses, des échelles, des outils de bricolage pourraient aussi être partagés facilement.

 

On peut aussi imaginer des Smarts contracts tels que proposent Slock.it sur Ethereum pour déclencher le paiement dès que la personne ouvre l'appartement, la voiture ou utilise un appareil partagé.

 

Ces plateformes, comme je l'évoquais dans mes prédictions 2017, pourraient d’ailleurs "blockchainiser" (et non "ubériser" qui serait un oxymoron car par définition, ubériser centralise le pouvoir sur un seul acteur à la différence de la blockchain)  les plateformes collaboratives actuelles et  remplacer les acteurs connus tels que AirBnB, Blablcar ou Uber. En revanche, la blockchain ne remplacerait que la partie transactionnelle et non tout le reste, service client, innovation en terme de services, de plateforme, Marketing et commercial, animation de la communauté … 

 

Je vais évoquer un autre usage : la sécurisation des objets connectés qui est un sujet de plus en plus critique. Imaginez juste un ransomware sur des pompes à insuline connectées qui ferait un chantage auprès d'un fabricant sur la vie de ses utilisateurs en les menaçant d'une overdose mortelle…

 

Une des grandes faiblesses des objets connectés par rapport à la sécurisation de plateformes digitales est la sécurisation de la transmission et de l'objet lui-même. (Schéma). (cf aussi article sur la prévention)

Les trois étapes à sécuriser sont

• s'assurer que l'objet même n'a pas été hacké / modifié par rapport à l'objet d'origine (hors évolutions du fabricant et données utilisateur)
• s'assurer que les données transmises n'ont pas été modifiées / hackées entre l'envoi et la réception par la plateforme
• s'assurer que les données transmises par la plateforme vers l'objet connecté ne sont pas modifiées / hackées

Pour s'assurer de cela, l'idée est simple : comparer une version originale non modifiable (d’un code intégré dans un objet connecté par exemple d'où l'utilisation de la blockchain) et sa version actuelle sur ces trois étapes (la sécurisation des trois étapes est essentielle sinon il y a une brèche). S'il y a une différence (en tenant compte des évolutions logicielles et matérielles et en sortant les données utilisateurs), cela signifie que le code a été hacké.

 

Pour le faire, on utilise un élément simple de la blockchain l'ancrage combiné au hashage de données.

 

Qu'est-ce le hachage ?

 

Le hachage (hashing) est une technique qui permet de créer une signature (ou hash) quasi-unique à partir de n'importe quelles données. Si l'on modifie une des données d'origine (même infime grâce à l'effet avalanche), on modifie totalement la signature. Il y a des similarités à la technique de compression de données mais avec une différence fondamentale, deux images proches pourraient avoir un fichier compressé identique, ce qui n'est pas le cas du hachage. Dans l'image ici, la Déclaration universelle des droits de l'homme ont été hashées (fichier sous format texte via un outil en ligne en SHA 256) en deux versions avec et sans le H ! Les deux hashs sont complètement différents.

 

L'intérêt est ici de vérifier si le programme ou les données d'origines sont modifiés. Pour cela, on peut hasher la totalité du programme (OS, code embarqué…), un numéro de série unique  et des données qui seront incluses dans un objet connecté juste avant l’injection du code embarqué dans le produit (à la chaîne de fabrication). 

 

Pour prévenir un hack combiné de la plateforme et de l’objet connecté, on peut mettre ce hash dans une blockchain publique en plus d’une plateforme du fabricant (ou autre entreprise en charge de l’objet connecté). Ce hash initial sera le hash officiel du produit auquel on pourra comparer les hashs calculés par la suite de l’objet. Toute différence signifie qu’il y a une modification non voulue, et donc potentiellement un hack du produit et peut même interdire l’utilisation du produit (définitive ou temporaire car les bugs sont toujours possibles), ou une alerte vers l’utilisateur et le fabricant.

 

Cela signifie néanmoins qu’il faut gérer des bases de données avec des versions multiples pour un même objet connecté en cas d’évolution/upgrade logicielle du produit. Les données modifiables, elles ne seraient pas a priori hashées pour vérifier l’intégrité de l’appareil (sauf potentiellement la structure des données si elle est suffisamment pérenne).

 

On peut utiliser une fonction de hashage publique (et open source) car il sera très long et difficile de passer du hash aux données d'origine ou de créer un même hash à partir de données falsifiées (problème NP-complet donc pour calculer le hash à partir de données c’est très rapide (temps polynomial) mais pour retrouver les données qui correspond à un hash c’est très long si la taille du hash est suffisamment long (temps exponentiel ex : cryptage AES 256bits)). 

Pour l'anecdote (Guardtime), le gouvernement estonien hasherait la totalité de ses données et imprimerait le hash sur des journaux papiers ce qui permettrait de s'assurer que les données n'ont pas été modifiées par des hackers (en gardant bien sûr un log quotidien des hashs de chaque jour et un hash des modifications apportées entre deux jours consécutifs ainsi que les journaux papier !)

 

Sans rentrer dans une description détaillée sur ce qu'est la Blockchain, voici une rapide définition en très simplifié.

 

La blockchain est une technologie de stockage et de transmission d’informations, transparente, sécurisée, et fonctionnant sans organe central de contrôle.

Par extension, une blockchain constitue une base de données qui contient l’historique de tous les échanges effectués entre ses utilisateurs depuis sa création. Cette base de données est sécurisée et distribuée : elle est partagée par ses différents utilisateurs, sans intermédiaires, ce qui permet à chacun de vérifier la validité de la chaîne. 

La blockchain permet d'enregistrer ainsi des transactions, des signatures ... dans un registre partagé parmi tous ses utilisateurs. L'objectif est de s'assurer que personne ne modifie après coup le registre de transactions.

 

Il n'est pas possible de modifier ce registre sauf si plus de 50% de la puissance de calcul des serveurs (les mineurs) reliés à la blockchain l’acceptent (d’où l’importance d’avoir des blockchains publics avec un très grand d’utilisateurs et d’éviter des concentrations autour de quelques utilisateurs). Une blockchain avec un seul utilisateur (!) est l'équivalent d'une plateforme centralisée. On pourrait aussi faire un parallèle avec une assemblée générale d’actionnaires où le nombre de votes correspond à la puissance de calcul. 

D’autre part, s’il y a une modification, tout le monde le saura. Donc, plus il y a d'utilisateurs indépendants dans la blockchain, plus il sera sécurisé. Ainsi une blockchain public est donc plus sécurisé normalement qu'une blockchain privée. Enfin, en fonction des règles de la blockchain, une partie des utilisateurs peuvent faire un "fork" (crée un deuxième registre identique au premier sur une première partie et qui devient indépendant par la suite.

 

C‘est ce qui s’est passé le 20 juillet 2016 avec Ethereum. Il ne faut pas s’en étonner … on en a vécu quelques forks dans d’autres domaines …  En 1204 entre l’Église catholique romaine et l'Église orthodoxe et 1517 entre l’Eglise catholique et protestante (nommé schisme mais ce n’est pas reconnu par les protestants, qui gardent la Bible comme Grand Livre Commun et sans parler des autres religions … pardon pour la digression ;).

 

L'ancrage associé à l'horodatage est une des composantes de la blockchain et permet de créer une transaction dans la blockchain en indiquant la date. Ici, ce sera le hash qui sera enregistré dans la blockchain. 

Rentrons dans les principes sur les 3 étapes :

 

1. Pour sécuriser le code d'origine et le matériel

Afin de s'assurer de l'intégrité du matériel et que celui-ci n'a pas été corrompu ou modifié entre sa version originale et la version effective reçue par l'utilisateur, on peut associer à chaque version du code à embarquer (OS, programme, numéro de série…) dans l'objet un hash code, potentiellement il pourrait y avoir plusieurs hash codes par type de code pour faciliter le traçage d'une corruption (quelle partie du code a été corrompue). Le hash serait intégré dans une blockchain publique, en plus d’une plateforme du fabricant pour s'assurer qu’il ne puisse être corrompu en accédant aux serveurs de l'entreprise.

 

Il est même possible de faire un hash du matériel lui-même en photographiant l’intérieur du matériel (avec des fonctions de « perceptual image hashing » ou « image fingerprinting » qui maintiennent un hash similaire pour des images similaires). Le SAV pourrait photographier le matériel et s’assurer que celui n’a pas été modifié par rapport à la version photographiée à la sortie d'usine (via la comparaison des deux hash).

 

D’autre part, la fonction de hashage sera aussi intégrée au code. Celui-ci doit être open-source, accessible à l’utilisateur (averti ou via des applications) qui pourra vérifier son authenticité en le comparant avec la version originale open-source, accessible en ligne.

 

Lors de la fabrication, le code, le hash (caché dans le code) et la fonction de hashage sont injectés dans la mémoire du processeur. On peut pour sécuriser encore plus, l’intégrer dans la ROM (Read Only Memory ou mémoire morte) pour empêcher toute écriture ultérieure (y compris par flashage). En revanche, pour tenir compte des upgrades du produit, il faudra aussi l’intégrer dans une RAM (Random Access Memory ou mémoire vive) afin d’intégrer de nouveaux hashs. Si nécessaire, une réinitialisation complète du produit pourrait être réalisée avec l’installation des évolutions si un objet a été corrompu.

 

Lors du premier démarrage de l'objet connecté, d'une part, la fonction de hashage va sur base de la totalité du code, calculer le hash et le comparer au hash intégré dans l'objet.

 

Si ce n'est pas le cas, on pourrait demander à réinitialiser l'appareil car il aurait été corrompu. Il n’y a pas besoin de connecter le produit à ce stade.

 

D'autre part, en se connectant à la plateforme, ce même hash ainsi que la fonction de hashage  (ou le hash de la fonction de hashage) pourraient être comparés à la base de données du fabricant ainsi qu'à la blockchain, s'il y a une différence, cela bloquerait le produit et demanderait une réinitialisation.

 

On pourrait imaginer qu’un hacker remplace complètement le code d’un produit pour renvoyer le bon hash du code à la plateforme (indépendamment de son calcul), le problème est que comme la fonction de hashage est publique, on pourra facilement voir que même si le hash transmis correspond à la blockchain, en revanche la fonction de hashage ou le hash de la fonction de hashage ne correspond pas à la blockchain.

 

L'intérêt en deux étapes (hors connexion) et avec connexion est de s'assurer que le code n'est pas corrompu même s'il n'y a pas de connexion (hors remplacement complet du code) et de s’assurer ensuite que le code complet n’a pas été complètement remplacé. 

 

L'objectif est de s'assurer que ce qui est transmis n'est pas modifié par un tiers (ex: via la technique du "middle man" même si cela ne permet pas de savoir si cela a été intercepté )

 

L'objet connecté transmet dans son mode usuel (WiFi, Bluetooth via Smartphone, GPRS/3G) les données plus un hash calculé par l'algorithme de hashage dans le code embarqué.

 

Ce même hash est transmis via un réseau bas débit type Sigfox ou Lora, enfin  le hash du code embarqué est aussi transmis par les deux moyens.

 

Les deux hash de données sont comparés aux données (en hashant de nouveau les données) et entre eux pour s'assurer qu'elles ne sont pas corrompues ainsi que le hash du code pour s'assurer de l'intégrité de la machine.

 

L'intérêt d'utiliser deux modes de transmission est de créer de la redondance et de la résilience. Cela complique la tâche du hacker qui doit hacker les deux modes de transmission en plus de trouver l'algorithme de hashage. Cela utilise vraiment le rôle de backup d’un réseau bas débit en intégrant ses contraintes (très peu de données transmises via le hash).

 

Les hashs de données pourraient être intégrés dans la blockchain (potentiellement agrégés par jour et re-hashés pour réduire les accès à la blockchain) afin aussi de sécuriser le relevé de données. 

Pour éviter aussi que des ordres soient transmis malicieusement vers l'objet connecté, de la même manière, il faut à la fois hasher les données constituant l'ordre et le transmettre idéalement via deux modes de transmissions (WiFi, Bluetooth via Smartphone, GPRS/3G) et Sigfox (dans la fenêtre de réception qui peut être ouverte lors d'une transmission de l'objet connecté vers le serveur) ou Lora.

 

Cela permet d'assurer la résilience et la redondance des modes de transmission. De la même manière, il est nécessaire aussi de transmettre le hash de l'appareil et de la fonction de hashage pour s’assurer de l’intégrité de l’appareil. Si le hash envoyé ne correspond à celui dans l’appareil, il pourrait être bloqué automatiquement ou alerter l’utilisateur, le fabricant ...

 

Les hashs de données pourraient être intégrés dans la blockchain (potentiellement agrégés par jour et re-hashés pour réduire les accès à la blockchain) pour s’assurer de leur non-modification.

 

Même si cela peut paraître compliqué ces solutions sont en réalité beaucoup plus faciles à mettre en œuvre qu’on ne pourrait le croire pour sécuriser les données. Le minimum étant d’intégrer un algorithme de hashage open source dans l’équipement et de s’assurer de l’intégrité des données en interne et lors des transmissions.

 

Si cela vous intéresse de réaliser un projet sur ces sujets, n’hésitez pas à me contacter. 

 

Dimitri Carbonnelle 

Fondateur de Livosphere 

Conseil en Innovation, et nouvelles technologies : Internet des Objets, intelligence artificielle, Blockchain ...