SHA-1 (Secure Hash Algorithm) est une fonction de « hachage » cryptographique.

Il s’agit d’un algorithme qui associe à une donnée de taille quelconque, une image de taille fixe. En quelque sorte, une empreinte de la donnée d’entrée. Le calcul de cette empreinte est à sens unique : il est possible de calculer l’empreinte d’une donnée, mais pas de retrouver la donnée depuis l’empreinte. Cela signifie donc qu’il est impossible de revenir en arrière une fois la donnée hachée. De plus, une fonction de hachage doit assigner UNE empreinte unique : 2 données d’entrée ne peuvent pas avoir la même empreinte.

C’est ainsi qu’un message « haché » par SHA-1 change radicalement de signature, même avec une modification mineure. Par exemple le mot "TalanLabs" devient "499dfc6db8ca1f785724cd88ffef5f471e874156" une fois « haché ». En revanche, "Talanlabs" devient "25f51e7cbd92b575adf321cc3b149e76d48e2431".

SHA-1 a été conçue par la puissante NSA, autrement dit l’agence nationale de la sécurité des États-Unis, en remplacement de SHA-0 (sortie en 1993) qui était compromise.

Depuis sa sortie en 1995, de nombreux chercheurs ont tenté de compromettre SHA-1, a minima dans des démonstrations mathématiques. C’est ainsi que depuis 2005, nous savons qu’il est en théorie possible d’obtenir une même empreinte pour 2 données différentes en réalisant 263 calculs (soit plus de 9 milliards de milliards…​). Ce nombre astronomique d’opérations est encore à la limite des capacités des super-ordinateurs actuels. Il semblerait que seul un immense réseau distribué à l’échelle mondiale (à l’image du réseau Bitcoin) soit capable de délivrer suffisamment de puissance de calcul pour obtenir une « collision » (deux données d’entrée différentes avec la même empreinte).

À titre de comparaison, il faudrait environ 12 millions de GPU (puces graphiques) qui fonctionneraient pendant un an pour obtenir cette même « collision ».

Jusqu’alors, nous ne disposions que de données théoriques, et jamais de cas pratiques. C’est finalement fin février qu’une équipe composée de chercheurs de Google et du CWI (centre de recherche en mathématiques et informatiques néerlandais) a annoncé avoir trouvé une « collision » entre 2 fichiers PDF qui ont la même signature une fois « hachés » par SHA-1.

Même avec les moyens considérables de Google, il n’était pas questions d’aligner des millions de cartes graphiques pour réaliser une telle prouesse. En affinant les calculs théoriques, et en éliminant d’office certains calculs, l’équipe a eu besoin que de 6 500 années CPU (soit 6 500 processeurs pendant un an) ou 110 années GPU (soit 110 cartes graphiques pendant un an) pour obtenir deux documents PDF différents mais avec la même signature.

Concrètement, l’outil mis au point permet d’obtenir un faux document qui sera identifié comme un vrai document. Autrement dit de faire passer une donnée potentiellement biaisée comme purement véridique et approuvée par son émetteur.

Alors, quels sont les systèmes potentiellement rendus vulnérables ? Tous ceux qui utilisent SHA-1 comme algorithme de « hachage » pour certifier leurs données…​ Et ils sont nombreux ! SHA-1 est utilisé pour certifier une connexion HTTPS, signer numériquement des documents, authentifier les informations contenues dans un système de sauvegarde (cloud par exemple), mais aussi par un outil de gestion de versions comme Git.

Git, outil privilégié pour la gestion des versions du code source de millions de projets informatiques, utilise SHA-1 pour identifier de manière unique chaque « commit » (modification) de code. Autrement dit, lorsque vous récupérez le code source d’un projet, la version que vous téléchargez est identifiée par un « hash » unique certifiant le contenu. Or, si du code malveillant a été injecté par la suite, mais avec une signature de « commit » identique à la dernière en date, nul système ne pourra le détecter et vous vous exposez à des failles de sécurité.

Autrement dit, sans le savoir nous utilisons tous les jours des algorithmes de « hachage », et la sécurité de nos données et de nos entreprises est fortement liée à leur qualité. Une remise en cause totale de nos habitudes est-elle encore envisageable ? Revenir exclusivement aux signatures sur papier, aux messagers humains et à la sauvegarde centralisée ?

Heureusement, des alternatives sont possibles. Et la responsabilité en incombe en grande partie aux développeurs, mais aussi aux décisionnaires de toutes les entreprises liées au numérique.

SHA-1 n’est pas la seule fonction disponible. bcrypt (présentée en 1999), SHA-2 (conçue par elle aussi par la NSA en 2001) et plus récemment SHA-3 (issue d’une compétition en 2012) n’ont pas été compromises. Même si l’on peut imaginer qu’il ne s’agit là encore que d’une question de temps…​

Google et le CWI ne cherchant évidemment pas à compromettre massivement les réseaux mondiaux, ils ont émis une recommandation simple : utiliser SHA-2 ou SHA-3 partout. De plus, ils ont attendu 90 jours avant de rendre publique la méthode utilisée pour arriver à leurs fins, afin de laisser le temps à l’industrie de se mettre à jour. De leur côté, ils garantissent que leurs produits comme Gmail ou Google Drive sont d’ores et déjà protégés. Par ailleurs, leur navigateur Chrome ne considère plus les certificats HTTPS basés sur SHA-1 comme sécurisés.

Ils fournissent de surcroit un outil en ligne permettant de vérifier si un document fait partie d’une attaque par « collision » ainsi qu’une infographie de référence qui mériterait d’être affichée dans de nombreuses DSI.