Quelles sont les implications d'une collision SHA-1 trouvée?
Google a annoncé la découverte d'une collision SHA-1 entre deux fichiers PDF au contenu distinct.
Bien que les hachages SHA-1 ne soient plus autorisés pour les empreintes digitales des certificats SSL/TLS et que d'autres mesures empêchent les empreintes digitales des certificats d'être manipulées de cette manière, quelles autres utilisations de SHA-1 seraient affectées?
Les auteurs d'attaques mentionnent les hachages GIT comme une possibilité, mais existe-t-il d'autres utilisations courantes qui n'ont pas d'atténuation autre que la mise à niveau vers une autre famille de hachage ou une méthode ultérieure SHA?
Pour les réponses concernant comment cette collision a été trouvée, voir cette autre question sur Crypto.se
Actuellement, compte tenu de la méthode de collision spécifique utilisée, l'impact est assez limité. En particulier, cette méthode ne permet pas à un attaquant de générer une collision avec un fichier existant, où un hachage SHA-1 a été fourni. Il ne serait pas possible, par exemple, d'utiliser cette méthode pour générer un fichier exécutable malveillant correspondant à la signature fournie sur le site Web de distribution légitime.
Il serait possible, en théorie, pour un attaquant de générer deux fichiers exécutables qui ont le même hachage SHA-1, mais effectuent des choses différentes lors de l'exécution. De même, il serait possible de générer plusieurs images ISO qui ont le même hachage SHA-1. Cependant, dans chaque cas, les autres valeurs de hachage ne correspondraient pas, et il est courant que les sites de téléchargement fournissent plusieurs types de hachage (par exemple, Ubuntu fournit des hachages MD5, SHA-1 et SHA256 pour tous les téléchargements). Cela peut être vu avec les fichiers shattered-1.pdf et shattered-2.pdf:
# sha1sum shattered-1.pdf
38762cf7f55934b34d179ae6a4c80cadccbb7f0a shattered-1.pdf
# md5sum shattered-1.pdf
ee4aa52b139d925f8d8884402b0a750c shattered-1.pdf
# sha1sum shattered-2.pdf
38762cf7f55934b34d179ae6a4c80cadccbb7f0a shattered-2.pdf
# md5sum shattered-2.pdf
5bd9d8cabc46041579a311230539b8d1 shattered-2.pdf
Il peut être possible de créer une sorte de fichier polyglotte qui produit les mêmes valeurs de hachage dans SHA-1 et MD5, mais cela n'a pas été démontré et échouerait toujours, étant donné, par exemple, un hachage SHA-512.
De même, pour tout système où un hachage SHA-1 est utilisé comme identifiant de fichier, il peut être possible d'obtenir la moitié d'une paire de fichiers en collision dans le système, puis de l'échanger contre l'autre. Un exemple de ceci serait un système de sauvegarde qui utilisait SHA-1 au niveau d'un fichier pour déterminer si les fichiers avaient été copiés correctement. Cependant, il serait difficile de faire en sorte que le hachage de tout le contenu de la sauvegarde reste le même dans ce cas, car le fichier malveillant est peu susceptible de former le préfixe de l'ensemble du fichier de sauvegarde (il est plus probable qu'il s'agisse de quelque chose identifiant l'ensemble du fichier comme sauvegarde).
Dans l'ensemble, par conséquent, l'annonce de Google ne fait que confirmer ce qui avait été suspecté pendant un certain temps - SHA-1 est vulnérable aux collisions, tout comme MD5, mais les trouver nécessite beaucoup d'efforts et la plupart des cibles très importantes (telles que comme générant des certificats CA) ont des mesures d'atténuation en place des collisions MD5 très similaires trouvées précédemment. Les experts conseillent de quitter SHA-1 depuis un certain temps maintenant, et cet avis est toujours valable.
Cependant, tout comme avec MD5, cela n'affecte pas particulièrement l'utilisation de HMAC-SHA1, car la méthode de combinaison spécifique utilisée dans la construction des valeurs HMAC rend ce type de collision non pertinent.