Provisionnement sécurisé des appareils IoT pour les parcs MQTT

Le provisionnement sécurisé des appareils IoT consiste à donner à chaque appareil une identité unique et les identifiants dont il a besoin pour joindre votre broker MQTT, sans que ces secrets fuient en chemin. Ce guide compare les principaux modèles de provisionnement, détaille un flux de bootstrap concret et montre comment des appareils provisionnés se connectent à un broker ConnectMQ avec des identifiants par appareil.

Ce que le provisionnement doit garantir

Quel que soit le modèle choisi, un bon processus de provisionnement apporte cinq propriétés :

1. L'unicité. Chaque appareil reçoit son propre identifiant. Deux appareils ne partagent jamais un secret.
2. La confidentialité. Le secret n'est jamais visible en clair pour les personnes ou les systèmes qui n'en ont pas besoin, y compris les journaux et les artefacts de build.
3. La traçabilité. Vous pouvez associer chaque identifiant à un numéro de série, un lot et un client.
4. La révocabilité. Vous pouvez désactiver un appareil sans toucher aux autres.
5. La récupérabilité. Vous pouvez reprovisionner un appareil après une réparation ou une réinitialisation d'usine.

Un mot de passe partagé compilé dans le firmware échoue sur au moins trois de ces points. C'est la raison la plus fréquente pour laquelle une seule unité compromise se transforme en incident à l'échelle du parc.

Comparaison des modèles de provisionnement

Provisionnement en usine

Pendant la fabrication, un poste de programmation génère ou récupère un identifiant unique et l'écrit dans le stockage protégé de l'appareil, généralement avec le numéro de série. Sur les microcontrôleurs, il s'agit souvent d'une partition NVS chiffrée ou d'un élément sécurisé ; sur les appareils Linux, d'un fichier chiffré ou d'un stockage adossé à un TPM. Le poste enregistre la correspondance dans votre système d'inventaire, jamais le secret lui-même en clair.

Points forts : les appareils sortent de l'usine prêts à se connecter. Points faibles : le réseau de l'usine manipule désormais des secrets ; il lui faut donc un contrôle d'accès et sa propre piste d'audit, et vous devez faire confiance au fabricant.

Claim certificates et flux de bootstrap

Un claim certificate est une identité limitée partagée par un lot d'appareils. Sa seule permission est d'appeler un service de provisionnement pour demander une identité unique et durable. Plusieurs plateformes IoT implémentent ce modèle, et vous pouvez construire la même idée vous-même avec n'importe quel broker :

1. L'appareil démarre avec un secret de bootstrap ou un claim certificate et son numéro de série matériel.
2. Il appelle votre service de provisionnement en HTTPS, en prouvant qu'il possède le secret de bootstrap.
3. Le service vérifie le numéro de série dans la liste autorisée de fabrication et s'assure qu'il n'a pas déjà été réclamé.
4. Le service renvoie un identifiant MQTT unique pour cet appareil et marque le numéro de série comme réclamé.
5. L'appareil stocke l'identifiant dans un stockage protégé et supprime le secret de bootstrap, ou ne le conserve que pour un reprovisionnement.

Comme l'identité de claim ne peut ni publier ni s'abonner à quoi que ce soit, une copie divulguée permet au mieux à un attaquant de réclamer des numéros de série encore non réclamés, et la liste autorisée combinée à la réclamation unique limite même ce risque.

Mise en service assistée par l'utilisateur

Les appareils grand public sont souvent provisionnés par leur propriétaire via une application qui se connecte à l'appareil en BLE ou par un point d'accès Wi-Fi temporaire. Chiffrez ce canal local, exigez une preuve de présence physique comme l'appui sur un bouton, et faites en sorte que l'application récupère l'identifiant de l'appareil depuis votre backend plutôt que d'embarquer quoi que ce soit dans l'application.

Un flux de bootstrap concret pour un broker MQTT

Si votre broker émet lui-même les identifiants, comme le fait généralement un broker MQTT managé, votre service de provisionnement devient le dépositaire qui distribue les identifiants un appareil à la fois. Avec ConnectMQ, vous émettez les identifiants dans le portail ; chaque jeu comprend un nom d'utilisateur, un mot de passe et un client ID lié à ces identifiants. Une conception simple et robuste :

• Émettez des jeux d'identifiants dans le portail avant un lot de production.
• Chargez-les dans le stockage chiffré de votre service de provisionnement, un par numéro de série attendu.
• Laissez les appareils les réclamer via le flux de bootstrap ci-dessus.

Un endpoint de provisionnement minimal, écrit en Python avec Flask à titre d'illustration :

# pip install flask
import hmac
import hashlib
import json
from flask import Flask, request, jsonify, abort

app = Flask(__name__)
BOOTSTRAP_KEY = b"load-from-a-secret-manager-not-source"

# serial -> {"claimed": bool, "cred": {...}}  (utiliser une vraie base de données en production)
INVENTORY = json.load(open("batch-2026-10.json"))

def valid_proof(serial: str, nonce: str, proof: str) -> bool:
    expected = hmac.new(BOOTSTRAP_KEY, f"{serial}:{nonce}".encode(),
                        hashlib.sha256).hexdigest()
    return hmac.compare_digest(expected, proof)

@app.post("/provision")
def provision():
    body = request.get_json(force=True)
    serial, nonce, proof = body.get("serial"), body.get("nonce"), body.get("proof")
    if not (serial and nonce and proof) or not valid_proof(serial, nonce, proof):
        abort(401)
    entry = INVENTORY.get(serial)
    if entry is None or entry["claimed"]:
        abort(403)
    entry["claimed"] = True        # en production, persister ceci avant de répondre
    return jsonify(entry["cred"])  # {"username": ..., "password": ..., "client_id": ...}

if __name__ == "__main__":
    # Servir derrière HTTPS (reverse proxy avec un certificat valide)
    app.run(host="127.0.0.1", port=8080)

En production, stockez les nonces pour empêcher le rejeu, limitez le débit de l'endpoint, persistez l'indicateur de réclamation de façon atomique et déclenchez une alerte en cas de réclamations répétées du même numéro de série.

Connecter un appareil provisionné

Une fois que l'appareil détient son identifiant, la connexion relève de l'authentification MQTT par nom d'utilisateur et mot de passe classique via TLS. Voici un exemple ESP32 avec PubSubClient qui lit l'identifiant depuis la NVS :

#include <WiFi.h>
#include <WiFiClientSecure.h>
#include <PubSubClient.h>
#include <Preferences.h>

extern const char ROOT_CA[];   // PEM ISRG Root X1, compilé dans le firmware

WiFiClientSecure net;
PubSubClient mqtt(net);
Preferences prefs;
String user, pass, clientId;

void setup() {
  Serial.begin(115200);
  prefs.begin("mqtt", true);                 // namespace en lecture seule
  user = prefs.getString("user", "");
  pass = prefs.getString("pass", "");
  clientId = prefs.getString("cid", "");
  prefs.end();
  if (user.isEmpty()) { Serial.println("Not provisioned"); return; }

  WiFi.begin("YOUR_SSID", "YOUR_WIFI_PASSWORD");
  while (WiFi.status() != WL_CONNECTED) delay(500);

  net.setCACert(ROOT_CA);
  mqtt.setServer("YOUR_BROKER_HOST", 8883);
}

void loop() {
  if (user.isEmpty()) { delay(1000); return; }   // attendre le provisionnement
  if (!mqtt.connected()) {
    if (mqtt.connect(clientId.c_str(), user.c_str(), pass.c_str())) {
      mqtt.publish(("devices/" + clientId + "/status").c_str(), "online", true);
    } else {
      Serial.printf("MQTT connect failed, state=%d\n", mqtt.state());
      delay(10000);                          // temporiser, ne pas marteler le broker
    }
  }
  mqtt.loop();
}

Activez le chiffrement de la flash et de la NVS pour que l'identifiant stocké ne soit pas lisible depuis une puce flash extraite. Les détails figurent dans sécuriser les identifiants MQTT sur les appareils.

Reprovisionnement, réparations et mise hors service

Le provisionnement n'est pas un événement ponctuel. Les appareils reviennent en réparation, sont réinitialisés par les clients, changent de propriétaire et finissent par arriver en fin de vie. Planifiez chacun de ces parcours avant l'expédition du premier lot :

• Réinitialisation d'usine. Décidez si une réinitialisation efface l'identifiant MQTT. Si c'est le cas, l'appareil doit pouvoir revenir au flux de bootstrap, ce qui signifie que votre service de provisionnement doit autoriser une nouvelle réclamation contrôlée, par exemple après qu'un ticket de support a marqué le numéro de série comme réinitialisable.
• Réparations et remplacements de carte. Lorsqu'une carte principale est remplacée, l'ancien identifiant part avec l'ancienne carte. Révoquez-le, émettez un nouveau jeu et mettez à jour l'inventaire pour que le numéro de série pointe vers le nouveau client ID.
• Changement de propriétaire. Pour les appareils vendus ou transférés entre clients, émettez de nouveaux identifiants sur un broker appartenant au nouveau propriétaire plutôt que de déplacer les anciens.
• Mise hors service. Révoquez l'identifiant dans le portail le jour où l'appareil quitte le service, et notez la date. Des identifiants abandonnés mais toujours valides sont une source fréquente de connexions inattendues des mois plus tard.

Chacun de ces parcours réutilise les mêmes briques que le provisionnement initial et la rotation des identifiants : émettre, livrer, vérifier, révoquer.

Checklist de provisionnement

1. Un identifiant unique par appareil, jamais un mot de passe commun à tout le parc.
2. Des secrets générés ou émis de façon centralisée, pas inventés par les ingénieurs firmware.
3. Une identité de bootstrap limitée au seul provisionnement, avec réclamation unique et liste autorisée.
4. Des identifiants stockés dans un stockage chiffré ou un élément sécurisé.
5. TLS avec vérification du certificat sur chaque connexion, y compris l'appel de provisionnement.
6. Un inventaire associant numéro de série et client ID, sans secrets en clair.
7. Un parcours éprouvé de reprovisionnement et de rotation des identifiants.
8. Un backoff en cas d'échec d'authentification ; ConnectMQ bloque les IP après des échecs de connexion répétés.

Planifier la capacité et les environnements

Le provisionnement interagit avec les limites des offres. L'offre Serverless (Free) autorise jusqu'à 25 connexions, ce qui suffit pour un pilote ; Serverless (Paid) va jusqu'à 1 000 connexions, et les offres Dedicated ou BYOC conviennent aux parcs plus grands ou réglementés. Gardez des brokers séparés pour le développement, la préproduction et la production afin que les appareils de test ne détiennent jamais d'identifiants de production, et n'utilisez le serveur MQTT public gratuit que pour des expériences non sensibles.

Démarrer avec ConnectMQ

Provisionnez vos premiers appareils sur un broker MQTT cloud avec TLS, isolation des tenants et client IDs liés aux identifiants émis. Créez gratuitement un broker Serverless sur app.connectmq.com, sans carte bancaire.

Questions fréquentes

Qu'est-ce que le provisionnement sécurisé des appareils IoT ?

C'est le processus qui consiste à donner à chaque appareil une identité et des identifiants uniques, à les livrer sans les exposer et à les enregistrer pour pouvoir les tracer et les révoquer ultérieurement.

Qu'est-ce qu'un claim certificate ?

Un claim certificate est une identité limitée, souvent partagée par un lot, dont la seule permission est de demander un identifiant d'appareil unique à un service de provisionnement lors du premier démarrage.

Faut-il embarquer les identifiants MQTT dans les images firmware ?

Non. Une image firmware est copiée de nombreuses fois et souvent facile à extraire. Écrivez plutôt des identifiants uniques dans le stockage protégé de chaque appareil.

ConnectMQ fournit-il un service de provisionnement d'appareils ?

Non. Vous émettez les identifiants dans le portail ConnectMQ et les livrez avec votre propre processus en usine ou de bootstrap, comme indiqué ci-dessus.