Zusammenfassung

  • RFC 5295 schafft getrennte Usage- und Domain-Roots aus dem EMSK, doch ein korrekter KDF-Wert beweist weder die Berechtigung des Aufrufers noch die korrekte Cache-Generation oder den erlaubten Empfänger.
  • Eine belastbare Beweiskette verbindet Label, Kontext, Domäne, Parent-Session, Caller-Entscheidung, Lebensdauer, Transport und tatsächlich beobachtete Nutzung, ohne Schlüsselmaterial zu protokollieren.

Der Testvektor kann die Zugriffsentscheidung nicht prüfen

In einer Schlüsselplattform durfte ein Prozess Root Keys für die Funktion A beziehen. Nach einer Rollenbereinigung erhielt er eine allgemeine Service-Identität, die auch Funktion B abrufen konnte. Als der Prozess eine USRK für B anforderte, stimmten Label, optionale Daten und Ausgabelänge. Der Dienst gab die mathematisch richtige Antwort an einen nicht vorgesehenen Aufrufer.

RFC 5295 hält das EMSK im EAP-Peer und im Server und leitet daraus Roots für bestimmte Zwecke ab. Eine USRK entsteht aus EMSK, Label, Null-Byte, optionalen Daten und Länge. Der Trenner verhindert Präfixverwechslungen bei Labels; gleiche Eingaben führen deterministisch zum gleichen Ergebnis.

Die Funktion kennt aber keine Organisationsrolle. Sie prüft nicht, ob der Caller die Ausgabe besitzen darf.

Der Namensraum ist Teil der Zugriffskontrolle

Jeder Verwendungszweck benötigt eine eigene Definition und ein koordiniertes, druckbares, groß-/kleinschreibungssensitives Label. Optionale Daten binden zusätzlichen Kontext. Ein USRK-Name kann aus der EAP Session-ID und denselben Koordinaten abgeleitet werden, sodass Systeme über den Schlüssel sprechen können, ohne ihn offenzulegen.

Wenn ein Client Labels normalisiert, ein anderer Kontext entfernt und ein Cache nur nach Benutzerkennung indexiert, landen getrennte Ausgaben im selben operativen Fach. Das ist keine Schwäche der KDF, sondern eine unvollständige Identität des abgeleiteten Objekts.

Ein Ableitungsbeleg sollte Usage ID, exakte Label-Bytes, Trenner, Hash der optionalen Daten, Länge, KDF-Version, EAP Session-ID, EMSK-Name und Ergebnisnamen festhalten. Eine Erfolgsmeldung ohne Koordinaten lässt sich nicht nachprüfen.

Eine Domänenwurzel ist delegierte Macht

Eine DSRK gehört zu einer Key-Management-Domäne; deren Label fließt in die Ableitung ein. Darunter liegen engere DSUSRKs. Der Umfang eines Kindes darf nie größer sein als der des Elternschlüssels.

Braucht eine Domäne nur eine Funktion, sollte sie die passende DSUSRK erhalten, nicht eine DSRK, aus der sie den ganzen Zweig ableiten kann. Die Zusage, weitere Schlüssel nicht zu erzeugen, ersetzt keine technische Begrenzung.

Auch Domänennamen brauchen kanonische Regeln. Abweichende Schreibweisen, die verschiedene Schlüssel erzeugen, fallen meist auf. Gefährlicher ist der richtige DSRK-Wert in einem Prozess, dessen Caller-Identität nie auf die Domäne begrenzt wurde.

Neue Roots beseitigen alte Rechte nicht

Die Lebensdauer eines Root Keys darf die des EMSK nicht übersteigen. Läuft das EMSK ab, müssen seine Roots aus der Nutzung verschwinden. Nach einem neuen EAP-Austausch sollten neue Roots so bald wie möglich eingesetzt werden; ob Kinder ersetzt werden, bestimmt der jeweilige Verwendungszweck.

Die Erzeugung einer neuen Generation und die Stilllegung der alten sind deshalb zwei getrennte Vorgänge. Verteilte Kopien, Cache-Replikate und Kindschlüssel benötigen Inventar und beobachtbare Retirement-Ereignisse. Sonst meldet das System Rotation, während alte Befugnisse weiter funktionieren.

Lebensdauer und Parent-Generation müssen auch die Verteilung überstehen. Fehlt die Frist, erfindet der Empfänger eine. Fehlt der Parent, kann er eine richtige Frist an die falsche Session binden.

Die Root-Schnittstelle ist eine Sicherheitsgrenze

Das EMSK sollte nahe am Ableitungspunkt bleiben. Eine Schnittstelle gibt Roots aus und kann festlegen, welche Schlüssel ein Aufrufer erhalten darf. Untere Schichten und externe Einheiten sollen keinen direkten EMSK-Zugang voraussetzen.

Damit wird Caller-Policy zu einem Bestandteil der kryptografischen Architektur. Protokolliert werden müssen Caller-Identität, angeforderter Verwendungszweck und Domäne, Policy-Version und Entscheidung, ausgegebener Schlüsselname sowie Parent-Generation — nie der geheime Wert.

Auch Anwendungen höherer Schichten sollten sich nicht allein auf Schlüssel der Netzzugangsauthentisierung stützen. Der scheinbar effiziente Wiedergebrauch koppelt Anwendungssicherheit an Zugangstechnik und erschwert Pfade ohne EAP.

Ein geschützter Transport braucht vollständige Semantik

Wenn Roots übertragen werden, verlangt RFC 5295 Vertraulichkeit und Integrität, authentisierte und autorisierte Parteien sowie Kontext zur Identifikation und Beschränkung des Schlüssels einschließlich seiner Laufzeit. Ein Transportprotokoll schreibt der RFC nicht vor.

Verschlüsselung verhindert Mitlesen. Sie verhindert nicht, dass ein Empfänger einen unvollständig bezeichneten Schlüssel falsch installiert. Ein Verteilungsbeleg verbindet Sender, Empfänger, Autorisierungsentscheidung, geschützten Kanal, Payload-Hash, Schlüsselname, Domäne, Usage, Parent und Frist mit der bestätigten installierten Generation.

Ableitung vermehrt keine Stärke

Die Stärke eines abgeleiteten Schlüssels kann weder das EMSK noch den internen Master Key der EAP-Methode übertreffen. Zusätzliche Labels erzeugen keine Entropie. Bei vielen Kindern kann deren Protokoll neue Zufälligkeit der beteiligten Parteien benötigen.

Eine große Hierarchie kann Least Privilege ausdrücken. Sie repariert keinen schwachen Parent, keinen unklaren Namen und keine zu breite Caller-Rolle.

Der Nachweis für jeden Aufruf

Verknüpft werden sollten EAP-Session, EMSK-Name, Usage ID, Label und Kontext-Hash, KDF und Länge, Domain-Label, Root- und Child-Namen, Abstammung, Erstellung und Ablauf, Cache-Key, Ersetzung und Stilllegung, Caller, Transportparteien und Kanal, installierte Generation, Bestätigung des Kindprotokolls sowie das spätere Zugangs- oder Anwendungsergebnis.

Der Schlüsselwert gehört nicht in diesen Beleg. Der Beleg soll zeigen, dass ein korrekter Wert nur innerhalb seiner korrekten Befugnis wirkte.

Sources