MQTT / TLS 1.3 — IN-SIGHT

Qu'est-ce que MQTT

MQTT (Message Queuing Telemetry Transport, ISO/IEC 20922) est un protocole de messagerie publish-subscribe conçu en 1999 par Andy Stanford-Clark (IBM) pour la télémétrie d'oléoducs sur des liaisons satellitaires à forte latence et faible bande passante. Aujourd'hui, c'est le standard de fait pour la communication IoT.

Sa conception est délibérément minimaliste : un message MQTT occupe au minimum 2 octets d'en-tête, contre les centaines d'octets de HTTP/REST. Un broker central (dans IN-SIGHT, Azure IoT Hub fait office de broker) distribue les messages aux abonnés du topic correspondant.

MQTT définit trois niveaux de Quality of Service (QoS) : QoS 0 (at-most-once, on envoie et on oublie), QoS 1 (at-least-once, confirmation de réception) et QoS 2 (exactly-once, handshake en 4 étapes). IN-SIGHT utilise QoS 1 pour la télémétrie : il accepte des doublons occasionnels en échange de la garantie qu'aucun paquet de données n'est perdu lors d'une déconnexion.

Qu'est-ce que TLS 1.3

TLS 1.3 (RFC 8446, 2018) est la version actuelle du protocole de sécurité de la couche transport. Par rapport à TLS 1.2, il introduit des améliorations critiques : le handshake se complète en 1 aller-retour (vs. 2 dans TLS 1.2), toutes les suites cryptographiques faibles sont supprimées, et le forward secrecy (ECDHE) est obligatoire — ce qui signifie que même si la clé privée d'un appareil est compromise à l'avenir, les données passées ne peuvent pas être déchiffrées.

En combinaison avec mTLS (mutual TLS), le serveur (IoT Hub) comme le client (Pod CM4) s'authentifient mutuellement avec des certificats X.509, éliminant la possibilité d'attaques de l'homme du milieu.

Rôle dans IN-SIGHT

Télémétrie périodique : Toutes les 30 s, le CM4 publie un paquet JSON compact (< 512 octets) avec les métriques de santé agrégées de l'intervalle. En condition normale, le Pod consomme ~2–4 Kbps.
Alertes immédiates : Lorsque l'EKF détecte une anomalie, le Pod publie un message d'alerte à l'instant, sans attendre le cycle de 30 s. Les propriétés du message déclenchent le routage vers la file d'alertes d'Azure IoT Hub.
Résilience dans les tunnels : Si la connexion est perdue (tunnel, zone sans couverture), le broker conserve les messages en attente (QoS 1, session persistante). Le Pod les retransmet dès que la connexion est rétablie.
Nomenclature des topics : in3/{fleet-id}/{vehicle-id}/{pod-id}/{metric-type} — la structure hiérarchique permet un abonnement sélectif depuis le portail d'exploitation sans traiter la télémétrie de toute la flotte.

Sécurité par conception : Chaque Pod dispose de sa propre paire de clés X.509 générée en usine et stockée dans un TPM (Trusted Platform Module) soudé au CM4. Les clés ne quittent jamais l'appareil. La révocation d'un Pod compromis n'affecte pas le reste de la flotte.

── Structure des topics IN-SIGHT ───────────────────────
in3/TMB/5042/pod-a/vibration     ← métriques bogie
in3/TMB/5042/pod-b/door-cycle    ← métriques portes
in3/TMB/5042/pod-a/alert         ← alertes EKF
in3/TMB/5042/$twin               ← sync Device Twin

── Charge utile télémétrie normale (exemple) ───────────
{
  "ts": "2026-06-17T10:22:05.412Z",
  "v":  "1.4.2",
  "rms": 0.42,
  "peak_freq": 87.3,
  "temp_c": 38.1,
  "ekf_innov": 0.031
}