Intro au protocole MQTT et son (in)sécurité pour les échanges M2M / IoT

de | 18 août 2017

Le protocole MQTT (Message Queuing Telemetry Transport) se distingue par sa capacité à transmettre des messages courts et une utilisation faible de la bande passante qui le rendent adapté pour les communications M2M (machine 2 machine) de type objets connectés.

Ce protocole est principalement utilisé pour la remontée d’information d’objets connectés destinés aux particuliers. Quelques implémentations dans les objets connectés du monde industriel ont été réalisées

Cet article a pour objectif de donner quelques éclairages sur les principales fonctionnalités de ce protocole, qui existe depuis 1999, et les fonctions de sécurité qu’il propose voire des fonctions complémentaires à envisager lors de son utilisation.

Un peu d’histoire

Créé en 1999 par Andy Stanford-Clark d’IBM  et Arlen Nipper lorsqu’il présidait Arcom Control Systems, le protocole MQTT a été standardisé en novembre 2014 par l’OASIS dans sa version 3.1 [1] puis intégré comme norme par l’ISO en janvier 2016 sous le référence ISO/IEC 20922.

Sa notoriété est née en 2011 lorsque facebook a annoncé son utilisation dans sa nouvelle application Facebook Messenger pour les mobiles Android et iPhone afin d’accélérer la transmission des messages, maintenir les sessions actives, et ce, sans consommation excessive de la batterie [2]. Par ailleurs, les communications entre deux personnes ou un groupe de personnes sont permises nativement par ce protocole grâce à son modèle par abonnement.

Son fonctionnement

MQTT fonctionne sur un modèle client/serveur par abonnement (publish-subscribe) :

  • Un programme ou objet connecté représente le client qui se connecte systématiquement au serveur. Le client peut
    • Transmettre des messages successibles d’intéresser d’autres clients
    • S’abonner (suscribe) afin de collecter les messages qui l’intéressent
    • Se désabonner d’un serveur
    • Se déconnecter d’un serveur
  • Un serveur, désigné par Broker, qui peut
    • Accepter les connexions depuis les clients
    • Collecter les messages, à publier (publish), transmis par les clients
    • Traiter les demandes d’abonnement et de désabonnement
    • Transférer les messages auxquels sont abonnés les clients

L’abonnement consiste en un sujet et une qualité de service (QoS) :

Le sujet est un élément d’une arborescence : s’abonner à un sujet permet d’accéder à son contenu qui peut être une valeur ou, grâce à la valeur #, aux valeurs de ses sous-sujets. Pour illustrer le point, ci-dessous un exemple d’une maison connecté avec des sujets et sous-sujets :

  • Maison
    • Pièces
      • Pièces 1
        • Température
        • Humidité
        • Alarme
        • Lumière 1
      • Pièce 2
        • Température
        • Humidité
        • Alarme
        • Lumière
      • Cuisine
        • Température
        • Humidité
        • Alarme
        • Lumière
    • Garage
      • Porte
      • Alarme
      • AlarmeLumière 1

Ainsi :

  • Le capteur de température 1 : écrit dans le sujet Maison/Chambres/Chambre 1/température.
  • Le capteur d’humidité 1 : écrit dans le sujet Maison/Chambres/Chambre 2/humidité
  • Le système de climatisation de la chambre 1 s’abonnera au topic Maison/Chambres/Chambre 1 afin de disposer de la température dans celle-ci et ainsi réguler la température de la pièce 1 en été.
  • Là où la chaudière s’abonnera au topic Maison/Pièces/# afin disposer des informations de l’ensemble des pièces, de leur température et ainsi réguler la température de chaque pièce de la maison en hiver.
  • L’application mobile de gestion de la maison s’abonnera au sujet Maison/# pour disposer de l’ensemble des sous-sujets et présenter l’état de la maison à son propriétaire (température et humidité de l’ensemble des pièces ainsi que l’état de la porte du garage qui peut être ouverte ou fermée)

Le standard détail l’ensemble des échanges entre un client et un serveur ainsi que le format des messages qui transitent.

La qualité de service (QoS) des échanges des messages :

Un niveau de qualité s’applique au message qu’il soit transmis depuis le client vers le serveur ou depuis le serveur vers le client. Dans le cas d’abonnements multiples vers un serveur, la qualité de service de chaque abonnement est gérée individuellement.

Il existe trois niveaux de qualité de service :

  • QoS 0 : transmission de message sans accusé de réception
  • QoS 1 : transmission de message avec accusé de réception
  • Qos 2 : transmission de message avec accusé de réception et vérification du message transmis afin d’éviter qu’un même message ne soit pas transmis de nombreuses fois.

À l’ouverture d’une connexion entre un client et un serveur, un niveau de qualité de service est intégré aux échanges qui initialisent les transmissions des messages.

A noter que le protocole étant de haut niveau, les messages MQTT peuvent être transportés sur tout type de connectivité : filaire, wifi ou radio.

Un flux entre un client et un serveur utilise exclusivement TCP (port 1883) ou accessoirement TLS (port 8883) ou une websocket (80 en standard ou 443 si encapsulation dans un flux TLS).

Les principales limites du protocole

La première est liée au modèle d’architecture de type Message-oriented middleware (MOM) sur lequel MQTT se base, le passage par un broker altère le caractère synchrone des échanges.

La seconde est inhérente à un déploiement d’un très grand nombre de clients, en l’occurrence des objets connectés, la norme ne prévoit aucun modèle d’architecture distribué. C’est à la solution qui implémentera le broker MQTT de prendre en charge sa scalabilité.

La dernière limite se situe au niveau de l’interopérabilité entre différentes solutions utilisées au niveau des clients et des brokers : avant la standardisation en 2014 de MQTT, un peu plus de la moitié des solutions disponibles sur le marché étaient interopérables [3]. Ce résultat avait été considéré à l’époque comme très positifs, pas certain qu’il le soit toujours aujourd’hui avec la généralisation des objets connectés et la démultiplication des solutions dédiées au M2M/IoT.

Son adoption

De nombreuses solutions de type MQTT brokers existent :

On-prem’s :
  • Red Hat JBoss A-MQ (Open source)
  • VerneMQ  (Open source)
  • mosquitto (Open source)
  • IBM MessageSight
  • HiveMQ
  • WSO2 message broker

Dans le Cloud :

  • CloudMQTT (solution hébergée dans le Cloud AWS)
  • AWS IoT (Issue du rachat de 2lementry)
  • Micrisoft azure iot hub
  • Google CLOUD IOT CORE (PRIVATE BETA)
  • IBM Watson Internet of Things
  • xively
  • ClearBlade

Les mécanismes de sécurité décrits dans la norme

La norme indique que chaque message transmis au serveur doit être accompagné d’un identifiant unique du client, et de manière optionnelle, un nom d’utilisateur et un mot de passe associé… sans imposer les modalités de protection de l’intégrité et la confidentialité du couple nom d’utilisateur et mot de passe lors du transit. Ce choix du modèle d’authentification ne prend pas en compte la complexité liée à la sécurisation du stockage de ces données sensibles dans un équipement qui peut être installé dans un environnement non-sûr, pour ne pas dire hostile  (une personne malveillante peut facilement ouvrir l’équipement y connecter ses propres outils afin d’en extraire des données lui permettant de se connecter aux systèmes centraux auxquels les objets se connectent).

La norme introduit la notion d’autorisation pour l’accès à un sujet… sans en décrire le modèle à utiliser (ACL, xBAC, etc.).

Et, that’s all folks, rien de plus de normatif sur le protocole.

Néanmoins, la norme intègre, dans son dernier chapitre des orientations, dixit « non-normatives », pour sécuriser les échanges entre les clients MQTT et un broker MQTT.

Les orientations mettent l’accent sur :

  1. L’utilisation du protocole TLS pour la sécurité des échanges voire l’authentification de la communication à travers des certificats (NDA: il est fortement conseiller d’utiliser la dernière version de TLS et de bloquer les versions antérieures.à la date de la rédaction de cet article = TLS v1.3)
  2. La supervision de sécurité pour détecter les compromissions des client MQTT ainsi que leurs activités anormales (connections continues, pas de transmission de message, abonnement ou accès à plusieurs sujets simultanément, etc.)

Du fait que la sécurité soit optionnelle dans la norme, de nombreuses mises en oeuvre ne sont pas sécurisées. Un scanne d’Internet semble avoir démontré que 87 000 brokers MQTT accessibles, sans sécurité, sur Internet et assurer des services à des pacemakers ou encore à des prisons ce qui permettaient de prendre le contrôle des portes de celle-ci.


En conclusion, il est impératif de mettre en œuvre systématiquement les orientations décrites dans la norme.

Il ne faudra pas baser l’authentification sur l’identifiant et un mot de passe décrit dans la norme, mais sur une authentification mutuelle (client <>broker) basée sur la dernière version du protocole TLS, ceci afin de rester conforme à la norme et assurer l’intéropérabilité. Se pose alors la sécurité des authentifiants pour le TLS qui seront stockés dans l’objet… mais cela est un autre débat hors MQTT.

Une alternative existe à MQTT : il agit du protocole radio Z-Ware [5] fortement utilisé dans la domotique et qui adresse toute les couches de communication et de sécurité. Ce protocole a un unique inconvénient : il nécessite des interfaces physiques de communication spécifiques.

Un prochain article adressera les mécanismes de sécurité complémentaires des solutions de broker MQTT et, notamment, celles proposées dans le cloud.

Les références

[1] MQTT Version 3.1.1 Plus Errata 01 http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html

[2] Building Facebook Messenger https://www.facebook.com/notes/facebook-engineering/building-facebook-messenger/10150259350998920

[3]  MQTT Interop Test Day Report March 17, 2014 https://iot.eclipse.org/documents/2014-04-08-MQTT-Interop-test-day-report.html

[4] Exposed IoT servers let hackers unlock prison cells, modify pacemakers http://www.zdnet.com/article/exposed-servers-hack-prison-cells-alter-pacemakers/

[5]  Z-Wave https://fr.wikipedia.org/wiki/Z-Wave

 

 

 

 

 

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *