Zusammenfassung

  • RFC 9529 veröffentlicht feste EDHOC-Eingaben, Nachrichten, Transcript-Hashes, Zwischen-PRKs, Chiffrate, Exporter, OSCORE-Parameter und ungültige Beispiele für bytegenaue Vergleiche.
  • Eine vollständige Übereinstimmung belegt diesen Rechenpfad, nicht frische Zufallswerte, Schlüsselverwahrung, vollständige Validierung, Berechtigung des Credentials oder die Wirkung einer Live-Sitzung.
  • Belastbare Assurance verbindet fünf Belege: Vektorreproduktion, Negativabdeckung, Entropie und Schlüssel, Identität und Policy sowie das beobachtete Ergebnis.

Der CI-Bericht war makellos. message_1, TH_2, CIPHERTEXT_3, PRK_exporter und das OSCORE-Master-Secret entsprachen der Referenz. Hunderte Vergleiche wurden zu einem Status verdichtet: EDHOC verifiziert.

Das Gerät verwendete nach jedem Neustart dennoch denselben ephemeren privaten Schlüssel.

Das ist ein illustratives Szenario, kein gemeldeter Produktvorfall. Es zeigt die Autoritätsgrenze des Tests. RFC 9529 stellt annotierte EDHOC-Spuren mit Ein-, Aus- und Zwischenergebnissen bereit. Zwei unabhängige Implementierungen prüften sie. Dadurch lässt sich die erste Abweichung finden, statt nur über ein endgültiges Rot oder Grün zu sprechen.

Eine Eigenschaft, die in den festen Daten nicht variiert, kann der Vektor nicht zertifizieren.

Die Schlüsselkette wird sichtbar

EDHOC ist für eingeschränkte Umgebungen gedacht, verbindet aber Methode und Suite, Connection IDs, ephemeres Diffie-Hellman, Credentials, Transcript-Hashes, MAC- oder Signaturdaten, authentisierte Verschlüsselung, Exporter und OSCORE.

Die erste Spur verwendet Signaturen, über x5t bezeichnete X.509-Zertifikate, X25519 und EdDSA. Die zweite verwendet statische DH-Authentisierung, durch kid bezeichnete CCS-Credentials, P-256 und eine Suite-Aushandlung mit Fehler und zweitem message_1.

Der RFC zeigt TH_2, TH_3, TH_4, Zwischen-PRKs, Klartext, Chiffrat und Associated Data, PRK_out, PRK_exporter, OSCORE Master Secret und Salt sowie KeyUpdate. Eine Differenz lässt sich zu CBOR, Credential, Suite oder KDF-Kontext zurückverfolgen.

Mehr behauptet die Referenz nicht: Bei diesen Eingaben liefert die spezifizierte Rechnung diese Bytes.

Veröffentlichte Geheimnisse gehören ins Labor

Reproduzierbarkeit verlangt feste Eingaben. Darum druckt RFC 9529 benötigte private Schlüssel ab und verbietet ihre Verwendung. Ein Testvektor braucht bekannte Geheimnisse; ein Betriebssystem braucht unvorhersehbare, kontrolliert erzeugte, geschützte und gelöschte Geheimnisse.

Ein bestandener Vektor misst weder Zufallszahlengenerator noch Unabhängigkeit nach Neustart, Extrahierbarkeit, Speicherlöschung, Hardwareisolation oder Trennung paralleler Sitzungen. Dafür braucht es eigene Tests.

Der Nachweis sollte Vektor, Build, Plattform und Compiler neben Entropiezustand, Schlüsselerzeugung, Verwahrung, Neustart-, Clone- und Paralleltests festhalten. „RFC 9529 bestanden“ darf diese Datensätze nicht ersetzen.

Transcript-Gleichheit ist keine Live-Identität

TH_2 verbindet den ephemeren Schlüssel des Responders mit dem Hash von message_1; spätere Zustände nehmen authentisierten Klartext und Credentials auf. Ableitungen und Chiffrate hängen von dieser Historie ab.

Die Referenz liefert Credential und Schlüssel aber selbst. Im Betrieb muss x5t oder kid aufgelöst, nach der richtigen Regel validiert, einem Gerät oder Principal zugeordnet und gegen eine Berechtigung geprüft werden. Mathematische Authentisierung kann trotz falscher lokaler Zuordnung gelingen.

Auch der Exporter ist kein Ergebnisbeleg. OSCORE-Material zu erzeugen beweist nicht, dass eine Anwendungsnachricht akzeptiert, Replay verhindert, ein Messwert frisch oder ein Aktor betätigt wurde. Diese Ereignisse liegen hinter der Ableitung.

Ungültige Beispiele sind keine vollständige Angriffsfläche

Abschnitt 4 zeigt unter anderem ein CBOR-Array statt einer Sequenz, überflüssige Hüllen, falsche Elementzahlen und Typen, einen ephemeren Schlüssel als Text sowie nichtdeterministische Formen. Kryptografische Fälle betreffen Länge, Feldgrenze, Kurvenpunkt, Low-Order-Point, zu kurzes MAC und fehlende führende Null.

Der RFC nennt die Sammlung ausdrücklich klein. Entsprechende Fehler können in anderen Feldern und Nachrichten liegen. Das Ablehnen aller Beispiele belegt nicht jede Tiefe, Länge, Zustandsfolge oder Ressourcenlast. Fuzzing, Property- und Differentialtests, Limits und Review bleiben eigenständig.

„Lehnt die ungültigen RFC-9529-Spuren ab“ ist prüfbar. „Ist robust gegen fehlerhaftes EDHOC“ ist breiter und braucht mehr Evidenz.

Deterministisches CBOR ist kryptografischer Zustand

Der RFC unterscheidet Rohbytes und CBOR-Encoding. Unnötig lange Integer und Indefinite-Length-Arrays können semantisch ähnlich aussehen, aber Hash-, Signatur-, MAC- und KDF-Eingaben verändern.

Der Beleg muss deshalb Rohbytes, Encoding-Entscheidung, ersten divergierenden Zwischenwert, Suite und Credential-Form behalten. Nur das dekodierte Objekt zu speichern kann die Ursache löschen.

Interoperabilität besitzt einen Umfang

Zwei unabhängige Implementierungen stimmten überein. Das senkt die Gefahr, eine private Konvention für das Protokoll zu halten.

Es bleibt eine Übereinstimmung über gewählte Beispiele. Nicht jede Suite, Methode, Credential-Form, EAD oder Fehlerstrecke ist abgedeckt. Das IANA-EDHOC-Register weist Werten Bedeutung zu; es zertifiziert weder Produktunterstützung noch sichere Aktivierung.

Standard und Spuren bilden einen portablen Mindestboden. Implementierungsumfang, Policy, Lebenszyklus und beobachtbares Fehlerverhalten bleiben lokale Verantwortung.

Fünf Belege statt eines Siegels

Der erste hält Vektor, Version, Plattform, Compiler, Backend und erste Abweichung fest. Der zweite dokumentiert negative Eingaben, Ablehnungsort, Kosten und Folgezustand.

Der dritte betrifft Entropie und Verwahrung: Gesundheit, Wiederholung, Herkunft, Isolation und Löschung. Der vierte betrifft Identität: Auflösung von x5t oder kid, Trust Anchor, Regel, Principal und Berechtigung. Der fünfte hält Live-Realität fest: Peer, Replay, Exporter-Nutzung, OSCORE-Kontext, geschützte Nachricht und Wirkung.

Heng Lus Trennung der Realitätsebenen ist hier operativ. Spezifikation ist nicht Implementierung; richtige Rechnung ist kein frischer Schlüssel; gültiges Credential ist keine Autorisierung; abgeleitetes Geheimnis ist kein Anwendungsergebnis. Erst die Verbindung der Belege schafft Kontrolle.

Was die Quellen nicht belegen

Die Quellen nennen keinen Hersteller mit wiederholten Schlüsseln und liefern keine Adoptions-, Flotten- oder Side-Channel-Statistik. Der Einstieg ist eine Kontrollhypothese.

Die Grenze stärkt RFC 9529: Es macht eine opake Berechnung ausführbar. Der Betrieb muss die übrigen Belege erzeugen.

Quellen