Pourquoi MD5 et SHA-1 sont-ils toujours utilisés pour les sommes de contrôle et les certificats s'ils sont appelés cassés?
Je venais de lire des informations sur SSL/TLS et selon ce site (qui est classé A par Qualys SSL Labs), MD5 est totalement cassé et SHA-1 est cryptographiquement faible depuis 2005. Et pourtant, j'ai remarqué que beaucoup de programmeurs et même Microsoft ne nous donnent que SHA-1/MD5 pour vérifier l'intégrité des fichiers ...
Pour autant que je sache, si je change un bit d'un fichier, leur MD5/SHA-1 changera alors pourquoi/comment ils sont cassés? Dans quelles situations puis-je encore faire confiance aux sommes de contrôle faites avec SHA-1/MD5? Qu'en est-il des certificats SSL qui utilisent toujours SHA-1 comme google.com?
Je suis intéressé par les applications de MD5 et SHA-1 pour les sommes de contrôle et pour la validation des certificats. Je ne demande pas de hachage de mot de passe, qui a été traité dans cette question .
SHA-1 et MD5 sont cassés dans le sens où ils sont vulnérables aux attaques par collision. Autrement dit, il est devenu (ou, pour SHA-1, deviendra bientôt) réaliste de trouver deux chaînes ayant le même hachage.
Comme expliqué ici , les attaques par collision n'affectent pas directement les mots de passe ou l'intégrité des fichiers car ceux-ci relèvent respectivement du préimage et du deuxième préimage.
Cependant, MD5 et SHA-1 sont encore moins coûteux en termes de calcul. Les mots de passe hachés avec ces algorithmes sont plus faciles à déchiffrer que les algorithmes plus puissants qui existent actuellement. Bien qu'il ne soit pas spécifiquement rompu, il est conseillé d'utiliser des algorithmes plus puissants.
Dans le cas des certificats, les signatures indiquent qu'un hachage d'un certificat particulier est valide pour un site Web particulier. Mais, si vous pouvez créer un deuxième certificat avec ce hachage, vous pouvez vous faire passer pour d'autres sites Web. Dans le cas de MD5, cela s'est déjà produit et les navigateurs supprimeront SHA-1 bientôt à titre préventif ( source ).
La vérification de l'intégrité des fichiers est souvent destinée à garantir qu'un fichier a été téléchargé correctement. Mais, s'il est utilisé pour vérifier que le fichier n'a pas été falsifié de manière malveillante, vous devriez envisager un algorithme plus résistant aux collisions (voir aussi: attaques avec préfixe choisi ).
Pour MD5, personne à la fois fiable et compétent ne l'utilise dans un contexte où la résistance aux collisions est importante. Pour SHA-1, il est progressivement supprimé; la rupture SHA-1 n'était pas pratique lorsqu'elle a été libérée, et c'est seulement maintenant qu'il devient important de penser à la supprimer progressivement là où la résistance aux collisions est nécessaire. En fait, il est en cours de suppression; par exemple, les certificats TLS à long terme avec SHA-1 ne fonctionnent plus dans Chrome, pour inciter les gens à passer à SHA-2. Cependant, il n'est pas encore pratiquement cassé, c'est donc acceptable pour l'instant.
La raison pour laquelle il n'a pas été abandonné pour tout immédiatement est que la sécurité implique des compromis. Vous ne laissez pas tomber une norme majeure et rendez tout incompatible avec une base d'installation géante au motif de quelque chose qui pourrait conduire à des attaques pratiques dans une décennie. La compatibilité est importante.
De plus, pour de nombreuses utilisations, MD5 et SHA-1 ne sont pas du tout fissurés. Ils ont tous deux des faiblesses contre la résistance aux collisions, ce qui signifie qu'un attaquant peut créer deux messages qui hachent la même chose. Ni l'un ni l'autre n'est brisé contre la résistance de pré-image (donné un hachage, trouver quelque chose qui fait ce hachage), ni contre la résistance de deuxième pré-image (donné un message, trouver un message différent avec le même hachage), ou (leurs fonctions de compression) comme pseudo-aléatoire les fonctions. Cela signifie que des constructions comme HMAC-MD5 peuvent toujours être sécurisées, car elles ne dépendent pas de la propriété de MD5 qui est cassée. Moins qu'idéal, bien sûr, mais voir "la compatibilité est importante si elle est toujours sécurisée" ci-dessus.
La vérification de l'intégrité des fichiers via des hachages est presque toujours inutile de toute façon; à moins que les hachages ne soient envoyés sur un canal plus sécurisé que le fichier, vous pouvez altérer les hachages aussi facilement qu'avec le fichier. Cependant, si les hachages sont envoyés de manière plus sécurisée que le fichier, MD5 et SHA-1 sont toujours capables de protéger l'intégrité du fichier. Étant donné que l'attaquant n'a pas aucun d'influence sur les fichiers légitimes (et qu'il doit y avoir zéro influence pour être vraiment sûr), la création d'un nouveau fichier avec le même hachage nécessite briser la deuxième résistance à la pré-image, ce que personne n'a fait pour MD5 ou SHA-1.
Notez la différence entre la vérification d'intégrité et les certificats. Les certificats sont émis par une autorité de certification à partir d'un CSR créé par l'utilisateur; l'attaquant peut avoir une énorme influence sur le contenu réel du certificat, donc une attaque par collision permet à un attaquant de créer un certificat légitime et un faux qui entrent en collision, font émettre le certificat légitime et utilisent la signature sur le faux. En revanche, dans l'intégrité du fichier, l'attaquant n'a normalement aucun contrôle sur le fichier légitime, il doit donc obtenir une collision avec un fichier donné, ce qui est beaucoup plus difficile (et qui, à notre connaissance, ne peut pas être fait avec MD5).
MD5 et SHA-1 sont rapide et peuvent être pris en charge par le matériel, contrairement aux hachages plus récents et plus sécurisés (bien que Bitcoin ait probablement changé cela avec son utilisation de SHA-2 en donnant lieu à des puces d'exploration de données qui calculent les collisions SHA-2 partielles).
collisions MD5 sont réalisables et des avancées d'attaque pré-image ont été faites; il y a est ne collision SHA-1 connue du public pour l'algorithme officiel complet, après d'autres attaques réduisant considérablement sa complexité effective , qui n'est peut-être pas encore assez pratique pour l'attaquant occasionnel mais dans le domaine des possibilités, c'est pourquoi il peut être appelé cassé.
Néanmoins, les hachages "faibles" ou cassés peuvent toujours être bons pour les utilisations qui n'ont pas besoin d'algorithmes sécurisés cryptographiquement, mais de nombreux objectifs qui n'étaient pas initialement considérés comme critique plus tard peut s'avérer exposer une surface d'attaque potentielle.
De bons exemples seraient de trouver des fichiers en double ou d'utiliser dans des systèmes de contrôle de version comme git - dans la plupart des cas, vous voulez de bonnes performances avec une grande fiabilité, mais n'avez pas besoin sécurité stricte - donner à quelqu'un un accès en écriture à un référentiel git officiel vous oblige déjà à faire confiance à d'autres personnes pour ne pas déconner, et les vérifications de duplication devraient en outre comparer le contenu après avoir constaté que deux fichiers ont la même taille et le même hachage.
Une sauvegarde insuffisante des hachages non sécurisés avec des faits (par exemple, une comparaison octet par octet) peut être un risque, par exemple quand quelqu'un comme Dropbox a eu la déduplication avec MD5 sans vérification appropriée et qu'un attaquant se faufile dans les données avec des hachages en collision pour provoquer une perte de données.
git résout ce problème en "faisant confiance à l'aîné" , comme l'a dit Linus lui-même:
si vous avez déjà un fichier A en git avec hachage X, y a-t-il une condition où un fichier distant avec hachage X (mais un contenu différent) écraserait la version locale?
Nan. S'il a le même SHA1, cela signifie que lorsque nous recevons l'objet de l'autre extrémité, nous allons pas écraser l'objet que nous avons déjà.
Donc, ce qui se passe, c'est que si jamais nous voyons une collision, l'objet "antérieur" dans un référentiel particulier finira toujours par remplacer. Mais notez que "plus tôt" est évidemment par référentiel, dans le sens où le réseau d'objets git génère un DAG qui n'est pas entièrement ordonné, donc si différents référentiels s'accorderont sur ce qui est "plus tôt" dans le cas de l'ascendance directe, si le l'objet est venu de branches distinctes et non directement liées, deux référentiels différents peuvent évidemment avoir obtenu les deux objets dans un ordre différent.
Cependant, le "plus tôt remplacera" est vraiment ce que vous voulez du point de vue de la sécurité: rappelez-vous que le modèle git est que vous ne devez principalement faire confiance qu'à votre propre référentiel. Donc, si vous faites un "git pull", les nouveaux objets entrants sont par définition moins fiables que les objets que vous avez déjà, et en tant que tel, il serait erroné de permettre à un nouvel objet de remplacer un ancien.
[Source d'origine: https://marc.info/?l=git&m=115678778717621&w=2]
Et comme on dit, une défaillance de disque est plus probable que de rencontrer une collision de hachage accidentelle (plusieurs ordres de grandeur - collision SHA-1 <10-40; erreur de bit non récupérable sur le disque ~ 10-15).
Bien que des collisions puissent exister, il est peu probable que la vérification de l'intégrité d'un fichier en présence d'un MD5 et d'un SHA1 permette une collision. donc si ces deux vérifications simples valident le même fichier, cela suffit. Je vois à peine les gens vérifier même un seul dans la plupart des cas de toute façon.