Zusammenfassung

  • draft-mittal-est-coap-ca-certs-00 schlägt vor, dass ein Gerät mit einem werkseitigen Hersteller-Trust-Anchor ein CMS-signiertes Bündel operativer CA-Zertifikate prüft. Es ist ein individueller Internet-Draft in Revision 00, kein RFC, kein IETF-Konsens und kein Einsatznachweis.
  • Der Bootstrap-Server darf noch unauthentifiziert sein. TLS oder DTLS transportiert nur; die Signatur autorisiert das begrenzte Objekt, das zusätzlich Zweck, Alias, Sequenz, Gültigkeit und lokale Richtlinie erfüllen muss.
  • Die Installation authentifiziert den bisherigen Server nicht rückwirkend. Für jede normale EST-Funktion muss der Client eine neue Sitzung aufbauen, den Server unter den neuen Ankern prüfen und Enrollment als weiteren Vorgang behandeln.

Das erste Vertrauen eines Geräts entsteht oft Jahre vor seiner ersten produktiven Verbindung. Der Hersteller kennt das Gerät, aber noch nicht die PKI des späteren Betreibers. Der Betreiber kennt seine CA, doch das Gerät kann ihren EST-Server nicht prüfen, bevor es genau diese CA erhalten hat.

Der individuelle Entwurf draft-mittal-est-coap-ca-certs-00 löst den Kreis, indem er die Autorisierung in ein signiertes Objekt legt. Der Hersteller oder eine von ihm autorisierte Stelle erstellt ein CMS-SignedData-Objekt mit den operativen CA-Zertifikaten. Ein EST-Server veröffentlicht es unter einem herstellerspezifischen Alias.

Der Client darf das Objekt über TLS/DTLS abrufen, obwohl das präsentierte Serverzertifikat noch nicht gegen die künftige operative CA validiert werden kann. Für tatsächlich öffentliche Metadaten lässt der Text sogar Klartext-HTTP oder -CoAP zu. Die Herkunft des Objekts folgt aus der Herstellersignatur, nicht aus dem Transport.

Die Ausnahme ist sinnvoll, solange sie schmal bleibt. Ein echtes Objekt macht seinen Relay nicht echt. Verschlüsselung macht aus einem nicht geprüften Peer keine autorisierte EST-Stelle. Ein installierter Anker genehmigt noch keinen Zertifikatsantrag.

Die Signatur gilt den Bytes, nicht dem Anschluss

ManufacturerSignedCACerts bindet Version, Alias, steigende Sequenznummer, notBefore, notAfter und die CA-Zertifikate. CMS schützt die vollständige Struktur. Der Client baut den Pfad des Signierers bis zum lokalen Herstelleranker und prüft, ob dessen Zertifikat gerade für Bootstrap-CA-Antworten autorisiert ist.

Ein positives Ergebnis besagt: Dieser akzeptierte Schlüssel hat diese Felder in dieser Rolle geschützt. Es besagt nicht, wer DNS, IP-Adresse oder CoAP-Endpunkt betreibt. Ein Angreifer kann ein authentisches Objekt spiegeln. Das Objekt bleibt echt, doch der Spiegel erhält dadurch kein Recht auf CSR, Gerätekennung oder langfristige Zugangsdaten.

Darum ist der vorläufige Kanal auf /cacerts beziehungsweise /crts beschränkt. Enrollment, Re-Enrollment, CSR-Attribute, serverseitige Schlüsselerzeugung und sensible Clientdaten bleiben gesperrt. DTLS kann Vertraulichkeit liefern, während Serveridentität und EST-Autorisierung weiterhin fehlen.

Der Server kann dasselbe statische Objekt für alle Geräte einer Herstellerdomäne ausgeben. Er braucht den Signaturschlüssel nicht online. Eine dynamische Herstellersignatur ist nur mit ausdrücklich autorisiertem Credential oder Dienst erlaubt.

Diese Rollentrennung muss in Belegen sichtbar sein. Der Distributor belegt Auslieferung, die Signierfunktion genehmigte Inhalt und Zweck, das Gerät protokolliert Prüfung und Installation. Ein zusammengefasster Status „vertrauenswürdige Quelle“ wäre institutionell falsch.

Der Alias ist Adresse, keine Vollmacht

Ein HTTPS-Pfad kann /.well-known/est/{manufacturer-alias}/cacerts lauten; EST-coaps nutzt /crts. Ein Profil darf den Alias aus einer IANA Private Enterprise Number ableiten, doch Revision 00 schreibt keine Form vor und verlangt keine neue Registrierung.

Der äußere Pfad allein darf niemals Installation autorisieren. Der Alias steht zusätzlich im signierten Inhalt. Der Client vergleicht ihn mit dem angeforderten oder lokal als gleichwertig konfigurierten Namen. Bei Abweichung wird das Paket trotz gültiger Signatur verworfen.

Das verhindert, dass ein gültiges Bündel einer Herstellerdomäne in eine andere eingesetzt wird. Der URI wählt Kontext, die Signatur bindet ihn und lokale Konfiguration definiert erlaubte Gleichheit. Keine dieser Ebenen darf die andere ersetzen.

Ein Audit braucht deshalb konfigurierten Alias, angefragten URI, geschützten Alias, Äquivalenzregel, CMS-Hash und Entscheidung. HTTP-Erfolg belegt keine Autorität; Signaturerfolg ohne Kontext erklärt keine Trust-Store-Änderung.

Ein altes Original kann ein Angriff sein

Eine Signatur bleibt nach einer CA-Kompromittierung mathematisch korrekt. Ein Angreifer kann ein früheres Bündel mit der zurückgezogenen CA erneut liefern. Besonders nach Werksreset könnte das Gerät vergessen haben, dass es bereits eine höhere Generation akzeptierte.

Die Struktur enthält eine Sequenznummer und ein Gültigkeitsintervall. Clients sollten den höchsten akzeptierten Wert je Alias beständig speichern und niedrigere ablehnen. Mit zuverlässiger Zeit müssen sie notBefore und notAfter prüfen. Ohne Uhr dürfen sie vorläufig Sequenzzustand nutzen und das Zeitfenster später gegen authentifizierte Zeit nachprüfen.

Damit wird Sequenzspeicher zu Sicherheitszustand. Liegt er in löschbarer Konfiguration, verschwindet der Rollback-Schutz genau beim Neustart. Betreiber müssen Verhalten bei gleichem Wert und unterschiedlichen Bytes, Backup-Restore, Board-Tausch, Zählerende und Notfallwiederherstellung festlegen.

Caching fügt eine weitere Uhr hinzu. Statische Objekte reduzieren DoS-Kosten, können aber nach Rücknahme im CDN bleiben. Bitgenaue Auslieferung beweist Unversehrtheit, nicht Aktualität.

Der belastbare Beleg verbindet Objekt-Hash, geschützte und vorherige Sequenz, Zeitvertrauen, Intervallprüfung, Cache-Alter, Richtlinienversion und Hash des resultierenden Ankersatzes. Eine Anzeige nur für Signaturgültigkeit verschweigt den realistischen Replay-Pfad.

Lokale Richtlinie ist das letzte Veto des Betreibers

Ein gültiges Paket kann Anker hinzufügen, ersetzen oder erweitern. Zugleich verlangt der Entwurf lokale Trust-Anchor-Management-Policy. Diese zweite Forderung verhindert, dass Herstellerauthorität unbegrenzt wird.

Die Signatur zeigt einen Vorschlag aus einer bei Fertigung anerkannten Beziehung. Sie entscheidet nicht, ob der Betreiber Wurzeln entfernen lässt, Übergangsüberlappung verlangt, bestimmte CAs ausschließt oder Wartungsfreigabe benötigt. Diese Entscheidung gehört zum Träger des Betriebsrisikos.

Lu Hengs Prinzip der minimalen Ausgangsspezifikation trennt die Ebenen. Gemeinsam müssen nur deterministische Prüfungen sein: Signiererpfad und Zweck, exakte Bytes, Alias, Sequenz, Zeit. Welche CA künftig gilt und wann gewechselt wird, bleibt lokal.

Wer jedes herstellergültige Paket automatisch installiert, schafft eine dauerhafte Fernsteuerung des Trust Stores. Der Fertigungsschlüssel bestimmt dann nicht nur den Einstieg, sondern alle künftigen Institutionen, denen das Gerät glauben kann.

Vor der Mutation sollte der Client aktuellen und vorgeschlagenen Satz hashen, Hinzufügungen und Löschungen anzeigen, Flottenregeln anwenden und einen unveränderlichen Übergangsbeleg schreiben. Eine Ablehnung muss Enrollment stoppen; sie darf nicht zur Nutzung des vorläufigen Servers führen.

Erst die neue Sitzung prüft den Server

Nach Installation baut der Client eine neue TLS- oder DTLS-Verbindung auf. In deren Handshake werden Name und Zertifikatspfad des operativen Servers unter den neuen Ankern validiert.

Die alte Verbindung weiterzuverwenden vermischt Epochen. Der Peer erschien vor der Richtlinienänderung; ausgehandelte Parameter gehören zum vorläufigen Kontext. Eine neue Verbindung ist die klare Beweisgrenze für alle Nicht-Bootstrap-Operationen.

RFC 7030 erlaubt schon, TLS vorläufig für /cacerts zu Ende zu führen, die Daten außerbandlich zu autorisieren und danach neu zu verbinden. Der Entwurf ersetzt manuelle Autorisierung des Pakets durch die Herstellersignatur, nicht den zweiten Handshake.

RFC 9148 bildet EST auf CoAP/DTLS ab und nennt /cacerts dort /crts. Transportoptimierung für kleine Geräte macht nicht jeden antwortenden Endpunkt zum legitimen Registrar. Der neue Sitzungsbeleg braucht erwarteten Namen, Kettenfingerprints, verwendeten Anker, Policy und Ergebnis.

Enrollment bleibt ein eigener Entscheidungsakt

Auch ein authentifizierter Server kann ablehnen. Das Gerät muss CSR und Besitznachweis liefern sowie CA-Regeln erfüllen. Ein ausgestelltes Zertifikat kann falsch profiliert sein oder keinen funktionierenden Dienst ergeben.

Revision 00 ändert ausdrücklich weder EST-Enrollment noch Proof of Possession oder CA-Policy. Sie verteilt operative CA-Zertifikate. Sie autorisiert kein Gerät, genehmigt keinen Antrag, stellt nichts aus und misst kein Ergebnis.

Orchestrierung braucht daher getrennte Zustände: Paket abgerufen, Signierer autorisiert, Aktualität bestanden, lokale Policy akzeptiert, Store geändert, neue Sitzung authentifiziert, Enrollment genehmigt, Zertifikat installiert, Dienst beobachtet.

Der Hersteller verantwortet Bootstrap-Signatur, der Betreiber lokale Policy, EST den Server und die Antragsannahme, die CA die Ausstellung und das laufende System das Ergebnis. Eine Unterschrift spricht nicht für alle.

Der Herstellerschlüssel wird zum Flottenhebel

Bei Kompromittierung kann ein Angreifer CA-Pakete erzeugen, die alle Geräte mit dem zugehörigen Anker installieren könnten. Der Entwurf empfiehlt HSM/KMS, Exportverhinderung und ein dediziertes Zertifikat, das nicht für TLS, CA-Ausstellung, Firmware oder andere Funktionen dient.

Zwecktrennung klärt Autorisierung. Eine gültige Kette zum Hersteller sagt nicht, welche institutionelle Handlung der Schlüssel ausführen durfte. Client-Policy muss Bootstrap-Paketsignatur ausdrücklich anerkennen.

Die harten Fragen beginnen nach Verdacht: Kann ein Alias separat stillgelegt werden? Wer genehmigt einen Nachfolger? Welche Geräte nahmen das verdächtige Paket an? Was geschieht bei Insolvenz des Herstellers? Wenn Wiederherstellung denselben kompromittierten Kanal braucht, ist sie nicht unabhängig.

RFC 8995 und RFC 8366 liefern Vergleichsmaterial zu Hersteller-Vouchern und Domain-Imprinting. Sie behandeln andere Subjekte und machen diesen Entwurf weder zu BRSKI noch zu einer eingesetzten Norm.

Der unauthentifizierte Endpunkt muss billig bleiben

Anfragen treffen vor normaler Authentifizierung ein. Empfohlen werden statische Objekte, keine Client-Datenbankabfragen, keine dynamische Signatur, Limits nach Quelle, Präfix, Alias und Instanz, stateless Retry, nur GET sowie Größen- und Verstärkungsschutz.

In dieser Phase ist der Dienst ein Repository signierter Objekte, keine personalisierte Enrollment-Plattform. Jede teure Abfrage vergrößert die Angriffsfläche. Einzelne Aliase müssen separat gedrosselt oder abgeschaltet werden können.

Klartext zeigt zudem: Integrität ist nicht Vertraulichkeit. CMS verhindert Änderung, verbirgt aber Alias und Zertifikate nicht. Offenbaren sie Kunde, Region oder Migrationszeitpunkt, braucht es TLS/DTLS gegen Beobachter, auch wenn der Peer noch nicht autorisiert ist.

Acht Belege statt „Bootstrap erfolgreich“

Beleg Mindestinhalt Beweist nicht
Fertigung Geräteklasse, Anker, Speicher, Aliasregel Aktuelle Herstellerkontrolle
Objektbefugnis CMS-Hash, Kette, Zweck, Ergebnis Serveridentität, Aktualität
Umfang/Zeit Aliase, Sequenz, Intervall, Zeitvertrauen Lokale Annahme
Lokale Änderung Policy, Differenz, Vorher/Nachher-Hash Serverauthentifizierung
Bootstrap-Transport URI, Peer-Zertifikat, Modus, Cache EST-Befugnis
Neue Sitzung Name, Kette, operativer Anker, Ergebnis Enrollment-Genehmigung
Enrollment CSR, Identität, Besitznachweis, CA-Entscheid Betriebsbereitschaft
Ergebnis Installiertes Zertifikat, Healthcheck Gültigkeit künftiger Pakete

Diese Trennung macht Wiederherstellung selektiv. Falscher Alias diskreditiert nicht jede CA. Ein Serverfehler löscht nicht die Paketautorität. Abgelehntes Enrollment kann neben korrektem Root-Wechsel bestehen. Kompromittierte Signatur lässt sich zu jeder betroffenen Mutation verfolgen.

Die wichtigste Grenze von Revision 00 ist damit: Ein unabhängig prüfbares Objekt kann einen nicht vertrauenswürdigen Transport durchqueren, ohne Vertrauen auf ihn zu übertragen. Serveridentität beginnt erst mit dem neuen Handshake unter lokal akzeptierten Ankern.