GitHub détaille son blocage des attaques basées sur les collisions SHA-1

GitHub détaille son blocage des attaques basées sur les collisions SHA-1

Avant l'intégration dans Git

Avatar de l'auteur
Vincent Hermann

Publié dans

Internet

21/03/2017 4 minutes
21

GitHub détaille son blocage des attaques basées sur les collisions SHA-1

L’algorithme de hachage SHA-1 n’est plus en odeur de sainteté depuis que des chercheurs ont montré de quelle manière des collisions pouvaient être exploitées dans des attaques. GitHub, qui l’utilise largement, a expliqué hier soir les mécanismes mis en place pour protéger ses utilisateurs.

Une attaque par collision se base sur l’idée qu’un algorithme puisse produire le même hash pour deux fichiers différents. Véritable bête noire dans ce domaine, une collision peut être exploitée pour faire passer un fichier malveillant comme légitime, ou même pour falsifier une signature électronique. Depuis qu’une équipe de chercheurs en a à nouveau montré les risques fin février (attaque SHAttered), SHA-1 fait justement l’objet d’attentions particulières.

GitHub explique comment il pourrait être attaqué

GitHub a d’ailleurs annoncé hier soir certaines mesures visant à court-circuiter les risques pour les utilisateurs. SHA-1 y est en effet utilisé pour identifier l’ensemble des données hébergées, stockées dans des objets. Il fallait donc empêcher que deux objets puissent obtenir le même hash. Un cas de figure accidentel que l’équipe juge extrêmement improbable. On parle donc bien ici d’une attaque éventuelle.

L’éditeur en explique d’ailleurs les mécanismes. Un pirate commence par générer une paire d’objets identifiés tous deux par le même hash. Il doit convaincre ensuite le développeur d’accepter le fichier innocent et attend qu’il le pousse dans son projet via un commit. Le pirate récupère ensuite le dépôt et le propose au téléchargement en ayant remplacé le fichier innocent par sa version malveillante. La signature SHA-1 générée n’aura pas changé.

Détection d'une attaque qui laisse des traces

Pour GitHub, la force brute reste considérée comme bien trop onéreuse pour SHA-1. Par contre, le modèle d’attaque utilisé par les chercheurs suit une ligne définie et « laisse des traces dans les octets », que l’on peut donc détecter si on en connait la signification. Le service s’occupe de cette étape dans tout calcul SHA-1 opéré. Le code de détection utilisé est open source et a notamment été développé par Marc Stevens, l’un des chercheurs à la base de l’attaque SHAttered.

GitHub indique qu’actuellement, aucune attaque de ce type n’a été détectée. L’éditeur rappelle à ce sujet que même si la théorie est tout à fait valide et qu’il est possible de réaliser de telles opérations, elles sont particulièrement coûteuses en l’état : « des centaines de milliers de dollars de calculs ».

Première étape avant l'intégration dans Git

Par ailleurs, la détection mise en place n’est qu’une première étape. Un travail est en cours avec Git pour l’intégrer directement au cœur du système. Les prochaines versions de Git seront donc à même de détecter les collisions et de rejeter toute opération impliquant des paires de fichiers « collisionnés », et ce pour l’ensemble des opérations, que l’on parle d’application de patchs, génération d’objets ou récupération de données depuis d’autres sites.

Surtout, Git réfléchit actuellement à une transition pour sortir de SHA-1 et basculer sur un algorithme plus sécurisé, par exemple SHA-256.  Rien n’a encore été décidé à ce stade, mais GitHub précise qu’il suivra le mouvement quand le projet « aura mûri ».

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

GitHub explique comment il pourrait être attaqué

Détection d'une attaque qui laisse des traces

Première étape avant l'intégration dans Git

Fermer

Commentaires (21)


Pourquoi ne pas passer directement au SHA-512 ?

Je ne comprendrai jamais pourquoi ces grosses boites n’utilisent pas les algo disponibles les plus performants… Contraintes de stockage ou charge CPU ?


C’est une contrainte de git. Git fonctionne via SHA-1 qui était probablement le bon choix lors de sa création. Github étant basé sur git il hérite donc de cette contrainte.

Si il change ils perde toute compatibilité avec l’écosystème git




The Git project is also developing a plan to transition away from SHA-1 to another, more secure hash algorithm, while minimizing the disruption to existing repository data. As that work matures, we plan to support it on GitHub.





Dans la source, pas de SHA-256…








JCDentonMale a écrit :



Pourquoi ne pas passer directement au SHA-512 ?

Je ne comprendrai jamais pourquoi ces grosses boites n’utilisent pas les algo disponibles les plus performants… Contraintes de stockage ou charge CPU ?





Avec ce genre de raisonnement, autant passer au SHA-1024. Sauf que ça ne sert à rien, le SHA-256 étant déjà très très loin des capacités de calculs actuels, même avec des progrès considérables en puissance.

Le SHA-1 a une attaque théorique qui demande 2^63 opérations (8 x 10^18), donc des moyens considérables ; SHA-256 demande 2^128 opération soit 2^65 fois plus que SHA-1, autant dire que le soleil sera éteint avant, même avec tous les ordinateurs de la planète.



Tu as raison le SHA-256 devrait être suffisant, ensuite, pour le SHA-1, à l’époque ils pensaient aussi avoir du temps avant qu’on parvienne à le mettre en défaut.


J’avais complètement oublié que c’est Git même qui impose le SHA-1. Merci de me le rappeler :-)


Et c’est possible de mettre git à jour ?



Je précise que je ne m’y connais pas beaucoup








JCDentonMale a écrit :



Tu as raison le SHA-256 devrait être suffisant, ensuite, pour le SHA-1, à l’époque ils pensaient aussi avoir du temps avant qu’on parvienne à le mettre en défaut.





C’est vrai, mais le SHA-1 a été créé en 1995 et reste fiable pour l’essentiel des besoins (vu le coût de craquage, faut un service secret ou une mafia bien organisée), et depuis on a encore mieux pris conscience des marges nécessaires (et en plus la puissance des CPU ne croît plus beaucoup depuis quelques années).









OlivierJ a écrit :



 SHA-256 demande 2^128 opération soit 2^65 fois plus que SHA-1, autant dire que le soleil sera éteint avant, même avec tous les ordinateurs de la planète.







Si la puissance des ordinateurs double tous les ans, il faudra 65 ans. J’espère que le soleil sera encore là. 



Ne pas trop prophétisé sur les évolutions future, ça ne réussit pas en général, de mon avis ils vaut mieux prendre en compte le maximum de paramètre même si cela paraît improbable.


Là on parle uniquement de résolution via la puissance de calcul brute avec une architecture classique. L’arrivée prochaine (entendre par là dans quelques années, une décénie peut-être) de l’informatique quantique change la donne. Et il me semble que justement les algorithmes de hachage sont beaucoup moins robuste avec une approche via des algorithmes quantique.


Très bonne remarque, d’autant que SHA-512 est plus rapide que SHA-256 (bien que cela puisse surprendre).



À creuser.


Cet outil détecte effectivement bien les collisions, en tout cas celles qui sont “dérivées” de shattered.



Par exemple, sur ces fichiers :

http://blog.rom1v.com/assets/shadow/shadow1.pdf

http://blog.rom1v.com/assets/shadow/shadow2.pdf



$ bin/sha1dcsum shadow1.pdf shadow2.pdf

9051ae45aeb14f65c3f6b1d8272f551ed38f94ba coll shadow1.pdf

a8b92b2489cb7d699aaf29aa3c2726abe0d7541b coll shadow2.pdf








v1nce a écrit :



Si la puissance des ordinateurs double tous les ans, il faudra 65 ans. J’espère que le soleil sera encore là.





<img data-src=" />

Tout est dans le “si”.

Et le doublement n’était pas tous les ans, mais tous les 18 mois à 2 ans.







AltreX a écrit :



Ne pas trop prophétisé sur les évolutions future, ça ne réussit pas en général, de mon avis ils vaut mieux prendre en compte le maximum de paramètre même si cela paraît improbable.





En effet, je ne me hasarderai pas à prédire la future augmentation de puissance des ordinateurs sur 30 ans, mais actuellement et pour quelques années (la recherche étant souvent en avance de 5 à 10 ans sur la commercialisation de découvertes), la puissance va stagner comme elle le fait depuis quelques années, ne serait-ce que parce que l’augmentation de fréquence est stoppée et était la cause principale du doublement (le gain en IPC est faible à chaque génération). Pour battre des records en TOP 500 on y arrive essentiellement en mettant plus de CPU et plus de coeurs.



Il y a peut-être quelque part une technique disruptive qui nous fera repartir dans la puissance. Cela dit, à long terme je pense qu’on sera touché par la double limite minerai-énergie (cf L’âge du low tech de Philippe Bouix, et d’autres articles et livres de Jancovici), et à la lumière de cette limite je me demande où en sera l’informatique dans 50 ans, a priori de nouveau chère et plus rare.



Effectivement l’informatique quantique nourrit un certain nombre d’espoirs (ou de craintes), je ne sais pas si ça sera généralisable et si oui, dans quelle mesure on pourra inventer des nouvelles méthodes cryptographiques robustes, ne serait-ce que pour le hashage (car pour la communication, on a déjà imaginé des techniques non interceptables).

Je ne sais pas non plus dans quelle mesure l’informatique quantique est autant concernée par la future limite minerai-énergie (cf mon commentaire #14), a priori oui.


Bon ben dans 130 ans alors.

Voire avant avec D-Wave, BlueMix…


intéressante analyse <img data-src=" />


SHA-Bit.



<img data-src=" />








OlivierJ a écrit :



Avec ce genre de raisonnement, autant passer au SHA-1024. Sauf que ça ne sert à rien, le SHA-256 étant déjà très très loin des capacités de calculs actuels, même avec des progrès considérables en puissance.

Le SHA-1 a une attaque théorique qui demande 2^63 opérations (8 x 10^18), donc des moyens considérables ; SHA-256 demande 2^128 opération soit 2^65 fois plus que SHA-1, autant dire que le soleil sera éteint avant, même avec tous les ordinateurs de la planète.





SHA-1024 n’existe pas.

SHA-3 (“Keccak”) par contre, oui, mais il n’est pas destiné à remplacer la famille des SHA-2 (SHA-256, SHA-384 et SHA-512).



Théoriquement oui.

Dans les fait c’est compliqué car il ne faut pas que la mise à jour casse l’existant et rende les dépots de code incompatible.

A mon avis le risque est trop mineur pour s’aventurer dans une mise à jour de cette ampleur.








aztazt a écrit :



SHA-1024 n’existe pas.





Ben justement, raison de plus pour s’y coller <img data-src=" /> .



(oui je savais, apparemment tu n’as pas compris pourquoi j’en parlais)