Quel que soit leur niveau de sophistication, les appareils IoT sont quasi inutiles s'ils ne peuvent pas communiquer avec d'autres dispositifs, services ou applications. Pour pouvoir se connecter, ils ont besoin d'un protocole et le plus populaire d'entre eux est MQTT.
Entre la fin du 20e et le début du 21e siècle, la convergence de plusieurs facteurs ont soudain fait de l'IoT (Internet des Objets) une réalité viable, lui permettant alors d'exploser. Ces facteurs sont multiples, tels que l'avènement de la technologie RFID (radio-identification), l'introduction du protocole IPv6 qui augmente largement le nombre de dispositifs pouvant être connectés, ou encore les connexions réseau plus rapides.
Mais un autre facteur figure parmi ceux ayant le plus contribué à ce qu'est l'IoT aujourd'hui : MQTT, pour Message Queuing Telemetry Transport. Il s'agit d'un protocole de messagerie léger, à utiliser lorsqu'on ne dispose que d'un petit espace de données et que l'on est connecté à des réseaux peu fiables ou à la bande passante limitée. Il est principalement utilisé pour les communications machine to machine (M2M) ou les connexions de l'IoT.
Les origines de MQTT
A la fin des années 90, les systèmes SCADA (Supervisory Control and Data Acquisition) étaient très utilisés pour gérer à distance de grandes infrastructures industrielles, telles que les oléoducs ou les réseaux électriques, et ils le sont encore beaucoup aujourd'hui. Comme ils se connectaient à distance à des machines et des appareils, ils sont largement considérés comme les précurseurs des systèmes IoT actuels.
Ce moyen de se connecter était appelé « télémétrie » et fonctionnait avec une diversité de protocoles propriétaires développés par des fabricants, entraînant toutes sortes de problèmes de compatibilité. C'est pourquoi deux ingénieurs d'IBM, Andy Stanford-Clark et Arlen Nipper, ont décidé de créer un protocole open-source pour tous les remplacer : MQTT.
Le fondement du développement de ce protocole publié en 1998 reposait sur trois principes toujours en vigueur aujourd'hui dans ses mises à jour : il devait être compact, facile à comprendre et simple à mettre en œuvre. Bien qu'il n'ait été initialement destiné qu'à la gestion à distance par satellite des composants des oléoducs, il est vite devenu évident que MQTT pourrait avoir des applications en dehors des systèmes SCADA.
L'IoT adopte MQTT
Lors de l'essor de l'IoT dans les années 2000, les ingénieurs et les fabricants cherchaient un moyen de connecter leurs nouveaux appareils. Par sa sophistication et son utilité, MQTT répondait parfaitement à leurs besoins et s'est donc peu à peu répandu. C'est vers 2008 que le point de bascule s'est produit lorsqu'a été lancé le broker MQTT open-source Mosquitto (appelé aujourd'hui Eclipse Mosquitto), rendant le protocole plus accessible. Son taux d'adoption a alors fortement augmenté.
Devenu une norme ISO en 2016, MQTT connectait déjà à cette date des millions d'appareils dans le monde entier, dans toutes sortes d'applications et d'industries. IBM, Amazon et Microsoft ne sont que quelques exemples de grands acteurs qui ont adopté MQTT comme protocole central.
Si MQTT a rencontré un tel succès, c'est grâce à l'objectif des trois principes que ses créateurs ont réussi à atteindre. En fait, MQTT a été si bien conçu que très peu de changements ont été apportés au protocole au cours de ses 10 premières années d'existence.
L'architecture de MQTT
En tant que protocole open-source léger et grâce à sa simplicité, MQTT nécessite peu de traitement et de consommation de la part des appareils IoT, mais aussi peu de bande passante, avec des entêtes de message très courts. Il est également possible de définir différents niveaux de Qualité de Service (QoS) pour les messages, afin de pouvoir contrôler le nombre de fois où ils sont envoyés et le type d'authentification utilisé. Tout cela rend MQTT pratique pour de nombreux types de réseaux différents.
Au cœur de son concept se trouvent les serveurs et les clients. Ceux-ci sont capables de s'envoyer des messages en utilisant les éléments suivants :
- Sujets (topics) : ils servent à catégoriser le type de messages à envoyer. Par exemple, si un capteur mesure la température, le sujet peut être défini en « TEMP », et le capteur enverra des messages étiquetés « TEMP ».
- Editeurs (publishers) : les appareils peuvent être configurés pour envoyer des messages contenant des données. Dans l'exemple ci-dessus, le capteur mesurant la température publie ces données.
- Abonnés (subscribers) : les appareils ou systèmes peuvent être configurés pour recevoir des messages sur un sujet spécifique uniquement. Ils peuvent également s'abonner à plusieurs sujets.
- Broker : c'est le serveur central qui transmet les messages publiés aux clients qui se sont abonnés à des sujets spécifiques.
Il s'agit donc d'une solution très simple où des serveurs peuvent publier des messages, et d'autres serveurs ou clients sont configurés pour "écouter" des messages spécifiques.
L'omniprésence de MQTT
Devenu une norme industrielle, le protocole MQTT est le plus utilisé dans les environnements IoT, alors qu'il existe pourtant plusieurs alternatives telles que :
- HTML : il y a 10 ans, il aurait pu être la solution la plus évidente, mais il n'est pas adapté aux exigences de l'IoT dans sa manière de gérer les événements. Avec HTML, le destinataire doit interroger continuellement la source pour vérifier si l'événement d'envoi s'est produit, ce qui n'est pas très efficace et peu économe en traitement et alimentation. Avec MQTT, au contraire, un message est envoyé une fois que l'événement s'est produit, il n'est pas nécessaire de procéder à une écoute continue.
- AMQP : il s'agit d'un protocole plus bavard mais aussi plus flexible que MQTT car il ne s'embarrasse pas d'établir un lien vers un nœud ni d'autoriser le flux. Il en résulte que sur des sessions de longue durée, la quantité de données transférées peut être inférieure à celle des opérations équivalentes de MQTT. AMQP est donc une bonne option, mais MQTT est souvent nécessaire lorsque l'on a besoin d'une option légère et peu encombrante.
- CoAP : une autre bonne solution, similaire à HTTP, mais conçue pour les appareils sous contraintes. Contrairement à MQTT qui permet de faire passer des messages entre plusieurs serveurs par un broker central, CoAP est un protocole de transfert d'état entre un client et un serveur, et non basé sur des événements. Comme de nombreuses installations IoT sont basées sur des événements, MQTT lui est très souvent préféré.
Les problèmes de sécurité
MQTT a donc connu une croissance fulgurante et il est aujourd'hui très populaire, mais on ne peut ignorer les questions de sécurité qui l'implique. En tant que protocole, MQTT est sûr, mais c'est la façon dont il est mis en œuvre et configuré qui peut poser problème. Car comme toujours, si la configuration n'est pas sécurisée, c'est tout l'environnement informatique qui est compromis.
Dans le cas de MQTT, le problème de sécurité est exacerbé par le fait que si un tiers accède à l'environnement, il peut s'abonner à tous les messages qui circulent. Lors d'une récente affaire, sur 49 000 serveurs MQTT exposés sur Internet, on a constaté que plus de 32 000 d'entre eux n'étaient pas protégés par un mot de passe. De multiples données liées à la Smart City, telles que des mesures environnementales, des données GPS et plus encore, étaient ainsi accessibles.
En réalité, les problèmes de sécurité auxquels MQTT est confronté sont les mêmes que ceux de l'IoT en général. Tant que les personnes qui mettent en œuvre ces systèmes ne seront pas mieux informées et sensibilisées à la manière de configurer et sécuriser des environnements, la sécurité restera le plus grand danger pour l'avenir de l'IoT. On peut être sûr cependant que la facilité d'utilisation et la simplicité de MQTT font qu'il continuera à contribuer fortement à la révolution de l'IoT actuellement en cours.