Un fichier peut-il être modifié de manière malveillante de manière à conserver son hachage SHA-1 d'origine?

Question

Selon cet article et beaucoup d’autres, SHA-1 n’est pas sécurisé.

Dans mon cas, les mots de passe ou les certificats numériques ne me préoccupent pas. Je suis préoccupé par l'intégrité des fichiers.

Est-il raisonnablement possible qu'un fichier (par exemple une image ISO ou un fichier exécutable) soit modifié de manière malveillante de manière à:

Conserve le hachage SHA-1 du fichier d'origine et
Maintient le contenu global et le fonctionnement du fichier (mais inclut bien sûr maintenant un contenu malveillant qui n'y était pas à l'origine)

À mon avis, modifier un fichier de manière à générer une collision SHA-1 le rendrait totalement inutile. L'ISO serait totalement corrompu, ou le fichier exécutable serait si complètement brouillé qu'il ne serait même plus un fichier exécutable.

Mais la façon dont je vois les choses pourrait bien être fausse. Jusqu'à présent, je n'ai rien trouvé sur les recherches Google concernant l'adéquation continue de SHA-1 pour la vérification des fichiers. Des idées?

David Schwartz · Accepted Answer

Personne n'a encore accompli cela pour SHA-1. C'est possible en théorie, mais pas encore pratique. Les informations sur l'insécurité dans SHA-1 signifient simplement que le niveau de sécurité n'est pas aussi élevé que nous le souhaiterions, ce qui signifie que nous n'aurons pas autant d'années à nous soucier de cela que nous le pensions.

Il est plus difficile de produire un fichier avec le même hachage SHA-1 que de créer deux fichiers vous-même avec le même hachage SHA-1. Et à notre connaissance, personne dans le monde n’a encore accompli cette tâche plus facile. Cela ne signifie pas que cela ne peut pas arriver demain cependant.

Cort Ammon · Answer

C'est théoriquement possible, mais cela n'a pas encore été fait.

Ce que vous recherchez s'appelle une "collision de hachage:" deux fichiers avec le même hachage. Les codes de hachage cryptographiques tels que SHA-1 sont généralement conçus pour rendre cela difficile. Comme SHA-1 est un code de 160 bits, il faudra en moyenne 2 ^ 159 tentatives de force brute pour trouver un doublon. Si on trouve un algorithme dont le résultat est meilleur que celui utilisé contre un hachage cryptographique, celui-ci est considéré comme "cassé".

MD-5 est un exemple de hachage très cassé. Il était censé avoir une puissance de 128 bits, nécessitant en moyenne 2 ^ 127 tentatives. En ce qui concerne les vulnérabilités connues, le nombre réel de tentatives nécessaires peut être aussi faible que 2 ^ 47. C'est beaucoup moins que 2 ^ 127. En fait, cela s’est fait en moins d’une journée sur un cluster informatique moderne.

Je donne cet exemple car il correspond le mieux à la manière dont vous envisagez d’utiliser SHA-1. Cependant, ce n’est pas l’approche la plus courante utilisée par la cryptanalyse pour s’assurer que les hachages ne sont pas cassés. Ils permettent généralement une collision entre deux fichiers, choisis par l'attaquant, au lieu de vous laisser choisir un fichier et l'attaquant cherchant à le faire correspondre. Ce type d'attaque a l'avantage d'être plus facile à évaluer. Si je trouve qu'il est "difficile" de déchiffrer votre fichier, cela signifie-t-il qu'un autre fichier est tout aussi puissant? Cette attaque qui permet à l’attaquant de choisir les deux fichiers nous permet d’attraper le pire du pire.

Ce type d'attaque permet une astuce intéressante appelée "attaque d'anniversaire ". Pour résumer, utiliser l'attaque d'anniversaire divise par deux la force de l'algorithme. SHA-1 nécessite donc 2 ^ 80 tentatives (en moyenne) et MD5, 2 ^ 64 tentatives (en moyenne). Ce sont la moitié de 160 et 128 respectivement.

SHA-1 a des attaques connues qui diminuent sa force de 2 ^ 80 à 2 ^ 69. Cela ne va pas avoir beaucoup d'importance pour vous. 2 ^ 69 tentatives est un temps long .

Cependant, de l’histoire, nous avons constaté que les algorithmes de hachage ne sont pas cassés spontanément, mais plutôt au fil du temps. Personne ne déchiffre un algorithme tel que MD-5 en le faisant passer de 2 ^ 64 à 2 ^ 47 en une nuit. Cela se produit au fil du temps, alors que de nombreuses personnes publient des articles sur les calculs qu’ils utilisent pour le contrer. On peut généralement voir la complexité des attaques diminuer lentement depuis le début de l’algorithme (où la meilleure attaque est généralement l’attaque anniversaire).

Le fait que nous assistions à quelques changements dans les collisions suggère que SHA-1 voit la lumière au bout du tunnel. Il est encore fort, mais on pourrait souhaiter passer au dernier SHA-3, qui est actuellement beaucoup plus sécurisé.

Vous devriez vraiment prendre de telles décisions du point de vue du modèle de menace. Combien de dégâts un attaquant peut-il causer s'il subit une de ces collisions? Les scripts de vos attaquants ont-ils accès à quelques ordinateurs portables ou les gouvernements disposent-ils de grappes complètes de superordinateurs? Quelle est la durée d'une fenêtre temporelle qu'un attaquant doit casser le hachage avant qu'il ne soit utilisé (de nombreuses utilisations de la cryptographie impliquent un "changement de garde", tel que la rotation du mot de passe). Tous ces facteurs affecteront le sérieux avec lequel vous devrez considérer les collisions.

cpast · Answer

Les failles de SHA-1 discutées dans cet article sont très spécifiques: elles permettent aux attaquants de créer deux choses qui ont la même valeur (cela s'appelle une "attaque par collision"). Cependant, une attaque par collision nécessite que l'attaquant contrôle les deux fichiers impliqués. Si l'attaquant ne contrôle pas le fichier d'origine, une attaque par collision ne leur permet pas de trouver un autre fichier avec la même valeur de hachage.

La raison pour laquelle cela est important pour TLS/SSL (et les signatures en général) est qu’avec ceux-ci, un attaquant peut souvent contrôler les deux fichiers. Un certificat TLS est principalement créé par la personne qui le demande (les bits qu’ils ne contrôlent pas sont souvent prévisibles). Les collisions leur permettent donc de créer un certificat légitime et un certificat illégitime, de faire signer le certificat légitime et de transférer la signature.

Pour les fichiers, la même situation ne s'applique pas toujours. Si vous craignez que la personne qui crée le fichier soit l'attaquant (par exemple, une chose sera vérifiée de manière indépendante, puis vous enverra la charge maléfique avec le même hachage), l'attaque SHA-1 s'applique et vous devriez regarder vers une élimination progressive (bien que ce ne soit pas critique, comme l'a mentionné David Schwartz). Si le fichier d'origine est approuvé, l'attaquant ne peut pas appliquer les attaques SHA-1 connues, bien que vous devriez tout de même penser à le supprimer progressivement si vous le pouvez (si vous avez le choix, utilisez un hachage sans attaques connues, comme SHA- 2).

En réponse à "la collision ne sera pas utile" - Alors qu'une attaque ne nécessite pas qu'un attaquant soit en mesure d'obtenir une collision utile , il n'est généralement pas si difficile de transformer une "collision" en "collision utile". De nombreux formats de fichiers disposent de suffisamment d'espace pour que vous puissiez avoir ce que vous voulez sans affecter les fonctionnalités du fichier; un attaquant peut généralement modifier cela afin d’obtenir une collision (si les collisions sont pratiquement détectables), tout en conservant la partie fonctionnelle comme elle le souhaiterait. L'écart entre "attaque académique" et "attaque pratique" peut être grand; l'écart entre "toute collision" et "collision utile" est généralement beaucoup plus petit.

Le problème le plus grave, qui n’est pas lié au choix de l’algorithme, est de savoir comment vous obtenez le hachage. Tout ce qu’un hachage fait, c’est de déplacer le problème de "récupère le fichier réel" à "récupère la valeur de hachage réelle"; une valeur de hachage envoyée par le même serveur et sur le même type de connexion que le fichier est totalement inutile contre les modifications malveillantes (tout attaquant qui peut altérer le fichier peut altérer le hachage). Les hachages ne sont utiles que si vous pouvez faire davantage confiance au hachage qu'au fichier; Bien que ce soit parfois le cas (torrents, miroirs), ils sont souvent utilisés quand ce n'est pas le cas. Vous devez donc faire très attention à cela chaque fois que vous utilisez des hachages pour la vérification de l'intégrité.

Damon · Answer

Vous devez faire la différence entre une attaque par collision et une attaque par préimage . La recherche de deux messages ayant une valeur identique est une attaque par collision.
Remplacer un message particulier donné (ici: un exécutable) par un autre message ayant le même hachage est une (seconde) attaque de pré-image.

SHA-1 est cassé dans la mesure où une attaque par collision peut être faite en 2⁵² opérations selon un article de Wikipedia qui ne fournit pas de citation pour ce numéro (la meilleure attaque que je connaisse et qui soit réellement crédible est celle de Marc Stevens, qui prend 2⁶⁰ opérations). Mais supposons le cas pessimiste de 2⁵².

C'est inquiétant, car une attaque de cette ampleur est non seulement théoriquement envisageable, mais parfaitement réalisable en moins d'une journée sur une plate-forme multi-GPU. C'est bien sûr un problème pour les applications où "deux messages" feront l'affaire. Même le 2⁶⁰ le chiffre donné par Stevens (qui représente 256 fois plus de travail) est parfaitement réalisable si votre attaquant est prêt à dépenser de l'argent supplémentaire pour résoudre le problème, ou à passer une année.
C'est exactement le genre de chose qui n'empêchera pas une personne impliquée dans l'espionnage ou la cybercriminalité de falsifier des certificats.

Maintenant, une attaque de pré-image a un exposant deux fois plus grand, alors supposons 2⁵² pour l'attaque par collision, ce serait 2¹⁰⁴ opérations, ce qui est un stade totalement différent.

Ce n'est pas seulement peu pratique (une machine qui est un milliard de fois plus rapide que celle mentionnée dans le paragraphe précédent nécessiterait encore environ 6 millions d'années), mais étant donné nos faibles moyens de production d'énergie, c'est tout à fait impossible.

Effectuer un calcul aussi massif nécessiterait une source d’énergie beaucoup plus importante que tout ce que nous pouvons nous permettre de consacrer à une seule opération. Non, ce n’est pas une source d’énergie de la taille du Soleil, mais un assez grand .

Vous pouvez raisonnablement vous attendre à obtenir entre 10 et 50 GFLOPS sur un Watt. En supposant qu'un miracle se produise et que les processeurs consomment environ plusieurs milliers de fois mieux en énergie pendant la nuit, on pourrait supposer que 1 SHA 1 FLOP (plutôt optimiste!). Cela voudrait dire que pour accomplir 2¹⁰⁴ calculs de hachage dans les 10 ans, vous avez besoin de 10¹²W centrale électrique. Pour pouvoir attaquer dans l’année qui suit, il vous faut 10¹³W centrale électrique. C'est environ 50 fois plus que ce que les centrales nucléaires des États-Unis, de la France et du Japon peuvent produire ensemble, uniquement pour forger un seul hasch.

Cela ne se produira pas , il existe des moyens beaucoup plus faciles d'atteindre le même objectif (exploiter le serveur qui stocke le hachage d'origine et le remplacer, faire chanter quelqu'un, etc.).

jmn · Answer

Le point général de l'article mentionné dans la question est le suivant: SHA1 est obsolète et doit être supprimé progressivement tant que vous avez encore le temps de le faire en douceur. Dans certaines régions, le temps presse car Google et Microsoft imposent des délais.

Règle générale pour la technologie obsolète :

Si vous créez un nouveau design ou ajoutez des fonctionnalités, ne l'utilisez pas (SHA1).
Si vous conservez un élément ancien, définissez un plan pour le remplacer (SHA1).

Résumé de la contribution de Bruce Schneier au blog de 2012: "Le fait est que nous, dans la communauté, devons commencer la migration de SHA-1 à SHA-1/maintenant . "

Ehryk · Answer

En ce qui concerne la partie collision de hachage SHA-1 de votre question, quelques-unes des réponses ont été apportées à cette question.

Cependant, une grande partie de ceci dépend du type de fichier avec lequel nous travaillons:

Maintient le contenu global et le fonctionnement du fichier (mais bien sûr, inclut désormais ~~contenu malveillant qui n'y était pas à l'origine~~ contenu modifié)

Ce que cela signifie varie énormément sur ce qui détecte les altérations:

S'il s'agit d'un exécutable signé, ce n'est pas une chance (raisonnable): vous devez obtenir deux collisions de hachage: le SHA-1 du fichier et la signature .exe interne.
S'il s'agit d'un exécutable non signé, .com, d'un fichier .dll non signé ou similaire, leurs fourches de ressources peuvent être ajoutées de manière à ne pas modifier leur fonctionnement. Vous pouvez ainsi (éventuellement) obtenir une collision de hachage non détectable par 'normale' opération.
S'il s'agit d'un fichier de code source ou d'une structure similaire (.cs, .c, .h, .cpp, .rb, .yml, .config, .xml, .pl, .bat, .ini, les ajouts, modifications ou suppressions peut être contraint à une syntaxe de commentaire valide telle que le changement ne soit pas perceptible par la plupart des utilisateurs (le compiler ou le lancer, pas l'ouvrir avec un éditeur de texte).
S'il s'agit d'un format de conteneur .iso ou .Zip ou autre, il est également plus improbable que la plupart des modifications aléatoires corrompent le conteneur. Il est possible de le faire: ajouter une fausse entrée de fichier ou modifier un contenu dans le conteneur et le revérifier, mais vous ajoutez une couche de complexité et un temps supplémentaire pour vérifier le résultat, en plus d'avoir des degrés de liberté limités. comment et quels contenus peuvent être changés.
S'il s'agit d'un format texte ou de type texte, ils peuvent être modifiés presque comme vous le souhaitez tout en restant un fichier 'valide', bien que le contenu soit probablement visible.
Avec de nombreux formats tels que .rtf, .doc, .html, .xslx et autres formats markup-esque, ils peuvent être ajoutés ou modifiés de manière indétectable par les analyseurs, donc différents de la longueur (ou même avec une longueur contrainte). , moins de liberté), les fichiers peuvent être modifiés pour (éventuellement) obtenir une collision de hachage tout en restant non seulement un fichier valide, mais pas sensiblement modifié de manière visible pour les applications types avec lesquelles ils seraient utilisés.

Donc, il ne vous reste plus qu'à trouver des solutions pour éviter les collisions, quelle que soit leur structure et leur degré indétectable:

Effectuez les modifications fonctionnelles souhaitées (par exemple, insertion de contenu malveillant) et apportez les modifications supplémentaires pour conserver la validité spécifique du format de fichier
Ajouter une section qui ne fonctionnera pas (entre les blocs de commentaires, à la toute fin d'un fichier texte avec 3k retours chariots au-dessus, isoler un bloc de commentaires en cours)
Ajoutez ou sélectionnez un caractère/point de code/octet à modifier et essayez toutes les combinaisons valides possibles (chaque combinaison d'octets n'est pas valable pour différents codages, par exemple).
Recalculer le hachage, voir si les correspondances de collision.
si ce n'est pas le cas, passez à 3.

Supposons que vous ayez un ordinateur super rapide et un fichier compact, de sorte qu'une modification avec une séquence d'octets valide et un nouveau calcul du hachage prennent 1 milliseconde (nécessitant probablement du matériel dédié). Si la distribution de hachage est parfaitement aléatoire et répartie sur toute la plage, vous obtiendrez une collision avec SHA-1 à chaque tentative de 2^160 (le forcera brutalement).

2^160/1000/60/60/24/365.24 = 4.63x10^37 years = 46,300,000,000,000,000,000,000,000,000,000,000,000 years = 46 undecillion years.

Mais bon, essayons les versions 2^60 et 2^52, et supposons qu'elles nous permettent de modifier le fichier comme bon nous semble (elles ne le font pas) et qu’elles aussi peuvent se faire en 1 ms à chaque essai:

2^52 yields 142,714 years /*humans might still be around to care, but not about these antiquated formats*/ 2^60 yields 3.65x10^7 years = 36,500,000 years /*machines will probably have taken over anyway*/

Mais bon, vous pourriez avoir de la chance. Vraiment, vraiment, plus d'un-miracle-que-tout-les-gens-appels-miracles chanceux.

Anthony Guess · Answer

Pas vraiment, vous pouvez satisfaire à une de ces conditions à la fois mais pas les deux .. il est possible d’obtenir le même hachage pour deux fichiers différents, mais il est pratiquement impossible de modifier un fichier et d’essayer d’obtenir le même hachage autant que je sache