3. Notes to HKDF Users (Notes aux utilisateurs de HKDF)

Cette section contient un ensemble de principes directeurs concernant l'utilisation de HKDF. Un compte rendu beaucoup plus complet de ces principes et de la justification de la conception peut être trouvé dans [HKDF-paper].

3.1. To Salt or not to Salt (Utiliser ou non un sel)

HKDF est défini pour fonctionner avec et sans sel aléatoire. Cela permet de s'adapter aux applications où une valeur de sel n'est pas disponible. Nous soulignons cependant que l'utilisation de sel ajoute significativement à la force de HKDF, assurant l'indépendance entre les différentes utilisations de la fonction de hachage, soutenant l'extraction "indépendante de la source" et renforçant les résultats analytiques qui soutiennent la conception de HKDF.

Le sel aléatoire diffère fondamentalement du matériel de clé initial de deux manières: il est non secret et peut être réutilisé. En tant que tel, les valeurs de sel sont disponibles pour de nombreuses applications. Par exemple, un générateur de nombres pseudoaléatoires (PRNG) qui produit continuellement des sorties en appliquant HKDF à des pools d'entropie renouvelables (par exemple, des événements système échantillonnés) peut fixer une valeur de sel et l'utiliser pour plusieurs applications de HKDF sans avoir à protéger le secret du sel. Dans un domaine d'application différent, un protocole d'accord de clé dérivant des clés cryptographiques à partir d'un échange Diffie-Hellman peut dériver une valeur de sel à partir de nonces publics échangés et authentifiés entre les parties communicantes dans le cadre de l'accord de clé (c'est l'approche adoptée dans [IKEv2]).

Idéalement, la valeur de sel est une chaîne aléatoire (ou pseudoaléatoire) de longueur HashLen. Cependant, même une valeur de sel de moindre qualité (plus courte ou avec une entropie limitée) peut encore apporter une contribution significative à la sécurité du matériel de clé de sortie; les concepteurs d'applications sont donc encouragés à fournir des valeurs de sel à HKDF si de telles valeurs peuvent être obtenues par l'application.

Il convient de noter que, bien que ce ne soit pas le cas typique, certaines applications peuvent même avoir une valeur de sel secrète disponible; dans un tel cas, HKDF fournit une garantie de sécurité encore plus forte. Un exemple d'une telle application est IKEv1 dans son "mode de chiffrement à clé publique", où le "sel" de l'extracteur est calculé à partir de nonces qui sont secrets; de même, le mode pré-partagé d'IKEv1 utilise un sel secret dérivé de la clé pré-partagée.

3.2. The 'info' Input to HKDF (L'entrée 'info' de HKDF)

Bien que la valeur 'info' soit optionnelle dans la définition de HKDF, elle est souvent de grande importance dans les applications. Son objectif principal est de lier le matériel de clé dérivé aux informations spécifiques à l'application et au contexte. Par exemple, 'info' peut contenir un numéro de protocole, des identificateurs d'algorithme, des identités d'utilisateur, etc. En particulier, il peut empêcher la dérivation du même matériel de clé pour différents contextes (lorsque le même matériel de clé d'entrée (IKM) est utilisé dans de tels contextes différents). Il peut également accueillir des entrées supplémentaires à la partie d'expansion de clé, si désiré (par exemple, une application peut vouloir lier le matériel de clé à sa longueur L, faisant ainsi de L une partie du champ 'info'). Il existe une exigence technique pour 'info': il doit être indépendant de la valeur du matériel de clé d'entrée IKM.

3.3. To Skip or not to Skip (Sauter ou non)

Dans certaines applications, le matériel de clé d'entrée IKM peut déjà être présent en tant que clé cryptographiquement forte (par exemple, le secret préliminaire dans les suites de chiffrement TLS RSA serait une chaîne pseudoaléatoire, à l'exception des deux premiers octets). Dans ce cas, on peut sauter la partie extraction et utiliser IKM directement comme clé HMAC dans l'étape d'expansion. D'autre part, les applications peuvent encore utiliser la partie extraction pour des raisons de compatibilité avec le cas général. En particulier, si IKM est aléatoire (ou pseudoaléatoire) mais plus long qu'une clé HMAC, l'étape d'extraction peut servir à produire une clé HMAC appropriée (dans le cas de HMAC, ce raccourcissement via l'extracteur n'est pas strictement nécessaire puisque HMAC est défini pour fonctionner avec des clés longues également). Notez cependant que si l'IKM est une valeur Diffie-Hellman, comme dans le cas de TLS avec Diffie-Hellman, alors la partie extraction NE DEVRAIT PAS être sautée. Cela entraînerait l'utilisation de la valeur Diffie-Hellman g^{xy} elle-même (qui n'est PAS une chaîne uniformément aléatoire ou pseudoaléatoire) comme clé PRK pour HMAC. Au lieu de cela, HKDF devrait appliquer l'étape d'extraction à g^{xy} (de préférence avec une valeur de sel) et utiliser le PRK résultant comme clé pour HMAC dans la partie expansion.

Dans le cas où la quantité de bits de clé requis, L, n'est pas supérieure à HashLen, on pourrait utiliser PRK directement comme OKM. Ceci, cependant, n'est PAS RECOMMANDÉ, en particulier parce que cela omettrait l'utilisation de 'info' dans le processus de dérivation (et l'ajout de 'info' comme entrée à l'étape d'extraction n'est pas conseillé -- voir [HKDF-paper]).

3.4. The Role of Independence (Le rôle de l'indépendance)

L'analyse des fonctions de dérivation de clé suppose que le matériel de clé d'entrée (IKM) provient d'une source modélisée comme une distribution de probabilité sur des flux de bits d'une certaine longueur (par exemple, des flux produits par un pool d'entropie, des valeurs dérivées d'exposants Diffie-Hellman choisis au hasard, etc.); chaque instance d'IKM est un échantillon de cette distribution. Un objectif majeur des fonctions de dérivation de clé est de s'assurer que, lors de l'application de la KDF à deux valeurs quelconques IKM et IKM' échantillonnées à partir de la (même) distribution source, les clés résultantes OKM et OKM' sont essentiellement indépendantes l'une de l'autre (dans un sens statistique ou computationnel). Pour atteindre cet objectif, il est important que les entrées de la KDF soient sélectionnées à partir de distributions d'entrée appropriées et également que les entrées soient choisies indépendamment les unes des autres (techniquement, il est nécessaire que chaque échantillon ait une entropie suffisante, même lorsqu'il est conditionné par d'autres entrées de la KDF).

L'indépendance est également un aspect important de la valeur de sel fournie à une KDF. Bien qu'il ne soit pas nécessaire de garder le sel secret, et que la même valeur de sel puisse être utilisée avec plusieurs valeurs IKM, on suppose que les valeurs de sel sont indépendantes du matériel de clé d'entrée. En particulier, une application doit s'assurer que les valeurs de sel ne sont pas choisies ou manipulées par un attaquant. À titre d'exemple, considérez le cas (comme dans IKE) où le sel est dérivé de nonces fournis par les parties dans un protocole d'échange de clés. Avant que le protocole puisse utiliser un tel sel pour dériver des clés, il doit s'assurer que ces nonces sont authentifiés comme provenant des parties légitimes plutôt que sélectionnés par l'attaquant (dans IKE, par exemple, cette authentification fait partie intégrante de l'échange Diffie-Hellman authentifié).