web-dev-qa-db-fra.com

Pourquoi les clés DSA obsolètes OpenSSH

Il y avait une question RSA contre DSA pour les clés d'authentification SSH demandant quelle clé est meilleure. Fondamentalement, toutes les réponses étaient plutôt en faveur de RSA par rapport à DSA, mais ne disaient pas vraiment que DSA serait en quelque sorte peu sûr.

Maintenant, cependant, DSA a été déconseillé par OpenSSH et va ensuite être entièrement supprimé: https://www.gentoo.org/support/news-items/2015-08-13-openssh-weak-keys.html

Les informations indiquent:

Depuis la version 7.0 d'OpenSSH, la prise en charge des clés ssh-dss a été désactivée par défaut au moment de l'exécution en raison de leur faiblesse héritée. Si vous comptez sur ces types de clés, vous devrez prendre des mesures correctives ou risquer d'être bloqué.

Votre meilleure option est de générer de nouvelles clés en utilisant des algos puissants tels que rsa ou ecdsa ou ed25519. Les clés RSA vous offriront la plus grande portabilité avec d'autres clients/serveurs tandis qu'ed25519 vous offrira la meilleure sécurité avec OpenSSH.

Qu'est-ce qui rend les clés DSA intrinsèquement faibles?

sshrsaopensshdsa
72
Petr

C'est une bonne question. La page dédiée d'OpenSSH dit seulement:

OpenSSH 7.0 et supérieur désactive également l'algorithme de clé publique ssh-dss (DSA). Il est également faible et nous déconseillons son utilisation.

qui n'est pas plus détaillée que la "faiblesse héritée" de l'annonce. Je n'ai trouvé aucune explication publiée à propos de ces faiblesses, à l'exception d'un certain raisonnement non étayé qui parle de "découvertes récentes". Ainsi, il est temps de faire un détour.

Dans le code source d'OpenSSH-6.9p1 (package Ubuntu 15.10), pour l'outil de génération de clés ssh-keygen, Je trouve ce bout de code remarquable:

    maxbits = (type == KEY_DSA) ?
        OPENSSL_DSA_MAX_MODULUS_BITS : OPENSSL_RSA_MAX_MODULUS_BITS;
    if (*bitsp > maxbits)
            fatal("key bits exceeds maximum %d", maxbits);
    if (type == KEY_DSA && *bitsp != 1024)
            fatal("DSA keys must be 1024 bits");

Le OPENSSL_DSA_MAX_MODULUS_BITS est une constante des en-têtes d'OpenSSL, qui la définit à 10000. Ainsi, les quatre premières lignes vérifient que la taille de clé demandée, au moment de la génération, peut réellement être gérée par le processus de génération de clé. Cependant, les deux lignes suivantes disent essentiellement: "quel que soit le test ci-dessus, si la clé est DSA et la taille n'est pas 1024, niet."

Ces 6 lignes sont, en soi, un signe certain que celui qui a développé ce code n'était pas complètement d'accord avec lui en ce qui concerne les tailles de clés. Ce code a probablement été assemblé progressivement et peut-être par différentes personnes. La source du "1024" peut être attribuée à la norme DSA réelle (appelée "DSS" en tant que "norme de signature numérique"), FIPS 186-4 . Cette norme a été révisée plusieurs fois. Dans sa première version, DSA a été mandaté pour utiliser un module dont la taille était comprise entre 512 et 1024 bits (et devrait être un multiple de 64, sans doute pour simplifier la tâche des implémenteurs). Une version ultérieure a reconnu l'augmentation de la puissance technologique et des avancées mathématiques, et a interdit toute taille autre que 1024 bits. La version moderne de FIPS 186 (la quatrième révision, début 2016) permet au module d'avoir une taille de 1024, 2048 ou 3072 bits.

On peut donc supposer que ssh-keygen refuse d'utiliser une taille de module différente de 1024 bits parce que quelqu'un, à un moment donné, a lu la version alors actuelle FIPS 186 version qui l'exigeait exactement, et personne n'a pris la peine de mettre à jour ssh-keygen lorsque la norme FIPS a été modifiée. Indépendamment de la façon dont ce spectaculaire élément de programmation de la schizophrénie a vu le jour, le résultat brut est que la plupart sinon toutes les clés SSH de type DSA utilisées aujourd'hui dépendent de un module de 1024 bits.

La pièce suivante du puzzle est la attaque Logjam . Logjam consiste essentiellement à remarquer que lorsqu'un client et un serveur acceptent d'utiliser une cryptographie faible, ils peuvent être attaqués. Il s'agit d'une attaque contre SSL/TLS, pas SSH. Cependant, l'article Logjam ne s'arrête pas à (à juste titre) dénigrer les implémentations SSL/TLS pour l'utilisation d'un module 512 bits pour DH; il consacre également un espace de discussion aux "adversaires au niveau de l'État". Cette partie dit surtout quelque chose qui était déjà connu, c'est-à-dire que casser un module de logarithme discret d'un module de 1024 bits (quelque chose qui permettrait de casser à la fois DH et DSA) est actuellement horriblement cher, mais pas impossible en ce qui concerne notre connaissance actuelle du problème et de la technologie disponible (similaire à la rupture du RSA-1024, et contrairement à la rupture d'un DH ou DSA à 2048 bits, qui sont au-delà de ce qui est possible avec les ressources terrestres actuelles ).

Pour les oreilles réceptives, tout cela sonnait comme "OMG, nous sommes tous piratés par le NSA!" Et la publicité autour du problème Logjam (qui est très réel) traîne dans son sillage une quantité importante d'hystérie au sujet des clés DSA 1024 bits, incluses lorsqu'elles sont utilisées en SSH.

Un point supplémentaire était que l'utilisation de DSA nécessite de générer, pour chaque signature , une nouvelle valeur aléatoire, et la qualité de la génération de cette valeur est d'une importance primordiale . Certaines implémentations ont échoué de manière spectaculaire, entraînant une fuite de clé privée (notamment pour certains "portefeuilles Bitcoin"). Cette caractéristique du DSA est partagée avec sa version ECDSA à courbe elliptique. Il peut être corrigé . Mais cela a inculqué l'idée que les signatures DSA peuvent être difficiles à faire correctement (et les signatures ECDSA également, mais les courbes elliptiques sont cool et personne ne veut les interdire).

Ces paramètres, pris ensemble, expliquent l'interdiction. Cela peut être considéré comme un cas où les développeurs d'OpenSSH sont proactifs dans leur notion de sécurité et sont prêts à forcer les utilisateurs à utiliser une cryptographie forte. Une autre façon de voir la même séquence de décisions est que les développeurs d'OpenSSH ont mal gâché à un moment donné en raison d'une mauvaise lecture de FIPS 186, puis ont cherché à le couvrir en équivalent de déversement en mer le cadavre du mari gênant.

Notez que briser votre clé DSA permettrait à l'attaquant de se faire passer pour vous, mais pas de décrypter les sessions enregistrées. Bien que l'on puisse dire que le passage à une clé ECDSA serait une bonne idée à un moment donné (cela économise un peu de bande passante et de CPU), il n'y a pas d'urgence cryptanalytique à le faire. Vous devrez toujours le faire, car sinon vous risquez d'être bloqué sur vos serveurs parce que certains emballeurs étaient trop zélés dans la politique de dépréciation.

98
Tom Leek

https://bugzilla.mindrot.org/show_bug.cgi?id=1647 a le raisonnement derrière la restriction des clés DSA à 1024 bits, mais fondamentalement:

  • La section 6.6 de la RFC4253 requiert le hachage SHA1 (160 bits) pour l'authentification ssh-dss (c'est-à-dire DSA).
  • FIPS 186-3 section 4.2 nécessite des clés DSA> 1024 bits pour utiliser un hachage plus fort que 160 bits.
  • la seule façon de respecter les deux est de n'autoriser que des clés de 1024 bits.
11
Darren Tucker