SHA-1 : des chercheurs prouvent l’exploitation des collisions dans une attaque
Jumeau maléfique
Le 27 février 2017 à 10h15
4 min
Internet
Internet
Deux équipes ont travaillé à la réalisation d’une méthode capable de produire en un temps « raisonnable » des collisions avec l’algorithme SHA-1. Un danger qui n’est pas neuf, mais qui s’amplifie, avec dans l’ombre la perspective de pouvoir falsifier des documents et donc faciliter certaines attaques.
L’algorithme SHA-1 (Secure Hash Algorithm) permet le hachage des données (voir notre dossier) afin d'en assurer l'intégrité. Pour cela, il produit une empreinte de 160 bits, censément unique.
On retrouve souvent le SHA-1 par exemple sur différents sites de téléchargement, quand l’utilisateur est invité à contrôler qu’il a bien le bon fichier mais aussi dans de nombreux services et outil de chiffrement. Mais SHA-1 n’est plus tout à fait considéré comme sûr depuis des années, et les principaux navigateurs comptent l’abandonner dans les mois qui viennent.
Repérer et exploiter les collisions
Pour montrer à quel point le SHA-1 n’est plus digne de confiance, deux équipes se sont associées, l’une de l’institut CWI d’Amsterdam, l’autre de Google. Dans un billet publié il y a quelques jours, les chercheurs en sécurité ont annoncé avoir trouvé une méthode, SHAttered, leur permettant de découvrir des cas de collision 100 000 fois plus rapidement qu’avec une méthode classique par force brute.
La collision est la bête noire de ce type d’algorithme. Elle se produit quand deux fichiers différents génèrent le même hash. Ce qui signifie que l’un des deux fichiers pourrait être malveillant et se faire passer pour la version authentique.
Sur le site ouvert pour l’occasion, les chercheurs évoquent les dangers inhérents à la collision. Ils présentent également deux fichiers PDF au contenu différent mais disposant de la même empreinte SHA-1. Or, on peut imaginer que le premier soit un contrat signé par un client, tandis que d’autre sera une version altérée, portant lui aussi la signature.
Faciliter les collisions revient donc à augmenter le risque que des données se fassent passer pour ce qu’elles ne sont pas. Signatures de documents, certificats électroniques, contrôle de versions, systèmes de sauvegarde, mises à jour de logiciels, correctifs de sécurité et autres sommes de contrôles pour les images ISO sont concernés.
Un défaut connu depuis 12 ans
Comme indiqué cependant, le défaut de sécurité dans SHA-1 n’est pas une nouveauté. L’expert en sécurité et cryptanalyse Bruce Schneier consacrait ainsi déjà en 2005 un article sur les collisions dans l’algorithme. Il avait été capable d’en trouver en 2^69 calculs, ce qui représentait déjà il y a 12 ans une méthode 2 000 fois plus rapide que la force brute.
Ce qui explique d’ailleurs en partie pourquoi Microsoft et Mozilla (entre autres) préparent actuellement l’abandon de SHA-1, d'ici la fin de l’année. Google l’a supprimé le mois dernier lors d’une mise à jour de Chrome. L’éditeur attendra d’ailleurs 90 jours avant de révéler le code d’exploitation et la méthode détaillée, en accord avec la politique de sa Zero Day Initiative. Les chercheurs se veulent cependant rassurants : ils n’ont observé aucune attaque par ce biais pour l’instant.
Un outil simple pour vérifier les documents
Le site des chercheurs fournit en outre une méthode simple pour vérifier si un document quelconque pourrait être impliqué dans une attaque par collision. Cette protection a été déployée par Google dans Gmail et sa Gsuite afin de signaler à la volée un éventuel problème. Le code de détection a été écrit par Marc Stevens (CWI) et Dan Shumow (Microsoft), et est disponible dans un dépôt GitHub.
Côté utilisateur, il n’y a pas grand-chose à faire, à part s’assurer que la dernière révision du navigateur est installée. Côté développeur par contre, il faudra basculer vers des algorithmes beaucoup plus récents, comme SHA-256 ou SHA-3. Notez cependant que dans le cas de Git, Linus Torvalds a indiqué durant le week-end que plusieurs protections avaient déjà été mises en place pour empêcher ce type d'attaque de fonctionner.
SHA-1 : des chercheurs prouvent l’exploitation des collisions dans une attaque
-
Repérer et exploiter les collisions
-
Un défaut connu depuis 12 ans
-
Un outil simple pour vérifier les documents
Commentaires (56)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 27/02/2017 à 10h49
“on peut imaginer que le premier soit un contrat signé par un client, tandis que d’autre sera une version altérée, portant lui aussi la signature.”
Pour que ce soit exploitable ainsi, encore faudrait-il qu’a partir d’un fichier donné on soit capable de générer son “jumeau de signature” avec le contenu qu’on désire. J’en doute un peu.
Le 27/02/2017 à 10h50
SHA256 avait pour cahier des charges d’optimiser les calculs, et se révèle en pratique équivalent (en charge de calcul) que SHA1.
Le problème de quitter SHA1 est plus complexe, notamment à cause des autorités de certification au-dessus qui ne savent pas faire, ou qui demandent à être changées (ou ajoutées). Pas simple dans un contexte professionnel.
Après, il n’est pas interdit d’utiliser SHA1 : dans certains cas il est largement suffisant. Il faut toujours évaluer le risque résiduel, en sécurité informatique…
Le 27/02/2017 à 11h00
Qui dit HASH, dit collisions, il n’y a pas de magie, seul l’infini permet d’éviter les collisions, mais on ne voudrait pas d’une clef infiniment grande…
Pour le moment, ils n’ont pas diffusé grand chose comme infos, il y a deux points où je serais curieux d’avoir l’explication :
1/ Comment ils ont réduit la complexité (je sens que je vais mourir suite à ce cours de maths)
2/ Comment ils détectent les mauvais clones dans leur outil (mais là j’imagine que pour faire le mauvais clone, on ajoute un truc dans le fichier qui pourrait apparaître bizarre car inutile dans son format)
Le 27/02/2017 à 11h00
Quoi? Tu veux dire qu’en 160 bit on ne peut pas recréer l’intégralité de tout ce qui existe? Dommage, on avait là l’archivage ultime :)
Le 27/02/2017 à 11h02
J’ai vu des poc justement où ils changent ce qu’ils veulent et par la suite ils rajoutent des bits invisible sur le rendu pour avoir une collision.
Le 27/02/2017 à 11h04
Le 27/02/2017 à 11h11
Le 27/02/2017 à 11h13
Le 27/02/2017 à 11h19
Oui, mais comme dit Linus, certains types de fichiers se prêtent «mieux» à l’ajout de ces données junk que d’autres. Ce n’est pas un hasard si les chercheurs parlent de documents pdf.
Le 27/02/2017 à 11h45
Sur le problème de collision sur sha1:
* on pense à Git mais c’est svn qui a eu le plus gros problème (ça pète le dépôt. cf dépôt webkit)
* pour git, il stocke la longueur donc ce qui complexifie grandement l’attaque (c’est pourquoi Linux dit qu’il y a pas le feu au lac)
* dans Git, le sha1 ne sert pas à authentifier un commit donc il fallait déjà signer les commits si on voulait être sur des données
* je ne connais pas le successeur de sha1 mais un bon prétendant est peut-être à voir du côté dehttps://blake2.net/
Le 27/02/2017 à 12h06
Le 27/02/2017 à 12h11
Le 27/02/2017 à 12h32
Merci pour le lien à propos de la réponse de Linus sur GIT.
Je cherchais des infos la semaine dernière…
Le 27/02/2017 à 12h49
Une fonction de hash n’est pas réversible. Donc ton archivage ultime n’était en fait pas du tout un système d’archivage.
Le 27/02/2017 à 12h50
Le 27/02/2017 à 12h54
Le 27/02/2017 à 10h40
Il est plus que temps de migrer vers md4, voire md5 si vous êtes vraiment parano " />
Le 27/02/2017 à 10h43
Le 27/02/2017 à 10h44
Google l’a supprimé le mois dernier lors d’une mise à jour de Chrome.
Firefox aussi lance la mise à jour.
Notez cependant que dans le cas de Git, Linus Torvalds a indiqué durant le week-end que plusieurs protections avaient déjà été mises en place pour empêcher ce type d’attaque de fonctionner.
C’est-à-dire ? Je n’ai pas vu de mise à jour de git sur mon poste ce week-end.
Le 27/02/2017 à 10h46
C’est impressionnant cette obsolescence des hachages.
Par contre SHA256 commence aussi a montrer ses faiblesses.
Pourquoi toujours tarder? Economiser un peu de charge CPU face a la sécurité a rarement été un paris gagnant jusqu’à présent …
Le 27/02/2017 à 10h48
L’algorithme SHA-1 (Secure Hash Algorithm) permet le hachage des données (voir notre dossier) afin d’en assurer l’intégrité. Pour cela, il produit une empreinte de 160 bits, censément unique.
Non, par définition l’empreinte n’est pas unique. Il est juste censément impossible “dans un temps raisonnable” de déterminer un jeu de données différent ayant la même empreinte.
Le 27/02/2017 à 10h48
Tu as un graphe d’évolution ici, ça permet de mieux visualiser : http://valerieaurora.org/hash.html
Le 27/02/2017 à 14h39
Ça peu sembler une bonne idée mais je ferais toujours la même réponse : ne pas essayer d’inventer son protocole crypto. Je suis rouillé en md5 (et en sha-1) mais tu as potentiellement des comportements similaires entre les deux algos qui font qu’une attaque par image inverse ne serait pas beaucoup plus compliqué sur le duo. Si la solution était si simple, sha-2 serait la concaténation d’un md5 et d’un sha1 (en général, c’est pas grave si le hashé est légèrement plus grand).
J’aime beaucoup le lien qui a été donné précédemment : http://valerieaurora.org/hash.html.
Donc, comme disais le poète : “Écoutez, laissez la police faire son travail, dès que j’aurai de plus amples informations croyez bien que vous en serez les premiers informés.“Ou encore mieux, faîtes des études en cryptographie ou en sécurité informatique et faites évaluer votre proposition (accompagné de sa preuve) par la communauté scientifique.
Après, ajouter des couches ou des vérifications de cohérence des données réduit le risque (et c’est probablement ce qui fait dire à Linus qu’il n’y a pas le feu au lac). Mais, malgré tout, la conclusion est qu’il est urgent d’envisager à penser à commencer un abandon de sha-1 (et de md5 pour ceux qui n’aurais pas déjà franchi le pas).
Le 27/02/2017 à 14h48
Attention, CRC32 est une fonction de hashage utilisé comme code correcteur d’erreur. Ce n’est pas un hashage cryptographique (résistant aux attaques par image inverse) cf. wikipedia. C’est à dire que tu peux modifier le fichier source intentionnellement et sans trop de difficulté en conservant la même signature (ce que l’on reproche à sha-1 maintenant). L’utilisation de md5 pour les téléchargement c’est un petit détournement du principe initial de l’algo qui se voulais être un hash crypto à l’origine. Md5 garde l’avantage d’être dispo dans tous les langages et d’avoir pleins d’outils qui l’utilisent mais grosso modo, tu pourrais donner un modulo des bites du fichier, tu aurais presque la même garanti de non modification (semi-)aléatoire.
Le 27/02/2017 à 14h57
Le 27/02/2017 à 15h33
Le 27/02/2017 à 15h38
Ok avec le fond, mais sinon oh, la fin des vacances ça vous a mis de mauvais poil ?! fallait pas en prendre alors.
Le 27/02/2017 à 15h53
Quelles vacances ?
Le 27/02/2017 à 16h10
vacances scolaires de février, période de ski ect.
Le 27/02/2017 à 16h15
Et c’était obligatoire d’être en vacances à ce moment ?
Tout le monde n’est pas en âge scolaire enseignant ou skieur sur NXI.
Edit : ah, j’oubliais : on écrit “etc.” abréviation de “et caetera” (et les autres choses)
Le 27/02/2017 à 16h29
Aucun rapport avec le fait d’être enseignant… Juste rapport avec le fait d’avoir des enfants. Bref.
Le 27/02/2017 à 16h59
Non non… c’était pas dit méchamment … :o) Des fois, j’oublie que je dois ajouter plus de smiley pour être bien compris par écrit. Je voulais juste donner un avis à sur le problème posé :o).
Sinon je suis d’accord avec Fred … c’est bien pour la détection d’erreur. Je voulais juste dire que CRC est un algo qui vient plutôt du domaine de la correction d’erreur (au sens large)/théorie de l’information plus que du domaine de la sécu info. " />
Enfin pour les vacs … Ben, dans certains métier, tu travailles mieux quand les étudiants sont pas là (genre enseignant-chercheur) ;o)
Le 27/02/2017 à 18h17
Il y a des spécialistes en crypto sur NextInpact qui n’en sont pas vraiment… alors dans le doute que ces gens créent des sites qui hébergent mes données, je préfère le préciser. " />
Le 27/02/2017 à 19h12
Personne ne l’a encore posté ?
Bon, le commitstrip du jour : http://www.commitstrip.com/fr/2017/02/27/17279/
Le 28/02/2017 à 09h10
Le 28/02/2017 à 09h14
Le 28/02/2017 à 09h26
Le 28/02/2017 à 10h45
Le 28/02/2017 à 11h59
“Pour cela, il produit une empreinte de 160 bits, censément unique.“Non ce n’est pas tout à fait ça la promesse de SHA-1.La promesse est : qu’il est en pratique (avec la puissance de calcul disponible) impossible de trouver deux messages différents qui ont la même empreinte, même si on sais qu’en théorie ça existe.
Le 28/02/2017 à 13h07
<3
Le 27/02/2017 à 12h56
Idée à la con (ou pas ?) : et pourquoi ne pas utiliser deux hash en meme temps, même s’ils sont réputés “risqués” ?
Quelle est la probabilité / difficulté pour avoir une collision réussie à la fois sur le SHA-1 et le MD5 d’un fichier ?
Le 27/02/2017 à 12h57
Il n’y a pas que les navigateurs qui vont avoir des soucis mais aussi les VCS, voir l’article ici :https://www.developpez.com/actu/119516/Un-developpeur-teste-dans-Webkit-les-deux…
Le 27/02/2017 à 12h58
Je crois que c’est justement ce qu’il soulignait, de manière humoristique :p
Le 27/02/2017 à 13h04
je dirai faible. nulle si tu contrains en plus la taille
Le 27/02/2017 à 13h04
J’ai déjà vu des gens couper un mdp en deux et hasher avec deux algos différents chaque partie. Le principe reste le même donc je ne pense pas qu’il y ait quelque chose qui l’interdise. Après pour un serveur web, selon son traffic, peut-être que ça peut plomber ses perfs, je vois que ça.
Le 27/02/2017 à 13h42
Blizzard utilisaient des collisions d’empreinte pour que chaque joueurs ait la même carte dans une langue différent sur Warcraft III, réutilisé plus tard pour les versions traduites de la carte DoTa.
Le 27/02/2017 à 13h46
Non mais non mais non …. Couper un mot de passe en deux pour utiliser 2 fonctions de hash !!! Quelle horreur.
Couper un mot de passe en deux … si j’ai un mot de passe de 8 caractères (ce qui est malheureusement considéré comme long pour beaucoup de gens) ça fait 2 hashs sur des mots de passes de 4 caractères …. donc je te trouve une image inverse (et tu peux choisir l’algo de hash que tu veux) par force brute en moins de 2x10 minutes … sur mon smartphone … en jouant à un jeu 3D en même temps dessus … avec un code écrit en brainfuck (bon ok, peut-être pas en brainfuck) !
La force des solutions crypto c’est quelles sont éprouvées par toute une communauté de chercheurs/scientifiques/ingénieurs/industriels. Et c’est pour ça que l’on change régulièrement d’algorithme de référence : on découvre de nouvelles faiblesses sur des algos “réputés” fiables.
Le 27/02/2017 à 13h48
Pour ça que certains sites donnent le md5 et le sha-1 en même temps je présume ? (et l’empreinte sha-256)
Le 27/02/2017 à 13h51
Merci
Le 27/02/2017 à 13h53
ah je connaissais Ook! mais pas son origine.
C’est toujours beau de voir des gens se dépasser de la sorte " />
Le 27/02/2017 à 13h54
au temps pour moi, je n’avais pas compris
Le 27/02/2017 à 13h59
Juste pour préciser, je ne parlais pas de faire un SHA-1 sur le MD5, mais de calculer en parallèle le MD5 et le SHA-1 d’un fichier, et de les comparer séparément.
Mais j’adore la réponse de tijojo :)
Le 27/02/2017 à 14h01
oui, oui, je saisis mieux l’idée, mais du coup tu perds un peu l’intérêt du hash, d’en avoir deux " />
Le 27/02/2017 à 14h02
Hash(“Question universelle”) = 42
Le 27/02/2017 à 14h24
Md5 est fortement utilisé pour vérifier qu’un téléchargement c’est bien passé. Si tu veux de la sécu, de la vrai : CRC32 ça roxx ! 😂
Le 27/02/2017 à 14h28
s/Hash/Réponse/
" />