14.4.6. Betrieb: Schlüssel, Ablauf und Fehlerbehebung

Drei Aspekte der Zertifikatsarbeit betreffen jedes ausgelieferte Gerät: der Schutz des privaten Schlüssels, sobald er sich auf der Kamera befindet, die Planung für den Tag, an dem das Zertifikat abläuft, und die kurze Liste der Fehlermodi, die in der Praxis auftreten.

14.4.6.1. Schutz des privaten Schlüssels

Immer wenn die Kamera ein Zertifikat vorlegt – als TLS-Server oder als Client bei mTLS – muss ihr privater Schlüssel auf dem Gerät liegen, im reinen DER-Format, im Dateisystem oder in ROMFS. So gespeichert ist er von jedem auf der Kamera laufenden Code lesbar sowie von jeder Person mit physischem Zugang: dem USB-Massenspeicherlaufwerk, einer REPL-Eingabeaufforderung oder dem rohen Flash. ROMFS und Schreibschutz-Flags verhindern Änderung, nicht Extraktion. Behandeln Sie jeden auf einem Gerät ausgelieferten privaten Schlüssel als wiederherstellbar durch einen entschlossenen Angreifer mit physischem oder Code-Zugang.

Das macht TLS nicht sinnlos – es prägt die Art, wie Sie es einsetzen:

  • Verwenden Sie pro Gerät einen eindeutigen Schlüssel und ein eindeutiges Zertifikat. Flashen Sie niemals einen gemeinsamen Schlüssel über die gesamte Flotte: Das Extrahieren aus einem einzelnen Gerät würde es einem Angreifer dann erlauben, sich als jede Kamera auszugeben. Gerätespezifische Schlüssel beschränken eine Kompromittierung auf dieses eine Gerät, das Sie serverseitig widerrufen oder deaktivieren können.

  • Halten Sie Zertifikate kurzlebig. Ein gestohlener Schlüssel ist nur nützlich, solange sein Zertifikat gültig ist; kurze Lebensdauern plus routinemäßige Rotation begrenzen den Schaden (siehe Certificate expiry and rotation weiter unten).

  • Vermeiden Sie es nach Möglichkeit ganz, ein Geheimnis auf dem Gerät abzulegen. Wenn Sie nur den Server verifizieren müssen (Serverauthentifizierung, kein mTLS), speichert die Kamera als Client nur das CA-Zertifikat – das öffentlich ist – und besitzt keinen privaten Schlüssel, der zu stehlen lohnt.

  • Liefern Sie niemals einen Schlüssel in einem öffentlichen Firmware-Image aus. Ein in ROMFS in einem von Ihnen verteilten Firmware-Build eingebackener Schlüssel ist nicht geheim; jeder, der die Firmware herunterlädt, besitzt ihn. Gerätespezifische Bereitstellung bedeutet, den Schlüssel nach der generischen Firmware zu programmieren, nicht darin.

  • Begrenzen Sie den Schadensradius. Beschränken Sie das, was das Zertifikat authentifiziert, auf das Nötigste (geringste Rechte) und stellen Sie sicher, dass eine einzelne durchgesickerte Geräteidentität widerrufen oder deaktiviert werden kann, ohne den Rest zu beeinträchtigen.

Wenn Ihr Bedrohungsmodell Angreifer mit physischem Zugang einschließt, entwerfen Sie unter der Annahme, dass der Geräteschlüssel irgendwann durchsickern wird, und machen Sie das überlebbar, anstatt anzunehmen, er ließe sich auf Hardware geheim halten, die dazu keine Möglichkeit bietet.

14.4.6.2. Zertifikatsablauf und Rotation

Jedes Zertifikat trägt ein Gültigkeitsfenster. Sobald es überschritten ist, lehnt ein ssl.CERT_REQUIRED-Peer die Verbindung ab – der Ablauf ist also ein realer, planbarer Ausfall, kein theoretisches Risiko. Auch die Uhr der Kamera muss korrekt sein, damit die Gültigkeitsprüfung ehrlich ausgewertet werden kann.

  • Selbstsigniert. Sie haben die Lebensdauer mit -days gewählt. Wenn sie abläuft, müssen Sie den Schlüssel bzw. das Zertifikat neu erzeugen und erneut bereitstellen: die DER-Dateien neu kopieren oder das ROMFS-Image neu bauen und neu flashen, falls das Zertifikat eingebacken ist. Wählen Sie einen -days-Wert, auf den Sie auch tatsächlich rechtzeitig reagieren werden.

  • Öffentliche CA. Diese sind bewusst kurzlebig. Let’s Encrypt stellt 90-Tage-Zertifikate aus und erwartet eine automatisierte Erneuerung etwa alle 60 Tage; es gibt keine Option zum „einmal installieren und vergessen“.

Der allgemeine Trend ist einseitig: Die maximale Gültigkeit öffentlich vertrauenswürdiger TLS-Zertifikate schrumpft stetig. Sie betrug 825 Tage, ist derzeit auf 398 Tage begrenzt, und das CA/Browser Forum hat einen Fahrplan beschlossen, der sie bis 2029 schrittweise auf etwa 47 Tage senkt. Die Schlussfolgerung für ein Gerätedesign lautet, davon auszugehen, dass Zertifikate kurzlebig sind und dass die Rotation automatisiert oder zumindest routinemäßig erfolgen muss – liefern Sie kein Produkt aus, das davon abhängt, dass ein Mensch ein Zehn-Jahres-Zertifikat austauscht.

Praktisch gesehen auf der Kamera: Bevorzugen Sie Designs, bei denen das Zertifikat ohne erneutes Flashen ersetzt werden kann (ein beschreibbares Dateisystem plus ein Remote-Update-Pfad oder der Betrieb der Kamera als Client, der einer von Ihnen zentral rotierten CA vertraut). Falls ein Zertifikat in ROMFS liegen muss, planen Sie Firmware-Updates entlang seiner Lebensdauer.

14.4.6.3. Fehlerbehebung

  • Die Uhr muss gestellt sein. Eine Kamera, die seit dem Einschalten ihre Uhr nicht gestellt hat, scheitert bei der Zertifikatsgültigkeitsprüfung – rufen Sie zuerst ntptime.settime() auf.

  • Der Hostname muss übereinstimmen. Wenn der Client server_hostname übergibt, muss dieser mit dem subjectAltName des Zertifikats (oder dem CN bei älteren Stacks) übereinstimmen, sonst schlägt die Verifizierung fehl.

  • Falsches Format. Eine auf die Kamera kopierte PEM-Datei lässt sich nicht laden – konvertieren Sie sie zuerst nach DER.

  • Zertifikat abgelaufen. Eine Verbindung, die zuvor funktionierte und nun mit OSError fehlschlägt, hat möglicherweise einfach ein abgelaufenes Zertifikat – prüfen Sie die Gültigkeitsdaten und erzeugen bzw. verteilen Sie es bei Bedarf neu.

  • Ed25519-Schlüssel schlagen fehl. Verwenden Sie ECDSA P-256/P-384 oder RSA, nicht Ed25519.

  • Fehler sind OSError. MicroPython implementiert ssl.SSLError nicht; TLS-Fehler (fehlerhaftes Zertifikat, abgelaufen, unbekannte CA, Formatfehler, Handshake-Fehler) werden als OSError ausgelöst.