Dossier : MQTT, protocole IoT destiné aux objets connectés – Fiabilité, Avantages & Vulnérabilités, l’avenir M2M des objets connectés IoT

L’internet des objets connectés « IoT » Internet of Things ou l’internet des objets connectés appliqué en industrie « IIoT » font partie intégrante de ce beau monde connecté que nous découvrons ou connaissons déjà. Lié de près ou de loin à la sécurité électronique, l’internet des objets connectés devient peu à peu un véritable allié dans le domaine de l’industrie, mais également pour la maison connectée, la future « Smart Home » qui devrait éclore d’ici quelques petites années. En environnement IoT et IIoT, de nombreux protocoles de transfert de données (M2M – Machine To Machine) existent, bien que depuis quelques années, le standard MQTT tend à devenir « LE » protocole de communication permettant de faire communiquer les objets connectés en toute simplicité. MQTT pour Message Queuing Telemetry Transport est utilisé par de nombreux acteurs dans le monde, Facebook, OpenStack, Geospatial, Bosch, IBM, Adafruit, EVRYTHING IoT, Amazon IoT, Google Home Assistant, Pimatic, MS Azure, certains systèmes de signalisation, systèmes d’alarme, l’industrie du Gaz, de l’électricité et bien plus encore.

À l’instar du P2P, ce protocole se montre efficace et simple à être intégré en environnement IoT. Les acteurs de l’IoT séduit par la légèreté de ce protocole, son appétit mesuré en termes de bande passante le rendant idéal en environnement dégradé par la présence de mécanisme de contrôle (QoS), par la qualité des phases connexion/reconnexion, ou encore par une gestion fine des privilèges utilisateur associé à une sécurité accrue (en TLS/SSL) l’intègre de ce fait de plus en plus au sein de produits dits connectés. Ce protocole de transport à l’instar des protocoles CoAp, XMPP ou encore AMQP fait partie du présent et du futur des objets connectés. Bidirectionnel, MQTT est un protocole ouvert répondant parfaitement à la demande actuelle en matière d’objet connecté en réduisant les coûts liés au développement de protocoles propriétaire. Peu énergivore en bande passante, le protocole ouvert MQTT ne nécessite pas de grosses ressources matérielles (CPU, RAM, ROM) et de surcroît, optimise la consommation énergétique tout en bénéficiant d’une rapidité sans précédent grâce à sa légèreté. MQTT est véritablement un protocole émergent qui devrait continuer à faire parler de lui dans les années à venir en se démocratisant massivement. Comme nous le verrons dans cet article, MQTT possède aussi des brèches, des lacunes qui malheureusement seront « utilisées » par des fabricants proposant une offre à bas coût (on pense à certaines caméras, à divers systèmes d’alarmes bon marchés ou autres objets connectés qui sévissent sur la toile).

Dossier : Protocole MQTT & IoT – Découvrons pourquoi & comment le protocole MQTT a-t-il vu le jour en 1999 ?

Initié en 1999 par des chercheurs d’IBM, le protocole MQTT c’est fortement démocratisé au fil des années grâce à l’avènement des objets connectés. Ce protocole est né pour répondre à une problématique de taille, la déconnexion fréquente des machines engendrant l’absence d’informations transmises pendant cette période d’inactivité. MQTT a permis de fiabiliser ce type de désagrément en rendant possible l’envoi des messages (conservation – mise en mémoire tampon) dès qu’une machine retrouvait son réseau. La légèreté du protocole faisait également partie intégrante du cahier des charges à l’époque de sa conception. MQTT à ce jour, est resté calqué sur un héritage de longue date et n’a en rien perdu de ses qualités, qualités qui en ont fait sa force à ses débuts à savoir, une rapidité d’exécution associée à une simplicité de déploiement. MQTT est un standard ISO (ISO/IEC PRF 20922) étant l’un des principaux protocoles de messagerie dans le domaine des objets connectés et objets connectés en industrie (IIoT).

Dossier : Protocole MQTT & IoT – Présentation détaillée du protocole MQTT implanté en milieu IoT « Internet of Things »

Open source, MQTT est un protocole de communication ouvert déployé sur la couche réseau TCP/IP. Fonctionnant sur le principe de « publication/abonnement » Publish/Suscribe, MQTT est un protocole à l’opposé du standard Web HTTP(S) Hyper Texte Transfer Protocole conçu pour la navigation internet et fonctionnant sur le principe des « questions/réponses - Request/réponse ». MQTT s’appuie principalement sur 4 axes pour s’exécuter. Le premier, baptiser « publisher » est comme son nom l’indique le publieur. Pour simplifier, nous prendrons pour exemple, une sonde d’inondation déployée en milieu résidentiel. Cette sonde « connectée » récupère différentes informations allant du simple « état » (inondation ou non) à une mesure plus précise du niveau d’eau. Cette sonde « publisher » va transmettre et publier les données vers le « Broker – courtier » qui lui-même sera en charge de transmettre l’information à l’utilisateur final appelé « client ». Le 4e axe est la partie « sujet » comprenant un ou plusieurs niveaux séparés auxquels le client s’abonne. MQTT n’est pas plus compliqué que ça dans les grandes lignes.

Le Broker véritablement maitre à bord joue un rôle crucial dans l’acquisition et la distribution des données entre le capteur et le/les utilisateurs abonnés. Le principe de l’abonnement du protocole MQTT s’appuie sur le fait qu’un « publisher » va émettre une information tout en se catégorisant dans un sujet. Le Broker est capable de « bufferiser » (mise ne mémoire tampon) toutes les informations provenant de différents capteurs ou objets connectés. Ainsi, si l’utilisateur est hors ligne (Smartphone éteint par exemple), les informations émises vers le Broker pendant cette période d’inactivité remonteront immédiatement lors de la prochaine connexion (principe de Facebook Messenger par ex.). L’utilisateur recevra ainsi toutes les données émises pendant ce laps d’inactivité grâce au Broker capable de gérer la notion de mise en mémoire tampon. L’utilisateur en liaison constante « Heartbeat » avec le Broker bénéficie en temps réel des informations émises par le Broker. MQTT utilise une certaine hiérarchisation très pratique.

Cette hiérarchisation dans le cadre d’une installation de plusieurs capteurs en environnement résidentiel pourrait se baser ainsi : Topic « domicile/garage/sonde-inondation » avec des niveaux séparés si plusieurs capteurs sont présents « domicile/garage/buanderie/sonde-inondation » ou encore « domicile/garage/detecteur-volumetrique-5 ». Si l’utilisateur souhaite recevoir les informations du garage, il n’aura qu’à s’abonner au topic « domicile/garage/# ». Si l’intégralité des informations émanant des capteurs/détecteurs situés dans toute la maison est souhaitée, l’utilisateur s’abonnera au topic « domicile/# ». Si plusieurs utilisateurs souhaitent recevoir les informations, le Broker sera capable de transmettre les éléments aux utilisateurs s’étant au préalable abonnés au topic attitré. Intégré dans une application, MQTT se montre bien évidemment plus agréable à utiliser. Toutefois le principe reste identique, avec une solution basée sur la « publication/abonnement » apportant souplesse et simplicité permettant à l’utilisateur de « Switcher » les données reçues et ainsi de ne sélectionner que les informations auquel il porterait un intérêt. En environnement MQTT, la taille maximum des informations transmises n’excède pas 256 Mo laissant une belle marge de manœuvre si l’on se réfère à la taille des flux transmis. Pour vulgariser la chose, le principe MQTT se calque sur celui d’un bon vieux forum internet. Des messages sont envoyés et l’utilisateur, par navigation dans l’arborescence du forum récupère l’info qu’il souhaite. MQTT se montre extrêmement pratique, souple et parfaitement sécurisé si déployé intelligemment comme nous le verrons plus loin dans cet article.

Dossier : Protocole MQTT & IoT – Quid de l’intégrité des données transmises/reçues entre le « Broker » & l’utilisateur ?

MQTT inclus nativement la notion de QoS « acronyme de Quality of Service – Qualité de service » permettant de véhiculer des données conformément à certaine exigence en matière de temps de réponse et de bande passante. MQTT s’appuie sur 3 niveaux de QoS allant du plus faible au plus élevé. QoS permet de « sélectionner » la qualité des données transmises.

La qualité de service se base sur plusieurs facteurs tels le débit, la fluctuation du signal numérique, la latence (ping), la perte de paquet et le déséquencement (ordre d’arrivée des paquets). QoS permet d’assurer une bonne réception des informations et l’intégrité de celles-ci.

Dossier : Protocole MQTT & IoT – Ce protocole est-il sécurisé en environnement IoT ? Failles & Vulnérabilités

Édulcoré par de nombreuses louanges, MQTT reste pourtant fortement vulnérable si certaines conditions ne sont pas réunies comme l’absence de chiffrage sur la transmission & l’authentification. MQTT est capable d’être déployé sans chiffrement TLS ou SSL (MQTT – Port TCP 1883 non crypté) | MQTTS port sécurisé 8883). L’authentification des clients avec les certificats SSL/TLS offre un excellent niveau de sécurité renforçant fortement la sécurité des objets connectés. Toutefois les couches additionnelles de sécurité nécessitent une partie « Hardware » supérieure et la gestion des certificats peut vite se montrer complexe à être déployé en environnement connecté. Ainsi, un objet connecté à bas coût aura de fortes chances d’être vendu dans le commerce en utilisant une version MQTT sans chiffrement… Les modes de connexions sans authentification sont également légion en environnement MQTT, principalement dans les Brokers publics « ouverts ». Si l’on se réfère aux chiffres d’Avast, près de 50 000 serveurs MQTT restent mal protégés les rendant vulnérables sur la toile.

Une simple recherche Shodan (www.shodan.io) sur le port par défaut (port : 1883 – sans SSL/TLS) va nous permettre de constater l’ampleur du phénomène ou de nombreux serveurs semblent être présents sans mécanismes d’authentification acceptant les utilisateurs anonymes (login/MDP laissés vide). Un script codé sous Python permettant de confirmer si l’authentification est activée par l’interrogation « Return Code » du paquet « CONNACK » apporte immédiatement réponse à notre question si oui ou non le serveur distant est sécurisé. Une vulnérabilité rendant certains objets connectés accessibles et c’est sans surprise que des données sensibles se retrouvent publiques. Des données allant d’une simple télémétrie de capteur en industrie en passant par diverses coordonnées de véhicule de livraison en circulation, états d’un système d’alarme, par des valeurs de température ou plus inquiétants, des données médicales issues d’un patient à l’autre bout du monde. Cette simple consultation peut se transformer en véritable prise de contrôle distante à l’aide d’un script Python (ou autre) tenant sur quelques lignes. Ouvrir une porte de garage ou encore modifier différentes valeurs (température, éclairage, etc.) se montre aisée pour quiconque maitrisant quelque peu les fondamentaux de MQTT associé à un zeste de codage.

Des « Brokers MQTT » en version de tests utilisés par des produits commercialisés

MQTT a toujours bénéficié de certaines faiblesses intrinsèques le rendant vulnérable dans certains cas de figure comme nous allons le voir. La plupart des « Brokers MQTT » restent malheureusement publiques. Les plus connus, « Mosquito - test.mosquitto.org » ou encore « IoT.eclipse.org » permettent comme nous l’avons vu plus haut de centraliser les données venant des capteurs. Ces Brokers utilisés à la base à des fins de tests sont utilisés par certains fabricants d’objets connectés et implantés dans leurs produits vendus dans le commerce en version finale. Cette implantation de Brokers au sein de certains objets connectés (je dis bien certains !) et qui de plus est, n’utilisent pas toujours d’authentification remets quand même sérieusement en doute l’avenir des objets connectés si conçus de cette façon. Pourtant le protocole MQTT peut se montrer particulièrement sécurisé si déployé intelligemment. Les acteurs majeurs dans le domaine MQTT ont bien pris conscience de la nature des failles intrinsèque de ce protocole.

L’avenir semble en la faveur du protocole MQTT avec une généralisation du chiffrage SSL/TLS, une meilleure gestion des identifiants de connexion associés à l’encryption tout en favorisant les connexions VPN. Peu de révolutions en sommes, mais rappelons que le protocole MQTT parfaitement conçu de base reste fiable et sécuritaire si déployé de manière intelligente. Le ratio sécurité/coût de production est une variable pas toujours respectée par les industriels. Une évolution, une standardisation de la sécurité des objets connectés ne serait pas de refus. Par manque de compétences, certains fabricants commettent de nombreuses erreurs. Cela s’est vu principalement dans le domaine de la vidéosurveillance avec des « brèches » flagrantes laissées dans un produit mis en production (exploitation login/mdp root/vizxv associé au service Telnet etc.). Cf. Dossier : Sécurité et vulnérabilités des technologies P2P, UPnP & Telnet en milieu IoT. Toutefois, la tendance semble s’inverser et de nombreux fabricants s’équipent de l’expertise d’organisme de Cybersécurité lors du développement de leurs produits. Une action louable que nous saluons grandement qui finira par porter ses fruits d’ici quelques années.

Comprendre pourquoi les fabricants n’implémentent pas de couches de sécurité supplémentaires en environnement IoT – Objets connectés

Les objets connectés peuvent être parfois véritablement limités en matière de performances (puissance de calcul, adaptation sur le réseau, etc.). L’internet des objets englobe une très grosse partie de produits à ressources limitées voir très limitées. Un simple capteur n’aura pas la vocation de pouvoir gérer de la mémoire virtuelle ni même de ROM (mémoire morte). Malgré les progrès sidérants en informatique Hardware, les objets connectés eux, n’ont que peu d’intérêt à bénéficier de la puissance de calcul d’un Smartphone. La réduction massive des coûts associés à l’optimisation énergétique des objets connectés font que ceux-ci restent (malheureusement) cantonnés à jouir d’une puissance de calcul incapable de rendre jalouse une console de jeux vidéo de 2 voire 3e génération. La loi de Moore ne s’applique que peu pour les objets connectés qui restent fatalement un monde à part, ou la performance matérielle ne fait pas partie des priorités majeures lors des phases de développement.

De ce fait, les objets connectés restent et resteront encore un bon moment des périphériques à « ressources limitées » (surtout en classe 0 – Voir tableau ci-dessous RFC 7228) limitant fortement l’exécution de mécanismes de sécurité telle l’exécution du chiffrement TLS. Cette contrainte « Hardware » vient bien souvent « entacher » la sécurité des objets connectés comme nous avons pu le voir tout au long de cet article. Un périphérique de classe 0 n’aura absolument pas la vocation de pouvoir des géré des protocoles TCP/IP. Le Hardware était tout bonnement insuffisant, celui-ci restera « dépendant » d’un serveur, d’une passerelle ou autre. Peu de chance de le voir 100% autonome. Un périphérique de type 1 bénéficiera de meilleure performance capable de prendre en charge des protocoles tels CoAP, MQTT, HTTP ou autres protocoles du même calibre. Toutefois, le niveau 1 n’offrira pas la garantie de pouvoir prendre en charge des couches de sécurité supplémentaires tel le TLS. Pour clore, le niveau 3 quant à lui sera capable de prendre en charge de très nombreux protocoles dont le chiffrement TLS/SSL sans restrictions (caméra de surveillance, Raspberry etc.). Pour terminer ce chapitre, nous ajouterons que la miniaturisation des composants permet d’apporter quelques évolutions. Sans surfer sur la croissance annuelle régie par la Loi de Moore, les objets connectés devraient bénéficier quand même au fils des années d’amélioration notoire en matière Hardware

Dossier : Protocole MQTT & IoT – Conclusion, MQTT es-t’il un protocole d’avenir ? Oui, sans aucune hésitation !

Cet article c’est appuyé sur de nombreuses ressources dont l’excellent « Building Smarter Planet Solutions With MQTT and IBM WebSphere MQ Telemetry » malheureusement non traduit dans la langue de Molière. Le protocole MQTT bien que vieux de 20 ans ne fait pas honneur sur la toile française et les articles le traitant se font plutôt rare ce qui est dommage compte tenu son déploiement à grande échelle au sein d’objets connectés ou de solutions de sécurité connectée. Ainsi, nous n’avons exclus certains détails de ce protocole, comme la présentation de cas concret d’équipementier de sécurité le déployant dans ses solutions. MQTT n’en est qu’à ses prémices malgré son âge avancé et devrait s’améliorer au fil des années par des évolutions portées plus particulièrement sur la sécurité. On espère que MQTT ne s’alourdisse que de manière modérée au fil des évolutions et qu’il restera un protocole léger comme l’avait voulu son propriétaire en 1999. Les forces de MQTT restent la sécurité du protocole si intelligemment déployé, la gestion de nombreux utilisateurs associés à une gestion fine de leurs privilèges, une gestion idéale des connexions/déconnexion, un contrôle strict des données transmises, une légèreté et de surcroît une rapidité à toute épreuve même en environnement dégradé (connexions instables, latence élevée…)

On apprécie également le protocole MQTT pour son côté « anonyme ». Avantageux pour certaines applications. À titre d’exemple, MQTT permet à l’utilisateur A recevant les informations émanant du Broker C d’une sonde A de ne pas être mis en relation avec l’utilisateur B ayant également accès aux informations du Broker C. Supporté par la plupart des services de Cloud, le protocole MQTT évolue constamment et s’intègre avec la plupart des langages de programmation. Pour clore, nous soulignerons que l’intégrité des données préservée par la notion « QoS » permet de garantir une fiabilité de transmission rendant ce protocole particulièrement séduisant. La sécurité des objets connectés est un défi de taille pour l’IoT et l’avenir semble quelque peu entaché de certaines lacunes. L’industrie de la vidéosurveillance c’est beaucoup inquiété des nombreuses attaques qui on sévit c’est dernières années. Cela se reproduira-t-il dans le domaine de la maison connecté ? Les maisons intelligentes idéalisées risquent de devoir être remises en cause plus vite que prévu si les fabricants ne « sécurisent » pas plus leurs produits connectés. Un très grand nombre d’acteurs du marché pensent et agissent en conséquence. La communauté des acteurs de l’IoT doit prendre en considération la sécurité de leurs produits, principalement sur les offres à bas coûts. Sans actions correctives ou plutôt sans changement de philosophie à ce sujet, le monde des objets connectés se transformera en véritable cauchemar numérique. Les protocoles « légers » tels que MQTT peuvent être utilisé en toute sécurité comme se retrouver être véritablement le maillon faible d’un objet connecté. L’avenir des objets connectés semble encore immature malgré la pléthore de discours ou d’actualités vantant leurs mérites. Nous espérons fortement que les portes de l’enfer ne soient pas une énième fois ré-ouvertes comme si le Concept nietzschéen de l’éternel recommencement n’avait pas suffi auparavant.