3. Notes to HKDF Users (Hinweise für HKDF-Benutzer)

Dieser Abschnitt enthält eine Reihe von Leitprinzipien zur Verwendung von HKDF. Eine viel umfassendere Darstellung dieser Prinzipien und der Designbegründung findet sich in [HKDF-paper].

3.1. To Salt or not to Salt (Salt verwenden oder nicht)

HKDF ist definiert, um mit und ohne zufälliges Salt zu funktionieren. Dies dient dazu, Anwendungen zu berücksichtigen, bei denen kein Salt-Wert verfügbar ist. Wir betonen jedoch, dass die Verwendung von Salt die Stärke von HKDF erheblich erhöht, die Unabhängigkeit zwischen verschiedenen Verwendungen der Hash-Funktion gewährleistet, die "quellenunabhängige" Extraktion unterstützt und die analytischen Ergebnisse stärkt, die das HKDF-Design unterstützen.

Zufälliges Salt unterscheidet sich grundlegend vom initialen Schlüsselmaterial in zweierlei Hinsicht: es ist nicht geheim und kann wiederverwendet werden. Als solche sind Salt-Werte für viele Anwendungen verfügbar. Beispielsweise kann ein Pseudozufallszahlengenerator (PRNG), der kontinuierlich Ausgaben durch Anwendung von HKDF auf erneuerbare Entropie-Pools (z.B. gesampelte Systemereignisse) erzeugt, einen Salt-Wert fixieren und ihn für mehrere Anwendungen von HKDF verwenden, ohne die Geheimhaltung des Salts schützen zu müssen. In einem anderen Anwendungsbereich kann ein Schlüsselaustauschprotokoll, das kryptographische Schlüssel aus einem Diffie-Hellman-Austausch ableitet, einen Salt-Wert aus öffentlichen Nonces ableiten, die zwischen kommunizierenden Parteien als Teil der Schlüsselvereinbarung ausgetauscht und authentifiziert werden (dies ist der in [IKEv2] gewählte Ansatz).

Idealerweise ist der Salt-Wert eine zufällige (oder pseudozufällige) Zeichenkette der Länge HashLen. Doch selbst ein Salt-Wert geringerer Qualität (kürzer oder mit begrenzter Entropie) kann noch einen signifikanten Beitrag zur Sicherheit des Ausgabeschlüsselmaterials leisten; Anwendungsentwickler werden daher ermutigt, Salt-Werte für HKDF bereitzustellen, wenn solche Werte von der Anwendung erhalten werden können.

Es ist erwähnenswert, dass einige Anwendungen, obwohl nicht der typische Fall, sogar einen geheimen Salt-Wert zur Verfügung haben können; in einem solchen Fall bietet HKDF eine noch stärkere Sicherheitsgarantie. Ein Beispiel für eine solche Anwendung ist IKEv1 in seinem "Public-Key-Verschlüsselungsmodus", wo das "Salt" für den Extraktor aus Nonces berechnet wird, die geheim sind; ähnlich verwendet der Pre-Shared-Modus von IKEv1 ein geheimes Salt, das aus dem Pre-Shared-Schlüssel abgeleitet wird.

3.2. The 'info' Input to HKDF (Die 'info'-Eingabe für HKDF)

Obwohl der 'info'-Wert in der Definition von HKDF optional ist, ist er in Anwendungen oft von großer Bedeutung. Sein Hauptziel ist es, das abgeleitete Schlüsselmaterial an anwendungs- und kontextspezifische Informationen zu binden. Zum Beispiel kann 'info' eine Protokollnummer, Algorithmusbezeichner, Benutzeridentitäten usw. enthalten. Insbesondere kann es die Ableitung desselben Schlüsselmaterials für verschiedene Kontexte verhindern (wenn dasselbe Eingabeschlüsselmaterial (IKM) in solchen verschiedenen Kontexten verwendet wird). Es kann auch zusätzliche Eingaben für den Schlüsselerweiterungsteil aufnehmen, falls gewünscht (z.B. eine Anwendung möchte das Schlüsselmaterial an seine Länge L binden und L somit Teil des 'info'-Feldes machen). Es gibt eine technische Anforderung an 'info': es sollte unabhängig vom Eingabeschlüsselmaterial-Wert IKM sein.

3.3. To Skip or not to Skip (Überspringen oder nicht)

In einigen Anwendungen kann das Eingabeschlüsselmaterial IKM bereits als kryptographisch starker Schlüssel vorliegen (zum Beispiel wäre das Premaster-Secret in TLS RSA-Cipher-Suites eine pseudozufällige Zeichenkette, mit Ausnahme der ersten zwei Oktette). In diesem Fall kann man den Extraktionsteil überspringen und IKM direkt als Schlüssel für HMAC im Expansionsschritt verwenden. Andererseits können Anwendungen den Extraktionsteil aus Gründen der Kompatibilität mit dem allgemeinen Fall verwenden. Insbesondere, wenn IKM zufällig (oder pseudozufällig) aber länger als ein HMAC-Schlüssel ist, kann der Extraktionsschritt dazu dienen, einen geeigneten HMAC-Schlüssel auszugeben (im Fall von HMAC ist diese Verkürzung über den Extraktor nicht unbedingt erforderlich, da HMAC auch für lange Schlüssel definiert ist). Beachten Sie jedoch, dass, wenn der IKM ein Diffie-Hellman-Wert ist, wie im Fall von TLS mit Diffie-Hellman, der Extraktionsteil NICHT übersprungen werden SOLLTE. Dies würde dazu führen, dass der Diffie-Hellman-Wert g^{xy} selbst (der NICHT eine gleichmäßig zufällige oder pseudozufällige Zeichenkette ist) als Schlüssel PRK für HMAC verwendet wird. Stattdessen sollte HKDF den Extraktionsschritt auf g^{xy} anwenden (vorzugsweise mit einem Salt-Wert) und den resultierenden PRK als Schlüssel für HMAC im Expansionsteil verwenden.

In dem Fall, wo die Menge der erforderlichen Schlüsselbits, L, nicht mehr als HashLen beträgt, könnte man PRK direkt als OKM verwenden. Dies ist jedoch NICHT EMPFOHLEN, insbesondere weil es die Verwendung von 'info' als Teil des Ableitungsprozesses auslassen würde (und das Hinzufügen von 'info' als Eingabe zum Extraktionsschritt ist nicht ratsam -- siehe [HKDF-paper]).

3.4. The Role of Independence (Die Rolle der Unabhängigkeit)

Die Analyse von Schlüsselableitungsfunktionen geht davon aus, dass das Eingabeschlüsselmaterial (IKM) aus einer Quelle stammt, die als Wahrscheinlichkeitsverteilung über Bitströme einer bestimmten Länge modelliert wird (z.B. Ströme, die von einem Entropie-Pool erzeugt werden, Werte, die von zufällig gewählten Diffie-Hellman-Exponenten abgeleitet werden, usw.); jede Instanz von IKM ist eine Stichprobe aus dieser Verteilung. Ein Hauptziel von Schlüsselableitungsfunktionen ist es sicherzustellen, dass bei Anwendung der KDF auf zwei beliebige Werte IKM und IKM', die aus der (gleichen) Quellverteilung gezogen wurden, die resultierenden Schlüssel OKM und OKM' im Wesentlichen unabhängig voneinander sind (in statistischem oder rechnerischem Sinne). Um dieses Ziel zu erreichen, ist es wichtig, dass Eingaben für KDF aus geeigneten Eingabeverteilungen ausgewählt werden und auch dass Eingaben unabhängig voneinander gewählt werden (technisch ist es notwendig, dass jede Stichprobe ausreichende Entropie hat, auch wenn sie auf andere KDF-Eingaben konditioniert ist).

Unabhängigkeit ist auch ein wichtiger Aspekt des Salt-Werts, der einer KDF bereitgestellt wird. Obwohl es nicht notwendig ist, das Salt geheim zu halten, und derselbe Salt-Wert mit mehreren IKM-Werten verwendet werden kann, wird angenommen, dass Salt-Werte unabhängig vom Eingabeschlüsselmaterial sind. Insbesondere muss eine Anwendung sicherstellen, dass Salt-Werte nicht von einem Angreifer gewählt oder manipuliert werden. Als Beispiel betrachten Sie den Fall (wie in IKE), wo das Salt von Nonces abgeleitet wird, die von den Parteien in einem Schlüsselaustauschprotokoll bereitgestellt werden. Bevor das Protokoll ein solches Salt zur Ableitung von Schlüsseln verwenden kann, muss es sicherstellen, dass diese Nonces als von den legitimen Parteien stammend authentifiziert werden und nicht vom Angreifer ausgewählt wurden (in IKE ist diese Authentifizierung beispielsweise ein integraler Bestandteil des authentifizierten Diffie-Hellman-Austauschs).