Obsolescence SHA1

mai 04, 2015  |   Actualités,Blog   |     |   0 commentaire

Introduction

Tout comme MD5 depuis 2004, l’utilisation de SHA1 est désormais déconseillée pour une utilisation cryptographique. Nous allons voir dans cet article à quoi servent ces fonctions ainsi que les pré-requis à l’utilisation de leurs successeurs.

Principe du hachage

Le hachage consiste à effectuer un calcul sur des données (chaines de caractères ou données binaires) afin d’en déterminer une chaine de caractère de longueur fixe appelée le hash (ou condensat) (128 bits pour le MD5 et 160 bits pour le SHA1). Ce hachage, irréversible, est utilisé dans essentiellement trois cas :

  1. La protection des mots de passe dans une base de données
  2. La validation de la cohérence des données.
  3. La signature des données (signature du hash d’un certificat par ex.)

Dans le premier cas, lorsqu’un mot de passe est demandé, sur un site Internet par exemple,  celui ci est “hashé” avant d’être stocké en base de données (c’est une bonne pratique). De ce fait, dans le cas d’un piratage de base de données, les mots de passes utilisateurs ne sont pas obtenus directement. De plus, un administrateur ne possède pas l’ensemble des couples login/mot de passe de ses utilisateurs.

Puisque le procédé est irréversible, il n’est pas possible de retransmettre un mot de passe à l’utilisateur en cas d’oubli, un administrateur doit vous demander d’en générer un nouveau.

Dans le second cas, cela permet de vérifier que des données transférées n’ont pas été altérées. Par exemple, lorsque l’on télécharge un nouveau firmware pour un équipement, il est risqué de l’appliquer sans vérifier au préalable son intégrité. Si le fichier était altéré, il pourrait rendre totalement inopérable l’équipement à mettre à jour.

Il suffit alors de générer le hash du fichier téléchargé :

# shasum firmware.fw
248a319cd5f6693c5f9ba39b7d733f4e6e39e0da  firmware.fw

Vous pourrez alors retourner sur le site où vous venez de télécharger le fichier et vérifier que le hash “248a319cd5f6693c5f9ba39b7d733f4e6e39e0da” est bien identique des deux cotés.

Toutefois, le nombre de combinaisons de hash étant fini (2,46 x 10^48), il se peut que deux fichiers différents aient le même hash. Lorsque deux contenus différents produisent le même hash, on parle alors de collision. C’est d’ailleurs le cas pour ces deux images. Vous pouvez vérifier le hash MD5 vaut e06723d4961a0a3f950e7786f3766338 !

barry

http://www.fishtrap.co.uk/white.jpg

brown

http://www.fishtrap.co.uk/brown.jpg

C’est la facilité de générer ces collisions qui rend ces algorithmes obsolètes. En 1996, une attaque [Ref. 2] permettant de générer des messages qui produisent le même hash avec MD5 a été découverte. Moins de 10 ans plus tard il en est de même pour le SHA1, qui est alors jugé trop faible d’un point de vue cryptographique. C’est alors que les travaux ont commencé pour mettre en place la relève.

Plan de retraite

Bien qu’aujourd’hui, il soit toujours extrêmement difficile (voir impossible) de générer un message à partir d’un hash, la retraite a sonné pour SHA1. L’enjeu est cryptographique puisque SHA1 est, à la rédaction de cet article, toujours utilisé afin de garantir l’intégrité des données présentes dans les certificats SSL.

C’est pour cette raison que que depuis quelques temps les autorités de certifications proposent par défaut de délivrer des certificats avec un hash au format SHA-2 qui est devenu le nouveau standard du NIST (organisme public des Etats Unis listant les standard à utiliser pour les communication non militaire) recommandé en cryptographie [Ref.9 p13-14].

Celles-ci ne délivreront plus de certificats SHA-1 à compter du 1er Janvier 2016. En parallèle, les navigateurs désactivent peu à peu le support de ces certificats (Google Chrome a d’ores et déjà commencé à afficher des alertes sur la non fiabilité de ces sites, Mozilla Firefox compte afficher le message “Untrusted Connection” dès le 1er Janvier 2016 et Microsoft Internet Explorer compte agir dès le 1er Janvier 2017)

Il faut donc dès maintenant, avant de renouveler vos certificats, vérifier que vos applications sont compatibles avec le nouveau standard, sans quoi vous risqueriez, soit de ne pas pouvoir importer votre nouveau certificat, soit de voir votre certificat inutile le 1 Janvier 2017.

SHA-2

Pour finir, quelques mots sur ce nouveau standard qui nous accompagnera probablement ces prochaines années.

Dans la famille du SHA-2, il existe plusieurs versions allant du SHA-224 au SHA-512, le suffixe indiquant la taille du hash produit par ces algorithmes. Les versions les plus standard sont les SHA-256 et SHA-512, desquelles découlent les autres versions.

Ces deux versions se différencient essentiellement par le nombre d’opérations réalisées avant d’obtenir le résultat et la taille maximale des données qu’elles peuvent traiter (264 pour SHA-256 et 2128 pour SHA-512). Avec une limite de 3,86 x 1025 To pour le SHA-512, nous avons le temps de voir venir.

Enfin, il existe d’ores et déjà une fonction dénommée SHA-3 qui n’est pas, à ce jour, considérée comme la remplaçante de SHA-2 mais comme une alternative. Elle produit d’ailleurs des hashs de même longueur.

Bibliographie

[1] http://fr.wikipedia.org/wiki/MD5

[2] http://cseweb.ucsd.edu/~bsy/dobbertin.ps

[3] http://fr.wikipedia.org/wiki/SHA-1

[4] http://fr.wikipedia.org/wiki/SHA-2

[5] https://community.qualys.com/blogs/securitylabs/2014/09/09/sha1-deprecation-what-you-need-to-know

[6] http://blogs.technet.com/b/pki/archive/2013/11/12/sha1-deprecation-policy.aspx

[7] https://blog.chromium.org/2014/09/gradually-sunsetting-sha-1.html

[8] http://natmchugh.blogspot.fr/2014/10/images-with-colliding-md5-hash.html

[9] http://dx.doi.org/10.6028/NIST.SP.800-131A

[10] http://fr.wikipedia.org/wiki/SHA-3

[11] https://blog.mozilla.org/security/2014/09/23/phasing-out-certificates-with-sha-1-based-signature-algorithms/

[12] http://blogs.technet.com/b/pki/archive/2013/11/12/sha1-deprecation-policy.aspx

[13] http://googleonlinesecurity.blogspot.fr/2014/09/gradually-sunsetting-sha-1.html