La présentation intitulé "SHA-1 collisions: Partial meaningful at no extra cost ?" a été produite par Christian Rechberger à la Rump Session de Crypto 2006. Il donne en exemple deux fichiers dont le contenu utile diffère de deux octets, suivi d'un bloc qui permettra finalement d'obtenir le même hash pour les deux fichiers. On pense évidemment rapidement au format HTML, où l'ajout de données après le tag </html> n'influe pas sur le rendu du document, mais également à de très nombreux formats auquel on peut ajouter du code soit en dehors des marqueurs de début et de fin, soit sous forme de commentaire, comme les archives ZIP, les images JPEG, les documents PDF, Word, OOo, etc. Bref, pratiquement tout ce qu'on pourrait un jour vouloir signer. Et s'il ne s'agit pour l'instant que d'une poignée de slides préssenté en vitesse, un article plus conséquent devrait être disponible sous peu et probablement détailler ces résultats.

Les conséquences de tout ça ? La potentielle remise en cause de SHA-1 en tant que preuve d'intégrité et dans la foulée les systèmes de signature numérique qui l'utilisent comme expliqué dans un article de Reinhard Wobst et Jürgen Schmidt. Pour ceux de mes lecteurs qui ne seraient pas familiers des protocoles de signature numérique, il faut juste savoir qu'ils reposent en pratique sur le calcul d'un hash cryptographique et qu'ils utilisent SHA-1 à cet effet. Une signature consiste généralement en un hash que l'auteur chiffre à l'aide d'une clé privée qu'il possède. Ainsi, tout lecteur du document signé peut dans un premier temps déchiffrer la signature à l'aide de la clé publique correspondante[1] puis, dans un second temps, calculer le hash du document et le comparer avec celui obtenu par déchiffrement de la signature. Si les deux valeurs sont les mêmes, on en déduit la vérification de l'intégrité du message d'une part et l'authentification de l'auteur[2] d'autre part. Si un attaquant se révélait alors capable de produire un document produisant le même hash que celui d'origine, il pourrait lui accoler la même signature et le faire passer pour un document authentique, voir remplacer le document original par un faux. Scary, isn't it ?

Cependant, si encore une fois l'urgence de trouver un remplaçant à SHA-1 est démontrée, tous les systèmes qui l'utilisent ne sont pas à jeter à la benne immédiatement. D'abord parce que dans cet article, on ne génère pas une véritable pré-image[3], mais plus une collision choisie dans la mesure où les deux documents doivent inclure un bloc de données ajouté à cet effet, ce qui implique en pratique la modification du document original et donc la regénération de la signature, action nécessitant la connaissance de la clé privée de l'auteur. Ensuite, la puissance de calcul demandée reste importante et hors de portée de l'attaquant lambda. Enfin, les systèmes comme SSH ou IPSEC qui utilisent des sommes d'intégrité soit chiffrée, soit générée par ajout d'un secret partagé (HMAC), ne sont pas impactés par cette découverte.

Il est juste urgent de penser à une transition rapide vers quelque chose de plus solide. L'idée qui vient immédiatement en tête est d'opter pour des versions plus solides de SHA produisant des hashes plus longs et donc réputés plus sûrs comme SHA-256 ou SHA-512 comme recommandé par le NIST. Mais cela ne fait en définitive que repousser le problème, dans la mesure où les fondements de l'algorithme sont remis en cause. Le challenge des années qui viennent consiste donc à trouver un nouvel algorithme comme remplaçant, comme Whirlpool par exemple.

Notes

[1] Lors de la génération d'une paire de clés, les deux clés obtenues sont parfaitement semblables en terme de propriétés. Le choix de la clé publique et de la clé privée est parfaitement arbitraire, ce qui implique que tout ce qui sera chiffré par l'une sera déchiffrable avec l'autre et inversement.

[2] Étant le seul à posséder sa clé privée, il est le seul à pouvoir chiffrer correctement le hash.

[3] Un document ayant un hash déterminé.