Cryptographie et objets connectés font ils bon ménage ?

Voir la vidéo sur Dailymotion

La cryptographie est-elle compatible avec les objets connectés ? Quels sont les grands challenges et les tendances dans le domaine ? Ce sont les thèmes que j’ai abordés avec Hervé Lehning, cryptographe, spécialiste du chiffre et de la sécurité de l'information, auteur de nombreux articles et ouvrages de vulgarisation, et  président de AC-HL, société de conseil et de formation.

Les techniques de chiffrement habituellement utilisées ont été conçues pour des systèmes disposants des microprocesseurs puissants avec des capacités de stockage très conséquentes. Or pour les objets connectés ce n'est pas le cas. En effet, s’ils sont limités en puissance de calcul ou en  espace de stockage, ils doivent aussi consommer le moins d’électricité possible.
De plus, les interfaces de configuration des objets connectés se résument souvent à 1 ou 2 boutons et un petit écran, voire même à un simple indicateur lumineux.

le grand challenge de l’espace mémoire

Le grand classique dans le monde de la bidouille électronique, c'est de connecter son Arduino (une petite carte électronique) à un compte Twitter afin d'envoyer un Tweet dès qu'un capteur détecte un évènement. C'est à la portée de tous et ça fonctionne très bien.

Mais comme le présente Denis Bodor dans son article « SSL/TLS m’a tuer mon Arduino », il n'est tout simplement pas possible d'utiliser TLS/SSL pour sécuriser les communications entre son Arduino et Twitter. La raison est simple : la librairie, pour "parler Twitter", consomme à elle seule déjà la majorité de la mémoire restreinte d'un Arduino (total disponible de 32 Ko de mémoire Flash et de 2 Ko de RAM). D’autant que Twitter n’accepte désormais que des connections en mode sécurisé.
La solution est de passer via un serveur intermédiaire (ou proxy) qui va relayer les requêtes vers Twitter (l’Arduino communiquera en clair avec le proxy qui lui fera du SSL/TLS avec Twitter).

Si les conséquences sont minimes pour un petit circuit expérimental, cela peut être différent pour les objets connectés plus « sérieux » comme un système d’alarme.

des librairies logicielles cryptographiques (trop) variées

L'un des premiers challenges lors de la mise en œuvre d’un système de cryptographie sur un objet connecté c’est la disponibilité  de librairies logicielles adéquates.

Pour y voir plus clair, voici quelques informations sur les librairies logicielles qui implémentent des fonctions cryptographiques pour des cartes de type « Arduino » dont le code source est ouvert/accessible. N’hésitez pas à me faire savoir si j’ai omis de mentionner une librairie importante ou fait des erreurs. Cela me permettra de modifier cet article en conséquence.

• Calcul de hashcodes (ou « codes de hachage »)
  Pour des plateformes Atmel/Arduino, il existe des librairies de calcul de codes de hachage comme Cryptosuite (support de SHA-1, SHA-256, HMAC-SHA-1 et HMAC-SHA-256). Cette librairie  « Cryptosuite » semble faire l’unanimité et de nombreux projets l’utilisent.
   
• Chiffrement symétrique
  Les librairies de chiffrement symétrique disponibles sont très variées :
  
  - Voici une librairie qui implémente du chiffrement DES sur Arduino.
  - Il y a aussi l'algorithme de chiffrement XXTEA ( avec une consommation en mémoire particulièrement faible) et dont l’une des librairies est disponible pour Arduino. Elle est notamment utilisée dans la librairie RF12 de Jeelabs.
  - Pour des modules de communication sans fil de chez NordicSemiconductor, on trouve un module de chiffrement RC4 pour le nRF24L01, ainsi qu’un module de chiffrement AES pour le module nRF24LE1.
  - Il existe aussi la librairie « AVR-Crypto-Lib » qui propose un large éventail de fonctions de chiffrement à clefs symétriques (et s’avère utile pour calculer des hashcodes).
  - Pour ceux qui recherchent uniquement du chiffrement AES, ce projet propose une extraction du code AES de la librairie AVR-Crypto-Lib mentionnée  juste avant.
   
• Chiffrement asymétrique et négociation de clefs
  En revanche, les librairies de chiffrement asymétriques sont moins nombreuses pour des plateformes comme Arduino. La librairie « Relic-Toolkit » du projet TinyPBC propose un éventail assez large d’algorithmes comme RSA mais aussi ECDSA. Il y a aussi des librairies de taille plus modestes qui propose notamment du RSA et du Diffie-Hellman.

difficile d’y voir clair avec toutes ces librairies

Clairement, dire qu’il n’y a pas de librairies crypto pour des plateformes ARM comme Arduino serait mentir. En fait, le challenge réside dans leur grand nombre et une relative absence de cohérence. Car on ne sait pas si elles sont toutes fiables, ou même si ces librairies sont interopérables (est-ce que des données chiffrées par l’une seront déchiffrables par une autre ?).

Autre écueil, le choix de l’algorithme n’est pas à la portée de tous.  Si un algorithme comme AES est considéré comme fiable, ce n’est plus le cas d’un DES. Pour simplifier, je doute que les ingénieurs en électronique, dont la spécialité est de créer des objets connectés, soient aussi des experts en cryptographie. La route de la cryptographie dans l’Internet des objets est donc pavée de chausse-trappes.

Mais ne gâchons pas notre plaisir ! La possibilité de calculer des codes de hachage est un bon début. Certains projets utilisent cette possibilité pour signer des requêtes Amazon AWS (« Signing AWS Requests With Your Arduino ») ou encore pour générer par eux-mêmes leurs propres jetons à usage unique (« My TOTP library ») compatibles avec le « Google Authenticator ». Mais les projets mettant en œuvre les fonctions de chiffrement symétriques sont difficiles à trouver, et c’est encore plus difficile pour le chiffrement asymétrique. N’hésitez pas à me signaler des projets utilisant du chiffrement (a)symétrique sur une base Arduino ou assimilée !

Néanmoins, ces librairies logicielles doivent être compatibles avec les contraintes techniques liées à l’IoT, et ce ne sera pas toujours possible, notamment en raison des capacités mémoire requises.
A fortiori si l’on a besoin d’utiliser plusieurs fonctions crypto en même temps (les 32Ko de mémoire Flash d’un Arduino sont une ressource rare).

Face à de telles contraintes, on comprend aisément l’intérêt que représentent les nouvelles approches plus « industrielles »… Même si, effectivement, le « code source ouvert » a ses avantages.

intégration de fonctions cryptographiques dans le silicium

Parmi les nouvelles tendances, il y a l’intégration de fonctions cryptographiques directement dans le silicium des composants. Actuellement, cette intégration n’est disponible que pour les microprocesseurs « classiques » comme ceux d’Intel et AMD.

Les microprocesseurs d'Intel ou AMD intègrent nativement un jeu d’instructions "AES-NI" (Advanced Encryption Standard New Instructions) permettant de réaliser un  chiffrement AES directement au cœur du microprocesseur. Pour les microprocesseurs de la famille ARM, la spécification ARMv8-A intègre désormais le support de fonctions de chiffrement AES et de calcul de codes de hachage conformes à SHA-1/SHA-256). Cette version ARMv8-A, assez récente (2008), est mise en œuvre pour des microprocesseurs particulièrement puissants, comme ceux de nos Smartphones. Les microprocesseurs Intel disposent, eux, d’une instruction « RdRand » permettant de générer des nombres aléatoires.

Si les « gros microprocesseurs » disposent de jeux d’instructions dédiés au chiffrement et à la génération de nombre aléatoire, les « petits microcontrôleurs » proposent, de leur côté, uniquement des fonctions de génération de nombres aléatoires, mais rien pour le chiffrement... On retrouve de telles fonctions de génération d’aléas dans les microcontrôleurs Atmel SAM3X8E (utilisés dans les cartes Arduino Due).

L’article « Using Arduino Due’s True Random Number Generator » de Kerry D. Wong montre comment utiliser la génération de nombre aléatoire disponible sur les Arduino Due.

Figure 1 - Code source Arduino pour test du TRNG du « Arduino Due »

Si L’intégration des fonctions cryptographiques dans le silicium devient la norme pour les microprocesseurs , ce n’est pas encore le cas pour les microcontrôleurs les plus petits. Ceux-ci  restent cantonnés aux fonctions de génération de nombres aléatoires. Pour des fonctions de chiffrement AES ou de calcul de codes de hachage pour les objets connectés il faudra donc aller chercher ailleurs…ou attendre l’évolution naturelle de la technologie.

composants électroniques dédiées aux fonctions crypto

L'utilisation de composants électroniques spécifiquement conçus pour des fonctions cryptographiques pourrait être une alternative particulièrement pertinente aux librairies logicielles ou aux fonctions intégrées dans les processeurs. Si finalement ces composants spécifiques apparaissaient comme des outils « sûrs » (ou « de confiance », cad sans « backdoors »), alors ils pourraient représenter une bonne alternative pour crypter nos objets connectés.

Néanmoins, ces composants électroniques conçus pour assurer des fonctions cryptographiques ne sont pas nouveaux. Certaines catégories de cartes mères de PC intègrent depuis quelques années des « puce TPM » (Trusted Platform Module). On les retrouve même dans les manettes de jeux des consoles XBOX360 ! Mais un TPM répond uniquement à des besoins spécifiques comme la création d'une sorte de "racine de confiance" utilisée pour vérifier l'authenticité d'un programme ou pour stocker des informations sensibles.
Pour les objets connectés, regardons plutôt du côté du fabricant de composants électroniques ATMEL. Et plus précisément vers leur gamme "CryptoAuthentication" dans laquelle on trouve des composants électroniques spécialisés dans les fonctions cryptographiques :

• Composant ATSHA204A : calcul de codes de hachage NIST SHA-256
• Composant ATAES132 : stockage sécurisé de clefs 128 bits, génération de nombre aléatoires
• Composant ATECC108 : fonctions de signature électronique ECC, stockage sécurisé de clefs, générateur de nombres aléatoires, compteurs infalsifiables, etc…

Un microcontrôleur de type Arduino pourra donc utiliser les fonctions cryptographiques de ces composants via un nombre restreint de lignes de code. Le tout via un interfaçage à partir d’un bus I2C ou SPI.

Pour ceux qui voudraient tester ces composants, j’ai identifié deux possibilités :

1. La carte CryptoCape intègre ces composants et a été conçue pour être directement connectée sur une carte BeagleBone (il devrait aussi être possible de l’utiliser depuis un Arduino en bidouillant un peu).

Figure 2 - CryptoCape pour BeagleBone

2. Le kit d’évaluation AT88CK490 d’Atmel est en fait une clef USB intégrant ces 3 composants ainsi qu’un microcontrôleur. Il est possible de demander un échantillon gratuit de cette clef USB (j’ai fait une demande il y 3 semaines, j’attends toujours mais il ne faut pas être trop exigeant – c’est gratuit !).

Figure 3 - Clef USB Crypto - ATMEL AT88CK490

Et pour ceux qui ne font pas confiance aux générateurs de nombres aléatoires intégrés dans le silicium (que ce soit dans des composants spécialisés ou dans des microprocesseurs), ils pourront se tourner vers des montages utilisant du "bruit électronique" afin de générer des nombres aléatoires. Il y a différents types de montage :

• basés sur des montages à transistors
• ou encore le « XR232USB True Random Numbers @ USB » qui utilise un amplificateur opérationnel pour générer du bruit et qui se connecte à un port USB.

la cryptographie et l'Internet des Objets

A l’avenir, la sécurisation des communications entre objets ou des services hébergés dans le Cloud devra passer par l'utilisation de mécanismes cryptographiques. Clairement, les librairies logicielles sont à proscrire car elles nécessitent des ressources dont les objets sont naturellement dépourvus. L’intégration des fonctions cryptographiques au niveau du silicium, plus économiques et plus simples à mettre en œuvre, devrait donc devenir la norme. Son seul désavantage : elle est statique car elle « fixe dans le silicium » un algorithme donné. Cette approche n’a donc pas que des atouts.

De même, il sera difficile de changer un composant une fois celui fabriqué et soudé. Les « vieux » algorithmes que sont MD5, SHA-1 ou la cryptographique asymétrique à base de RSA sont donc à proscrire. Au contraire, ce sont des algorithmes considérés comme offrant une pérennité qui doivent être retenus : SHA-256 et de la cryptographie à base de courbes elliptiques (ECC - Elliptic_curve_cryptography). Les choix d’ATMEL dans leur gamme CryptoAuthentication vont dans ce sens. Bien vu !

Jean-François (Jeff) Audenard