Comment keytool protège les clés?

Question

Lorsque vous créez un magasin de clés avec l'utilitaire Java Keytool, comment les clés sont-elles protégées? J'ai lu la documentation, et je me rends compte que chaque clé privée a un mot de passe clé, puis le magasin a un mot de passe de magasin.

Mais quel mécanisme est utilisé pour protéger les données? Est-ce un chiffrement? Si oui, quel est l'algorithme? Je me concentre spécifiquement sur la façon dont keytool fait la protection quand il construit un fichier JKS.

Answer 1

Le keystore JKS par défaut de Sun utilise un algorithme propriétaire, principalement pour contourner les restrictions d'exportation sur les algorithmes standard. L'algorithme est mis en œuvre dans cette classe,

sun.security.provider.KeyProtector 

La est la description de l'algorithme,

C'est une implémentation d'un algorithme propriétaire Sun, exportables destiné à être utilisé lors de la protection (ou récupérer la version texte clair de) touches sensibles. Cet algorithme n'est pas conçu comme un chiffrement à usage général. Voici comment fonctionne l'algorithme pour la protection des clés: p - mot de passe utilisateur s - sel aléatoire X - clé xor P - clé à protéger Y - clé protégée R - ce qui est stocké dans le keystore Étape 1: prendre le mot de passe de l'utilisateur, ajoutez un salt aléatoire (de taille fixe) et hachez-le: d1 = digest (p, s) Stockez d1 dans X. Étape 2: prenez le mot de passe de l'utilisateur, ajoutez le résultat digéré de l'étape précédente et hachez-le: dn = digérer (p, dn-1). Stockez dn dans X (ajoutez-le aux digests précédemment stockés). Répétez cette étape jusqu'à ce que la longueur de X corresponde à la longueur de la clé privée P. Étape 3: XOR X et P, et stockez le résultat dans Y: Y = X XOR P. Étape 4: Stockez s, Y et digérer (p , P) dans le tampon de résultat R: R = s + Y + digest (p, P), où "+" désigne une concaténation. (NOTE: digest (p, P) est stocké dans le tampon de résultat, de sorte que lorsque la clé est récupérée, nous pouvons vérifier si la clé récupérée correspond effectivement à la clé d'origine.) R est stocké dans le keystore. La clé protégée est récupérée comme suit: Step1 et Step2 sont les mêmes que ci-dessus, sauf que le sel n'est pas généré aléatoirement, mais pris dans le résultat R de l'étape 4 (la première longueur (s) octets). L'étape 3 (opération XOR) donne la clé en clair. Puis concaténez le mot de passe avec la clé récupérée, et comparez avec la dernière longueur (digest (p, P)) octets de R. Si elles correspondent, la clé récupérée est en effet la même clé que la clé originale.

Answer 2

L'algorithme utilisé dépend du fichier de clés que vous utilisez (il peut s'agir d'une carte à puce, par exemple).

Le keystore par défaut que les navires Sun avec le JDK crée un jeton logiciel (sur fichier disque) avec three encryption options:

1. par défaut: "JKS", un type de keystore propriétaire (format). Je ne suis pas sûr de l'algorithme.

2. "JCEKS", un format propriétaire alternatif, en utilisant 3-DES

3. "pkcs12", un format standard (OpenSSL peut le lire), avec plusieurs options, mais généralement 3-DES pour les clés privées et RC2-40 pour les certificats.

Dans les trois cas, vous avez les données privées cryptées (de façon symétrique, en utilisant des mots de passe individuels), et l'intégrité de l'ensemble du magasin clé protégée par un condensé cryptographique (en utilisant le mot de passe keystore).