Mardi

• Erik Tews, “DECT (part II), what has changed in DECT security after one year“. Auteur d’attaques contre WPA/TKIP (voir cet article), Erik Tews faisait le point (avec Karsten Nohl) une année après une présentation faite au 25C3 sur les défauts de sécurité du chiffrement DSC et DSAA utilisés par le standard de communication sans fil DECT (http://www.dedected.org/). Cette année, ils exposent des scénarios d’attaque contre DSC et le DECT Forum a d’ailleurs annoncé par avance un certain nombre d’évolutions à venir dans le standard.
• Andrew Strutt (rodent) et DaBeave, “DDoS/botnet mitigation & hosting online communities“, sur l’impact des Botnets sur les communautés en ligne. En réalité une présentation très concrète sur la façon de sécuriser un serveur de communauté en ligne (forums Web, serveur IRC, etc…) contre les attaques typiques que peuvent créer les botnets et autres sources de problèmes.
• Harald Welte, “Using OpenBSC for fuzzing of GSM handsets“, sur le développement d’OpenBSC, les découvertes sur les difficultés des implémentations des protocoles du GSM et les potentialités en termes d’expérimentation de sécurité.
• Steven J. Murdoch, “Optimised to fail“, sur la sécurité des lecteurs de carte bancaire anglais destinés au commerce ou à la banque en ligne. Il propose un certain nombre de pistes d’amélioration.
• Moti Yung, “Yes we can’t ! On kleptography and cryptovirology“, sur les diverses utilisations des techniques de chiffrement par les logiciels malveillants. Site web sur la cryptovirologie.
• Dan Kaminsky, met en évidence dans sa présentation “Black Ops of PKI” un certain nombre de défauts dans les procédures prévues par le protocole X509 sous-jacent dans la gestion des infrastructures de gestion de clés publiques. Notamment le fait que sur Internet il existe une égalité de fait des autorités de certification, que la délivrance de certificats est le plus souvent basée sur le protocole DNS (très critiqué par Kaminsky), etc. Il passe notamment un certain temps à montrer les problèmes d’implémentation liés à l’encodage ASN.1 utilisé dans les certifications X509 (par Internet Explorer notamment, mais sans préciser la version). Il finit par une promotion appuyée de DNSSEC (par ici, un commentaire d’Ivan Ristić sur cette prestation). Pas très neuf au final, déjà développé par Kaminsky à Black Hat USA 2009, Toorcon, et peut-être à d’autres conférences.

Tout d’abord, à quoi cela sert-il ? Différents algorithmes sont utilisés pour produire des “hachages” sensés représenter de façon unique tout document numérique. Les fonctions de hachage à usage cryptographique doivent posséder différentes caractéristiques :

• la très grande difficulté de retrouver ou de recalculer le document numérique initial ;
• à partir d’un premier document et de sa valeur de hachage, il est très difficile de retrouver un document numérique ayant la même valeur de hachage (en particulier, toute modification, même mineure, du document initial, entraîne une modification très importante de la signature calculée) ;
• il est très difficile de tomber au hasard sur deux documents ayant la même valeur de hachage.

Par document numérique, on entend une suite d’octets de longueur non nulle (un fichier informatique, un flux d’informations numériques, …) Mais, on comprend donc très bien que ces fonctions qui à tout document numérique associent un nombre dont la longueur est donnée, ont forcément un risque de collision non nul. En effet, puisque la variété des documents numériques de toutes tailles est infinie et que l’on cherche à la représenter par une valeur finie, il y a pour chaque valeur de hachage un grand nombre de documents numériques théoriquement possible.

Il existe différentes fonctions de hachage utilisées classiquement: MD5, SHA-1, Tiger,… La longueur des signatures MD5 est de 32 octets ou 128 bits. Dans un certificat utilisé pour identifier un serveur web, cette fonction de hachage est utilisée sur l’ensemble des informations contenues dans le certificat (le nom du serveur, ses dates de validité, etc.) et c’est cette valeur qui est ensuite signée numériquement par une fonction cryptographique. Sur l’image ci-dessous vous pouvez-lire ces différentes informations pour le certificat SSL du site web www.verisign.com :

Plus précisément, ces certificats sont signés par une autorité de certification qui est elle-même reconnue par une autorité de certification “racine”. Ce sont – normalement – les certificats de ces autorités de certification “racines” qui sont pré-installés dans nos navigateurs (il est possible d’en installer volontairement d’autres, en fonction de besoins internes à son entreprise par exemple).

Dès 2004, des chercheurs ont démontré qu’il était possible de fabriquer des documents différents possédant la même signature MD5.  Ce qui a été rapidement très inquiétant c’est qu’il était possible de fabriquer des documents très ressemblants (des PDF par exemple) ayant la même signature, mais dont un élément important était différent (dans l’exemple présent sur ce site : http://www.win.tue.nl/hashclash/Nostradamus/, 12 documents prédisant le résultat de l’élection présidentielle avec des noms différents).

Ce qui est inquiétant aujourd’hui c’est que d’importants prestataires en matière de fourniture de certificats permettant d’identifier des sites web (et d’autres fonctions de signature électronique en fait), autorités de certification reconnues par tous les navigateurs Internet, autorisent encore la fabrication de certificats basés sur des hachages MD5.

De façon assez amusante, mais pas surprenante étant donnée la puissance de calcul des consoles de jeux, les chercheurs qui ont présenté leurs résultats au 25C3 ont utilisé des batteries de consoles Sony Playstation 3. Ils ont ainsi démontré qu’il était possible de fabriquer, pour un coût assez raisonnable un certificat pour une autorité de certification “pourrie”. Cette autorité de certification leur permet de fabriquer des certificats reconnus par la plupart des navigateurs Internet.

Quelle réponse apporter ?

Les auteurs de cette démonstration donnent un certain nombre de recommandations :

• ils confirment tout d’abord que les autorités de certification identifiées comme utilisant encore des fonctions MD5 ont été prévenues et sont en train de prendre des mesures immédiates (voir par exemple l’annonce de Verisign) ;
• ne plus utiliser MD5 dans des fonctions de signature, et éviter sur de nouveaux projets d’utiliser SHA-1 (en effet, il existe différents indices montrant que SHA-1 devrait rencontrer le même sort assez rapidement…).

On peut aussi souhaiter que la profession d’autorité de certification soit un peu mieux réglementée. En effet, différentes publications ont montré récemment qu’il était possible, dans certaines conditions, d’obtenir un certificat pour un nom de domaine dont on n’est pas propriétaire…

Pourquoi est-ce que tout cela est important ? Ce n’est pas tant le risque que votre communication soit interceptée, mais surtout que vous ayez confiance dans l’identité du serveur auquel vous vous connectez.

Mais que peut faire l’utilisateur individuel en pratique ? Peut-être faire confiance aux sociétés émettrices de certificats, qui grâce au système des listes de révocation vont rapidement débarrasser l’Internet de ces certificats malhonnêtes (note du 06 janvier 22:20, encore qu’il semble qu’ils ne soient pas décidés à utiliser la révocation, pour éviter de léser leurs clients). Mais pour les applications les plus importantes (votre banque par exemple), vous pouvez jeter un coup d’œil à l’algorithme utilisé pour la signature. Voici la marche à suivre :

Sous Mozilla, par exemple, une fois connecté sur le site de ma banque, je double clique sur le cadenas de sécurité ce qui me permet d’afficher le certificat utilisé (semblable à l’image d’illustration utilisée plus haut) et je demande ensuite à afficher les détails de ce certificat. Dans la liste des caractéristiques, je retrouve un champ intitulé : “Algorithme de signature des certificats” (sous Internet Explorer, on retrouve “Algorithme de signature”). Dans mon cas cela affiche : “PKCS #1 SHA-1 avec chiffrement RSA”. Pas de MD5 ici !