Rejoignez Keyfactor à la RSA Conference™ 2024 | du 6 au 9 mai | En savoir plus

SHA-1 est "brisé"

SHA-1 fait (à nouveau) la une de l'actualité. Nous savons tous que la fonction de hachage SHA-1 est cryptographiquement faible. En fait, cela fait des années que le CSS met en évidence les faiblesses de SHA-1.

Mais tout récemment, les chercheurs de Google ont publié une démonstration pratique d'un algorithme qui permet à quiconque de modifier le contenu d'un document, tout en conservant la valeur de hachage SHA-1 d'origine de ce document. Normalement, si un document est modifié de quelque manière que ce soit, la valeur de hachage calculée doit également changer. Cette fonctionnalité de base du hachage est à la base des affirmations cryptographiques sur l'intégrité des données.

Bien que la faiblesse de l'algorithme de hachage SHA-1 soit connue depuis des années, c'est la première fois qu'un processus permettant de subvertir SHA-1 est largement disponible.

SHA_1 hash.png

Cela ne veut pas dire que les efforts pour subvertir les hachages SHA-1 ne sont pas triviaux. Le calcul d'une collision de hachage à l'aide de la nouvelle méthode de Google nécessite 6 500 années de temps CPU et 110 années de temps GPU. C'est certainement beaucoup de temps et d'argent. Mais cela est tout à fait à la portée des États-nations ou des organisations criminelles qui exploitent les ressources de l'informatique en nuage.

Qu'est-ce que cela signifie ? 

Je pense qu'il est judicieux de mettre en perspective le nouvel algorithme de Google. En lisant les blogs techniques sur Internet, j'ai l'impression que SHA-1 doit être remplacé dès maintenant. Je ne peux vraiment pas contester ce point de vue. Ma seule suggestion est de prendre une pause et de comprendre ce que ce nouvel algorithme signifie en termes de risques accrus pour votre environnement. Ensuite, planifiez votre passage de SHA-1 en conséquence.

Le nouvel algorithme de collision de hachage de Google signifie que l'intégrité des données que vous protégez a considérablement diminué. De même que l'assurance globale de votre infrastructure à clé publique (PKI).

Cela signifie-t-il pour autant que vos certificats SHA-1 existants n'ont plus aucune valeur ? Probablement pas.

Le nouvel algorithme de collision de hachage de Google signifie que toute personne ayant accès à 6 500 ans de temps CPU et 110 ans de temps GPU peut désormais calculer une collision de hachage pour toute valeur de hachage calculée dans votre environnement. Ce n'est pas une bonne chose.

Et comme nous le savons tous, ces exigences informatiques ne peuvent que devenir moins chères et plus faciles à atteindre au fil du temps. En raison de l'économie informatique, cette vulnérabilité deviendra de plus en plus facile à exploiter. Les exemples de collisions de hachage SHA-1 seront de plus en plus fréquents. En définitive, ce risque ne fera qu'augmenter avec le temps.

Alors oui, il est temps de migrer.

Les cinq premières lignes d'action du CSA :

1. Examiner les niveaux d'assurance de la sécurité

L'assurance, dans ce cas, est la mesure de la confiance que l'on a, ou que l'on devrait pouvoir avoir, dans l'intégrité de ses données. Elle est généralement fonction des risques liés aux systèmes et des types de données que ces systèmes protègent.

Dans ce cas, si vous avez défini des niveaux d'assurance, vous devrez réévaluer vos définitions de l'assurance afin de maintenir des niveaux de sécurité appropriés pour les données protégées.

2. Mettre à jour les politiques de certification pertinentes

Il s'agit d'un document de référence que les autorités de certification utilisent comme base pour toute déclaration d'assurance. À la suite de tout ajustement de la définition de l'assurance, il sera nécessaire de mettre à jour toutes les politiques de certification appropriées pour s'assurer qu'elles sont conformes aux dernières exigences de SHA-2.

3. Mise à jour des énoncés des pratiques de certification de l'AC

Le complément de la "politique de certification" est la "déclaration des pratiques de certification". C'est ce document qui contient les détails relatifs au fonctionnement et à la configuration de l'autorité de certification.

Lorsque vous mettrez à jour votre PC pour y inclure des références appropriées à SHA-2, votre ou vos CPS devront être mis à jour en conséquence. Ce document est utilisé par les parties utilisatrices pour déterminer si l'AC est appropriée pour une application donnée.

4. Donner la priorité aux efforts migratoires

La migration vers SHA-2 peut être une entreprise de grande envergure, coûteuse et complexe. Mais elle ne doit pas se faire en une seule fois.

Je recommande de mettre en place une hiérarchie d'autorité de certification distincte et parallèle. Une hiérarchie qui utilise SHA-2. Toutes les parties qui se fient à l'autorité devraient faire confiance aux deux hiérarchies pendant la migration. Cette approche permet un rythme de migration délibéré et précis.

Créer une liste des applications PKI classées par ordre de priorité et de risque. Les applications qui présentent le plus de risques doivent être migrées en premier. Migrer les applications dans cet ordre.

Toute évaluation des applications PKI ne serait pas complète sans une liste des ressources que l'application protège. Signature de code ? Signature des courriels ? Signature de documents ?

Compte tenu des ressources nécessaires pour calculer une collision de hachage, vous pourriez commencer votre migration par les applications dont la valeur vaut la dépense qu'implique le calcul d'une collision de hachage.

5. Audit des systèmes non conformes

Lorsque la migration de votre site d'entreprise PKI est terminée, il se peut que vous n'ayez pas fini. Il est possible que des certificats SHA-1 soient encore utilisés dans votre environnement, qu'ils proviennent d'autorités de certification malhonnêtes, qu'ils soient auto-signés ou qu'ils proviennent de fournisseurs, etc.

Cela signifie que pour protéger vos actifs des risques liés à l'utilisation de SHA-1, vous devrez non seulement cesser d'émettre de nouveaux certificats SHA-1, mais aussi vous assurer que les certificats SHA-1 ne sont pas utilisés ou que ceux qui le sont encore ne présentent pas de risque.

Cela peut signifier une analyse continue des différents points de terminaison pour s'assurer qu'aucun certificat SHA-1 n'est utilisé.

En définitive, si votre politique de certification a été modifiée pour exclure SHA-1, il vous faudra, pour être en conformité avec cette politique, veiller de manière proactive à ce qu'aucun certificat ne soit utilisé en violation d'une politique de certification mise à jour.

Principaux enseignements

Oui, SHA-1 est officiellement cassé. Mais nous savions que cela allait arriver depuis des années, ce n'est donc pas une surprise pour quiconque travaille dans ce domaine. Mais cela signifie-t-il que toutes les valeurs de hachage sont désormais sans valeur ? Cela signifie qu'elles valent toutes beaucoup moins, et que vous jetez vraiment les dés avec toute confiance que vous pourriez placer dans vos hachages SHA-1 existants. En fin de compte, si un acteur malveillant se soucie suffisamment d'investir dans les ressources, vos valeurs de hachage peuvent maintenant être rendues sans valeur. Il est temps d'abandonner SHA-1.