La complexité des attaques contre SHA-1. Le prix est basé sur le calcul du prix de location d'une GTX 1060 à 35 $ / mois.Beaucoup plus tard que tous les autres, mais les développeurs des bibliothèques pour SSH ont décidé de désactiver enfin la fonction de cryptage SHA-1 obsolète par défaut. Aujourd'hui, la sélection de la clé d'authentification du serveur SHA-1, c'est-à-dire un conflit avec le préfixe sélectionné, sur un cluster GPU loué coûtera 45 000 $ , comme indiqué dans le tableau ci-dessus. Cela rend l'attaque accessible non seulement aux services de renseignement de l'État, mais également aux clients commerciaux.La désactivation de SHA-1 par défaut a été annoncée simultanément par les développeurs des bibliothèques OpenSSH openSSH ( notes de version ) et libssh ( changement de code ).L'algorithme de hachage sécurisé (SHA) a été développé par la NSA en collaboration avec le NIST. La première version de SHA-0 a été introduite en 1993, mais la NSA a rapidement rappelé cette version, citant une erreur qu'elle a découverte et qui n'a jamais été divulguée.Une version fixe de la NSA a été publiée en 1995, elle s'appelait SHA-1.La fonction de hachage cryptographique SHA-1 (Secure Hash Algorithm 1) génère une chaîne de 160 bits appelée condensé de hachage. Théoriquement, les résumés doivent être uniques pour chaque fichier, message ou autre entrée de la fonction. En tant que valeur d'entrée, SHA-1 accepte un message pas plus debit, soit environ 2 exaoctets.Il est clair que la plage de valeurs de résumé est plus petite que la plage de valeurs d'entrée. Mais dans la pratique, les collisions de condensé ne devraient pas être possibles, étant donné les capacités de performance des ressources informatiques existantes. Malheureusement, SHA-1 ne répond plus à ce critère.En 2017, les employés de Google et du Center for Mathematics and Computer Science d'Amsterdam ont présenté la première façon de générer des collisions pour SHA-1 .Ils ont publié une preuve: deux documents PDF avec des contenus différents mais les mêmes signatures numériques SHA-1. $ls -l sha*.pdf
-rw-r--r--@ 1 amichal staff 422435 Feb 23 10:01 shattered-1.pdf
-rw-r--r--@ 1 amichal staff 422435 Feb 23 10:14 shattered-2.pdf
$shasum -a 1 sha*.pdf
38762cf7f55934b34d179ae6a4c80cadccbb7f0a shattered-1.pdf
38762cf7f55934b34d179ae6a4c80cadccbb7f0a shattered-2.pdf
Sur le site Web shattered.it , vous pouvez vérifier n'importe quel fichier pour savoir s'il est inclus dans l'espace des collisions possibles. Autrement dit, est-il possible de récupérer un autre ensemble de données (fichier) avec le même hachage. Le vecteur d'attaque est clair: un attaquant peut remplacer un «bon» fichier par sa copie par un signet, une macro malveillante ou un téléchargeur de chevaux de Troie. Et ce «mauvais» fichier aura le même hachage ou la même signature numérique.Ces dernières années, de nombreux programmes et services ont cessé d'utiliser SHA-1 après que les chercheurs ont montré des moyens pratiques de contrefaire les signatures numériques à l'aide de SHA-1. L'opinion unanime des experts est que cet algorithme n'est désormais plus sûr dans presque tous les contextes de sécurité.Google exprime depuis longtemps sa méfiance à l'égard de SHA-1, d'autant plus qu'il utilise cette fonctionnalité pour signer des certificats TLS. En 2014, l'équipe de développement de Chrome a annoncé la suppression progressive de SHA-1.En 2017, les chercheurs ont utilisé l'infrastructure de Google pour effectuer des calculs et vérifier les calculs théoriques de la durée de la recherche de collision. Les développeurs affirment qu'il s'agit de l'un des plus gros calculs jamais réalisés par Google. Au total, neuf quintillions de calculs SHA-1 ont été effectués (9 223 372 036 854 775 808), ce qui a nécessité 6 500 années de processeur dans la première phase et 110 ans de processeur graphique dans la deuxième phase de l'attaque.Blocs de messages avec le même hachage SHA-1
En 2019, les chercheurs Gaetan Laurent et Thomas Peyrin ont démontré une attaque contre la recherche d'un conflit avec un préfixe choisi, ce qui est pratique pour sélectionner des clés de chiffrement PGP / GnuPG spécifiques. Enfin, en janvier 2020, les auteurs ont réussi à optimiser l'attaque d'un ordre de grandeur et à réduire son coût théorique à un prix commercialement acceptable (voir tableau ci-dessus et pdf ). Pour démontrer, ils ont créé une paire de clés PGP / GnuPG différentes avec les mêmes certificats SHA-1.Pour se défendre contre une attaque visant à trouver des collisions SHA-1, il est recommandé de passer à de meilleures fonctions de hachage cryptographique SHA-256 et SHA-3.Les développeurs d'OpenSSH, qui ont écrit dans les notes de la dernière version, citent cette étude de janvier 2020: «Maintenant, vous pouvez effectuer des attaques avec le préfixe sélectionné en utilisant l'algorithme SHA-1 pour moins de 50 000 dollars américains. Pour cette raison, dans un proche avenir, nous désactiverons l'algorithme de signature de clé publique ssh-rsa par défaut. Malheureusement, cet algorithme est encore largement utilisé. Malgré l'existence de meilleures alternatives, il est resté longtemps le seul algorithme de signature à clé publique défini par le RFC SSH d'origine. »Parmi les meilleures alternatives, les développeurs OpenSSH ont appelé les algorithmes RFC8332 RSA SHA-2 (pris en charge par OpenSSH 7.2 et déjà utilisés par défaut si le serveur et le client le prennent en charge), ssh-ed25519 (pris en charge à partir de 6.5) et RFC5656 ECDSA (à partir de la version 5.7) .Pour vérifier que le serveur utilise l'algorithme SHA-1 faible lors de la génération de la clé publique pour l'authentification, essayez de vous y connecter après avoir supprimé l'algorithme ssh-rsa de la liste des permis dans ssh (1) :ssh -oHostKeyAlgorithms=-ssh-rsa user@host
Si la vérification échoue et que d'autres types de clés ne sont pas disponibles, le logiciel serveur doit être mis à jour.Dans les futures versions d'OpenSSH, l'option UpdateHostKeys sera activée par défaut, dans laquelle le client basculera automatiquement vers les meilleurs algorithmes. Il peut être activé manuellement.Apparemment, l'arrêt complet de SHA-1 prendra beaucoup de temps. Gaetan Laurent de l'Institut national de recherche en informatique et automatisation (France), l'un des co-auteurs de l'étude de janvier, ne s'attend pas à ce que les développeurs d'OpenSSH le fassent rapidement: «Quand ils désactiveront complètement SHA-1, il sera impossible de se connecter de la nouvelle version d'OpenSSH à l'appareil avec l'ancien Serveur SSH, - écritil. - Probablement, avant cela, ils prendront une série d'étapes progressives (avec de forts avertissements). D'un autre côté, dans les systèmes embarqués avec SSH qui n'ont pas été mis à jour depuis de nombreuses années, il y a probablement beaucoup de problèmes de sécurité, donc ce n'est peut-être pas trop grave de perturber leur travail ... exactement ce que nous voulions réaliser :-) ”.Après qu'OpenSSH et libssh ont annoncé leur intention de désactiver SHA-1, la liste des utilisateurs de SHA-1 est devenue plus courte, mais n'a pas disparu. Cette fonctionnalité est toujours prise en charge dans les dernières versions de la bibliothèque OpenSSL, que de nombreux sites Web et services Internet utilisent pour implémenter HTTPS et d'autres protocoles de chiffrement. La dernière version du compilateur GNU Collection, publiée plus tôt ce mois-ci, est signée numériquement avec le hachage SHA-1.Linus Torvaldsm'a ditque dans les référentiels Git, les collisions de hachage ne posent pas de risque pour la sécurité. Il a expliqué qu'il existe une grande différence entre l'utilisation d'un hachage cryptographique pour les signatures numériques dans les systèmes de cryptage et pour générer une «identification de contenu» dans un système comme Git. Lorsque toutes les données sont dans le domaine public, une véritable attaque est presque impossible. Les auteurs des travaux scientifiques donnent un exemple d'attaque contre des documents avec le même préfixe. Cette attaque est réussie car le préfixe lui-même est «fermé» à l'intérieur du document, comme un blob. Si nous avons l'open source dans le référentiel, alors c'est une question complètement différente. Il est à peine possible de faire un tel préfixe à partir du code source (uniquement à partir de blob). En d'autres termes, pour créer un préfixe identique puis générer des branches de code avec les mêmes hachages SHA-1, vous devrez injecter des données aléatoires dans le code, ce qui sera immédiatement remarqué. Linus ditqu'il y a des endroits où vous pouvez cacher les données, maisgit fsckattrape déjà de telles astuces. Cependant, Linus a l'intention de ne plus utiliser SHA-1 pour que personne ne doive même convertir ses référentiels.