« SSL/TLS m’a tuer mon Arduino »

Question : comment envoyer une notification sur un smartphone / le Web depuis un Arduino Uno ?

Réponse 1 : Avec l’Internet d’il y a 5 ans, il suffit d’utiliser, la messagerie instantanée, le mail ou Twitter !
Réponse 2 : Avec l’Internet d’aujourd’hui, tu peux te brosser Martine… ou bricoler un truc comme tu peux…Imaginez, une chatière, un capteur, un Arduino et un shield Ethernet ou Wifi. Le but du jeu :  lorsque le chat passe par la chatière une notification arrive sur votre smartphone, votre tablette et/ou votre PC/Mac. Séduisant, non ? (oui, ça dépend des habitudes du chat)

Avec une connaissance minimale du fonctionnement d’Internet et des services qui y sont disponibles, on imagine plein de solutions :

  • Envoyer un mail sur un compte relevé par les périphériques, au hasard, une adresse Gmail et hop une notification apparaît.
  • Se connecter à une messagerie instantanée et envoyer un message. Là encore, la notification arrive sur tous les supports.
  • Tweeter un petit message et vous, en tant que follower serez notifié aussi bien sur votre ordinateur que votre smartphone/tablette.

Le petit problème, c’est que depuis quelque temps, le monde s’est rendu compte que tout ceci circulait majoritairement « en clair » sur un réseau où un groupe de « petits curieux aux grandes oreilles » était en mesure de lire tous ces messages. S’en est suivi un changement radical en deux étapes :

  1. On ajoute du chiffrement et de la sécurité partout où c’est possible en utilisant SSL/TLS et on recommande l’utilisation de HTTPS, POP3S, IMAPS, SMTPS et XMPPS en lieu et place de HTTP, POP3, IMAP, SMTP et XMPP.
  2. On arrête de fournir la possibilité d’utiliser les protocoles en version non protégé (sans le « S »), comme ça, la sécurité est de mise par défaut et sans alternative (du moins dans l’esprit des utilisateurs, car les implémentations de SSL/TLS sont loin d’être le Saint Graal de la sécurité).

Le dernier en date à avoir franchi le second pas est Twitter qui depuis mi-janvier n’autorise plus l’utilisation de son API (l’interface permettant à un programme de tweeter) sans SSL/TLS.

C’est une très bonne chose dans la majorité des cas, seulement voilà : une petite carte comme un Arduino Uno avec un shield Ethernet ou Wifi, n’est pas en mesure de supporter SSL/TLS, même avec des toutes petites implémentations comme PolarSSL ou CyaSSL. C’est tout simplement trop difficile. SSL/TLS implique énormément de choses. Il faut faire des calculs importants, générer des nombres aléatoires (vraiment aléatoires), calculer des condensés, chiffrer des bloc de données… Même si un ATmega328 avait la puissance nécessaire, ses 2 Ko de mémoire (SRAM) ne sont pas suffisants, pas plus que ses 32 Ko de flash si l’on ajoute le code permettant de gérer le protocole qu’on cherche à utiliser avec SSL/TLS. À titre d’exemple, la bibliothèque Twitter pour Arduino de Markku Rossi occupe à elle seule 22 Ko de la flash de 32 Ko d’un Arduino Uno ou Duemilanove (et 1,4 Ko des 2 Ko de mémoire SRAM).

Alors, il existe des solutions pour contourner le problème :

  • Utiliser un service de relais sur lequel se connecter et qui se connectera ensuite au service visé : dans quelle mesure peut-on avoir confiance ?
  • Utiliser un PC qui sera connecté à l’Arduino via le réseau ou une liaison série et celui-ci fera office de relais : si un PC est impliqué, autant utiliser le PC pour la partie notification et réserver éventuellement l’Arduino comme périphérique de capture d’événement (bonjour la consommation électrique), voire remplacer tout bonnement l’ensemble par une Raspberry Pi.
  • Sortir l’artillerie, installer son serveur de mails ou de messagerie instantanée ou, pourquoi pas, développer une application Android (et soyons fou, une autre pour iOS).

Le problème qui se pose, même si la protection des données et parfaitement légitime et indispensable, tient dans le fait que, en dehors de l’aspect « réseaux local », les shields Ethernet et Wifi, couplés à un Arduino Uno, s’en trouvent mis quelque peu à l’écart. SSL/TLS est clairement au-delà des capacités d’un petit microcontrôleur 8 bits et n’est utilisable qu’avec la gamme supérieure. Il y a donc clairement une escalade de la puissance et du besoin de puissance. SSL/TLS, le protocole lui-même, n’a jamais été conçu pour des périphériques limités en ressources et nous devons faire avec cela.

Il semble pourtant évident qu’il serait nécessaire aujourd’hui, à l’heure où tout le monde parle tant de l’Internet des objets, de disposer d’un protocole de chiffrement et d’authentification à très faible empreinte mémoire et ce, standardisé et globalement accepté.

Car il ne s’agit pas que de nos créations, mais également de tout un secteur émergeant qui risque de se voir diviser en deux avec, d’un côté des périphériques connectés puissants et chers disposant d’un niveau de sécurité acceptable, et de l’autre l’entrée de gamme, incompatible avec les gros acteurs ayant basculé vers le « tout-SSL/TLS » et envoyant joyeusement les informations en clair à des serveurs sans doute tout aussi sécurisés que le protocole purement textuel…

Ce n’est, bien entendu là qu’une théorie. Il est bien plus probable qu’une bonne partie des équipements de marque utilisent des protocoles non sûrs, sans chiffrement, car nécessitant moins de puissance et donc ayant un coût de production et de R&D moindre. À votre avis, votre balance connectée ou votre téléviseur flambant neuf, communique-t-il via SSL/TLS ou pas ?

Internet semble avoir besoin d’un nouveau protocole et rapidement !