cryptage renforcé pour les clés SSH

Question

J'ai configuré mon serveur pour crypter les mots de passe des utilisateurs à l'aide de 500 000 tours de SHA-512.

La question est de savoir comment la pile de clés privées SSH chiffrée AES-128-CBC standard peut atteindre cette valeur, à condition que le même mot de passe/phrase de passe (ou longueur similaire) soit utilisé? Cela doit être une phrase secrète typable par l'homme, bien sûr, et le manque d'entropie dans ce cas est (espérons-le) le maillon le plus faible ici. Ma compréhension est que le renforcement des clés étendra l'effort requis pour forcer la phrase secrète par force brute, peu importe la faiblesse de la phrase secrète.

Il est clair pour moi que puisque la clé publique est publique et peut être utilisée pour vérifier la clé privée, la sécurité de cette clé privée dépendra de la phrase secrète (la longueur de la clé RSA ne tiendra pas compte de la facilité avec laquelle elle est le révéler). J'imagine que la vérification serait assez rapide, donc je voudrais idéalement augmenter le nombre de tours et utiliser des suites de chiffrement plus fortes pour ralentir le processus de renforcement de la phrase secrète.

Combien de sécurité supplémentaire sur la phrase secrète peut être obtenue en en utilisant PKCS # 8 pour une clé privée SSH?

Je me demande également comment améliorer potentiellement cela. Existe-t-il un moyen de faire ce cryptage

openssl pkcs8 -topk8 -v2 des3

utiliser encore plus de tours que la valeur par défaut (et être toujours accepté par ssh)? Existe-t-il également des suites encore plus performantes? Je travaille avec Centos 6.4 ici pour l'instant (car j'aime les scripts kickstart), donc c'est probablement une bonne idée de ne pas jouer avec la suite de programmes sécurisée si je peux l'aider, mais il existe peut-être une suite de chiffrement symétrique encore plus puissante que PKCS # 8 qui peut être utilisé?

Une chose que j'ai remarquée, c'est que le PBKDF2 ici ne semble pas spécifier le hachage sous-jacent utilisé. En regardant la liste ça ne va pas mieux que SHA1 semble-t-il.

Je veux trouver un moyen de tirer le meilleur parti des ~ 0,5 seconde tolérables pour une authentification réussie afin de maximiser la quantité de calcul requise pour le forçage brutal.

Je suppose que si je tenais vraiment au renforcement, je devrais regarder scrypt , mais il n'y a pas de support natif dans les outils, donc cela ne peut pas être utilisé pour la clé privée SSH au jour le jour gestion (mais il pourrait convenir à une utilisation dans des applications spéciales).

Edit: Intéressant. Ma clé privée chiffrée sur CentOS ressemble à ceci:

-----BEGIN RSA PRIVATE KEY----- Proc-Type: 4,ENCRYPTED DEK-Info: DES-EDE3-CBC,D3A046CD...

Je suppose que ce n'est pas nécessairement pire qu'AES-128-CBC (c'est ce que mon Mac a produit).

Tom Leek · Accepted Answer

Ce qui se passe pour le stockage de clé privée est un peu complexe car il implique plusieurs couches de crud sous-spécifiées accumulées au fil des ans et conservées pour une compatibilité descendante. Découvrons le mystère.

Pour ses opérations cryptographiques, y compris le stockage de clés privées (ce qui nous intéresse actuellement), OpenSSH s'appuie sur bibliothèque OpenSSL . Donc OpenSSH supportera ce que OpenSSL supporte.

Une clé privée est un groupe d'objets mathématiques qui peuvent être codés dans une structure qui est, normalement, binaire (c'est-à-dire un groupe de octets , pas caractères imprimables). Supposons une clé RSA. Le format d'une clé privée RSA est défini dans PKCS # 1 comme structure ASN.1 qui sera codé à l'aide des règles de codage DER.

Depuis que de nombreux outils liés à la cryptographie ont commencé leur vie au début et au milieu des années 1990 et, à cette époque, le courrier électronique était le plus à la mode (le Web était encore jeune), les outils s'efforçaient d'utiliser caractères qui pourrait être collé dans un e-mail (les fichiers joints n'étaient pas encore courants de nos jours). En particulier, il existait une première norme appelée Courrier électronique à confidentialité améliorée , ou "PEM". Cette norme n'a jamais été vraiment déployée ou utilisée, et d'autres systèmes l'ont emporté (à savoir PGP et S/MIME ), mais une fonctionnalité de PEM bloqué: un moyen de coder un objet binaire en texte imprimable. Il s'agit du format PEM . Cela ressemble à ceci:

-----BEGIN SOMETHING----- Some-optional: headers Base64+Encoded+Data== -----END SOMETHING-----

PEM est donc une sorte d'encapsuleur avec les données binaires codées en Base64 , et des lignes d'en-tête et de pied de page ajoutées, qui incluent un type (le "SOMETHING"). Les "en-têtes facultatifs" sont un ajout ultérieur d'OpenSSL, et ils n'ont jamais été standardisés, donc PEM-avec-en-têtes n'est documenté que comme "ce que fait OpenSSL". La documentation OpenSSL étant ce qu'elle est, cela signifie que, pour savoir exactement ce que ce processus implique, vous devez plonger dans le code source redouté d'OpenSSL.

Voici une clé privée RSA non chiffrée, au format PEM:

Comme vous pouvez le voir, le type est "RSA PRIVATE KEY". La structure ASN.1 peut être explorée avec openssl asn1parse:

$ openssl asn1parse -i -in keyraw.pem 0:d=0 hl=4 l= 605 cons: SEQUENCE 4:d=1 hl=2 l= 1 prim: INTEGER :00 7:d=1 hl=3 l= 129 prim: INTEGER :D0DF79DD0EBE4DFC023CCB63F3AEA19B69D2DE4B97D27F61AC549C760762B185ACCBDB3E4EB9F8A7FB08C9D615B5DBFCD6C90B3FF42158405AE27DEF8FACC50E74B8ADB26943DE5E25050DBDF972AC98F69BB4834F250D27E1DC60046785C5309DE252708B2B2656C5CF9CDAE0413731DA78ABAC89350BBC125BD022F56DDF65 139:d=1 hl=2 l= 3 prim: INTEGER :010001 144:d=1 hl=3 l= 129 prim: INTEGER :A88A4AF916F67452CF33632309F475AEC41B4508563FA24D9C12C215732C2DF6A151F55D378554A1A72C9640CB4FED6CFD9B481A98D17736A69F6FE32859CEBEBF0543D7F8DD45396F10E4E5C7303E1F5D28B1AD7D2F60E4FC850B827A14C05EC4AD8E466ACC2742B0A57D60876E4C7A328CBDA31BA401BC540AEE41DA614C19 276:d=1 hl=2 l= 65 prim: INTEGER :FABA766FE7810C9AE096A70F384D879029107117925B4388A1481DDAD2223C52FC1D23702AFBC0007F9004A2FA8EF79C2ECC099DE79CA27F198EC827E0AFC4A7 343:d=1 hl=2 l= 65 prim: INTEGER :D543BA5B5B62AFE1DC5E456C0438AFA70C4366669A130576DF2B46F01D133D7C0AEA1B1AF010CB7D6153F2275B49FE674A070AC220CA8C127821B044B3096113 410:d=1 hl=2 l= 64 prim: INTEGER :62835D01BEFE4F8B92EEDE98F65050116E710D5E6B9CFC3DF4D0B71A41323E6D84AD963CFE46883C29E2D64F8B0F1D6EFA5C24F32C0BB935233F9C993E891145 476:d=1 hl=2 l= 64 prim: INTEGER :1C735F9E266FE0F4E9B82DDCBE276DCF84444D99EC7E13218B9E33657F0B7D0D5A4B66F84E047F912775D27D4BA1706E09232D5D3E90A6E523DFA2AB57932DBF 542:d=1 hl=2 l= 65 prim: INTEGER :BE40317B635A382290C672EFB75A14BFA48FC29170F6A4330933AAC60601BA83D0F55533C2C742D90162B819D9842E13CCFB478F1F83F6E3F56C258E26BEEB50

Nous reconnaissons ici les composants d'une clé privée RSA: quelques gros entiers. Voir PKCS # 1 pour les détails mathématiques.

Il se trouve que le format PEM étendu qu'OpenSSL utilise prend en charge le cryptage par mot de passe . Après une lecture de code, il s'avère que le chiffrement utilise le mode CBC, avec un IV et un algorithme spécifiés dans les en-têtes; et la transformation mot de passe en clé repose sur EVP_BytesToKey() (définie dans crypto\evp\evp_key.c) avec les fonctionnalités suivantes:

Il s'agit d'un hachage non standard fonction de dérivation de clé .
L'IV pour le cryptage est également utilisé comme sel.
La fonction de hachage est MD5.
Le hachage est utilisé à plusieurs reprises, pour n itérations, mais dans le cas du chiffrement PEM, le nombre d'itérations n est défini sur 1.

Le fait que le KDF ne soit pas standard est une source d'inquiétude. La réutilisation du chiffrement IV pour un sel est une préoccupation mineure (c'est mathématiquement impur, mais probablement pas un vrai problème - et, au moins, il y a est un sel). L'utilisation de MD5 est également une préoccupation mineure (bien que MD5 soit complètement rompu en ce qui concerne les collisions, la dérivation des clés repose généralement sur résistance à la pré-image, pour laquelle MD5 est encore assez fort, presque aussi bon que neuf) . Le nombre d'itérations défini sur 1 (ce qui signifie qu'il n'y a pas de boucle du tout) est un problème sérieux.

Cela signifie que si un attaquant tente de deviner le mot de passe d'une clé cryptée PEM, le coût de calcul pour chaque essai sera minime. Avec un bon GPU, cet attaquant pourrait essayer plusieurs milliards de mots de passe par seconde. C'est beaucoup trop rapide pour le confort. La dérivation de clé basée sur le mot de passe doit être à la fois salée et lente, et le format de cryptage OpenSSL PEM échoue sur le deuxième point. Voir cette réponse pour une discussion détaillée.

Voici une clé privée cryptée PEM; l'algorithme de chiffrement a été défini sur AES-128. Le mot de passe est "1234":

En raison du cryptage, les octets ne peuvent plus être analysés avec asn1parse.

PKCS # 8 est une norme sans rapport avec le codage des clés privées. Il s'agit en fait d'un wrapper. Un objet PKCS # 8 est une structure ASN.1 qui comprend quelques informations de type et, en tant que sous-objet, une clé privée. Les informations de type indiqueront "ceci est une clé privée RSA". Étant donné que PKCS # 8 est basé sur ASN.1, il en résulte un binaire non imprimable, donc OpenSSL l'enveloppera avec plaisir à nouveau dans un objet PEM.

Ainsi, voici la même clé privée RSA que ci-dessus, comme un objet PKCS # 8, lui-même encodé en PEM:

Comme vous le voyez, le type indiqué dans l'en-tête PEM n'est plus "RSA PRIVATE KEY" mais simplement "PRIVATE KEY". Si nous appliquons asn1parse Dessus, nous obtenons ceci:

 0:d=0 hl=4 l= 631 cons: SEQUENCE 4:d=1 hl=2 l= 1 prim: INTEGER :00 7:d=1 hl=2 l= 13 cons: SEQUENCE 9:d=2 hl=2 l= 9 prim: OBJECT :rsaEncryption 20:d=2 hl=2 l= 0 prim: NULL 22:d=1 hl=4 l= 609 prim: OCTET STRING [HEX DUMP]:30820<skip...>

(J'ai coupé beaucoup d'octets dans la dernière ligne). Nous voyons que la structure commence par un identifiant qui dit "ceci est une clé privée RSA", et la clé privée elle-même est incluse en tant que OCTET STRING (Et le contenu de cela chaîne sont exactement la structure basée sur ASN.1 décrite ci-dessus).

PKCS # 8 prend en charge en option le cryptage basé sur un mot de passe . Il s'agit d'un format très ouvert, il est donc potentiellement compatible avec tous les systèmes de cryptage par mot de passe dans le monde, mais le logiciel doit le prendre en charge. OpenSSL prend en charge l'ancien cryptage DES + MD5, ou le plus récent PBKDF2 et un algorithme configurable. DES (pas 3DES) est un problème mineur: DES est relativement faible en raison de sa petite taille de clé (56 bits) rendant une rupture à travers une recherche exhaustive technologiquement faisable) (cela a été fait), mais cela coûterait assez cher à un amateur, mais il vaut mieux utiliser PBKDF2 et un meilleur algorithme de chiffrement.

Étant donné une clé privée brute comme indiqué ci-dessus, voici une ligne de commande OpenSSL qui la transforme en un objet PKCS # 8, avec cryptage 3DES et PBKDF2 pour la dérivation de clé basée sur un mot de passe:

openssl pkcs8 -topk8 -in keyraw.pem -out keypk8.pem -v2 des3

ce qui donne:

Alors maintenant, c'est une "CLÉ PRIVÉE CRYPTÉE". Voyons ce que asn1parse Peut en dire:

 0:d=0 hl=4 l= 710 cons: SEQUENCE 4:d=1 hl=2 l= 64 cons: SEQUENCE 6:d=2 hl=2 l= 9 prim: OBJECT :PBES2 17:d=2 hl=2 l= 51 cons: SEQUENCE 19:d=3 hl=2 l= 27 cons: SEQUENCE 21:d=4 hl=2 l= 9 prim: OBJECT :PBKDF2 32:d=4 hl=2 l= 14 cons: SEQUENCE 34:d=5 hl=2 l= 8 prim: OCTET STRING [HEX DUMP]:653DEBBD553CE69D 44:d=5 hl=2 l= 2 prim: INTEGER :0800 48:d=3 hl=2 l= 20 cons: SEQUENCE 50:d=4 hl=2 l= 8 prim: OBJECT :des-ede3-cbc 60:d=4 hl=2 l= 8 prim: OCTET STRING [HEX DUMP]:2D6175AB346F8E62 70:d=1 hl=4 l= 640 prim: OCTET STRING [HEX DUMP]:9EC2DF16920<skip...>

On voit là que PBKDF2 est utilisé. Le OCTET STRING Avec le contenu 653DEBBD553CE69D Est le sel de PBKDF2. Le INTEGER de la valeur 0800 (Qui est hexadécimal pour 2048) est le nombre d'itérations. Le chiffrement lui-même utilise 3DES en mode CBC, avec son propre IV généré de façon aléatoire (2D6175AB346F8E62). C'est très bien. PBKDF2 utilise SHA-1 par défaut, ce qui n'est pas un problème.

Il se trouve que même si OpenSSL prend en charge les nombres d'itérations quelque peu arbitraires (eh bien, gardez-le sous 2 milliards pour éviter les problèmes avec les entiers signés 32 bits), l'outil de ligne de commande openssl pkcs8 Fait pas vous permet de changer le nombre d'itérations par rapport au 2048 par défaut, sauf pour le mettre à 1 (avec l'option -noiter). C'est donc 2048 ou 1, rien d'autre. 2048 est bien meilleur que 1 (disons, c'est 2048 fois mieux), mais il est encore assez faible par rapport à la norme d'aujourd'hui.

Résumé: OpenSSH peut accepter des clés privées au format RSA/PEM brut, RSA/PEM avec cryptage, PKCS # 8 sans cryptage ou PKCS # 8 avec cryptage (qui peut être "à l'ancienne" ou PBKDF2). Pour la protection par mot de passe de la clé privée, contre les attaquants qui pourraient voler une copie de votre fichier de clé privée, vous vraiment souhaitez utiliser la dernière option: PKCS # 8 avec cryptage avec PBKDF2. Malheureusement, avec l'outil de ligne de commande openssl, vous ne pouvez pas configurer beaucoup PBKDF2; vous ne pouvez pas choisir la fonction de hachage (c'est SHA-1, et c'est tout - et ce n'est pas un vrai problème), et, plus important encore, vous ne pouvez pas choisir le nombre d'itérations, avec une valeur par défaut de 2048 qui est un peu faible pour le confort.

Vous pouvez crypter votre clé avec un autre outil, avec un nombre d'itérations PBKDF2 plus élevé, mais je ne connais aucun outil facilement disponible pour cela. Ce serait une question de programmation avec une bibliothèque de crypto.

Dans tous les cas, vous feriez mieux d'avoir un mot de passe fort. 15 lettres minuscules aléatoires (faciles à taper, pas si difficiles à retenir) offriront 70 bits d'entropie, ce qui est assez pour contrecarrer les attaquants, même en cas de mauvaise dérivation de mot de passe (nombre d'itérations de 1).

Lekensteyn · Answer

Les versions plus récentes du client OpenSSH (> = 6.5) prennent en charge un format de clé privée spécifique à OpenSSH plus récent qui utilise une fonction dérivée de clé appropriée. À l'heure actuelle, seul bcrypt est pris en charge en tant que kdfname (voir ceci document de spécification ). Ce format est utilisé par défaut depuis OpenSSH 7.8 .

Pour les versions plus anciennes (<7.8), passez le -o option pour ssh-keygen, cela forcera l'utilisation du nouveau format OpenSSH. La clé privée résultante ressemble à:

Cet article mentionne d'autres considérations telles que l'utilisation d'un nombre personnalisé de tours avec le -a option (voir aussi la page de manuel de ssh-keygen).

Si vous avez une ancienne clé PKCS # 8 avec un nombre d'itérations supérieur , déchiffrez-la d'abord, puis convertissez-la au nouveau format en définissant un mot de passe:

# WARNING: /tmp/mykey will contain the unencrypted key. # If /tmp is a tmpfs, this is ok. openssl pkcs8 -in ~/.ssh/id_rsa -out /tmp/mykey ssh-keygen -p -f /tmp/mykey # validate the key and then move back: mv /tmp/mykey ~/.ssh/id_rsa