Zusammenfassung

  • HPKE Base ermöglicht Verschlüsselung für den Inhaber eines bestimmten KEM-Privatschlüssels. Ein erfolgreiches Open() belegt die Annahme im gewählten Kontext, nicht die Identität oder Beauftragung des Senders.
  • PSK, Auth und AuthPSK belegen unter ihren jeweiligen Voraussetzungen den Besitz konfigurierten Schlüsselmaterials. Sie liefern keinen vollständigen Nachrichtenrahmen, keine allgemeine Nichtabstreitbarkeit und keine Geschäftsfreigabe.
  • Zwischen Schlüsselwahl und Wirkung liegen eigene Kontrollpunkte: Verteilung, Bindung von Schlüssel und Identität, Kontext, Format, Reihenfolge, Frische, Richtlinie und Ausführung.

Ein Unternehmen kann einen einzigen technischen Satz protokollieren und daraus eine falsche institutionelle Geschichte machen. Der Satz lautet: „Nachricht entschlüsselt.“ Daraus wird dann: „Der Lieferant hat freigegeben.“ Die erste Aussage kann stimmen; die zweite verlangt Beweise, die in der ersten nicht enthalten sind.

RFC 9180 beschreibt Hybrid Public Key Encryption als Zusammensetzung aus Key Encapsulation Mechanism, Key Derivation Function und Authenticated Encryption with Associated Data. Damit erhalten unterschiedliche Implementierungen eine gemeinsame, klar beschriebene kryptographische Strecke. Das RFC beschreibt aber keine universelle Identitätszuordnung, keinen Transportumschlag, keine Freigabeordnung und keinen Vollzug einer geschäftlichen Entscheidung.

Diese Begrenzung schützt Verantwortung. Ein gemeinsamer Standard kann kryptographische Übergänge deterministisch machen, ohne vorzugeben, welche lokale Organisation, welches Konto, welcher Vertrag oder welche irreversible Folge hinter einer Nutzlast stehen. Wird der Erfolg des Standards als Ersatz für diese Entscheidungen gelesen, entsteht Autorität ohne zuständige Stelle.

Der enge Befund des Base-Modus

Eine HPKE-Ciphersuite besteht aus KEM, KDF und AEAD. Das KEM kapselt ein gemeinsames Geheimnis für den öffentlichen Schlüssel des Empfängers und erlaubt dessen Entkapselung mit dem passenden privaten Schlüssel. Der KDF leitet daraus Kontextmaterial ab. AEAD schützt Klartext und die von der Anwendung gewählten assoziierten Daten.

Im Base-Modus setzt der Sender mit pkR und dem Anwendungswert info auf; der Empfänger verarbeitet enc mit skR und demselben Kontext. Der berechtigte Schluss lautet: Diese Bytes konnten unter dieser Suite und diesem Empfängerschlüssel geöffnet werden.

Der Absender kommt in diesem Schluss nicht vor. Wer den öffentlichen Schlüssel kennt, kann einen Base-Chiffretext für den Empfänger erzeugen. Die Eigenschaftstabelle von RFC 9180 schreibt Base deshalb keine Absenderauthentisierung zu. Ein öffentlicher Schlüssel ist ein kryptographisches Ziel, keine Zugangsliste der zulässigen Sender.

Nehmen wir einen Empfängerschlüssel, den mehrere interne Dienste für vertrauliche Zustellungen kennen. Ein Telemetrieprozess mag ihn berechtigt verwenden dürfen; ein anderer Prozess mag keine Produktionsänderung anstoßen dürfen. Der Base-Modus sieht den Unterschied nicht. Die Zuordnung von Kanal, Nachrichtentyp, Absender und Erlaubnis muss außerhalb der Verschlüsselung durchgesetzt werden.

Auch AAD löst dieses Problem nicht. Eine Anwendung kann Mandant, Version oder Vorgangsnummer so binden, dass eine Veränderung das Öffnen scheitern lässt. Sie beweist damit nicht, dass der benannte Mandant korrekt ist oder der Sender den Namen benutzen durfte. Integrität einer Behauptung ist nicht die Zuständigkeit für die Behauptung.

Mehr Schlüsselbesitz, aber keine automatische Zuständigkeit

PSK erlaubt dem Empfänger, den Besitz eines vereinbarten Pre-Shared Key zu prüfen. Auth bindet die Zusicherung an den Besitz des privaten KEM-Schlüssels des Senders. AuthPSK kombiniert beide Formen. Richtig provisioniert, sind das wertvolle zusätzliche Aussagen.

Doch sie sagen weiterhin „dieses Material wurde besessen“. Ob ein Schlüssel einen Menschen, ein Servicekonto, ein HSM, eine Rolle oder mehrere Betreiber repräsentiert, wird durch Ausstellung, Verwahrung, Rotation, Sperrung und Umfang entschieden. Diese administrative Bindung ist nicht das Ergebnis von AuthDecap().

RFC 9180 weist ausdrücklich darauf hin, dass Auth/AuthPSK das Sender-Schlüsselpaar und keine andere Identität authentisieren. Soll etwa ein Domainname oder eine Geschäftskennung gebunden werden, soll die Anwendung ihn in info aufnehmen. Das ist eine Anweisung, die Bindung sichtbar zu modellieren, statt sie in einer Interpretation des Kryptographie-Logs zu verstecken.

Hinzu kommt die im RFC beschriebene Key-Compromise-Impersonation-Grenze der DHKEM-Auth-Varianten unter den dort genannten Empfängerschlüssel-Kompromissbedingungen. Ein Auth-Erfolg ist daher kein zeitloser Nachweis menschlicher Urheberschaft. Er ist eine begrenzte Zusicherung für einen bestimmten Schlüsselzustand und Zeitpunkt.

Format und Wiederholung sind keine Nebensache

info bindet anwendungsseitige Information beim Aufbau des Kontexts; AAD bindet Information je Nachricht. Beides kann präzise sein. RFC 9180 bestimmt trotzdem kein Wire-Format für HPKE-Nachrichten. Anwendungen müssen enc, Ciphertext(s), ihre Reihenfolge und nicht implizite info-Werte eindeutig rahmen; bei mehreren Empfängerschlüsseln kann auch die Schlüsselauswahl Teil dieses Rahmens sein.

Der Rahmen entscheidet, welche Felder zusammengehören, welche Version und Suite erwartet werden und wie der Kontext rekonstruiert wird. Ein kryptographisch korrektes Öffnen repariert keine mehrdeutige Zerlegung. Noch weniger definiert es die Semantik: Ist der Klartext Diagnose, Antrag, Freigabe oder Test? Welche Rolle darf ihn senden? Welche Aktion ist erlaubt? Diese Fragen gehören zu Schema, Identitätsbindung, Sperrstatus und Richtlinienprüfung.

Frische muss ebenfalls aufgebaut werden. Innerhalb eines Kontextstroms gibt die Reihenfolge der Seal()- und Open()-Operationen begrenzten Replay-Schutz; außerhalb davon bietet HPKE keinen weiteren Replay-Schutz. Mehrnachrichten-Anwendungen müssen Ordnung und Verlust selbst behandeln, typischerweise mit Sequenzen oder unveränderlichen Kennungen, die als AAD gebunden werden.

Ein Vorgang von gestern kann heute korrekt entschlüsselbar und dennoch unzulässig sein. Ablaufzeit, Idempotenz, Geschäftsstatus und Behandlung doppelter Aufträge sind lokale Autoritätsentscheidungen. Der Ciphertext verlängert keine Befugnis.

Auch die Zeitachse des Empfängerschlüssels zählt. RFC 9180 gibt keine Forward Secrecy gegen Kompromittierung des Empfängers: Wird dessen langfristiges Geheimnis später erlangt, können frühere an diesen Schlüssel verschlüsselte Ciphertexte entschlüsselbar werden. Das ist kein Befund über einen konkreten Vorfall, wohl aber eine Grenze für Archivierung, Rotation und Reaktion.

Ein Protokoll, das Folgen erklären kann

Beim Schlüssel festhalten: Kennung, Eigentümer, erlaubter Zweck, Verteilungsweg, Ausgabe, Rotation und Sperrung. Bei der Senderseite: Modus, Suite, Ursprung eines PSK oder Senderschlüssels, info, AAD, äußerer Rahmen und Nachweis der Algorithmenwahl.

Beim Empfang: sichere Referenz auf enc und Ciphertext, ausgewählter Empfängerschlüssel, Ergebnis des Kontextaufbaus und Ergebnis von Open(). Der technische Erfolg bleibt dabei ein eigener Eintrag; er darf Parser und Policy nicht überschreiben.

Danach folgen Schema-Version, Nachrichtentyp, erkannte Identität, Schlüsselstatus, Reihenfolge und Replay-Prüfung, Frische, Policy-Entscheidung und Ablehnungsgrund. Erst danach folgen beantragte, erlaubte und ausgeführte Aktion, unabhängige Beobachtung und Rollback. So kann eine Untersuchung vom Effekt zum jeweiligen Entscheidungsnachweis zurückgehen.