Summary

  • draft-ietf-cose-hpke-27 erschien am 12. September und befindet sich weiter im Follow-up des Area Directors. Es ist ein Standards-Track-Internet-Draft, kein RFC und kein gebilligtes Einsatzprofil.
  • Ein geschützter psk_id wählt den PSK-Modus. Fehlt er, gilt Base: Die Daten sind für den privaten Empfängerschlüssel geschützt, doch das HPKE-KEM authentifiziert den Absender nicht.
  • kid bezeichnet den Empfängerschlüssel, nicht den Sender. Daniel Kade schlägt einen datensparsamen Nachweis des tatsächlich verwendeten Authentifizierungs- und Autorisierungspfads vor; er ist redaktionelle Analyse, keine IETF-Vorgabe.

Ein erfolgreiches Öffnen hat eine begrenzte Aussage

Die Revision 27 wurde am 12. September veröffentlicht. Laut Datatracker-Verlauf ist das Dokument nach der Einreichung zur Veröffentlichung im Zustand AD Evaluation::AD Followup. Neu präzisiert wurde die Zufallsquelle: HPKE verlangt kryptografisch sicheren Zufall; im Key-Encryption-Verfahren muss auch der Inhaltsverschlüsselungsschlüssel so erzeugt werden.

Das ist eine normative Schärfung, aber kein Abschluss. Der aktuelle Datensatz kann sich ändern, IANA-Werte sind noch angenommen, und ein endgültiger RFC-Text liegt nicht vor. Schon jetzt lässt sich jedoch erkennen, wie leicht ein technischer Erfolg in eine zu große Vertrauensaussage umgedeutet werden kann.

Im Base-Modus kann jeder, der den öffentlichen Empfängerschlüssel kennt, ein Objekt erzeugen, das dessen privater Schlüssel öffnet. AEAD authentifiziert Chiffrat und Begleitdaten unter dem abgeleiteten symmetrischen Schlüssel. Daraus entsteht keine Organisationsidentität desjenigen, der die Public-Key-Kapselung erzeugt hat.

Verschlüsselungsaufbau und Absenderauthentisierung sind getrennt

Der Entwurf kennt Integrated Encryption und Key Encryption. Bei Integrated Encryption schützt HPKE den Klartext direkt in COSE_Encrypt0 für genau einen Empfänger. Bei Key Encryption verschlüsselt ein Inhaltschlüssel die Nachricht, und HPKE umhüllt diesen Schlüssel in einer Empfängerschicht. So sind mehrere Empfänger möglich.

Jede vorgesehene COSE-Algorithmuskennung bindet ein vollständiges KEM/KDF/AEAD-Triplett und den zulässigen Aufbau. Das verhindert, dass Komponenten oder Schichten stillschweigend vertauscht werden.

Der Authentisierungsmodus wird dagegen durch den geschützten Header bestimmt. Mit psk_id gilt mode_psk, ohne ihn mode_base. Der Entwurf weist selbst darauf hin, dass der Modus nicht ausdrücklich in der Ciphersuite-Kennung steckt.

Zwei Objekte mit derselben Algorithmusnummer können damit unterschiedliche Authentisierungsaussagen haben. PSK bestätigt den Besitz eines extern bereitgestellten gemeinsamen Geheimnisses. Base bestätigt diesen Besitz nicht. Wer nur die Algorithmuskennung protokolliert, lässt genau die Auswahlvariable weg, die den Vertrauenspfad festgelegt hat.

kid sucht auf der Empfängerseite

Der Entwurf empfiehlt kid, damit der Sender den benutzten statischen öffentlichen Empfängerschlüssel nennt. Der Empfänger kann so während einer Rotation den passenden privaten Schlüssel auswählen. Der Parameter zeigt zum Ziel der Verschlüsselung, nicht zu ihrem Urheber.

Die Verteilung des öffentlichen Schlüssels bleibt außerhalb des Dokuments. Eine Anwendung muss daher Herkunft, Mandantenzuordnung und Laufzeit des Schlüssels kennen. Ein formal richtiger Schlüssel aus dem falschen Verzeichnis kann ein kryptografisch gültiges Objekt für den falschen Betriebskontext hervorbringen.

Auch psk_id ist nicht das Geheimnis. Die Kennung ist geschützt, die PSK kommt als externe Eingabe und darf nicht im COSE-Objekt stehen. Erfolgreiche Verarbeitung belegt Geheimnisbesitz, aber weder eine Person noch eine aktuelle Rolle oder Berechtigung. Der laufende HPKE-Entwurf verlangt hohe Entropie und warnt vor dem Einsatz schwacher Passwörter als PSK.

Gebundener Kontext braucht eine betriebliche Bedeutung

Geschützte Header und externe authentifizierte Daten können Kontext in die Berechnung einbeziehen. Bei Key Encryption bindet die deterministische Recipient_structure den Algorithmus der unmittelbar folgenden Schicht, geschützte Empfängerheader und Zusatzinformationen. Dadurch wird eine Algorithmussubstitution an der Schichtgrenze erschwert.

Die Konstruktion schützt jedoch nur, was das Profil hineinschreibt. Ob Mandant, Zweck, Ablaufzeit, Policystand oder Auftragsnummer Pflicht sind, entscheidet die Anwendung. Ein leerer externer Kontext kann syntaktisch zulässig und für eine Autorisierung trotzdem unzureichend sein.

HPKE ist bewusst ein Low-Level-Baustein. Replay-Schutz außerhalb eines geordneten Kontexts, Downgrade-Abwehr, Nachrichtenverlust und Frische liegen beim einbettenden Protokoll. Ein Single-Shot-Objekt kann bei erneuter Einreichung erneut kryptografisch gültig sein. Eine doppelte Handlung verhindert nur zusätzlicher Zustand.

Getrenntes Chiffrat schafft eine weitere Grenze. Eine später angewandte COSE-Signatur oder ein MAC deckt die ausgelagerten Bytes nicht automatisch ab. Der Entwurf verlangt dort eigenen Integritätsschutz. Der Befund „Signatur gültig“ ist ohne den dokumentierten Umfang unvollständig.

Base ist eine legitime, aber bewusste Wahl

Ein vertrauliches öffentliches Postfach darf anonyme Einsendungen erlauben. Ein anderes Protokoll kann den Sender separat über Signatur, MAC, authentisierten Kanal oder Anwendungsidentität prüfen. Der Entwurf nennt COSE_Sign, COSE_Sign1, COSE_Mac und COSE_Mac0 ausdrücklich als Ergänzungen.

Nicht Base selbst ist das Problem, sondern eine darüber hinausgehende Auslegung seines Erfolgs. Auch PSK ersetzt keine Autorisierung. Ein gemeinsames Geheimnis kann ein Gerät, eine Flotte oder eine Schicht von Beschäftigten repräsentieren. Besitz entscheidet nicht automatisch über Widerruf, Delegation und die erlaubte Handlung.

Governance beginnt, wenn der kryptografische Befund eine Konfiguration, einen Befehl oder die Annahme eines Berichts auslöst. Dann müssen Inhaltschutz, geprüfte Identität und erlaubende Regel getrennt nachvollziehbar sein.

Den Grund für die Annahme belegen

Daniel Kade schlägt einen Absenderauthentisierungsnachweis für jedes angenommene COSE-HPKE-Objekt vor. Er enthält Profilversion, Integrated oder Key Encryption, Ciphersuite, wirksamen HPKE-Modus, Fingerabdruck und Verteilungsprovenienz des Empfängerschlüssels. Im PSK-Modus kommen ein Einweg-Fingerabdruck von psk_id, eine nicht geheime Schlüsselversion und der Lebenszyklusstatus hinzu. Im Base-Modus nennt er Signatur, MAC, Kanal oder Anwendungsprüfung — oder erklärt anonyme Einsendung ausdrücklich für zulässig.

Der Nachweis bindet zudem Kontextprofil, Frische- und Replay-Ergebnis, Integrität des getrennten Chiffrats, Autorisierungspolicy und Entscheidung. PSK, Klartext und unnötige Identitätsdaten bleiben draußen. Eine opake Ereigniskennung und Hashes können Prüfbarkeit schaffen, ohne ein neues Geheimnisarchiv zu bauen.

Der Vorschlag steht nicht im Entwurf, in RFC 9052, RFC 8937 oder dem IANA-COSE-Register. Er überträgt Heng Lus Policy Mirror auf den Betrieb: Mechanismuserfolg ist noch keine Autorität. Die minimale Anfangsspezifikation hält den gemeinsamen Nachweis klein; die BTW-Redaktionsregel verhindert, dass ein Entwurf als Beleg für einen Vorfall erscheint.

Sources

  1. COSE HPKE, Revision 27
  2. COSE HPKE, Revision 26
  3. Aktueller Datatracker-Eintrag
  4. Datatracker-Dokumentverlauf
  5. HPKE, Revision 04
  6. RFC 9052 — COSE-Strukturen und Verarbeitung
  7. RFC 8937 — Verbesserung kryptografischen Zufalls
  8. IANA-COSE-Register
  9. Heng Lu — The Policy Mirror
  10. Heng Lu — Minimum Initial Specification
  11. Heng Lu — Why BTW Media Exists