Zusammenfassung

  • RFC 9807 ermöglicht Registrierung und Anmeldung, ohne dem Server das Passwort offenzulegen. Nach dem Verlust eines betroffenen Datensatzes und der einschlägigen Servergeheimnisse bleibt der unvermeidbare Offline-Wörterbuchangriff auf dieses Konto möglich.
  • Individuelle OPRF-Schlüssel können eine gemeinsame Wurzel haben. Ein geteilter oprf_seed verbindet Schadensräume; unabhängige Seeds, Scheinantworten, Schwellen-OPRF und Neuregistrierung verschieben Risiko und Aufwand.

„Der Server kennt das Passwort nicht“ ist richtig. Als Risikomodell ist der Satz unvollständig.

Er verrät nicht, wer die Wurzel zur Ableitung der OPRF-Schlüssel kontrolliert, wie viele Nutzer von ihr abhängen, ob AKE-Schlüssel und Registrierungsdatensätze im selben Wiederherstellungsbereich liegen oder ob ruhende Konten bei einem Kryptowechsel rechtzeitig erneuert werden können.

RFC 9807 beschreibt OPAQUE, ein erweitertes passwortauthentifiziertes Schlüsselaustauschverfahren. Der Client verbindet eine oblivious pseudorandom function, einen Wiederherstellungsumschlag und einen authentifizierten Schlüsselaustausch. Er weist Passwortkenntnis nach und vereinbart einen Sitzungsschlüssel, ohne das Passwort auszuliefern – auch nicht bei der Registrierung.

Auch der Status ist eng zu lesen. RFC Editor und Datatracker führen das Dokument als Informational RFC im IRTF-Stream und als Konsens der Crypto Forum Research Group. Der Text ist ausdrücklich weder IETF-Produkt noch Standard. Der Verzeichnislink dient der Auffindbarkeit, nicht der Erhebung zum Standards Track.

Was wirklich vom Server verschwindet

Im klassischen Ablauf schützt TLS 1.3 das Passwort bis zum Endpunkt. Danach kann die Anwendung es protokollieren, im Speicher offenlegen oder an einen falschen Dienst reichen. Transportsicherheit kontrolliert den Empfänger nicht.

Beim OPRF aus RFC 9497 hält der Server den Funktionsschlüssel und sieht einen geblendeten Eingang. Der Client erhält das Ergebnis; der Server lernt weder Eingang noch Ausgang. Danach streckt der Client den Wert und baut selbst den Umschlag für sein Authentisierungsmaterial.

Die Online-Phase läuft über KE1, KE2 und KE3. Erst die dritte Nachricht liefert explizite Client-Authentisierung. Eine gesendete KE2 ist kein Erfolg; erst gültige KE3 und ServerFinish schaffen den Beleg. session_key und clientexklusiver export_key erfüllen ebenfalls verschiedene Aufgaben. Keiner ersetzt die Anwendungsentscheidung, ob eine Handlung erlaubt wird.

Raten bleibt möglich

Die OPAQUE-Ursprungsarbeit benennt die Grenze: Bei einem Ein-Server-aPAKE ist nach Kompromittierung der einschlägigen Datei und Geheimnisse ein erschöpfender Offline-Angriff auf das individuelle Passwort unvermeidbar. OPAQUE verhindert vorab berechnete Tabellen gegen eine vorhersehbare Abbildung. Der Angreifer muss nach dem Einbruch für jeden Kandidaten neu zahlen.

Die KSF erhöht diese Kosten. RFC 9807 nennt Argon2id und scrypt; RFC 9106 liefert Argon2-Leitlinien. Berechnet wird aber auf dem Client. Mehr Zeit und Speicher belasten Angreifer ebenso wie günstige Telefone, eingebettete Geräte und Wiederherstellungspfade. Maßgeblich sind Randlatenz und Ausfallquote der schwächsten unterstützten Geräte.

OPAQUE beseitigt weder Online-Raten noch schwache Passwörter oder kompromittierte Endgeräte. Es hält das wiederverwendbare Geheimnis vom Server fern, erschwert Vorberechnung und liefert gegenseitige Authentisierung sowie Forward Secrecy. Diese präzise Zusage ist wertvoller als eine unbelegbare Vollschutzbehauptung.

Eine gemeinsame Wurzel unter individuellen Schlüsseln

Der Server erzeugt AKE-Schlüssel und oprf_seed. Aus Seed und eindeutiger Credential-ID entsteht je Client ein anderer OPRF-Schlüssel. Unterschiedliche Blätter bedeuten aber nicht automatisch unterschiedliche Wurzeln.

RFC 9807 empfiehlt für seine Enumerationsabwehr einen gemeinsamen Seed und hält zugleich fest: Sein Verlust beeinträchtigt sämtliche davon abhängigen Clients. Die Darstellung „ein Schlüssel pro Nutzer“ kann daher rechnerisch stimmen und betrieblich den Querschnitt verbergen.

(Strong) aPAKE Revisited untersuchte 2024 die Mehrnutzerfrage der Entwurfslinie. Nicht der Seed allein enthüllt alle Passwörter. Eine kompromittierte Nutzerdatei offenbart die globale Wurzel; daraus lässt sich der OPRF-Schlüssel eines anderen Nutzers ableiten; eine harmlose Interaktion mit dem ehrlichen Server liefert zusätzliches Material für Offline-Tests gegen diesen zweiten Nutzer. Der endgültige RFC zitiert die Analyse und nennt die Folge.

Wo die beschriebene Enumerationsabwehr nicht erforderlich ist, sind unabhängige Client-Seeds möglich. Dann muss die Zuordnung über Registrierung, Anmeldung, Replikation und Wiederherstellung konsistent bleiben. Abweichungen können Existenz verraten oder Nutzer aussperren. Weniger gemeinsame Wurzel bedeutet mehr zu regierenden Zustand.

Vorrang für laufenden Code übersetzt das Etikett in Belege: Welcher Administrator, Prozess, Backup oder Enklave kann wie viele Schlüssel rekonstruieren?

Enumerationsschutz ist ein eigener Tausch

Für unbekannte Identitäten kann der Server eine falsche CredentialResponse erzeugen. Der vom Client registrierte masking_key verschlüsselt die Antwort, damit realer und simulierter Fall ähnlich aussehen. Unterschiedliche Laufzeiten und Fehler würden dennoch ein Orakel bilden.

Die Registrierung bleibt unterscheidbar und muss begrenzt werden. Scheinantworten können außerdem missbraucht werden, wenn ihre Erzeugung den Server weniger kostet als die Anfrage den Client. Der Maskierungsschlüssel benötigt bei der Registrierung Vertraulichkeit; RFC 9807 nennt TLS und HPKE als Baustein für einen bereits authentisierten Kanal.

Gemeinsamer oder unabhängiger Seed ist somit eine Abwägung zwischen Identitätsprivatsphäre, Querschaden, Datenkonsistenz und Betrieb. Minimale Anfangsspezifikation und lokale Zukunftsentscheidung liefern die passende Ordnung: Das gemeinsame Protokoll definiert Interoperabilität; der Betreiber begründet lokal sein Bedrohungsmodell.

Drei Verwahrungsbereiche

OPRF-Seed, AKE-Privatschlüssel und RegistrationRecord-Bestand ermöglichen verschiedene Angriffe. Ein HSM kann die AKE-Operation ohne Schlüsselexport anbieten. Das kann Server-Imitation nach Verlust von Seed und Umschlägen verhindern, nicht aber automatisch Offline-Tests aus OPRF-Material und Datensätzen.

Das Zugriffsbild muss getrennt ausweisen, wer OPRF für wie viele Konten auswertet, wer AKE aufruft und wer Datensätze mit Identitäten verknüpft. Drei Dienste unter demselben Administrator und Backup sind ein Tresor.

Ein Schwellen-OPRF könnte den ersten Bereich verteilen: Ein Angreifer braucht genügend Anteile oder muss online bleiben. Werden OPRF- und Authentisierungsserver getrennt, fehlen ohne Datensatzbestand weiterhin Angriffsdaten. Die Ursprungsarbeit sieht diese Möglichkeit vor, RFC 9807 lässt die Umsetzung jedoch außerhalb seines Umfangs. „Threshold-fähig“ beweist keine unabhängigen Hüter.

HKDF, Hash-to-Curve aus RFC 9380 und PAKE-Anforderungen aus RFC 8125 sind Bestandteile, keine Abnahme der gesamten Implementierung.

Migration heißt Neuregistrierung

Wer KSF, Algorithmen oder an den RegistrationRecord gebundenes Material wie den Server-Public-Key ändert, braucht neue Registrierungen. Auch ein Passwortwechsel erzeugt mit frischer Zufälligkeit einen neuen Datensatz. Das macht die Kosten kryptografischer Agilität sichtbar.

Neue Serversoftware verändert keine ruhenden Konten, Altclients, gescheiterten Wiederherstellungen oder Daten unter einem früheren export_key. In großem Maßstab wird die Konfiguration zur Bindung: Ohne Nutzerbeteiligung lässt sich der alte Schadensraum nicht verlassen.

Die Realitätsebenen trennen drei Wahrheiten: neue Software läuft, Datensätze wurden erneuert, alte Geheimnisse sind außer Betrieb. Der letzte Satz stimmt erst, wenn kein Legacy-Datensatz und kein Fallback mehr angenommen wird.

Der Nachweis ist ein Kohortenregister mit berechtigten Konten, neuen und noch gültigen alten Records, ruhenden Nutzern, Wiederherstellungsfehlern, schwachen Clients, Abhängigkeiten vom alten Export-Key, Fallback-Aufrufen und dem tatsächlichen Abschaltdatum früherer OPRF-, AKE- und Record-Materialien.

OPAQUE beantwortet eine begrenzte Frage überzeugend: Passwortauthentisierung ohne Passwortübergabe und ohne wiederverwendbare Vorberechnung. Führung versagt, wenn sie daraus ein allgemeines Sicherheitszertifikat macht.

Das Passwort verschwindet aus der Sicht des Servers. Macht wandert in Ableitungswurzeln, Datensätze, private Operationen, Simulation, Clientbudgets und Migration. Erst eine prüfbare Karte macht daraus Risikominderung.

Sources