web-dev-qa-db-fra.com

Sécurité de la clé privée protégée par mot de passe

Si un attaquant obtient une clé privée qui a été créée sans phrase secrète, il accède évidemment à tout ce qui est protégé par cette clé. Dans quelle mesure les clés privées sont-elles sécurisées avec une phrase secrète? Si un attaquant vole une clé protégée par une phrase secrète, à quel point est-il difficile de compromettre la clé? En d'autres termes, une clé privée avec une bonne phrase secrète est-elle sécurisée même si un attaquant y accède?

45
jrdioko

Avec OpenSSL, OpenSSH et GPG/PGP, l'algorithme d'encapsulation sera suffisamment fort pour que vous n'ayez pas à vous en préoccuper (et si vous en avez besoin, vous avez de plus gros problèmes, et c'est le moindre de vos soucis) .

Comme tout mot de passe ou phrase de passe, cela dépend de la force de la phrase de passe. Une phrase de passe de 40 caractères est aussi difficile à utiliser brutalement qu'une clé de 256 bits (puisque ASCII n'utilise que 7 bits). Les mêmes règles pour les mots de passe forts s'appliquent ici:

  • Le hasard c'est mieux
  • Plus long est plus fort
24
bahamat

Une fois qu'un bloc de données chiffré est entre les mains d'un attaquant, il n'est jamais sécurisé pour toujours - il s'agit de savoir combien de temps et quels moyens sont disponibles pour craque le.

Voici les éléments à considérer:

  • force de l'algorithme d'encapsulation - Je suis prêt à croire bahamat à propos d'OpenSSL, OpenSSH et GPG/PGP - ce sont des composants assez bien contrôlés.

  • taille de l'espace clé - c'est-à-dire - taille et complexité du mot de passe - les coûts typiques de la devinette par force brute s'appliquent. Il convient de noter que certaines formes de stockage de clés limitent les types de caractères pouvant être utilisés dans un mot de passe - par exemple, JKS (le Java Key Store) a éliminé un certain nombre de caractères spéciaux, réduisant le potentiel taille de l'espace clé. Méfiez-vous également des systèmes qui recadrent la taille de la clé à un certain nombre de caractères.

  • coût de la tentative combien coûte le calcul pour tenter de déballer la clé? Cela ralentira la tentative de force brute.

  • quel algorithme? - dépend de la façon dont le fichier sécurisé est stocké - est-il évident quel algorithme a été utilisé pour le chiffrement?

  • y a-t-il du texte chiffré disponible pour comparer? comment l'attaquant saura-t-il qu'il a réussi - quel est son mécanisme de test? L'un des éléments les plus puissants de la capture d'un magasin de clés est que l'attaquant peut être en mesure de tester ses tentatives sans autre détection par le système stockant la clé.

  • combien de ressources sont à la disposition de l'attaquant? - généralement, l'analyse des menaces implique d'analyser les ressources de l'attaquant. At-il 1 ordinateur? Une banque d'ordinateurs? Et tout le réseau viral de CPU volé à sa disposition? Cela dépend si vous parlez du script kiddie de 13 ans à côté ou d'une nation voyou.

  • combien de temps jusqu'à ce que la clé soit modifiée? & combien de temps les données doivent-elles rester protégées? - s'il faut plus de temps à l'attaquant pour casser le magasin de mots de passe que l'utilité des données à l'intérieur le magasin, puis le magasin est considéré comme suffisamment sécurisé

15
bethlakshmi

Selon Martin Kleppmann :

la protection de la clé privée [OpenSSH par défaut] présente deux faiblesses:

  • L'algorithme de résumé est codé en dur pour être MD5, ce qui signifie que sans changer le format, il n'est pas possible de passer à une autre fonction de hachage (par exemple SHA-1). Cela pourrait être un problème si MD5 ne s'avère pas assez bon.
  • La fonction de hachage n'est appliquée qu'une seule fois --- il n'y a pas d'étirement. C'est un problème car MD5 et AES sont tous deux rapides à calculer, et donc une phrase de passe courte est assez facile à casser avec la force brute.

Si votre clé SSH privée tombe entre de mauvaises mains [et si elle était protégée par un mot de passe à l'aide des paramètres OpenSSH par défaut et si] votre mot de passe est un mot de dictionnaire, il peut probablement être [déchiffré] en quelques secondes. ... Mais il y a une bonne nouvelle: vous pouvez passer à un format de clé privée plus sécurisé, et tout continue à fonctionner!

Il explique ensuite comment utiliser "PKCS # 8" selon la RFC 5208 pour obtenir une clé privée cryptée de manière plus sécurisée:

$ mv test_rsa_key test_rsa_key.old
$ openssl pkcs8 -topk8 -v2 des3 \
    -in test_rsa_key.old -passin 'pass:super secret passphrase' \
    -out test_rsa_key -passout 'pass:super secret passphrase'
7
sampablokuper

Le cryptage de la clé privée OpenSSH est-il vulnérable?

La protection d'une clé privée avec une phrase secrète doit être effectuée avec soin, comme c'est généralement le cas en matière de cryptographie. Généralement, l'approche consiste à chiffrer la clé privée avec un algorithme symétrique en utilisant une clé dérivée de la phrase secrète via une fonction de dérivation de clé. Un exemple classique d'une fonction de dérivation de clé appropriée est PBKDF2 de RFC 2898 - PKCS # 5: Spécification de cryptographie basée sur mot de passe version 2. .

Selon Colin Percival présentation scrypt , "OpenSSH utilise MD5 comme fonction de dérivation de clé pour les phrases de passe sur les fichiers de clés". Du contexte, il semble qu'il dit qu'ils n'utilisent pas de sels ou d'itérations, ce qui est effrayant compte tenu de la rapidité du forçage brutal de nos jours. Il existe plusieurs formats différents qu'OpenSSH utilise pour stocker des clés privées, j'aimerais donc en savoir plus sur les versions concernées, mais cela ressemble beaucoup à PBKDF2 ou à l'autre techniques itérées et salées qui existent depuis 1978 .

Je vois une référence affirmant que PGP et GPG utilisent des techniques d'itération/d'étirement lors de la protection d'une clé privée stockée dans un fichier, mais encore une fois, je ne connais pas encore les détails.

4
nealmcb