vendredi 05 février
Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Liens connexes

Dépêche modérée par

Dépêche éditée par

: Nouvelles attaques sur SHA-1 : Debian pourrait migrer vers SHA-2

Posté par apterium (). Modéré le 09 mai 2009.
25
La conférence Eurocrypt 2009 qui s'est achevé le 20 avril dernier nous a donné de nouvelles attaques sur la fonction de hachage SHA-1. Trouver une collision ne nécessite maintenant plus que 2^52 opérations, soit quelques semaines de calcul sur un PC standard (voir ce document pdf d'annonce de la nouvelle attaque).

Un plan de migration pour la bien connue distribution GNU/Linux Debian a été proposé, soit une migration de l'ensemble des clefs PGP et GPG de son infrastructure (développeurs compris) vers des clefs plus robustes. Beaucoup de ses clefs font en effet appel aux mécanismes RSA ou DSA, avec des clefs de 1024 bits, ainsi qu'à la fonction de hachage SHA-1, à l'exception notable de la clef primaire de la distribution stable actuelle, Lenny, qui fait 4096 bits (RSA).

Les clefs migreraient donc toutes vers l'algorithme RSA, taille 2048 bits, ainsi que vers les fonctions de hachage de la famille SHA-2 (SHA-224, SHA-256, SHA-384 et SHA-512). Tout l'enjeu de cette migration est de ne pas casser le Web of Trust (chaîne de confiance) déjà existant mais de le faire migrer en douceur.

Plus de détails dans la suite de la dépêche.

> Lire la suite (18 commentaires, moyenne: 6,1).   [dépêche : 3009 caractères]

Concernant la migration
Il s'agit de signer les nouvelles clefs, fortes, avec les anciennes. Ainsi, la confiance déjà existante dans l'infrastructure actuelle se transposera naturellement vers les nouvelles clefs, plus robustes. Une fois que la nouvelle clef est prise en compte partout où nécessaire, on peut alors publier un certificat de révocation de l'ancienne.

À propos des fonctions de hachage et de cryptographie
Une fonction de hachage est une des primitives de base de la cryptographie. Elles servent notamment à tout ce qui est signature et authentification. Pour schématiser, une fonction de hachage prend un gros fichier (typiquement, un paquet logiciel dont on veut certifier la provenance, ou bien une clef GPG d'une personne à qui on donne confiance), et fournit ce qu'on appelle un hash ou condensat de quelques centaines de bits. On signe alors uniquement le hash avec sa clef publique (RSA ou DSA) et non pas le fichier total initial. Comme la signature est une opération longue, on évite ainsi de signer un fichier qui peut être très gros.

La sécurité de la fonction de hachage repose alors sur l'impossibilité pratique de calculer une « collision » - c'est-à-dire de trouver deux fichiers qui ont le même hash - ou pire, une « deuxième pré-image » - c'est-à-dire trouver un deuxième fichier de même hash qu'un fichier donné. Dans l'exemple d'un paquet logiciel, trouver un autre fichier possédant le même hash qu'un paquet signé signifie que ce deuxième fichier sera reconnu comme paquet certifié par le gestionnaire de paquets. Ajoutons qu'une fois trouvé un deuxième fichier de même hash que le paquet initial, il est souvent « aisé » (au moins pour un spécialiste, aidé de quelques machines de calcul :) de le triturer jusqu'à en faire à peu près n'importe quoi (un programme malveillant par exemple). Ce genre d'attaque ouvre alors la voie à l'émission de paquets avec signatures valables sans aucune compromission de l'infrastructure existante : il suffit de créer un faux paquet de même hash qu'un paquet déjà existant (ou ancien) et on peut récupérer la signature de cet ancien paquet pour faire passer le nouveau comme valide.

Un successeur pour la famille SHA-2
Notons par ailleurs que la famille SHA-2 a été construite sur le même principe que la fonction SHA-1. Si aucune attaque n'a encore été trouvée (au moins officiellement :), il n'en demeure pas moins que leur sécurité n'est plus aussi estimée qu'avant. C'est pour cela que le NIST (l'Institut national des standards et de la technologie aux USA) a proposé une compétition internationale pour trouver un successeur à la famille SHA, sur le même modèle que celle qui avait eu lieu pour l'AES. Il est prévu que cette compétition débouche en 2012 sur la nouvelle fonction de hachage SHA-3.

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

Annonce un peu hâtive ?

Posté par Aurélien Jarno (page perso, ) le 09/05/2009 à 11:42. (lien). Évalué à 10.

Je pense que la nouvelle va un peu fort avec un titre comme « Debian migre vers SHA-2 ». Une personne qui n'est pas (encore) Developeur Debian propose un mécanisme de migration, et on en conclu que Debian migre vers SHA-2. Oui, c'est quelque chose qui va se faire tôt ou tard, mais pour le moment rien n'a encore été décidé.

Pas une migration officielle

Posté par Julien Valroff (page perso, ) le 09/05/2009 à 11:43. (lien). Évalué à 10.

Il ne s'agit pas d'une annonce officielle du projet Debian, simplement une (excellente) méthode de migration proposée par un utilisateur du site debian-administration.org

De nombreux développeurs ont déjà annoncé la migration de leur clé personnelle (utilisée notamment pour signer les paquets qui vont atterrir dans l'archive officielle), mais je n'ai vu aucune annonce du projet pour le moment.

@++
Julien

Pas critique

Posté par Aris Adamantiadis (page perso, ) le 09/05/2009 à 11:47. (lien). Évalué à 10.

Attention à ne pas sombrer dans l'hystérie : cette faille est loin d'être critique. Elle permet de fabriquer une paire X et X' qui ont la propriété SHA1(X) = SHA1(X'), mais ne permet pas de choisir X ou X', ce qui fait qu'il serait très difficile d'imiter une signature numérique.

D'ailleurs, cette attaque est connue pour MD5 depuis un bout de temps, et n'a pu être exploitée en situation réelle qu'une seule fois (voir l'attaque sur les certifs SSL).

Bref, il vaut mieux rester avec du SHA-1 que se ruer sur un successeur qui n'a pas encore fait ses preuves. Debian agit prudemment en voulant passer en douceur à une solution plus sécurisée.

J'attendrais aussi d'avoir des preuves un peu plus sérieuses que ce pdf avant de crier au loup (par ex la publication d'une collision)

"Aisé"?

Posté par Grunt () le 09/05/2009 à 11:58. (lien). Évalué à 9.

<<il est souvent « aisé » (au moins pour un spécialiste, aidé de quelques machines de calcul :) de le triturer jusqu'à en faire à peu près n'importe quoi (un programme malveillant par exemple).>>

Là, je tique un peu: un paquet étant donné, il est si "facile" de créer un deuxième paquet avec la même signature, les mêmes fonctions "apparentes" et du code malveillant en plus? ça fait beaucoup de contraintes!

Car même l'utilisateur le plus basique va se rendre compte que quelque chose cloche, s'il installe le paquet "iceweasel" et que le navigateur n'est toujours pas apparu dans ses menus et son PATH.
Reprendre une application existante, et insérer du code malveillant, en gardant la même signature, ça me parait un peu "mission impossible."

Revenir en haut de page

Run by Team LinuxFr.org

Cette page a été générée par Templeet en 0.1072s (dont 0.0157 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !