SHAttered : Google a cassé la fonction de hachage SHA-1

Écrire cet article est difficile : si vous avez compris de quoi il s’agit et de l’importance du sujet en lisant le titre, vous savez probablement déjà tout sur la question. Sinon, et personne ne vous en voudra, il est possible que cette affaire ne vous passionne pas le moins du monde. Alors nous allons essayer de la rendre intelligible — en demandant l’absolution a priori des experts si des raccourcis sont empruntés par souci d’intelligibilité.

Aujourd’hui, Google et le CWI ont annoncé dans un billet de blog avoir trouvé une technique pour casser la fonction de hachage SHA-1. Pour faire simple, il s’agit d’une manière d’attribuer une chaîne de caractères à un document pour l’authentifier. En principe, cette chaîne de caractères est censée être suffisamment longue et aléatoire pour qu’elle ne puisse pas être dédoublée : deux documents ne devraient pas pouvoir entrer en collision, c’est-à-dire avoir le même hash (signature).. La théorie repose sur le constat que la puissance d’un ordinateur (ou de plusieurs ordinateurs travaillant ensemble) n’est pas suffisante pour cloner la combinaison à l’aveuglette, en tentant une attaque dite « brute force » qui va chercher à provoquer une collision en tentant toutes les possibilités une à une.

La méthode n’a eu besoin que de 6 500 années CPU et 110 années GPU

Maintenant, en pratique, la technique évolue. Ce qui était impossible il y a quelques années se rapproche petit à petit du probable. Seulement du probable, car il faut aujourd’hui 12 millions de GPU (puces graphiques) travaillant pendant un an pour provoquer une collision de deux chaînes SHA-1. Google ne s’est évidemment pas amusé à une telle expérience irréalisable en pratique, mais a plutôt préféré la ruse. La méthode de Mountain View nommée Shattered, réduit le nombre de possibilités que les unités de calcul vont explorer. Pour imager la chose, c’est comme si vous aviez devant vous 1 000 chemins, qu’un seul menait quelque part et qu’au lieu de tous les tester un par un, vous admettiez que les chemins boueux ne mènent nulle part. Vous allez ainsi réduire les possibilités.

C’est à peu près comme cela que Google a procédé avec SHA-1. Leur méthode n’a eu besoin que de 6 500 années CPU (donc 6 500 CPU pendant un an) et 110 années GPU (donc 110 GPU pendant un an) pour trouver une collision entre deux chaînes SHA-1. Ce n’est pas une mince affaire puisqu’il a fallu faire 9 223 372 036 854 775 808 calculs, mais la preuve est là : avec du matériel qu’un état ou une grosse entreprise peut posséder sans problème, deux documents peuvent avoir la même authentification SHA-1.

Tout cela est bien beau, mais en pratique, qu’est-ce que cela signifie ? Eh bien que le SHA-1 n’est plus sûr et le sera de moins en moins. Si vous utilisez un protocole d’authentification en SHA-1, que ce soit pour sécuriser une connexion HTTPS ou authentifier un fichier, vous ne pouvez plus être sûrs à 100 % que les données que vous lisez sont les bonnes.

Google dévoilera sa méthode dans 90 jours, laissant ainsi l’industrie et les services sensibles se protéger. Car si la découverte est importante, rien n’est pourtant perdu. Mountain View conseille par exemple de basculer vers des fonctions SHA-3 ou SHA-256. Google assure également que tous ses services, de Gmail à G Suite sont déjà protégés contre l’attaque. L’entreprise a déployé un petit site pour tester des fichiers PDF, l’objet numérique qui a servi à prouver l’attaque, pour voir s’ils peuvent être victimes d’une collision. Enfin, à partir de la version 56 disponible depuis janvier 2017, Chrome ne dit plus qu’un site est sécurisé s’il chiffre ses transferts de données en SHA-1.

Merci à Cryptie_ et Mina_vidar pour les précisions sur la fonction SHA-1. Merci également à nos lecteurs pour cet article crowd-écrit. 

https://twitter.com/Mina_Vidar/status/834790312262377472

https://twitter.com/Cryptie_/status/834789545317113856