Qu'est-ce qu'une fonction de dérivation de clé (KDF) et comment fonctionnent-elles ?

Les fonctions de dérivation de clé (KDF) sont des éléments essentiels des systèmes cryptographiques. Comme leur nom l’indique, ils peuvent être utilisés pour dériver des clés fortes à partir d’autres entrées. Ceux-ci inclus:

• Mots de passe
• Secrets partagés
• Autres clés sécurisées (lorsque des clés supplémentaires sont nécessaires)
• Touches plus faibles

Ils peuvent également être utilisés pour stocker des mots de passe en toute sécurité.

Mais les fonctions de dérivation clés et leurs utilisations qui se chevauchent peuvent prêter à confusion. Pour vraiment les comprendre, il est préférable de revenir aux principes fondamentaux et d’expliquer ce que sont les clés, en quoi elles diffèrent des mots de passe et les meilleures façons de stocker les mots de passe.

Que sont les clés ?

Commençons par les bases absolues. Le Institut national des normes et de la technologie (NIST) définit une clé comme :

« Paramètre utilisé avec un algorithme cryptographique qui détermine son fonctionnement de telle manière qu'une entité connaissant la clé puisse reproduire ou inverser l'opération, alors qu'une entité ne connaissant pas la clé ne le peut pas. »

Il s’agit d’une définition complexe, alors décomposons-la un peu plus. Une clé est essentiellement une entrée supplémentaire que nous ajoutons à différents types d'algorithmes cryptographiques afin de produire un résultat spécifique. . Les clés prennent la forme de très grands nombres, souvent appelés chaînes.

Donnons une explication plus concrète des touches. Dans le contexte d'un algorithme de chiffrement à clé symétrique comme AES - c'est ce que nous utilisons pour chiffrer la plupart de nos données - nous prenons les données que nous voulons chiffrer et les exécutons via l'algorithme avec une clé secrète afin de nous fournir le texte chiffré.

Ce texte chiffré ne peut pas être déchiffré sans la clé (il y a quelques mises en garde ici, mais ne compliquons pas trop les choses à ce stade). Lorsque nous voulons décrypter les données afin de pouvoir y accéder, nous prenons notre texte chiffré et la clé, et les exécutons essentiellement à l'envers dans l'algorithme pour nous donner les données d'origine.

Puisque les clés nous permettent de garder les données confidentielles, nous devons souvent les garder secrètes. Lorsque nous sommes les seuls à connaître une clé qui protège les données, cela signifie que nous sommes également les seuls à pouvoir accéder à ces données. Cela empêche les attaquants d’accéder à nos informations sensibles.

Clés asymétriques

Toutes les clés ne doivent pas nécessairement rester secrètes. La cryptographie asymétrique, également connue sous le nom de cryptographie à clé publique, est un élément essentiel de notre paysage de cybersécurité qui implique de garder certaines clés publiques.

Algorithmes de chiffrement asymétriques comme RSA nous permettent de faire toutes sortes de choses au-delà de ce dont est capable le cryptage à clé symétrique que nous venons de décrire. Ils nous permettent de communiquer en toute sécurité avec des personnes que nous n'avons jamais rencontrées auparavant et apportent de la confiance dans nos communications via signatures numériques .

Les clés sont complexes et il existe de nombreux types différents qui nous aident à réaliser diverses choses importantes. Cependant, dans cet article, nous nous concentrerons sur les types de clés que nous devons garder secrètes .

Les propriétés des clés

Si nos données importantes sont sécurisées par une clé secrète, nous devons nous assurer que les pirates ne peuvent pas trouver la clé. S’ils parviennent à trouver la clé, ils pourront décrypter les données aussi facilement que nous.

En plus de devoir garder la clé secrète, la clé doit également répondre à certaines propriétés pour que nous puissions être sûrs qu'un attaquant ne sera pas en mesure de la découvrir :

Longueur de clé

La longueur de la clé est un facteur important dans la sécurité globale d’un système cryptographique donné. La longueur de la clé fait essentiellement référence à la taille de la clé, avec les clés plus grandes sont généralement plus sécurisées (il y a des exceptions à cela). Cependant, il y a toujours un compromis entre sécurité et rapidité.

Le concept sous-jacent est relativement simple : si quelqu'un pense à un nombre compris entre un et dix, vous pourrez le deviner en quelques essais seulement. S’ils pensent à un nombre compris entre un et un million, vous vous ennuierez probablement avant de l’avoir compris.

Les clés ne sont essentiellement que de gros nombres, donc plus le champ de nombres parmi lesquels choisir est grand, plus il sera difficile pour un attaquant de comprendre votre clé. Les clés doivent avoir une certaine longueur ou plus afin d'être sécurisées dans un but donné. Cela dépend de la situation, mais à titre d'exemple, AES a trois longueurs de clé :

• 128 bits
• 192 bits
• 256 bits

D'autres algorithmes, comme RSA , utilisez des clés beaucoup plus grandes. Il n’est pas rare que RSA utilise des clés de 4 096 bits. Cependant, ces grandes clés RSA n’accordent pas nécessairement plus de sécurité à un système de chiffrement que les petites clés AES. Cela est dû à certaines complexités mathématiques qui sous-tendent ces deux algorithmes, mais cela sort du cadre de cet article.

Le hasard

Une clé doit être aléatoire, ou suffisamment proche du hasard pour que même les techniques sophistiquées ne puissent détecter aucun modèle. . S’il existe des modèles ou des restrictions, il peut être beaucoup plus facile pour un pirate informatique de trouver la clé.

Expliquons cela plus en détail en revenant à notre exemple ci-dessus : si votre ami choisit un nombre véritablement aléatoire entre un et un million, alors il y a une chance égale qu'il s'agisse de n'importe quel nombre unique dans cette plage. Pour le comprendre, vous devrez deviner chaque numéro de manière systématique jusqu'à ce que vous ayez de la chance et trouviez le bon. En moyenne, il vous faudrait 500 000 suppositions pour réussir. Cela vous prendrait un temps exceptionnellement long.

Changeons d’exemple et disons que vous avez déjà vu votre ami jouer à ce jeu avec d’autres. Vous avez remarqué que les nombres qu’ils choisissent ne sont pas réellement aléatoires. Chaque fois qu’ils jouent, le numéro se termine toujours par 837. Vous ne savez pas pourquoi, mais pour une raison quelconque, votre ami est obsédé par ce numéro. Vous avez remarqué un modèle et vous pouvez l’utiliser pour rendre votre travail beaucoup plus facile.

Au lieu de devoir parcourir chaque nombre, vous pouvez accélérer considérablement les choses en devinant uniquement les nombres qui se terminent par 837 :

837, 1837, 2837, 3837, 4837, etc.

Parce que vous avez compris le modèle, il ne vous faudra en moyenne que 500 suppositions pour déterminer le nombre auquel pense votre ami.

La sécurité des clés fonctionne exactement de la même manière. Si toutes les clés d’un système donné suivent un modèle prévisible, il est beaucoup plus facile de déterminer quelle est réellement la clé.

Distribution uniforme

Ce ne sont pas seulement les modèles dont nous devons nous soucier. Nous devons également nous demander si les clés proviennent d'un distribution uniforme . Par exemple, disons que vous disposez d’un générateur de clés censé vous donner des clés aléatoires de 128 bits. Nous utiliserons des nombres décimaux pour expliquer cela, afin d’éviter de compliquer les choses plus que nécessaire.

En décimal, le plus grand nombre de 128 bits est :

340 282 366 920 938 463 463 374 607 431 768 211 456

Si le générateur de clé était véritablement aléatoire et avait une distribution uniforme, vous vous attendriez à ce qu'il soit également probable que la clé soit un nombre unique compris entre 0 et 340 282 366 920 938 463 463 374 607 431 768 211 456.

Mais disons qu'il y a un bug dans le générateur de clés. Vous l'exécutez plusieurs fois, et voici les clés qu'il génère :

• 8722
• 9345
• 0497
• 1438
• 7506
• 4379
• 3984

Ce qui s'est passé? Ces nombres semblent aléatoires, mais ils ne sont certainement pas uniformes et répartis uniformément entre 0 et 340 282 366 920 938 463 463 374 607 431 768 211 456. Ils sont tous regroupés sous la barre des 10 000 à cause du bug.

Si un attaquant découvrait que le générateur de clés utilisé dans le système de cryptographie était défectueux et ne produisait que des clés dans une plage aussi limitée, cela rendrait son travail beaucoup plus facile. En raison de la distribution limitée des clés, la clé de 128 bits serait triviale à deviner.

Cela nécessiterait en moyenne seulement 5 000 suppositions, au lieu des milliards et des milliards qu'exigerait une clé de 128 bits véritablement aléatoire et uniforme. C'est pourquoi l'uniformité est un autre aspect important de la génération de clés.

Il ne devrait y avoir aucune relation observable entre les différentes clés

Une menace contre les cryptosystèmes que nous devons prendre en compte est connue sous le nom de attaque par clé associée . Dans ce scénario, un attaquant est capable d'observer le fonctionnement d'un algorithme de chiffrement alors qu'il traite les données à l'aide d'un certain nombre de clés différentes.

Au début de l’observation, l’attaquant ne connaît les valeurs d’aucune des clés, mais il sait qu’il existe une relation entre elles.

Un exemple est WEP, un protocole défectueux que vous avez peut-être rencontré lors de la configuration d'un routeur Wi-Fi. Il implémente une clé principale unique pour tous les utilisateurs d'un WLAN. Lorsqu'il chiffre les données avec RC4, il utilise cette clé ainsi qu'un vecteur d'initialisation de 24 bits comme clé de chiffrement pour chaque paquet. Cela signifie qu'il existe une relation entre les clés.

La réutilisation de la clé, ainsi que le vecteur d'initialisation relativement court, signifient qu'un attaquant peut intercepter les paquets de données pendant une période de temps relativement courte, puis exploiter les propriétés connues de la planification de la clé RC4 pour récupérer la clé .

La réutilisation de clés similaires signifie finalement que les attaquants peuvent facilement récupérer le texte en clair, annulant ainsi complètement toute sécurité prétendument fournie par WEP. Ceci n'est qu'un exemple de la raison pour laquelle nos cryptosystèmes ne doivent jamais réutiliser des clés ayant des relations observables entre elles .

Clés vs mots de passe

Les mots de passe sont des éléments importants de nos systèmes de sécurité.

Les clés peuvent ressembler beaucoup à des mots de passe en surface, et il existe en effet de nombreuses similitudes entre les deux. Cependant, il est important de comprendre les différences et les rôles distincts que chacun joue dans nos cryptosystèmes.

Tout comme les clés, les mots de passe sont également des éléments de données qui doivent rester secrets vis-à-vis des parties non autorisées. Ils jouent également un rôle essentiel dans la protection de nos données. Cependant, les mots de passe étaient à l'origine destinés à être mémorisés par des humains , et ils sont principalement utilisés pour permettre aux utilisateurs de prouver leur identité.

Lorsqu'il se connecte à un système, un utilisateur peut essentiellement revendiquer n'importe quel nom d'utilisateur, car il n'est pas nécessaire que les noms d'utilisateur soient privés. Les systèmes de contrôle d'accès utilisent des mots de passe pour trier les utilisateurs légitimes des attaquants et des imposteurs. Essentiellement, si une personne essaie de se connecter en tant queutilisateur123, le système leur demande essentiellement de le prouver :

« Si tu es vraimentutilisateur123, Eh bien prouve le! Dites-moi l'information secrète que seulutilisateur123sait.

La personne saisit ensuite son mot de passe. Si cela correspond aux informations que le système a enregistrées pourutilisateur123, alors cela suppose que la personne doit être la personne légitimeutilisateur123et leur donne accès. Ce n’est pas un système parfait, mais il fonctionne plus ou moins.

Si les mots de passe sont censés être des informations secrètes que nous utilisons pour prouver notre identité, nous avons alors besoin d'un moyen de les stocker qui limite le risque que des attaquants puissent les découvrir. Traditionnellement, il était préférable de les garder en tête et peut-être d’en conserver une copie de sauvegarde dans un coffre-fort à la maison.

Cela nous amène au premier point majeur de différenciation entre clés et mots de passe :

Les mots de passe doivent être mémorisables

Historiquement, les gens devaient pouvoir mémoriser leurs mots de passe afin de les garder en sécurité tout en étant facilement accessibles. En tant qu'humains, nous sommes doués pour mémoriser des schémas et des mots, mais nous sommes aussi paresseux . Cela nous amène à créer des mots de passe qui ne sont souvent pas assez longs, ni des chaînes de données complètement aléatoires avec des distributions uniformes.

Les gens ont tendance à choisir des choses commechasseur2, ou le nom de leur équipe sportive préférée plus leur date de naissance (notez que ce ne sont pas de bons mots de passe) plutôt queZq4t7w!z%C^F-J@N. Celles-ci sont beaucoup plus faciles à mémoriser que les chaînes aléatoires.

Le résultat est que la plupart des mots de passe n'ont pas la longueur ou le caractère aléatoire nécessaires pour qu'ils soient des clés appropriées , et ils ne sont pas non plus issus d'une distribution uniforme. Si nous devions les utiliser comme clés, cela rendrait nos systèmes vulnérables aux attaques.

Ces dernières années, les choses ont un peu changé avec l’essor des gestionnaires de mots de passe. Ceux-ci permettent aux utilisateurs de mémoriser un seul mot de passe principal, qui contrôle ensuite l'accès à tous leurs autres mots de passe. Puisqu’un seul mot de passe doit être mémorisé, cela permet à tous les autres d’être aléatoires et issus de distributions uniformes : les utilisateurs n’ont pas besoin de les garder enfermés dans leur cerveau.

Cependant, de nombreuses personnes n’ont toujours pas adopté les gestionnaires de mots de passe, ce qui n’a donc pas entraîné de changements majeurs dans la structure globale des systèmes de sécurité.

Comment transformer les mots de passe en clés ?

Nous avons déclaré que nous avons besoin de clés pour agir comme entrées sécurisées dans nos systèmes cryptographiques, mais que les gens ont tendance à mémoriser et à saisir des mots de passe.

Cela nous amène à un problème majeur : Comment pouvons-nous transformer des mots de passe mémorisables par l’homme en clés que nos systèmes cryptographiques peuvent utiliser ?

Avec fonctions de dérivation de clés (KDF).

Qu'est-ce qu'une fonction de dérivation de clé (KDF) ?

Au sens le plus général, une fonction de dérivation de clé (KDF) prend une entrée, l'exécute via une fonction spéciale, puis génère du matériel de clé sécurisé . L'entrée peut être un mot de passe ou un autre élément de saisie faible.

À quoi servent les fonctions de dérivation de clé (KDF) ?

Les fonctions de dérivation de clés peuvent en réalité effectuer toute une série de choses, notamment :

• Transformer les mots de passe et autres sources faibles de matériel de saisie en clés fortes. C'est ce qu'on appelle étirement des touches .
• Générer de nombreuses clés à partir d'une source unique de matériel de chiffrement. Cela nous permet d’utiliser des clés distinctes pour chaque aspect d’un cryptosystème.
• Stockage sécurisé des mots de passe pour les protéger des pirates informatiques.

Comment fonctionnent les fonctions de dérivation de clé basées sur un mot de passe (PBKDF) ?

Il existe un certain nombre de fonctions différentes de dérivation de clé basées sur un mot de passe, mais nous démontrerons comment elles fonctionnent en discutant de PBKDF2 :

Comment fonctionne PBKDF2 ?

Comme vous pouvez probablement le deviner, PBKDF2 signifie Password-Based Key Derivation Function 2. PBKDF2 a été publié en 2000 dans le cadre de la série de RSA Laboratories sur les normes de cryptographie à clé publique (PKCS). PKCS expose les principes fondamentaux de la manière dont un système de cryptographie à clé publique sécurisé doit être mis en œuvre. PBKDF2 a remplacé PBKDF1, qui produit des clés qui ne sont pas suffisamment grandes pour être sécurisées dans l'environnement actuel.

L'un des objectifs d'une fonction de dérivation de clé basée sur un mot de passe est de transformer un mot de passe, un secret à faible entropie, en une clé d'une longueur appropriée et suffisamment aléatoire à partir d'une distribution uniforme.

PBKDF2 fait cela en prenant quatre entrées :

• Un mot de passe — Il s'agit du mot de passe de l'utilisateur qui doit être transformé en clé forte. Bien entendu, le mot de passe doit rester secret.
• UN sel — Un sel est essentiellement une entrée aléatoire supplémentaire de données qui est traitée par le KDF parallèlement au mot de passe. Les sels ne doivent pas nécessairement être secrets et ils sont stockés avec les hachages de mots de passe.
• Un nombre d'itérations — Le nombre d'itérations indique combien de fois les valeurs seront exécutées via la fonction.
• La longueur de clé dérivée — C'est la longueur que l'implémenteur souhaite que le résultat – la clé forte – soit.

PBKDF2 place le mot de passe et le sel via un fonction pseudo-aléatoire un nombre défini de fois, en fonction de la valeur du nombre d'itérations. Le résultat final est une clé forte de la longueur spécifiée dans l’entrée de longueur de clé dérivée. Cette clé peut ensuite être utilisée pour sécuriser divers aspects d’un cryptosystème.

PBKDF2 peut utiliser une gamme de différentes fonctions pseudo-aléatoires. Ceux-ci inclus:

• HMAC-SHA-256
• HMAC-SHA-512
• Même HMAC-SHA-1 peut être utilisé pour le hachage de mot de passe, bien qu'il nécessite un nombre d'itérations beaucoup plus élevé pour être sécurisé. SHA-1 n’est normalement pas considéré comme sécurisé dans la plupart des autres applications.

Maintenant que nous avons décrit la conception globale du PBKDF2, prenons du recul et examinons certains de ses composants plus en détail.

Qu'est-ce qu'une fonction pseudo-aléatoire (PRF) ?

D'une manière générale, une fonction pseudo-aléatoire est une fonction qui prend une graine aléatoire secrète et un variable de données comme ses entrées. Il génère une valeur qui ne peut pas être distinguée informatiquement d'une sortie véritablement aléatoire.

PBKDF2 utilise code d'authentification de message basé sur le hachage (HMAC) fonctionne comme son PRF. Les HMAC ont été initialement conçus pour l'authentification des messages, mais ils peuvent être facilement adaptés pour s'adapter au rôle des PRF.

Que sont les codes d'authentification de message basés sur le hachage (HMAC) ?

Les fonctions de code d'authentification de message basé sur le hachage (HMAC) s'appuient sur des fonctions de hachage cryptographique telles que :

• Le SHA-2 famille
• Le SHA-3 famille

Dans les applications plus traditionnelles, les fonctions HMAC prennent une clé comme graine aléatoire et le texte d'un message comme variable de données. Ils génèrent un code d'authentification de message (MAC), qui est utilisé pour authentifier les messages, comme vous pouvez probablement le deviner d'après son nom.

La clé initiale est d’abord transformée en clé de la taille d’un bloc, qui est ensuite utilisée deux fois comme entrée dans le HMAC. La première fois, il est ajouté au remplissage interne et concaténé (cela signifie essentiellement qu'une valeur est ajoutée à l'autre, formant une chaîne plus grande composée d'une valeur après l'autre) au texte du message. Cette chaîne est ensuite exécutée via un hachage, nous donnant la première sortie.

La clé est ensuite ajoutée au remplissage externe et est concaténée à la sortie de l'opération précédente. Cette chaîne est ensuite hachée, ce qui donne le résultat final, le code d'authentification du message (MAC).

La fonction de hachage utilisée dans la fonction globale HMAC peut varier, mais dans HMAC-SHA-256, il s'agit de SHA-256. Dans ce cas, SHA-256 est utilisé pour les deux opérations de hachage de la fonction HMAC.

En notation mathématique, cela ressemble à ceci :

HMAC = H (K XOR opad ‖ H(K XOR ipad ‖ texte))

Où:

• HMACest le code d'authentification de message basé sur le hachage résultant.
• Hest la fonction de hachage. Dans HMAC-SHA-256, ce serait SHA-256.
• Kest une version de la taille d'un bloc de la clé initiale.
• GRATUITreprésente un Opération XOR .
• en hautreprésente le rembourrage extérieur.
• ‖symbolise la concaténation.
• iPadreprésente le rembourrage intérieur.
• textereprésente le texte du message.

Comment les fonctions d'authentification de message par hachage (HMAC) sont-elles utilisées dans PBKDF ?

Vous avez peut-être remarqué qu'un type HMAC normal fonctionne en boucle. La clé avec un type de remplissage est concaténée au texte, puis cette chaîne est hachée :

H(K XOR iPad ‖ texte)

La clé avec un autre type de remplissage est ensuite concaténée avec la sortie de la fonction ci-dessus :

H(K XOR opad ‖ Première sortie)

Normalement, une fonction HMAC s'arrêterait là et nous aurions un code d'authentification du message, que nous pourrions utiliser pour authentifier le message.

Et si nous continuions dans cette boucle ?

H(K‖ texte)

Alors:

H(K ‖ Première sortie)

Alors:

H(K ‖ Deuxième sortie)

Alors:

H(K ‖ Troisième sortie)

Alors:

H(K ‖ Quatrième sortie)

Et ainsi de suite…

C'est exactement ce que PBKDF2 fait avec les HMAC . C'est là qu'intervient le nombre d'itérations. Il précise combien de fois nous devons répéter ce processus. OWASP recommande actuellement un 310 000 itérations de HMAC-SHA-256 pour un hachage sécurisé des mots de passe. Cela signifie que les sorties doivent être hachées encore et encore dans cette boucle 310 000 fois.

Le but est de ralentir les pirates qui tentent de trouver des mots de passe, mais nous y reviendrons plus en détail plus tard.

Dans PBKDF2, le mot de passe de l’utilisateur fait office de graine , alors que le sel fonctionne comme le texte . Ainsi, la première itération de PBKDF-HMAC-SHA-256 ressemblerait à ceci :

HMAC = H (Mot de passe ‖ H (Mot de passe ‖ Sel))

Nous avons mentionné que PBKDF2 possède quatre entrées. Choisissons-leur quelques valeurs :

• Le mot de passe (P) — PASSWORD123
• Le sel (S) — 12345678
• Le nombre d'itérations (c) - 310 000
• La longueur de la clé dérivée (dkLen) — 256 bits, soit 32 octets

La longueur de clé dérivée et la fonction de hachage ont la même longueur (256 bits), ce qui nous facilite les choses. Si la clé dérivée dont nous avions besoin devait être plus longue que la longueur de hachage, nous devrions effectuer tout le processus que nous sommes sur le point de décrire pour chacun des blocs de hachage. Ensuite, nous devrons concaténer chacune de ces sorties individuelles pour obtenir notre sortie clé finale de la fonction.

La fonction PBKDF2 peut s'écrire ainsi :

F (P, S, c, je) = U_1 XOR ET_2 XOR … XOR Et_c

Où:

U_1 = PRF (P, S || INT (i)) ,

U_2 = PRF (P, U_1) ,

…

U_c = PRF (P, U{c-1}).

Dans notre cas:

• U_x représente la fonction pseudo-aléatoire sous-jacente. U_1 est le résultat de PRF (P, S || INT (i)).
• PRF est HMAC-SHA-256
• P est MOT DE PASSE123
• S est 12345678
• INT (i) vaut 1, car la longueur de la clé dérivée et la longueur du hachage sont identiques. Nous ne prendrons pas la peine d’en expliquer la raison précise, mais vous pouvez la trouver par vous-même dans le RFC .
• c vaut 310 000, car le nombre d’itérations est de 310 000.

Donc:

DANS1 = HMAC-SHA-256 (MOT DE PASSE123, 12345678 || 1)

U_2 = HMAC-SHA-256 (MOT DE PASSE123 || U_1)

U_3 = HMAC-SHA-256 (MOT DE PASSE123 || U_2)

…

U_310 000 = HMAC-SHA-256 (MOT DE PASSE123 ‖ U{310 000-1])

Comme il n'y a qu'un seul bloc à traiter dans notre exemple simple, notre sortie pour notre clé dérivée finale est la même que U_310 000 . S'il y avait plusieurs blocs, les résultats finaux de chaque bloc devraient être concaténés pour obtenir la clé finale.

Disons simplement que la clé suivante est de 256 bits, car personne ne veut répéter le processus 310 000 fois :

bd4650a6091a9ec0efd4cee0551a8da15bca4a7766c7e5c56e676c646e8b1f0b

Comment transformer les mots de passe en clés renforce-t-il notre sécurité ?

Nous avons mentionné que l'une des principales utilisations des KDF est de transformer les mots de passe et autres sources faibles de matériel de chiffrement en clés fortes. C'est ce qu'on appelle étirement des touches . Mais comment l’extension des clés rend-elle nos systèmes plus sécurisés ? Quel rôle y jouent les fonctions de dérivation clés comme PBKDF2 ?

Pour démontrer comment les fonctions de dérivation de clé basées sur un mot de passe peuvent renforcer les cryptosystèmes, comparons un système qui n'en implémente pas avec un système qui le fait .

Dans les deux cas, nous avons une utilisateur, Alice, qui a un mot de passe faible,Lapins192. Bien queLapins192est définitivement un mot de passe faible, il n’est pas inhabituellement faible. De nombreux utilisateurs utiliseraient par défaut des mots de passe aussi simples, à moins qu'ils ne soient obligés de ne pas le faire. Notre testeur de mots de passe indique qu’il faudrait environ deux semaines pour résoudre ce problème avec un ordinateur.

Si PBKDF2 n’était pas utilisé, un attaquant utiliserait probablement un attaque de dictionnaire pour parcourir les combinaisons de mots de passe les plus probables jusqu'à ce qu'elles arrivent àLapins192. Après avoir mené l’attaque pendant deux semaines, il est probable que ils déchiffreraient le mot de passe et pourraient prendre le contrôle total du compte d'Alice .

Passons maintenant à la même chose avec un système qui implémente PBKDF2 avec HMAC-SHA-256 pour étendre le mot de passe en une clé plus forte. Dans ce système, Alice saisit son mot de passe,Lapins192, et le système l'exécute à travers les nombreuses itérations de hachage. Il crache ensuite un hachage de 256 bits. Disons que c'est quelque chose comme ça :

ff2fcd3cc0fe4ab6cc18a17a643483588f744a6af664eba96cfe651dc58a69d5

Cette fois, le pirate informatique a deux options s’il souhaite accéder au système :

Tentative de déchiffrer le mot de passe amélioré

Ils pourraient tenter de déchiffrer ce nouveau mot de passe amélioré. Cependant, ce nouveau mot de passe est aléatoire et issu d’une distribution uniforme, ce qui signifie que les attaques par dictionnaire ne seraient pas efficaces. Au lieu de cela, le pirate informatique serait obligé de le forcer brutalement, essayant chaque combinaison de caractères jusqu'à ce qu'il parvienne finalement à la clé. Comme il fait 256 bits, cela leur prendrait beaucoup de temps.

Notre outil de test de force de mot de passe estime qu’il faudrait « 3 760 septuagintillions d’années » pour déchiffrer le mot de passe . C'est bien après la mort thermique de l'univers, donc notre hacker va s'ennuyer beaucoup à attendre aussi longtemps. Dans ce cas, PBKDF2 rendrait impossible le déchiffrement du mot de passe.

Tentative de déchiffrer le mot de passe d'origine

L’autre option de l’attaquant consiste à essayer de déchiffrer le mot de passe d’origine. Mais maintenant que PBKDF2 a été implémenté, c’est un jeu complètement différent.

Un système terriblement peu sécurisé

Dans un système de mot de passe terriblement peu sécurisé, lorsque quelqu'un saisit une tentative de mot de passe, le système consulte simplement sa base de données et voit si la tentative correspond au mot de passe enregistré. Cela se produirait presque instantanément .

SHA-256 uniquement

Une avancée significative par rapport à cela serait que la base de données stocke uniquement un hachage SHA-256 du mot de passe, plutôt que le mot de passe lui-même. Dans ce cas, lorsqu'une personne saisit le mot de passe, le système le hache d'abord, puis vérifie dans sa base de données si ce hachage correspond au hachage qu'il avait enregistré.

Étant donné que le système doit également hacher le mot de passe avant de le rechercher, cela prend une infime fraction de seconde de plus . Notez que cela est toujours considéré comme non sécurisé, mais pas aussi dangereux que le premier système d'authentification par mot de passe.

Implémentation de PBKDF2

Comparons maintenant ces deux options précédentes avec un système qui implémente PBKDF2. Dans ce système, lorsqu’une personne tente de saisir un mot de passe, celui-ci n’est pas simplement haché une seule fois via SHA-256, ce qui ajoute ce tout petit peu de temps supplémentaire.

Au lieu de cela, comme nous l'avons vu précédemment, PBKDF2 implique de hacher le mot de passe avec le sel, puis de hacher ce résultat avec le mot de passe, puis de hacher ce résultat avec le mot de passe, etc.

Le nombre exact de fois dépend du nombre d'itérations qui a été choisi pour la mise en œuvre. Chaque itération supplémentaire prend un peu plus de temps. Dans notre exemple ci-dessus, il y a eu 310 000 itérations, ce qui signifie que le résultat a été haché avec le mot de passe encore et encore, 310 000 fois au total.

Pourquoi est-ce important ?

Mettez-vous à la place de l’attaquant. Ils essaient de trouver le bon mot de passe en devinant les combinaisons possibles. Dans le cadre du deuxième système d'authentification par mot de passe, chaque supposition ne prendrait qu'une infime fraction de seconde, car ils n'auraient à calculer un hachage SHA-256 qu'une seule fois.

Avec une implémentation de PBKDF2 exécutant 310 000 itérations de HMAC-SHA-256, vous les obligez essentiellement à faire 310 000 fois plus de travail pour chaque tentative de mot de passe . Cela augmente également le coût d’un multiple de 310 000.

Le résultat de la mise en œuvre de PBKDF2 est qu’il devient trop coûteux de déchiffrer un grand nombre de mots de passe qui auraient pu l’être sans lui. En rendant considérablement plus difficile le déchiffrement des mots de passe, PBKDF2 peut contribuer à assurer la sécurité de nombreux utilisateurs.

Toutes ces itérations supplémentaires de SHA-256 ont un impact sur les utilisateurs, mais cela n’est pas vraiment perceptible. Nous nous connectons relativement rarement et la plupart d’entre nous ne font que quelques tentatives avant d’obtenir nos mots de passe corrects.

Même si PBKDF2 modifie le temps de connexion d'un utilisateur de quasi-instantané à environ une seconde, cela a un effet négligeable sur lui. Mais rendre le travail d’un hacker 310 000 fois plus dur a un impact énorme sur lui. Ce compromis en vaut la peine car les gains en matière de sécurité sont énormes.

Qu'est-ce que le salage et quel rôle joue-t-il dans les fonctions de dérivation clés (KDF) ?

Maintenant que nous avons expliqué comment fonctionnent les fonctions pseudo-aléatoires comme HMAC-SHA-256 dans PBKDF2, examinons le rôle du salage. Un sel est une valeur non secrète qui est finalement stockée avec le hachage final du mot de passe.

Comme vous l'avez vu, le sel a été ajouté en tant qu'entrée dans la première itération de la fonction HMAC-SHA-256 de PBKDF2 :

U_1 = HMAC-SHA-256 (MOT DE PASSE123, 12345678 || 1)

Dans notre exemple, le sel était 12345678.

Pour comprendre ce que le sel fait réellement pour nous, nous devons discuter de la manière dont les mots de passe sont stockés et comment ils peuvent être déchiffrés.

Comment les mots de passe sont-ils stockés ?

Si vous vous souvenez de ce que nous avons mentionné précédemment, les organisations ne devraient jamais stocker les mots de passe de leurs utilisateurs. Au lieu de cela, le système doit stocker le hachage de leur mot de passe. Le système fonctionne un peu comme ceci :

• Un utilisateur saisit son mot de passe pour se connecter.
• Le système hache immédiatement le mot de passe et ne le stocke jamais.
• Le système recherche ensuite dans sa base de données pour vérifier si ce hachage de mot de passe correspond au hachage de mot de passe qu'il a dans ses fichiers pour cet utilisateur. Si les deux correspondent, l’utilisateur est autorisé à entrer.

L’avantage de ce système est que les hachages de mots de passe ne peuvent pas être utilisés pour pirater directement les comptes d’utilisateurs. Si une organisation est victime d’une violation de données, il est beaucoup plus difficile pour les pirates informatiques de compromettre les comptes d’utilisateurs lorsqu’ils ne disposent que de hachages de mots de passe plutôt que de mots de passe en texte brut.

Donnons un exemple plus concret : Alice a un compte dans une entreprise, et son mot de passe estLapin9(nous avons rendu son mot de passe encore plus faible que la dernière fois pour faciliter le travail du hacker).

Lorsqu'elle crée son compte, l'entreprise hache le mot de passe qu'elle saisit avec la fonction de hachage SHA-256 (ce n'est pas une bonne pratique de sécurité, c'est juste un exemple simplifié) et conserve cette valeur dans sa base de données afin de pouvoir la vérifier. mot de passe à l'avenir.

Un simple Hachage SHA-256 pourLapin9 serait:

7c848f9515f8d64b9e37f4459e5232b373746178c0129ddefe8c3315088db32e

Ainsi, l'entreprise aurait le hachage ci-dessus dans sa base de données, et chaque fois qu'Alice se connecterait, elle taperaitLapin9dans le champ mot de passe. L’entreprise le hacherait immédiatement, ce qui donnerait la même valeur. Il comparerait ensuite ce résultat avec le hachage dont il dispose dans sa base de données. Puisque les deux correspondent, cela lui donnerait accès.

Maintenant, disons que l'entreprise a subi une violation de données et qu'un pirate informatique a trouvé le nom d'utilisateur d'Alice et hachage du mot de passe dans la brèche. Si l'attaquant a tenté de se connecter avec :

7c848f9515f8d64b9e37f4459e5232b373746178c0129ddefe8c3315088db32e

Le système de l’entreprise hacherait immédiatement la valeur, résultant en :

ca32706cd89b61ba81c734630d09a7ec3982ca0b01e08084aebfed531b5ed61c

Le système de l’entreprise prendrait alors cette valeur et la comparerait au hachage stocké dans sa base de données. Puisque les deux ne correspondent pas, l’attaquant ne se verrait pas accorder l’accès.

Étant donné que les systèmes d'authentification sont configurés de cette manière, les hachages de mots de passe ne permettent pas aux attaquants de les utiliser pour obtenir un accès direct. Au lieu de cela, les attaquants doivent trouver un moyen de déterminer le mot de passe d'origine à partir du hachage. Mais l’une des propriétés clés des fonctions de hachage est qu’elles sont censées être Sens Unique . Ainsi, si une fonction de hachage forte a été utilisée, il n’est pas possible de simplement reconvertir le hachage en mot de passe.

Mais cela ne signifie pas que les hachages de mots de passe sont totalement inutiles aux attaquants.

Présentation des tables arc-en-ciel

Malheureusement, il n’y a pas beaucoup d’arcs-en-ciel impliqués dans les tables arc-en-ciel.

Une option consiste à construire tables arc-en-ciel . Ces tableaux sont construits en exécutant des mots de passe courants via des fonctions de hachage, puis en stockant les résultats dans un grand tableau.

En termes relatifs, le hachage peut prendre beaucoup de temps pour que les ordinateurs soient exécutés. Les recherches peuvent être effectuées beaucoup plus rapidement. Cela signifie que si vous disposez déjà d’une table arc-en-ciel précalculée de mots de passe et de hachages de mots de passe correspondants, vous pouvez économiser le temps nécessaire pour calculer tous ces hachages.

Si un attaquant est confronté à une violation de données incluant des hachages de mots de passe d'utilisateurs, il pourrait comparer ces hachages avec les hachages de mots de passe de sa table arc-en-ciel.

S'ils trouvent des correspondances entre les hachages de la violation de données et leur table arc-en-ciel, ils pourront rechercher le mot de passe correspondant pour ces utilisateurs dans leur table arc-en-ciel. Cela leur donne un moyen efficace de trouver les mots de passe des utilisateurs qui utilisent des mots de passe relativement courants.

Maintenant, nous avons dit qu’il n’était pratique de calculer des tables arc-en-ciel que pour des mots de passe relativement courants. En effet, même si les tables arc-en-ciel peuvent vous faire gagner beaucoup de temps, il existe un compromis : elles nécessitent beaucoup plus d'espace mémoire. Cela limite la taille d’une table arc-en-ciel, et c’est pourquoi elle n’est efficace que contre les combinaisons de mots de passe les plus courantes.

Le salage protège les utilisateurs

Revenons à Alice et son mot de passe faible,Lapin9.Lapin9est suffisamment simple pour que de nombreux pirates l'aient dans leurs tables arc-en-ciel précalculées. Ils savent peut-être déjà que Hachage SHA-256 pourLapin9est:

7c848f9515f8d64b9e37f4459e5232b373746178c0129ddefe8c3315088db32e

Cela signifie que lorsque l’entreprise subit une violation de données et que sa base de données de hachages de mots de passe est compromise, le hachage du mot de passe d’Alice correspondra au hachage de la table arc-en-ciel du pirate informatique. Le pirate informatique peut alors rechercher le mot de passe correspondant dans la table arc-en-ciel et prendre facilement possession de son compte.

Une façon de protéger les utilisateurs contre les attaques de table arc-en-ciel consiste à utiliser le salage. Simplifions encore les choses et disons qu'au lieu de simplement hacherLapin9avec SHA-256, le système l'ajoute d'abord avec un sel, puis le hache. Le sel est une valeur non secrète. Disons que dans ce cas, le sel est la chaîne de huit chiffres 95056398 . Cela nous donne :

Lapin995056398

Lorsque vous insérez le mot de passe et le sel via SHA-256, vous obtenez un hachage complètement différent :

82ab7b8879960812cca5091215f9a7a6462f44a4c41b8c949eeec61577a27fb1

En quoi cela change-t-il les choses du point de vue de l’utilisateur ?

Ce n'est pas le cas . Le système enregistre simplement les sels à côté des hachages de mot de passe. Chaque fois qu'un utilisateur saisit son mot de passe pour se connecter, le système récupère le sel, l'ajoute à son mot de passe, puis les hache ensemble. Une fois les deux hachés, le système prend le résultat et le compare ensuite au hachage du mot de passe contenu dans le fichier. Si les deux correspondent, cela accorde l’accès à l’utilisateur.

C’est du point de vue de l’attaquant qu’on voit une grande différence. Pourquoi? Parce que cela rend les attaques de table arc-en-ciel irréalisables . Comme nous l'avons dit, les tables arc-en-ciel accélèrent les choses au détriment de l'espace. Plus un mot de passe est long et complexe, plus la table arc-en-ciel devra être grande pour que son hachage soit inclus sur la table.

Anthony Ferrara a fait certains calculs sur son Blog :

• Un mot de passe à quatre caractères : 35 153 041 combinaisons uniques, ce qui nécessiterait une table arc-en-ciel de 913 Mo. N'importe lequel d'entre nous pourrait stocker cela sur nos ordinateurs. C’est la taille d’un film de mauvaise qualité.
• Un mot de passe à cinq caractères : 2 706 784 157 combinaisons uniques, ce qui nécessiterait une table arc-en-ciel de 70 Go. De nombreux téléphones disposent d’autant de stockage. Certains en ont beaucoup plus.
• Un mot de passe à six caractères : 208 422 380 089 combinaisons uniques, ce qui nécessiterait une table arc-en-ciel de 5,4 To. Selon votre pays, vous pouvez probablement acheter un disque dur plus gros pour quelques centaines de dollars.
• Un mot de passe à sept caractères : 16 048 523 266 853 combinaisons uniques, ce qui nécessiterait une table arc-en-ciel de 417 To. À ce stade, nous sommes hors de portée d’un pirate informatique isolé, mais de nombreux groupes de hackers ou États-nations disposeraient facilement d’une telle quantité de stockage disponible.
• Un mot de passe à huit caractères – 1 235 736 291 547 681 combinaisons uniques, ce qui nécessiterait une table arc-en-ciel de 32 Po. Un pétaoctet (PB) équivaut à 1 024 téraoctets. Cela représente beaucoup de stockage. Un adversaire aurait besoin d’une quantité exceptionnelle de ressources et d’une détermination incroyable pour construire une table arc-en-ciel d’une telle taille.

Même avec seulement 7 caractères, il est impossible pour la plupart des pirates informatiques solo de créer une table arc-en-ciel capable de deviner tous les mots de passe possibles dans cette plage. . Cela ne signifie pas que tout mot de passe de plus de 8 caractères est sûr : les mots de passe plus longs qui sont courants peuvent toujours figurer dans les tables arc-en-ciel.

En gardant ces chiffres à l'esprit, le hachage deLapin9est très probablement dans la table arc-en-ciel d’un hacker. Le hachage pourLapin995056398ce n'est pas le cas, car il s'agit d'un mot de passe long et beaucoup moins courant, et cela coûterait tout simplement trop cher de stocker des mots de passe inhabituels de cette longueur .

Le concept derrière tout cela est que l'ajout d'un sel à un mot de passe augmente radicalement la taille de la table arc-en-ciel dont un pirate informatique aurait besoin pour faire correspondre les hachages du mot de passe . Peu importe que le pirate informatique connaisse le sel, il n’est donc pas nécessaire que le sel soit une valeur secrète.

De cette façon, le sel offre aux utilisateurs disposant de mots de passe faibles une bien meilleure protection, sans que les utilisateurs n’aient à faire quoi que ce soit. Notez qu'il ne s'agit pas d'une recommandation d'utiliser des mots de passe faibles car le système compensera. Au lieu de cela, c'est une pratique de défense en profondeur .

Quel rôle joue le nombre d'itérations dans les fonctions de dérivation clés (KDF)

Le nombre d'itérations joue un autre rôle essentiel dans la sécurité des fonctions de dérivation de clé (KDF). Il permet à un implémenteur de spécifier le nombre de fois qu'un mot de passe et un sel seront hachés . Chaque itération de hachage supplémentaire rend le processus de dérivation de clé légèrement plus long et nécessite un peu plus de puissance de calcul.

Le génie de PBKDF2 est que les itérations peuvent être définies sur une échelle mobile. En quelques itérations seulement, l’algorithme s’exécute incroyablement vite. Plus un implémenteur définit d’itérations, plus le calcul de la clé est long. L'OWASP recommande actuellement 310 000 itérations de SHA-256 lorsque PBKDF2 est utilisé à des fins de hachage de mot de passe .

Nous augmentons le nombre d'itérations pour ralentir délibérément l'algorithme . Étant donné que les utilisateurs légitimes ne doivent exécuter le processus que quelques fois au maximum, cela a un effet limité sur eux.

Ce sont les pirates informatiques qui tentent de deviner des milliards et des milliards de mots de passe qui sont considérablement touchés. Puisqu’ils doivent faire de nombreuses tentatives pour déchiffrer les mots de passe, augmenter le nombre d’itérations d’un facteur 100 augmente également leurs coûts 100 fois. Ajuster le nombre d'itérations à la hausse peut rendre impossible le déchiffrement de nombreux mots de passe qui auraient été faciles à déchiffrer avec un nombre inférieur.

Lorsque PBKDF2 a été publié pour la première fois, la recommandation était de définir le nombre d'itérations sur 1 000 . Cependant, ce nombre a considérablement augmenté au fil des années, à mesure que la technologie est devenue plus puissante. Les pirates peuvent désormais accéder à des équipements plus puissants, ce qui rendrait 1 000 itérations triviales.

Quelle est la longueur de la clé dérivée ?

L'entrée de longueur de clé dérivée permet à un implémenteur de spécifier la durée de la sortie souhaitée . Ceci est essentiel lorsque des fonctions de dérivation de clé sont utilisées pour transformer des mots de passe en clés fortes, car un système de chiffrement donné aura besoin d'une clé d'une taille spécifique.

Si le système de chiffrement utilise AES 128 bits pour le chiffrement à clé symétrique, la sortie de la fonction de dérivation de clé pour AES doit être de 128 bits. AES 256 bits nécessiterait une clé de 256 bits, et ainsi de suite.

L'entrée de longueur de clé dérivée de PBKDF2 et de KDF similaires permet aux implémenteurs de définir la longueur de clé en fonction des besoins du système de cryptographie. C'est une des raisons pourquoi bcrypt ne convient pas pour dériver des clés à partir de mots de passe. Il s'agit d'un système de hachage de mot de passe qui ne permet pas à l'implémenteur de sélectionner la longueur de sortie.

Lorsqu’une fonction de dérivation de clé est utilisée pour le hachage de mot de passe, il n’est pas nécessaire de disposer d’une sortie réglable pour la longueur de clé. C'est pourquoi certains KDF peuvent être utilisés à la fois pour la dérivation de clé et le hachage de mot de passe, mais tous les schémas de hachage de mot de passe ne sont pas adaptés à la dérivation de clé.

Qu'est-ce qu'une fonction de dérivation de clé basée sur le hachage (HKDF) ?

Le fonction de dérivation de clé basée sur le hachage (HKDF) peut prendre du matériel de saisie d'entrée (IKM) et le transformer en un matériel de saisie de sortie puissant (OKM). Il est basé sur des codes d'authentification de message basés sur le hachage (HMAC) et est conçu pour être un mécanisme rapide pour produire des clés solides .

La fonction de dérivation de clé basée sur le hachage (HKDF) y parvient grâce à une approche d'extraction puis d'expansion, qui a deux utilisations :

• Extrait — Cela nous permet de prendre des sources imparfaites de matériel de chiffrement initial et de produire à partir d'elles un matériel de chiffrement de sortie solide. Des exemples de matériel de saisie imparfait incluent des sources qui ne sont pas suffisamment aléatoires et celles qui ne proviennent pas d’une distribution uniforme.
• Développer — Le module d'extension nous permet de produire plusieurs clés fortes à partir d'une seule source de matériel de clé forte.

Ces deux modules nous permettent de :

• Prenez une source de matériau faible et produisez-en une clé solide.
• Prenez une clé forte et produisez-en plusieurs clés fortes.
• Prenez une source faible de matériel de chiffrement et produisez-en plusieurs clés fortes.

La capacité de produire plusieurs clés fortes est extrêmement importante pour nos systèmes de cryptographie, car les clés ne doivent jamais être réutilisées à des fins différentes. Un outil comme HKDF nous offre un moyen simple de produire des clés distinctes pour des processus tels que :

• Chiffrement
• Authentification
• Intégrité
• Emballage des clés
• Génération de bits aléatoires

Nous devons utiliser des clés distinctes pour chaque aspect de notre système de cryptographie, car cela permet de limiter les dommages pouvant être causés si un attaquant parvient à compromettre une clé. Si un attaquant parvient à compromettre une clé qui contrôle tout, il peut dévaster la sécurité du canal de communication. Ils pouvaient lire tous les messages et même s'insérer au milieu de la conversation et produire des messages frauduleux.

Lorsque des clés distinctes sont utilisées pour chaque objectif, les conséquences potentielles peuvent être moins graves. Si un attaquant compromet une clé qui contrôle uniquement le cryptage, la confidentialité du canal de communication sera violée, mais l'intégrité et l'authenticité du canal resteront intactes. Cela reste un gros problème, mais ce n’est pas aussi grave qu’une chaîne complètement compromise.

Comme nous l'avons dit, la fonction de dérivation de clé basée sur le hachage est conçue pour être rapide. Cela fait ne convient pas pour dériver des clés à partir de mots de passe ou pour stocker des mots de passe .

Si HKDF était implémenté dans ces applications, sa vitesse signifierait qu'un attaquant pourrait effectuer beaucoup plus de tentatives de mot de passe par seconde qu'avec un système de hachage de mot de passe sécurisé. Cela rendrait beaucoup plus facile le déchiffrement des mots de passe, c'est pourquoi HKDF ne devrait être mis en œuvre que pour les utilisations prévues.

Les différentes exigences des fonctions de dérivation de clés et des schémas de hachage de mots de passe

Maintenant que nous avons parcouru PBKDF2 comme exemple de fonction de dérivation de clé basée sur un mot de passe et couvert chacun des éléments importants en détail, nous pouvons prendre du recul et résumer nos exigences pour chacun des différents cas d'utilisation.

Pour dériver des clés fortes à partir de mots de passe :

• Nous voulons un algorithme capable de prendre des mots de passe comme entrées et de produire des clés aléatoires et uniformes. Passer l'entrée via un grand nombre d'itérations dans une fonction HMAC aide à étirer les touches de cette façon.
• Nous voulons pouvoir définir la longueur de la clé dérivée .

Pour stocker les mots de passe :

• Nous voulons que l’algorithme soit lent, afin de rendre le travail du hacker encore plus difficile. L'étirement des clés sur un grand nombre d'itérations permet d'y parvenir .
• Nous voulons rendre les attaques de table arc-en-ciel peu pratiques. C'est pourquoi le salage est si important .

Pour dériver des clés fortes à partir de sources plus faibles de matériel de saisie qui ne sont pas des mots de passe :

• Nous voulons produire clés fortes avec une entropie suffisante à partir d'une distribution uniforme .
• Nous voulons pouvoir définir la longueur de clé souhaitée .
• Ces sources plus faibles de matériel de chiffrement ont toujours une entropie beaucoup plus élevée que de nombreux mots de passe. Dans ce scénario, il n’est pas non plus nécessaire d’avoir une fonction délibérément lente, comme dans les PBKDF. Plutôt, l'efficacité est plus souhaitable .

Pour dériver plusieurs clés fortes à partir d’une seule source de matériel de clé forte :

• Chacune de ces clés doit être forts et indépendants les uns des autres de sorte que si un attaquant en compromet une, cela n’entraîne pas la compromission de toutes les clés utilisées dans d’autres aspects du cryptosystème.
• Nous voulons pouvoir définir la longueur de clé souhaitée .
• Étant donné qu’aucun mot de passe n’est impliqué et que les clés initiales disposent déjà d’une forte source d’entropie, il n’est pas nécessaire d’effectuer un grand nombre d’itérations pour ralentir délibérément les attaquants. Encore une fois, l'efficacité est souhaitée .

Fonctions communes et leurs utilisations

Voici une liste de certaines des fonctions les plus couramment utilisées pour la dérivation de clé ou le hachage de mot de passe :

• Argon2 — Cette fonction a été gagnante du concours de hachage de mot de passe. Argon2 est un KDF conçu pour être gourmand en mémoire. Cela le rend adapté à la fois au hachage de mot de passe et à la dérivation de clé. Il prend un mot de passe et un sel comme entrées principales, ainsi que huit entrées secondaires distinctes. Il existe plusieurs versions différentes, chacune avec ses propres avantages spécifiques :
  • Argon2d
  • Argon2i
  • Argon2id
• scénario — scénario est une autre fonction de dérivation de clé qui peut être utilisée à la fois pour stocker des mots de passe et pour dériver des clés. Il a également été conçu pour être gourmand en mémoire afin de rendre le piratage de mots de passe beaucoup plus coûteux pour les attaquants. Ses entrées incluent le mot de passe, le sel, le facteur de coût, le facteur de taille de bloc, le facteur de parallélisation, la longueur de clé souhaitée et quelques autres paramètres.
• PBKDF2 — Nous avons déjà discuté PBKDF2 en profondeur tout au long de cet article. Juste pour réitérer, ses entrées incluent le mot de passe, le sel, le nombre d'itérations et la longueur de la clé dérivée. Bien qu'il puisse être utilisé à la fois pour dériver des clés et pour le hachage de mots de passe, de nos jours, il est principalement utilisé pour le hachage de mots de passe car il s'agit d'une fonction assez ancienne. L'OWASP recommande 310 000 itérations de SHA-256 dans PBKDF2 afin que ses hachages de mot de passe disposent d'une marge de sécurité sûre.
• bcrypt — bcrypt est uniquement un système de hachage de mot de passe, plutôt qu'un KDF pouvant être utilisé dans les deux applications. Il intègre un sel et possède un nombre d'itérations qui peut être varié afin de le ralentir et de le rendre plus résistant aux attaques. Cependant, un implémenteur ne peut pas ajuster la longueur de la clé de sortie, ce qui la rend impropre à la déduction des clés.
• HKDF — HKDF est une fonction de dérivation clé. Cependant, il ne doit pas être utilisé pour extraire des clés de mots de passe ou pour stocker des mots de passe, car il est trop rapide. Au lieu de cela, il doit être utilisé pour dériver des clés fortes à partir de matériaux de saisie plus faibles (pas de mots de passe), pour dériver plusieurs clés à partir de matériaux d'entrée forts, ou les deux.