Key derivation function
Eine Schlüsselableitungsfunktion (KDF) ist ein kryptografischer Algorithmus, der einen oder mehrere Sätze von Schlüsselmaterial aus einem vorhandenen Geheimnis ableitet, z. B. einem gemeinsamen Schlüssel, einem Schlüsselvereinbarungsergebnis oder einem Passwort, zusammen mit Kontextinformationen und anderen Parametern.[1] KDFs ermöglichen es einem Protokoll, ein Geheimnis in Schlüssel der erforderlichen Länge umzuwandeln und separate Schlüssel unterschiedlichen Zwecken zuzuweisen.
Der Begriff umfasst zwei verwandte, aber unterschiedliche Klassen. Ein schlüsselbasierter KDF beginnt mit einer Eingabe, die bereits über eine erhebliche kryptografische Stärke verfügt. Ein passwortbasiertes KDF geht von einem von Menschen gewählten Passwort oder einer Passphrase aus und erhöht absichtlich die Kosten für das Testen von Vermutungen. Die Verwechslung der beiden kann zu unsicheren Designs führen: Ein schnelles allgemeines KDF macht ein schwaches Passwort nicht resistent gegen Offline-Erraten.
Schlüsselbasierte Ableitung
Protokolle erhalten häufig ein anfängliches Geheimnis durch eine Schlüsselvereinbarungsoperation und benötigen dann unterschiedliche Schlüssel für die Verschlüsselung, Nachrichtenauthentifizierung oder unterschiedliche Richtungen einer Verbindung. Ein KDF kann das Geheimnis mit Bezeichnungen und Kontext – wie Protokollkennungen, Parteiidentitäten oder Transkriptdaten – kombinieren, sodass Ausgaben für verschiedene Zwecke getrennt werden.
NIST SP 800-108 spezifiziert Zähler-, Feedback- und Doppelpipeline-Konstruktionen basierend auf Pseudozufallsfunktionen, einschließlich HMAC, CMAC und KMAC.[2] Die genaue Konstruktion und ihre Eingaben sind Teil einer Protokollspezifikation; Das bloße Hashen eines Geheimnisses ohne Domänentrennung stellt möglicherweise nicht die erforderlichen Eigenschaften bereit.
Extrahieren und erweitern
HKDF ist ein HMAC-basiertes KDF, das in RFC 5869 standardisiert ist. Es folgt einem extract-then-expand-Design. Die Extraktionsstufe wandelt potenziell uneinheitliches Eingabeschlüsselmaterial in einen pseudozufälligen Schlüssel fester Länge um. Die Erweiterungsphase leitet eine oder mehrere Ausgaben ab und bindet dabei optionale Kontextinformationen.[3]
HKDF ist für kryptografisches Schlüsselmaterial wie ein Diffie-Hellman-Ergebnis gedacht. Es ist bewusst effizient und kein Ersatz für ein Passwort-Hashing-Schema, wenn die Eingabe anhand eines kleinen Wörterbuchs erraten werden kann.
Passwortbasierte Ableitung
Ein passwortbasiertes KDF kombiniert ein Passwort mit einem Salt- und Kostenparametern. Das Salz wird normalerweise zusammen mit dem Ergebnis aufbewahrt und muss nicht geheim gehalten werden. Sein Zweck besteht darin, dass identische Passwörter unterschiedliche Ausgaben erzeugen und verhindern, dass eine vorberechnete Tabelle in vielen Datensätzen wiederverwendet wird. Der Arbeitsfaktor macht jede Vermutung sowohl für das legitime System als auch für einen Angreifer teurer.[4]
PBKDF2 wendet wiederholt eine Pseudozufallsfunktion an und wird durch PKCS #5 und NIST-Richtlinien spezifiziert. Der wichtigste einstellbare Aufwand ist die Anzahl der Iterationen. Dieser Parameter muss für die Anwendung und Hardware ausgewählt werden und sollte im Laufe der Zeit erhöht werden, sofern die Kompatibilität dies zulässt. Es gibt keine permanente Iterationszahl, die für jedes System geeignet ist.
Moderne Passwort-Hashing-Systeme können auch konfigurierbare Speicherkosten verursachen. Speicherharte Funktionen zielen darauf ab, umfangreiche Schätzungen nicht nur im Prozessorbetrieb, sondern auch im Speicher und in der Bandbreite teuer zu machen. scrypt, Argon2 und Lyra2 sind Beispiele für Designs dieser Familie. RFC 9106 spezifiziert Argon2 und empfiehlt die hybride Argon2id-Variante für allgemeines Passwort-Hashing, wobei Profile entsprechend dem verfügbaren Speicher und der Latenz ausgewählt werden.[5]
Verwendungsmöglichkeiten
KDFs werden verwendet, um:
- Verkehrsschlüssel und Initialisierungsmaterial nach einem Schlüsselaustausch ableiten;
- Erstellen Sie separate Verschlüsselungs- und Authentifizierungsschlüssel aus einem Hauptgeheimnis.
- Schlüssel an ein Protokoll, eine Sitzung, eine Identität oder einen Zweck binden;
- einen Speicherverschlüsselungsschlüssel aus einer Passphrase ableiten;
- Speichern Sie einen von einem Passwort abgeleiteten Prüfer und nicht das Passwort selbst. Und
- Erzeugen Sie einen Schlüssel mit der genauen Länge, die von einem anderen kryptografischen Grundelement benötigt wird.
Ein Passwortprüfer und ein Verschlüsselungsschlüssel können beide Ergebnisse einer passwortbasierten Ableitung sein, die sie umgebenden Bedrohungsmodelle unterscheiden sich jedoch. Die Passwortüberprüfung muss Online-Versuche begrenzen und die Verifiziererdatenbank schützen; Bei der Speicherverschlüsselung muss auch berücksichtigt werden, wie der abgeleitete Schlüssel gelöscht, aufbewahrt und wiederhergestellt wird.
Sicherheitsüberlegungen
Die Sicherheit eines KDF hängt von der Stärke seiner Eingabe, der Konstruktion, der Parameterauswahl und der Kontextbindung ab. Ein KDF kann keine Entropie erzeugen, die in einem errätbaren Passwort fehlt. Salts verhindern eine datensatzübergreifende Vorberechnung, müssen jedoch nicht erraten werden und verlangsamen einen gezielten Angriff nicht von selbst.
Für die passwortbasierte Nutzung sollten die Kostenparameter auf die tatsächliche Bereitstellung abgestimmt werden, sodass die legitime Nutzung akzeptabel bleibt, während Vermutungen teuer sind. Implementierungen müssen auch von Angreifern kontrollierte Parameter binden, um Denial-of-Service zu verhindern, Passwortprüfer vergleichen, ohne nützliche Zeitinformationen preiszugeben, und alte Parametersätze nach erfolgreicher Authentifizierung migrieren. Ein geheimer serverseitiger Wert, manchmal auch Pepper genannt, kann eine separate Schutzschicht hinzufügen, ist jedoch kein Ersatz für ein eindeutiges Salt oder eine geeignete Passwort-Hashing-Funktion.
Für die schlüsselbasierte Verwendung sollten Anwendungen dem in ihrem Protokoll definierten KDF folgen, anstatt eine neue Zusammensetzung zu erfinden. Die Wiederverwendung eines abgeleiteten Schlüssels für nicht verwandte Algorithmen oder das Weglassen des Protokollkontexts kann die Trennung zwischen Verwendungen verhindern.
Standards und historische Entwicklung
Die frühe Unix-Passwortspeicherung war ein wichtiger Vorläufer moderner passwortbasierter KDFs. Der Bericht von Robert Morris und Ken Thompson aus dem Jahr 1979 beschrieb ein crypt-Design, das die ersten acht Passwortzeichen als Schlüssel verwendete, 25 Mal eine modifizierte DES-Berechnung anwendete und eine von 4.096 Varianten mit einem 12-Bit-Salt auswählte.[6] Das Salt machte die Wiederverwendung eines vorberechneten Wörterbuchs über alle Konten hinweg unmöglich, während die wiederholte Berechnung die Kosten jeder Schätzung auf moderner Hardware erhöhte. Feste Limits und zunehmende Rechenleistung machten dieses Schema schließlich für den modernen Passwortschutz ungeeignet.
Spätere Passwort-Hashes führten einstellbare Kostenparameter und stärkere Grundelemente ein. Bcrypt fügte in den 1990er Jahren einen anpassbaren Arbeitsfaktor hinzu; Scrypt fügte konfigurierbare Speicherkosten hinzu; und der Passwort-Hashing-Wettbewerb hat sich für Argon2 entschieden und gleichzeitig Catena, Lyra2, Makwa und Yescrypt besonders hervorgehoben.[7] Diese Funktionen sind nicht austauschbar, nur weil jede ein Passwort verarbeiten kann: Anwendungen müssen den Codierungs-, Parameter- und Migrationsregeln der ausgewählten Funktion folgen.
NIST SP 800-132 spezifiziert eine PBKDF2-basierte Ableitung zum Schutz gespeicherter Daten und enthält einen Hinweis, dass NIST eine Überarbeitung der Veröffentlichung plant.[8] Die aktuellen NIST-Leitlinien zur digitalen Identität erfordern gesalzenes Passwort-Hashing mit einem geeigneten Schema und empfehlen eine speicherintensive Funktion. Diese Anforderungen gelten für Passwortprüfer; Sie sollten nicht zu der Behauptung verallgemeinert werden, dass jedes kryptografische KDF langsam oder speicherintensiv sein muss.[9]
Referenzen
- ↑ NIST Computer Security Resource Center, “Key-derivation function”, accessed 13 September 2026
- ↑ NIST SP 800-108 Rev. 1, Recommendation for Key Derivation Using Pseudorandom Functions, updated 2 February 2024
- ↑ Hugo Krawczyk and Pasi Eronen, RFC 5869, “HMAC-based Extract-and-Expand Key Derivation Function”, May 2010
- ↑ K. Moriarty, B. Kaliski and A. Rusch, RFC 8018, PKCS #5: Password-Based Cryptography Specification Version 2.1, January 2017
- ↑ Alex Biryukov et al., RFC 9106, “Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications”, September 2021
- ↑ Robert Morris and Ken Thompson, “Password Security: A Case History”, Communications of the ACM, November 1979; Niels Provos, “Bcrypt at 25: A Retrospective on Password Security”, USENIX, 22 May 2023
- ↑ Password Hashing Competition, “Password Hashing Competition”, accessed 13 September 2026
- ↑ NIST SP 800-132, Recommendation for Password-Based Key Derivation: Part 1: Storage Applications, December 2010
- ↑ NIST SP 800-63B, Digital Identity Guidelines: Authentication and Authenticator Management, 2025
