Retrait progressif de certificats SHA-1

Google en route vers un internet plus sécuritaire

Voilà qu’après avoir cessé de supporter l’algorithme MD5, Google nous avise en septembre 2014 que son navigateur Chrome (plus de 40% des internautes) ne supporterait plus l’algorithme de hachage SHA-1! Le niveau de sécurité considérablement affaiblie depuis 2005 et après la découverte de faille qui permettrait d’aboutir rapidement à ce qu’on appelle des « collisions » (quand deux documents différents génèrent le même « hachage »).

Ça reste très hypothétique mais c’est une question de rassurer la clientèle avant qu’un tel événement ne se produises réellement. D’autant qu’il s’est déjà produits avec l’algorithme de hachage MD5.

Les certificats utilisant une chaine de hachage SHA-1 valide après le 1^er janvier 2017 ne seront plus perçus comme « dignes de confiance » dans l’interface utilisateur de Google Chrome. Or donc les utilisateurs de Chrome commenceront à voir des avertissements sur les sites qui utilisent des certificats SHA-1 à partir de décembre. Et en 2015, c’est un élégant « x » rouge qui nous en avisera! SSL non sécur (google)

Vérifier le chiffrement de vos certificats SSL

SHAAAAAAAAAAAAA détecte les certificats SHA-1.

Même si en principe il n’est plus considéré comme un standard depuis 2010, cette annonce a créé tout un émoi dans le mondes du Web et une vague de contestation. Certains se plaigne du délais trop court, d’autre que la plupart des certificats sont valides pour trois ans (alors que les certificat de Google on une duré de 3 mois!) d’autres enfin que Windows XP (avant le SP3) n’est tout simplement pas compatible SHA-2 etc.

Des bonnes raisons, même si le changement d’un certificat prend 5 minutes! Par contre, pas de panique, un « x » sans plus. La transaction reste valide! Hypothétique et très subjectif si on se comprend bien! Google estimera en 2017 une connexion déjà non-sécuritaire depuis 10 ans! Changer de navigateur si vous ne voulez pas changer votre Windows XP!

Déjà-vu!

Pour une grosse organisation c’est effectivement un tas de problèmes mais pas en raison de Google, cette fois! Les fournisseurs, surtout ceux qui vendent encore des certificats avec algorithme SHA-1, on une grande part de la responsabilité. Tout d’abord ça ne date pas d’hier! Déjà Microsoft annonçait il y a un an (novembre 2013) qu’il n’accepterais plus les certificats SHA-1 dès 2017. Et même si Google parle de 2011, des recherches du Forum CA/Browser et de l’autorité des certificats (CA) ont démontré les premiers exemples de collisions dès 2004! En principe cette "norme" SHA-1 de hachage, qui n’en était pas une, devrait être au rancart depuis 2010 au profit du SHA-2.

Certificat numérique

Un certificat numérique est essentiellement une façon de confirmer l’identité du serveur. S’assurer que la chaine HTTP cryptée (HTTPS) est envoyée par un serveur de confiance, sans plus. Rien avoir avec le chiffrement du texte ou de la transaction en tant que tel. Le tout confirmé par une clé public du « certificat serveur » elle aussi "garantie" par l’ « autorité de certification (AC ou CA) », unique gestionnaire de "confiance". Ça fait beaucoup de guillemets!

Sans rentrer dans la « dite confiance de la NSA » (quelqu’un se sent en confiance sur le web?), c’est en fait seulement le chiffrement et plus précisément l’algorithme de hachage SHA-1 de cette dernière clé qui fait défaut. Et d’ailleurs les attaques simulées non jamais permis de récupérer autres choses que des données éparse sans importance.

Chaine de vérification

Exemple de chaine de confiance SSL (SHA-1)

L’autorité racine ou « certificat racine » attribut donc des certificats à l’autorité de certification intermédiaire qui a la possibilité à son tour d’émettre des certificats de serveur, des certificats personnels, des certificats d’éditeur ou des certificats pour d’autres autorités de Certification intermédiaires. C’est ce qu’on appelle la « Chaine de vérification » ou « chaîne de confiance » (chain of trust).

En ce qui nous concernent, le certificats de serveur identifient les serveurs participant aux communications sécurisées avec d’autres ordinateurs à l’aide de protocoles de communication tels que le SSL ou le TLS. Ces certificats permettent à un serveur d’authentifier son identité aux clients sans plus. Car c’est bien beau crypter des données, il faut aussi s’assurer que le serveur et bel et bien celui mentionné par le certificat. C’est l’objectif principal du certificat numérique, garantir que la clé publique contenue dans le certificat appartient bien à l’entité à laquelle le certificat a été délivré.

Cryptographie à clé publique

Les certificats de serveur respectent le format de certificat X.509 défini par les normes de cryptographie à clé publique (Public Key Cryptographic Standards).

Il faut deux authentifications pour authentifier un certificat. Si le certificats racines (trusted root certificates) et validé par le client TSL (le navigateur) à l’aide de son identité, le certificat serveur demande une authentification à partir de la chaîne de confiance (chain of trust). Cette authentification est assuré par la clé publique que l’on crypte en SHA-1 parce que l’on ne peut pas décoder du « hachage »! On l’utilise pour comparer deux clés publiques SHA-1 sans jamais, en principe, compromettre la clé elle-même.

Si on trouve des décodeurs de « hachage », c’est que des banques de « hachage de mots » se constituent un peu partout. Il suffit de construire une table de références mot / hachage pour rechercher des mots hachés et même arriver à décoder des petits textes. Ceci dit, c’était impossible de décrypter le hachage d’un texte avant les nombreux exemple de collisions. Je ne dirait pas une attaque mais plutôt une "signature" détectée par la collision de deux hachages identiques.

SHA-1 et singularité observable

Shéma de l’algorithme SHA-1 (source Wikipédia) — Un tour de la fonction de compression de SHA-1 (source Wikipédia)

SHA-1 (Secure Hash Algorithm) est un algorithme à 160-bit de hachage cryptographique créé par la NSA. C’est à dire une méthode de chiffrement aléatoirement des données en principe de façon irréversible. Utilisé notamment pour encoder les signatures des certificats SSL des serveurs (connexion avec le petit cadenas).

Le mot clé en sécurité c’est les « couches ». Tant au niveau de la chaîne de confiance que dans les algorithmes de chiffrement. On ajouter des couches de sécurité au fil des idées, des outils et des ...patchs! Comme l’ajout de l’opérateur XOR dans la plupart des algorithmes. Déjà les algorithmes de chiffrement et tout particulièrement de « hachage » utilisent deux transformations majeures. La permutation et la substitution. Un tour ou « round » consiste à effectuer les deux. Plus le nombre de tour est élevé, plus grande sera la sécurité, au prix de la lourdeur et d’une plus grande charge de calcul. Chacun à ça manière, le SHA-1 à la particularité de faire un seul tour et comme l’algorithme MD5 (d’ailleurs déconseillé pour les nouvelles applications) d’être vulnérable à ce qu’on appelle les « collisioons ».

C’est d’ailleurs ce qui distingue le SH1-0 du SHA-1 et du SHA-2. L’ajout de nouvelles couches pour boucher les failles! Par exemple une permutation de bits ou décalage binaire, en gros de la droite ou de la gauche, qui permet de casser certaines caractéristiques linéaires ou signature dans la structure de l’algorithme SHA-0. Voir en exemple la figure 1.0.

Sinon, L’algorithme SHA-1 travail essentiellement sur des bloc de 512 bits et ajoute une permutation de bits de la droite ou de la gauche qui permet de casser certaines caractéristiques linéaires ou signature dans la structure du SHA-0. Une couche intéressante c’est le remplissage de l’algorithme SHA-1 qui ajoute des bits pour obtenir une chaine toujours de la même longeur.

Selon Wikipedia

La pierre de RosetteBritish Museum, Londres

Le SHA-1 est le successeur du SHA-0 qui a été rapidement mis de côté par le NIST pour des raisons de sécurité insuffisante. Le SHA-0 était légitimement soupçonné de contenir des failles qui permettraient d’aboutir rapidement à des collisions (deux documents différents qui génèrent le même condensat). Face à la controverse soulevée par le fonctionnement du SHA-0 et certains constats que l’on attribue à la NSA, le SHA-0 s’est vu modifié peu après sa sortie (1993) et complexifié pour devenir le SHA-1 (1995). Une collision complète sur le SHA-0 a été découverte par Antoine Joux et al. en août 2004 et laisse penser que le SHA-1 pourrait lui aussi subir une attaque.

« L’attaque générique des anniversaires permet de trouver une collision en 2⁸⁰ opérations, ce qui est donc la sécurité attendue pour une telle fonction de hachage. Mais dans le cas de SHA-1, il existe une attaque théorique en 2⁶⁹ connue depuis 2005!, qui a été améliorée en une attaque en 2⁶³ opérations. Ces attaques, bien que théoriques, ouvrent la possibilité que de réelles collisions soient découvertes (ce qui est également une question de temps et de moyens). ...En février 2005, Bruce Schneier a fait état d’une attaque sur la version complète du SHA-1 par l’équipe chinoise de Wang, Yin et Yu. »

À quand le tour du SHA-256 ?

Depuis l’annonce de l’attaque de Wang et al., SHA-1 a tendance à être retiré progressivement, au moins de certaines applications cryptographiques, essentiellement au profit de SHA-256. ...Vu les faiblesses constatées sur SHA-1, et la conception de SHA-2 qui est voisine, une compétition a été organisée par la NIST, afin de trouver un nouveau standard de hachage (SHA-3) comme cela fut le cas il y a quelques années pour la cryptographie symétrique avec AES.

Le SSL sécuritaire, vraiment?

Hum! J’avais déjà des doutes avec le SSL bien avant Julian Assange! L’art de la cryptographie est une affaire d’État au USA! L’importation de technique de chiffrements est carrément illégale aux États-Unis depuis la deuxième guerre mondiale! Je vous laisse sur cette réflexion et cet exemple de type « man in the middle attack (MITM) ».

Certain prétende que cette méthode compromet déjà la sécurité. En simplifiant, si mon certificat serveur a besoin de deux signatures pour l’authentifier, n’importe lequel des 377 certificats racine autorisé par l’ « autorité de certification » peut signer mon certificat et sera accepté sans problème par mon navigateur (peut importe le prix payé d’ailleurs). La chaine de confiance est basée sur une simple liste de « certificat racine » pré-autorisé par l’ « autorité de certification » stocké par le navigateur! L’autorité de certification peut bien nous assurer que les mesures plus plus rigoureuses sont mise en place, il suffit d’un seul malhonnête pour créer un environnement propice aux attaque de type « man in the middle attack (MITM) ». Il suffit d’un tel certificat frauduleux (comme on a déjà vu), combiner à un certificat intermédiaire, pour compromettre l’ensemble des serveurs de la planète qui y ajouterais au bout son certificat serveur. Exactement comme la faille « Heartbleed » de l’OpenSSL (2012) découverte en mars 2014 par Google.

Chaine de confiance