Sichere IoT-Geräte-Provisionierung für MQTT-Flotten

Sichere IoT-Geräte-Provisionierung ist der Prozess, jedem Gerät eine eindeutige Identität und die Zugangsdaten zu geben, die es für Ihren MQTT-Broker braucht, ohne dass diese Geheimnisse unterwegs durchsickern. Dieser Leitfaden vergleicht die wichtigsten Provisionierungsmodelle, führt durch einen praxistauglichen Bootstrap-Ablauf und zeigt, wie sich provisionierte Geräte mit Zugangsdaten pro Gerät mit einem ConnectMQ-Broker verbinden.

Was Provisionierung leisten muss

Egal für welches Modell Sie sich entscheiden, ein guter Provisionierungsprozess erfüllt fünf Eigenschaften:

1. Eindeutigkeit. Jedes Gerät erhält eigene Zugangsdaten. Keine zwei Geräte teilen sich ein Geheimnis.
2. Vertraulichkeit. Das Geheimnis ist für Personen oder Systeme, die es nicht brauchen, nie im Klartext sichtbar, auch nicht in Logs und Build-Artefakten.
3. Nachvollziehbarkeit. Sie können alle Zugangsdaten einer Seriennummer, einer Charge und einem Kunden zuordnen, idealerweise verknüpft mit dem Fertigungsauftrag in MES oder ERP.
4. Widerrufbarkeit. Sie können ein einzelnes Gerät deaktivieren, ohne die anderen anzufassen.
5. Wiederherstellbarkeit. Sie können ein Gerät nach einer Reparatur oder einem Werksreset neu provisionieren.

Ein gemeinsames, in die Firmware kompiliertes Passwort verfehlt mindestens drei davon. Es ist der häufigste Grund, warum aus einem einzelnen kompromittierten Gerät ein flottenweiter Vorfall wird.

Für Hersteller im DACH-Raum ist das längst nicht mehr nur eine Frage guter Praxis. Der EU Cyber Resilience Act verlangt für vernetzte Produkte unter anderem eine sichere Standardkonfiguration und Schutz vor unbefugtem Zugriff, und IEC 62443-4-2 formuliert Anforderungen an die Identifikation und Authentifizierung industrieller Komponenten. Ein Maschinenbauer, der Anlagen mit einem Edge-Gateway für Fernwartung und Maschinendaten ausliefert, sollte die Provisionierung deshalb als Teil des Fertigungs- und Qualitätsprozesses planen, nicht als nachträgliches Firmware-Detail.

Provisionierungsmodelle im Vergleich

Provisionierung im Werk

Während der Fertigung erzeugt oder holt eine Programmierstation eindeutige Zugangsdaten und schreibt sie, meist zusammen mit der Seriennummer, in einen geschützten Speicher auf dem Gerät. Auf Mikrocontrollern ist das oft eine verschlüsselte NVS-Partition oder ein Secure Element, auf Linux-Geräten eine verschlüsselte Datei oder ein TPM-gestützter Speicher. Die Station protokolliert die Zuordnung in Ihrem Inventarsystem, niemals aber das Geheimnis selbst im Klartext.

Stärken: Geräte verlassen das Werk verbindungsbereit. Schwächen: Das Fabriknetz verarbeitet nun Geheimnisse und braucht daher Zugriffskontrolle und einen eigenen Audit-Trail, und Sie müssen dem Hersteller vertrauen.

Claim-Zertifikate und Bootstrap-Abläufe

Ein Claim-Zertifikat ist eine eingeschränkte Identität, die sich eine Charge von Geräten teilt. Seine einzige Berechtigung besteht darin, einen Provisionierungsdienst aufzurufen und eine eindeutige, langfristige Identität anzufordern. Mehrere IoT-Plattformen setzen dieses Muster um, und Sie können dieselbe Idee mit jedem Broker selbst bauen:

1. Das Gerät startet mit einem Bootstrap-Geheimnis oder Claim-Zertifikat und seiner Hardware-Seriennummer.
2. Es ruft Ihren Provisionierungsdienst über HTTPS auf und weist den Besitz des Bootstrap-Geheimnisses nach.
3. Der Dienst prüft die Seriennummer gegen die Allowlist aus der Fertigung und stellt sicher, dass sie noch nicht beansprucht wurde.
4. Der Dienst gibt eindeutige MQTT-Zugangsdaten für dieses Gerät zurück und markiert die Seriennummer als beansprucht.
5. Das Gerät speichert die Zugangsdaten in geschütztem Speicher und verwirft das Bootstrap-Geheimnis oder behält es nur für eine erneute Provisionierung.

Da die Claim-Identität nichts publizieren oder abonnieren kann, erlaubt eine geleakte Kopie einem Angreifer höchstens, noch nicht beanspruchte Seriennummern zu beanspruchen, und selbst das begrenzen Allowlist und einmalige Beanspruchung.

Nutzergestütztes Onboarding

Consumer-Geräte werden oft vom Besitzer über eine App provisioniert, die sich per BLE oder über einen temporären WLAN-Access-Point mit dem Gerät verbindet. Verschlüsseln Sie diesen lokalen Kanal, verlangen Sie einen Nachweis physischer Anwesenheit wie einen Tastendruck, und lassen Sie die App die Gerätezugangsdaten von Ihrem Backend holen, statt etwas in die App einzubetten.

Ein praxistauglicher Bootstrap-Ablauf für einen MQTT-Broker

Wenn Ihr Broker Zugangsdaten selbst ausstellt, wie es ein verwalteter MQTT-Broker üblicherweise tut, wird Ihr Provisionierungsdienst zum Verwalter, der Zugangsdaten Gerät für Gerät ausgibt. Bei ConnectMQ stellen Sie Zugangsdaten im Portal aus; jeder Satz enthält einen Benutzernamen, ein Passwort und eine Client ID, die an diese Zugangsdaten gebunden ist. Ein einfaches, robustes Design:

• Stellen Sie vor einer Produktionscharge Sätze von Zugangsdaten im Portal aus.
• Laden Sie sie in den verschlüsselten Speicher Ihres Provisionierungsdienstes, einen pro erwarteter Seriennummer.
• Lassen Sie die Geräte sie über den oben beschriebenen Bootstrap-Ablauf beanspruchen.

Ein minimaler Provisionierungs-Endpunkt, zur Veranschaulichung in Python mit Flask geschrieben:

# 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"

# Seriennummer -> {"claimed": bool, "cred": {...}}  (in Produktion eine echte Datenbank verwenden)
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        # in Produktion vor der Antwort persistieren
    return jsonify(entry["cred"])  # {"username": ..., "password": ..., "client_id": ...}

if __name__ == "__main__":
    # Hinter HTTPS betreiben (Reverse Proxy mit gültigem Zertifikat)
    app.run(host="127.0.0.1", port=8080)

Speichern Sie in Produktion Nonces, um Replay-Angriffe zu verhindern, begrenzen Sie die Anfragerate des Endpunkts, persistieren Sie das Claimed-Flag atomar und lösen Sie bei wiederholten Beanspruchungen derselben Seriennummer einen Alarm aus.

Ein provisioniertes Gerät verbinden

Sobald das Gerät seine Zugangsdaten besitzt, ist die Verbindung gewöhnliche MQTT-Authentifizierung mit Benutzername und Passwort über TLS. Ein ESP32-Beispiel mit PubSubClient, das die Zugangsdaten aus dem NVS liest:

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

extern const char ROOT_CA[];   // ISRG Root X1 PEM, in die Firmware kompiliert

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

void setup() {
  Serial.begin(115200);
  prefs.begin("mqtt", true);                 // schreibgeschützter Namespace
  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; }   // auf Provisionierung warten
  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);                          // zurückhalten, den Broker nicht überlasten
    }
  }
  mqtt.loop();
}

Aktivieren Sie Flash- und NVS-Verschlüsselung, damit die gespeicherten Zugangsdaten nicht aus einem ausgelesenen Flash-Chip gelesen werden können. Details finden Sie unter MQTT-Zugangsdaten auf Geräten schützen.

Neu-Provisionierung, Reparaturen und Außerbetriebnahme

Provisionierung ist kein einmaliges Ereignis. Geräte kommen zur Reparatur zurück, werden von Kunden auf Werkseinstellungen zurückgesetzt, wechseln den Besitzer und erreichen irgendwann ihr Lebensende. Planen Sie jeden dieser Wege, bevor die erste Charge ausgeliefert wird:

• Werksreset. Legen Sie fest, ob ein Reset die MQTT-Zugangsdaten löscht. Wenn ja, braucht das Gerät einen Weg zurück in den Bootstrap-Ablauf, das heißt, Ihr Provisionierungsdienst muss eine kontrollierte erneute Beanspruchung erlauben, etwa nachdem ein Support-Ticket die Seriennummer als rücksetzbar markiert hat.
• Reparatur und Platinentausch. Wird eine Hauptplatine ersetzt, gehen die alten Zugangsdaten mit der alten Platine. Widerrufen Sie sie, stellen Sie einen neuen Satz aus und aktualisieren Sie das Inventar, sodass die Seriennummer auf die neue Client ID verweist.
• Besitzerwechsel. Bei Geräten, die zwischen Kunden verkauft oder übertragen werden, stellen Sie neue Zugangsdaten auf einem Broker des neuen Besitzers aus, statt die alten zu übertragen.
• Außerbetriebnahme. Widerrufen Sie die Zugangsdaten im Portal an dem Tag, an dem das Gerät außer Betrieb geht, und dokumentieren Sie das Datum. Vergessene, aber noch funktionierende Zugangsdaten sind eine häufige Quelle überraschender Verbindungen Monate später.

Jeder dieser Wege nutzt dieselben Bausteine wie die Erstprovisionierung und die Rotation von Zugangsdaten: ausstellen, ausliefern, prüfen, widerrufen.

Checkliste für die Provisionierung

1. Eindeutige Zugangsdaten pro Gerät, niemals ein flottenweites Passwort.
2. Geheimnisse werden zentral erzeugt oder ausgestellt, nicht von Firmware-Entwicklern erfunden.
3. Die Bootstrap-Identität ist auf die Provisionierung beschränkt, mit einmaliger Beanspruchung und Allowlist.
4. Zugangsdaten liegen in verschlüsseltem Speicher oder einem Secure Element.
5. TLS mit Zertifikatsprüfung bei jeder Verbindung, auch beim Provisionierungsaufruf.
6. Das Inventar ordnet Seriennummern Client IDs zu, ohne Geheimnisse im Klartext.
7. Ein erprobter Weg für Neu-Provisionierung und Rotation von Zugangsdaten.
8. Backoff bei Authentifizierungsfehlern; ConnectMQ sperrt IPs nach wiederholten fehlgeschlagenen Logins.

Kapazität und Umgebungen planen

Provisionierung hängt mit den Plan-Limits zusammen. Der Plan Serverless (Free) erlaubt bis zu 25 Verbindungen, was für ein Pilotprojekt reicht; Serverless (Paid) geht bis zu 1.000 Verbindungen, und Dedicated- oder BYOC-Pläne eignen sich für größere oder regulierte Flotten. Halten Sie getrennte Broker für Entwicklung, Staging und Produktion, damit Testgeräte nie Produktionszugangsdaten besitzen, und nutzen Sie den öffentlichen MQTT-Broker nur für Tests und Prototypen ohne sensible Daten oder Produktionsdaten.

Starten Sie mit ConnectMQ

Provisionieren Sie Ihre ersten Geräte gegen einen Cloud-MQTT-Broker mit TLS, Mandantenisolation und an ausgestellte Zugangsdaten gebundenen Client IDs. Erstellen Sie unter app.connectmq.com einen kostenlosen Serverless-Broker, ganz ohne Kreditkarte.

Häufig gestellte Fragen

Was ist sichere IoT-Geräte-Provisionierung?

Der Prozess, jedem Gerät eine eindeutige Identität und Zugangsdaten zu geben, sie ohne Offenlegung auszuliefern und sie so zu erfassen, dass sie später nachverfolgt und widerrufen werden können.

Was ist ein Claim-Zertifikat?

Ein Claim-Zertifikat ist eine eingeschränkte, oft von einer ganzen Charge geteilte Identität, deren einzige Berechtigung darin besteht, beim ersten Start eindeutige Gerätezugangsdaten von einem Provisionierungsdienst anzufordern.

Sollte ich MQTT-Zugangsdaten in Firmware-Images einbetten?

Nein. Ein Firmware-Image wird vielfach kopiert und lässt sich oft leicht extrahieren. Schreiben Sie stattdessen eindeutige Zugangsdaten pro Gerät in geschützten Speicher.

Bietet ConnectMQ einen Dienst zur Geräte-Provisionierung?

Nein. Sie stellen Zugangsdaten im ConnectMQ-Portal aus und liefern sie mit Ihrem eigenen Werks- oder Bootstrap-Prozess aus, wie oben gezeigt.