Journal Fichiers de signature des distributions

Posté par  .
Étiquettes : aucune
-6
6
nov.
2010
Bonjour,
il s'agit ici de discuter d'authentification et de contrôle d'intégrité des fichiers .ISO des OS que l'on télécharge pour installation.

Je recycle en le synthétisant, un échange qui s'est tenu dans le fil des commentaires à l'occasion de la sortie de DragonFly BSD 2.8.2 : http://linuxfr.org/2010/11/03/27537.html
Les questions soulevées sont loin d'avoir trouver des réponses satisfaisantes.

Voilà, lorsqu'on télécharge un fichier .ISO d'un programme (comme un système d'exploitation), on dispose normalement d'une signature de contrôle d'intégrité, sur une page Web du site original notamment. Charge à l'utilisateur de vérifier que cette signature est la même que celle qu'il reproduit chez lui, par application du même calcul (de la signature) à partir du fichier .ISO reçu.


1) Je mets en cause l'usage des signatures MD5 qui se perpétue.

En considérant un petit panel d'OS comme les distributions GNU/Linux Slitaz et Salix (observation faite il y a quelques mois) ainsi que DragonFly BSD il y a quelques jours, j'observe que les fichiers de signature fournis sont au format MD5.

Pourquoi fournir des signatures MD5 alors qu'il est connu qu'il est possible de provoquer des collisions de signatures avec cet algorithme. Précisément, il est possible de fabriquer un contenu qui aura la même signature qu'un contenu de référence (on récupère un .ISO corrompu mais le contrôle est bon). Cf par exemple : http://www.win.tue.nl/hashclash/Nostradamus/ ...Les tailles des fichiers ne sont pas les mêmes mais le protocole de contrôle d'intégrité des fichiers téléchargés n'implique pas de vérifier nécessairement la taille du fichier reçu...

Tant qu'à faire le travail de mise en oeuvre de la sécurité, autant le faire solidement, sinon c'est carrément ridicule parce qu'improductif ou même risqué (croyance illusoire de sécurité). L'usage abusif du MD5 démontre à mon avis l'insouciance des équipes concernées.

Lorsque je considère ce que propose Debian, je vois du MD5 (pourquoi est-ce encore utilisé ?) mais aussi du SHA1, SHA256 et SHA512 (par exemple, miroir officiel ici : ftp://ftp.proxad.net/mirrors/cdimage.debian.org/debian-cd/5.(...) ). On y trouve aussi un fichier de signature PGP (par "GnuPG v1.4.10 (GNU/Linux)") pour chaque fichier de signature MD5|SHA1|... de manière à authentifier le contenu des fichiers concernés.

2) je questionne le protocole proposé par Debian

a) la problématique adressée par le protocole de Debian

En prenant soin d'écarter MD5, il reste qu'il faut une authentification de la source qui propose la "signature de contrôle d'intégrité" (le fichier SHA1|256|512) et un contrôle d'intégrité sur cette signature.

Pour mettre en évidence la problématique du contrôle d'intégrité des fichiers de signature SHAx, imaginons que sur la page web du site, il y ait une signature SHAx, mais qu'elle soit changée le temps que l'information arrive chez l'utilisateur. À un point quelconque du chemin (un routeur... Un fournisseur d'accès à Internet par exemple), elle pourrait être changée pour être conforme au fichier .ISO qui est reçu... L'utilisateur ne verrait que du feu lors de la vérification de la signature SHAx.

b) une solution hypothétique

Pour éviter les problèmes, on peut envisager que la page HTML sur laquelle se trouve la signature SHAx, ou le FTP sur lequel on prend le fichier qui contient cette signature, soient accédés en mode "sécurisé" (pour une page web, une adresse en https). Est-ce nécessaire et suffisant ? Pas sûr... Avec un certificat auto-signé (généré gratuitement par n'importe qui voulant utliser le https), sans tier de confiance impliqué, comment être garanti de l'authenticité de la source ? Pour avoir un tier de confiance, il faut payer (et quelle confiance accorder à un tier officiel, de nos jours ?).

c) la solution Debian

La solution que propose Debian, avec ses fichiers de signature PGP, a pour vocation de répondre à la double problématique de l'authentification de la source et du contrôle d'intégrité des signatures (...de contrôle d'intégrité des fichier .ISO), quel que soit leur lieu de stockage, sans nécessité d'utiliser un protocole chiffré avec authentification du serveur. Par exemple, on trouve le fichier de signature "SHA256SUMS" et le fichier de signature PGP associé "SHA256SUMS.sign". Ces fichiers .sign doivent permettre de réaliser les deux fonctions a) d'authentification et b) de contrôle d'intégrité des signatures MD5|SHAx. Je n'ai pas encore vérifié ces supputations, je n'ai pas encore eu l'occasion de télécharger et de mettre en oeuvre les .ISO de Debian. J'invite les connaisseurs à se manifester.

d) deux questions vitales

Voici deux questions complémentaires importantes, pour qui a mit en oeuvre GPG pour exploiter les données des .sign de Debian : comment obtient-on la certitude que l'on récupère bien des .ISO mis à disposition par le projet Debian ? Le .sign est produit par une clé privée, déchiffrable avec la clé publique correspondante. Comment l'utilisateur final peut s'assurer de l'identité du (des) détenteurs de la clé privée ? Et si la certitude de l'identité du détenteur légitime de la clé privé est obtenue, comment être certain qu'il n'y a pas eu de fuite de la clé privée (ce qui casserait toute la politique de sécurité) ?

e) une proposition complémentaire pour éviter un écueil de sécurité

Idéalement, je considère qu'il faudrait une signature PGP réalisée par chacun des membres d'une portion (élue) de la communauté concernée (Debian dans l'exemple). Ainsi, en cas de fuite d'une des clés privées, impossible de reconstituer l'ensemble des signatures valides, à moins d'avoir obtenu l'ensemble des clés privées utilisées !

f) simplification envisagée : conserver uniquement des fichiers de signature PGP.

En réfléchissant plus avant, je note que si les .sign précités réalisent bien les deux fonctions que je mentionne, je ne vois pas ce qui empêche de simplifier le processus en proposant uniquement des .sign qui authentifieraient les .ISO tout en permettant d'en contrôler l'intégrité. Est-ce une question de simplicité des algo SHAx qui encourage leur usage, du fait d'un temps de calcul minimisé par rapport aux signatures PGP produites par GPG ?

A qui le tour ?
  • # Collisions et préimages

    Posté par  (site Web personnel) . Évalué à 10.

    > Pourquoi fournir des signatures MD5 alors qu'il est connu qu'il est possible de provoquer des collisions de signatures avec cet algorithme

    Le fait d'avoir des collisions veut dire que l'on peut créer deux fichiers qui ont la même empreinte. Ca ne veut pas dire que l'on peut à partir d'un fichier donner en trouver un autre qui a la même empreinte (c'est le problème de la "seconde préimage").

    <mode cuistre>
    Sinon, si GPG peut fournir des signatures, MD5 et les SHA fournissent des empreintes. Ce n'est pas pareil.
    </mode cuistre>
    • [^] # Re: Collisions et préimages

      Posté par  (site Web personnel) . Évalué à 2.

      Arrghhh!
      s/donner/donné/
    • [^] # Re: Collisions et préimages

      Posté par  (site Web personnel) . Évalué à 4.

      « Préimage » ? Est-ce un mot étrange pour parler d'un antécédent par une fonction ?
    • [^] # Re: Collisions et préimages

      Posté par  . Évalué à 2.

      Ca ne veut pas dire que l'on peut à partir d'un fichier donner en trouver un autre qui a la même empreinte

      Même avec du code de bourrage ? C'est ce qui était évoqué sur le fil de commentaires sur DragonFly BSD.

      <mode cuistre> (...)

      si GPG peut générer une signature authentifiant un fichier à partir d'une clé privée, je suppose qu'il permet également de contrôler un minimum l'intégrité du fichier par une forme d'empreinte... Non ? Sans quoi il est facile de proposer un .ISO et son MD5|SHAx trafiqués et d'y associer une signature PGP produite par ailleurs par la bonne clé privée...

      Désolé de réfléchir...
      • [^] # Re: Collisions et préimages

        Posté par  (site Web personnel) . Évalué à 3.

        si GPG peut générer une signature authentifiant un fichier à partir d'une clé privée, je suppose qu'il permet également de contrôler un minimum l'intégrité du fichier par une forme d'empreinte... Non ?

        Eh bien oui, évidemment. Par définition, la signature permet de vérifier l'intégrité, sinon elle n'a aucun sens : vérifier qu'un document a été signé par une clef donnée sans vérifier s'il est intact, ça ne veut rien dire du tout.
        • [^] # Re: Collisions et préimages

          Posté par  . Évalué à 1.

          Maintenant qu'il est entendu qu'une signature PGP permet de vérifier l'intégrité du contenu authentifié, et puisque par ailleurs je peux témoigner (cf plus bas) que depuis au moins 10 ans on dispose, y compris sous Windows, d'une implémentation de PGP, qu'est-ce qui retient Debian d'appliquer le point f) que j'ai mentionné ?
          Et tant qu'à faire, je propose que soit appliqué le e) et que soit mis en place un petit script qui enchaine les vérifications des signatures ! (1)

          (1) là, je confesse que ça va plus... S'il faut signer tout un fichier ISO plusieurs fois, c'est beaucoup de calcul, y compris sur le poste de l'utilisateur pour la phase de vérification. On peut donc garder les empreintes SHAx et les faire signer par un ensemble de contributeurs Debian élus (ré-élus régulièrement, il ne s'agit pas de laisser à cette "élite" l'occasion de se faire corrompre sur le long terme, par exemple), ça évitera le risque de perte/vol/abus d'une unique clé privée, remettant en cause tout l'édifice sécurisé.
          • [^] # Re: Collisions et préimages

            Posté par  (site Web personnel) . Évalué à 6.

            Il faut plusieurs personnes pour révoquer la clé et avoir la clé publique, c'est expliqué sur la page http://ftp-master.debian.org/keys.html expliquant le fonctionnement des clés.

            Ensuite c'est plus court de faire une signature GPG qu'un sha512sum (dépend de l'algo de hash utilisé par GPG, mais par défaut c'est SHA1, si mes souvenirs sont exactes). Mais le vrai problème est : il faut réunir plusieurs personnes, est-il plus facile de les réunir pour signer un millier de petit fichier texte prenant au total quelque minute à être signé ou une grande quantité de données prenant l'ordre de plusieurs heures ?

            Donc il génère, durant plusieurs heures, plein de petits fichiers qui seront signés rapidement par les personnes nécessaires.

            Chaque année les clés sont changées.

            Bref, je trouve que tu aurais dû un peu te documenter avant de remettre en cause le fonctionnement de Debian.

            "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

    • [^] # Re: Collisions et préimages

      Posté par  . Évalué à 7.

      de toute façon cette histoire de collisions c'est de la branlette de chinchilla.

      colle une autre somme de controle à coté, obtenue par une autre méthode de calcul de CRC, et tu auras un peu beaucoup du mal à faire des collisions sur les deux en même temps
      • [^] # Re: Collisions et préimages

        Posté par  . Évalué à 3.

        C'est vrai, mais pas exact :-)

        D'un point de vue strictement théorique, additionner deux algorithmes qui produisent des empreintes de 512 bits ne donne qu'une sécurité équivalente à 513 bits (si les deux algos sont de résistance équivalente). Ceci dans le cas d'algorithmes non cassés.

        Dans le cas où l'un des deux est cassé, ou partiellement, le second algorithme permet de conserver la résistance initiale.

        Dans le cas où le second est cassé également, il faudrait trouver la méthode pour réduire les calculs de manière simultanée pour ce couple précis.

        Le mieux reste d'utiliser un algo non cassé. http://fr.wikipedia.org/wiki/Truisme
  • # Réponses

    Posté par  (site Web personnel) . Évalué à 8.

    2.d) deux questions vitales

    Comment l'utilisateur final peut s'assurer de l'identité du (des) détenteurs de la clé privée ?

    S'il ne fait pas partie de la toile de confiance PGP, il ne peut pas. C'est comme ça, quand on n'a pas rencontré quelqu'un, ou rencontré des gens qui l'ont rencontré, eh bien on n'en sait rien, si la clef en question est bien à lui. C'est imparable, et insoluble sans une hiérarchie ou une toile de confiance.

    t si la certitude de l'identité du détenteur légitime de la clé privé est obtenue, comment être certain qu'il n'y a pas eu de fuite de la clé privée (ce qui casserait toute la politique de sécurité) ?

    On ne peut pas. C'est aussi un problème imparable de la cryptographie : même si on est sûr qu'Alice affirme que la clef A est bien à sa seule disposition, on ne sait pas si c'est vrai. Elle a pu la perdre, se la faire voler ou se la faire copier par un méchant.

    L'utilisation de chiffrement ne garantit pas que seul le correspondant légitime peut lire les informations. L'utilisation de signature ne garantit pas que les informations ont bien été rédigées par le correspondant légitime. Tout ce que ces mécanismes garantissent, c'est que si ce n'est pas le cas, c'est sa faute.
    • [^] # Re: Réponses

      Posté par  (site Web personnel) . Évalué à 1.

      2.f) simplification envisagée : conserver uniquement des fichiers de signature PGP.

      je ne vois pas ce qui empêche de simplifier le processus en proposant uniquement des .sign qui authentifieraient les .ISO tout en permettant d'en contrôler l'intégrité

      Les gens sous Windows. Peuvent pas vérifier simplement une signature PGP. Une somme MD5, SHA1 ou SHA2 non plus, ceci dit, mais PGP encore moins…
      • [^] # Re: Réponses

        Posté par  . Évalué à 2.

        Il y a dix ans, il m'est arrivé de chiffrer des données par PGP sous Windows 2000 (avec la clé publique de mon correspondant - je n'utilisais pas la fonction d'authentification en utilisant ma clé privée, mais la fonction était aussi disponible).
      • [^] # Re: Réponses

        Posté par  . Évalué à 3.

        Je me souviens que sous Windows j'utilisais des « .sfv », et il y avait plein d'outils pour ça. Ça a l'air d'être pire que MD5 niveau collisions, mais le but n'est pas d'être sécurisé, juste de détecter une corruption involontaire.

        DLFP >> PCInpact > Numerama >> LinuxFr.org

        • [^] # Re: Réponses

          Posté par  (site Web personnel) . Évalué à 0.

          Plein d'outils, bien sûr. Mais pas intégrés d'office, donc pas évident à utiliser : pour les utiliser, il faut le vouloir.

          Sous un système libre, graver une image ISO, vérifier une somme SHA1, imprimer dans un PDF, c'est trozimple. Sous Windows, ne sont trozimples que les fonctions prévues par Microsoft, après tout…
          • [^] # Re: Réponses

            Posté par  . Évalué à 4.

            sérieux ? hohohohahahaha !

            L'outils PGP que j'ai manipulé en 2000, c'était à la souris, intuitif. Il m'a fallu l'installer, c'est vrai.

            Les outils que j'ai manipulé depuis 3 ans pour vérifier les sommes de contrôle MD5 et SHA sous Linux, ils étaient fournis mais il m'a fallu ouvrir la console, ouvrir le manuel et identifier les bon paramètres à fournir... Pour arriver à ça, je te raconte pas la courbe d'apprentissage pour le pékin moyen :-)
            • [^] # Re: Réponses

              Posté par  (site Web personnel) . Évalué à 3.

              Ben si tu dois ouvrir le manuel pour utiliser sha1sum… Sa syntaxe est évidente : sha1sum fichier. Ou sha1sum tout court pour calculer la somme de l'entrée standard.
          • [^] # Re: Réponses

            Posté par  . Évalué à 8.

            tu te moques de qui ?

            sur une des plateformes, c'est simple, en ligne de commande ou avec une GUI, mais juste il faut vouloir le faire

            sur l'autre... ah merde, c'est exactement pareil !

            le problème c'est pas la plateforme, c'est toujours cette grosse conne de madame Michu et de son crétin de rejeton Jean-Kevin qui feront tout et n'importe quoi et ne voudront jamais consacrer 15 secondes à réfléchir à ce genre de détails chiants qui prennent du temps de cerveau à vérifier.

            ces gens-là, typiquement, je leur explique une paire de fois, ensuite ils s'élèvent ou ils restent dans leur fange numérique.
            • [^] # Re: Réponses

              Posté par  (site Web personnel) . Évalué à 0.

              sur l'autre... ah merde, c'est exactement pareil !

              Non. Sur l'une il faut :
              1. lancer un logiciel.

              autre il faut :
              1. chercher un logiciel qui le fasse ;
              2. installer ce logiciel ;
              3. lancer ce logiciel.
              • [^] # Re: Réponses

                Posté par  (site Web personnel) . Évalué à 1.

                Sous linux aussi il faut installer (ou au moins chercher le nom du soft) et lancer le logiciel.
                • [^] # Re: Réponses

                  Posté par  (site Web personnel) . Évalué à 3.

                  Ça fait partie des GNU coreutils. Donc bon…
                  • [^] # Re: Réponses

                    Posté par  (site Web personnel) . Évalué à 3.

                    et tu connais le nom et l'utilité de tout les gnu coreutils ?

                    parce qu'un mec qui est capable d'aller telecharger et installer un autre OS depuis son windows, il est capable de telecharger et installer un outils de verification de hash depuis son windows.
                  • [^] # Re: Réponses

                    Posté par  . Évalué à 3.

                    C'est quoi la commande qui fait partie des GNU coreutils pour imprimer dans un pdf ?

                    Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

              • [^] # Re: Réponses

                Posté par  . Évalué à 4.

                foutaises, c'est juste que ta distribution classique de base a ce logiciel de présent presque à coup sûr.

                sauf que sur plein de distributions, ou en cas d'installation minimale, ca sera pas le cas (au pif, Slackware)
    • [^] # Re: Réponses

      Posté par  . Évalué à 1.

      Je te décerne le trophée de la pédagogie lumineuse. Oublie ton trophée n-1 :-)
      • [^] # Re: Réponses

        Posté par  . Évalué à 7.

        À quoi ressemble ce trophée lumineux ? Une ampoule incandescente, fluocompacte, ou à LED ?

        DLFP >> PCInpact > Numerama >> LinuxFr.org

  • # ...

    Posté par  . Évalué à 10.

    f) simplification envisagée : conserver uniquement des fichiers de signature PGP.
    Je pense que tu n'as pas compris l'utiliser des hash.

    Leur but c'est de détecter une corruption du fichier lors du téléchargement, pas de signer le fichier.

    La crypto pgp par contre permet de signer les fichiers, mais c'est beaucoup plus lourd : il faut que tu ai les clefs publiques de l'emetteur et que tu leur fasse confiance.
    Et vu que la plupart du temps tu connais pas l’émetteur, ça revient à faire confiance a la première signature (clef publique) que tu vois.

    En fait c'est le meme pb que les certificats ssl.
    • [^] # Re: ...

      Posté par  . Évalué à 4.

      Exactement,

      C'est d’ailleurs très utile, il m'est déjà arrivé de cracher sur une distribution qui ne voulait pas s'installer, pour au final me rendre compte que l'image télécharger était corrompue.

      Donc vue le but recherché, je pense que MD5 suffit largement, la probabilité d'avoir une image corrompue qui donne la même clé doit tendre vers zéro.
      • [^] # Re: ...

        Posté par  . Évalué à -2.

        C'est un complot ?

        Je vais conclure avec tout le monde que MD5 c'est la fête, je serai malhonnête mais dans le confort du con sensus.
        • [^] # Re: ...

          Posté par  . Évalué à 5.

          Encore une fois, je pense que tu n'as pas compris à quoi sert le MD5.

          C'est juste pour s'assurer que la communication du fichier s'est bien établie. Rien d'autre. Il n'a jamais été question de garantir la source du fichier.

          En mettant un fichier sur ma page, ainsi que sa signature MD5 (oui, signature c'est totalement abusif, mais je n'ai jamais vu "son hash MD5"), je permets à ceux qui vont télécharger ce fichier de s'assurer qu'il n'y a pas eu de merdouilles pendant le téléchargement.

          Alors certes, on peut imaginer 2 fichiers différents ayant le même MD5, et donc que une erreur de transmission du premier fichier donne le 2nd fichier, avec donc la même signature.

          Mais la différence entre les 2 fichiers sera telle qu'elle ne correspond en rien à la probabilité que ça arrive concrêtement (en fonction de la fiabilité du médium).

          En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

        • [^] # Re: ...

          Posté par  (site Web personnel) . Évalué à 7.

          Je vais conclure avec tout le monde que MD5 c'est la fête, je serai malhonnête mais dans le confort du con sensus.
          (la mise en gras est de moi)
          C'est tellement plus simple d'insulter les autres ou de se faire victime de la majorité plutôt que d'accepter d'avoir tord.
          • [^] # Re: ...

            Posté par  . Évalué à 4.

            >>> accepter d'avoir tord

            accepte d'avoir tort ou prosterne-toi
  • # Question

    Posté par  . Évalué à 2.

    Générer une collision c'est bien mais encore faut il qu'elle soit utilisable. Il est facile de générer une image iso qui quand on bout dessus va formater le disque de manière silencieuse ou un truc du genre ?

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Question

      Posté par  . Évalué à 2.

      Plus près de toi et moins dramatique, pourquoi ne pas envisager une ISO de Squeeze presque parfaite, mais avec un OpenSSH corrompu (lol dans ma barbe) et le code de bourrage qui va bien pour obtenir la bonne signature MD5 ?
      • [^] # Re: Question

        Posté par  . Évalué à 2.

        Très pertinent je n'avais pas vu le problème dans ce sens là (intégrer des logiciels vérolés dans une iso "normale").

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Question

          Posté par  . Évalué à 7.

          Oui enfin si tu es capable de remplacer l'iso sur le site de téléchargement, autant en profiter pour remplacer aussi le MD5. C'est un peu plus facile que de faire une collision...
          • [^] # Re: Question

            Posté par  . Évalué à 2.

            pas faux, mais ça pourrait également être un iso vérolé disponible sur un miroir, sur un site de p2p ou un ftp quelconque. En se référant au md5 du site officiel, on pourrait croire que c'est le même iso. Ce n'est sans doute pas trivial à générer ce type d'iso, mais peut-être pas impossible (avec l'idée de bourrage de données pour obtenir le bon md5).

            Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

  • # http/ftp

    Posté par  . Évalué à 2.

    Pourquoi déjà ne pas commencer par utiliser des moyens de téléchargement plus sûr tel que jigdo ou bitorrent ?

    Si le problème est toujours d'identifier le premier fichier, une fois fait tu n'a plus à te soucier d'une attaque type man in the middle ou du moins ça la complexifie (il faut que le "man" soit entre toi et l'ensemble des sources).

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: http/ftp

      Posté par  (site Web personnel) . Évalué à 1.

      Dans le cas de BitTorrent, il suffit que le "man" contrôle le tracker pour te fournir une liste de pairs complices.

      Ça devient nettement plus technique une fois qu'on utilise une table de hashage distribuée (DHT). Mais si l'on suppose que l'attaquant contrôle le serveur HTTP, il n'a qu'à mettre un lien vers un fichier BitTorrent vérolé et le problème est le même. Non, je ne crois pas que ça résolve quoi que ce soit en fait...
    • [^] # Re: http/ftp

      Posté par  . Évalué à 10.

      je trouve le terme de "man in the middle" très sexiste car il implique que nos amiEs ne sauraient faire de même.

      (bon déjà il faudrait qu'elles arrivent à brancher correctement leur ordinateur et ne pas se ruer tout de suite sur Facebook, mais bref...)
      • [^] # Re: http/ftp

        Posté par  . Évalué à 9.

        Pourtant je connais plein de fille qui aime être "in the middle"
      • [^] # Re: http/ftp

        Posté par  . Évalué à 2.

        C'est toi qui a l'esprit sexiste ça peu juste signifier juste qu'elles ne s'abaissent pas à ce genre de pratique.

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: http/ftp

          Posté par  . Évalué à 4.

          C'est sexiste aussi comme raisonnement.

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: http/ftp

        Posté par  . Évalué à 2.

        Pourtant le personnage classique qui cherche à intercepter le message entre Alice et Bob, c'est Eve, l'ex de Bob. Ça veut donc dire qu'elles savent chiffrer et décrypter ;)
  • # Vérification depuis le navigateur

    Posté par  . Évalué à 3.

    J'ai vu que Pypi ajoute un hash md5 (après un #) dans les URLs des fichiers à télécharger. On peut discuter de l'utilisation de md5, mais je trouve l'idée plutôt intéressante. Malheureusement je ne crois pas qu'il existe de browser qui le supporte.

    DLFP >> PCInpact > Numerama >> LinuxFr.org

    • [^] # Re: Vérification depuis le navigateur

      Posté par  . Évalué à 3.

      Il y a aussi l'entête "Content MD5" qui peut être renvoyée par le serveur, et qui contient la somme MD5 du contenu en base 64.
      Cela dit, je ne sais pas non plus comment se comportent les navigateurs en cas de somme incorrecte, ni même s'ils prennent la peine de le vérifier.

      --
      Unk
  • # Contexte et utilisation de MD5

    Posté par  (site Web personnel) . Évalué à 5.

    Oui MD5 est vulnérable aux attaques en seconde pré-image mais ce n'est pas nécessairement un problème. Si je suis en mesure de modifier une ISO sur le serveur alors il est fort probable que je puisse modifier le fichier contenant l'empreinte ; dans ce cas, peu importe qu'il soit en MD5, SHA1 ou SHA512.

    Le contrôle d'intégrité, comme son nom l'indique, sert à vérifier l'intégrité d'un fichier, que ce que j'ai téléchargé correspond bien à ce qu'il avait sur le serveur. Mais si on veut vérifier intégrité et authenticité alors il faut mettre en place une signature cryptographique (GPG, CMS ou autre)
    • [^] # Re: Contexte et utilisation de MD5

      Posté par  . Évalué à -5.

      Ton propos me laisse un arrière goût de lecture talmudique...

      Comment défendre l'usage de MD5 ? En citant un cas d'usage où on ne perd rien à l'utiliser par rapport à des solutions sérieuses... Donc, en effet, MD5 est vulnérable, mais ce n'est pas nécessairement un problème. Maintenant, tu peux proposer au moins un cas où on perd quelque chose... L'homme du milieu (man in the middle), un méchant qui trafique le contenu que tu télécharges en te laissant croire (après vérification dans la console avec md5sum) que ce contenu est intègre, du fait d'une "attaque en seconde pré-image" (formule indéchiffrable pour le péquin moyen qui en l'espèce signifie risque de tromperie sur la marchandise) ? Tu dois pouvoir trouver d'autres exemples, je te laisse chercher.

      Chacun pourra observer que ton commentaire vaut 4 points en positif quand mon journal a pris 3 points en négatif.

      Après, je ne m'étonnerai pas de voir des signatures MD5... Non plus que les français puissent élire à nouveau Sarko en 2012 (misère) !
      • [^] # Re: Contexte et utilisation de MD5

        Posté par  (site Web personnel) . Évalué à 4.

        L'homme du milieu (man in the middle), un méchant qui trafique le contenu que tu télécharges en te laissant croire (après vérification dans la console avec md5sum) que ce contenu est intègre,

        Tu insiste dans l'erreur...
        Qu'on remplace MD5 par SHA-8 avec 1000000 bits pour la taille de la clé ne changera rien a Man in the Middle : si je suis capable de changer l'ISO que tu télécharge, je suis capable de changer sa signature aussi.

        Répète après moi : la signature MD5 est faite pour vérifier l'intégrité d'un fichier, et elle rempli très bien son rôle. Rien de plus.
        On ne vérifie pas l'identité ou autre, ce n'est pas fait pour ça.
        De toutes manière, si ton lien entre toi et le site de la distro est troué, t'es mal, c'est tout. Reste alors SSL et compagnie, mais c'est une problématique différente, lien de confiance etc... Pour les distro, on part du principe que ton install est propre pour le moment, avec les clés qui vont bien pour faire les updates. Si tu veux travailler sur l'intégrité d'un download, libre à toi de mettres les ISO sur un serveur SSL (et de payer la charge de chiffrement) et de faire accepter ta clé en tant que clé "sûre" par le plus de monde possible. D'autres n'éprouvent pas le besoin pour le moment.

        Chacun pourra observer que ton commentaire vaut 4 points en positif quand mon journal a pris 3 points en négatif

        Normal, tu t'obstines dans l'erreur rien que sur le but des gens qui filent le hash MD5. Mauvais diagnostic, mauvaise solution proposée.
    • [^] # Re: Contexte et utilisation de MD5

      Posté par  . Évalué à 3.

      MD5 n'est PAS (en pratique) vulnérables aux attaques en seconde préimage, mais vulnérable aux _collisions_.
      Ce qui est clairement différent : les collisions permettent à une personne de générer 2 fichiers ayant le même MD5, par contre générer un autre fichier ayant le même MD5 qu'un fichier existant, on ne sait pas faire.

      Petite information supplémentaire, SHA-1 est considéré comme devant être abandonné. L'ANSSI recommande (et impose, dans certains cas), l'utilisation de fonctions de hachage ayant une sortie de 256 bits : http://www.ssi.gouv.fr/IMG/pdf/RGS_B_1.pdf
      • [^] # Re: Contexte et utilisation de MD5

        Posté par  . Évalué à 0.

        hey, cowboy, t'es un dur... Tu casses des rêves.
        Je voyais déjà un avenir rose sans MD5...
        Je rêvais d'unité dans l'usage de SHA...

        Mais voilà que paf, le chien...

        Ce que je souhaite : que des mathématiciens libristes prennent la peine de vérifier toutes ces conneries et pondent un document lisible qui sera audité par des gens signant numériquement leur audit. Je suis sérieux.

        D'abord, quand on creuse, on découvre que SHA a été pondu par la NSA (National Security Agency), maintenant, on voit que des services du gouvernement français relaient des recommandations sur l'abandon de SHA.

        Tout ça ne m'inspire aucune confiance.

        Donc, je reprends, ici comme ailleurs : montons en compétence, auditons nous-même et signons nos audits. On pourra commencer à y voir clair.
        • [^] # Re: Contexte et utilisation de MD5

          Posté par  . Évalué à 1.

          Il a dit SHA-1 (qui en plus d'être trop faible, a une faille de sécurité). Les variantes de SHA-2 sont encore bonnes.

          Il y a actuellement un concours entre tout un tas de fonctions de hashage pour déterminer la meilleure et en faire SHA-3.
        • [^] # Re: Contexte et utilisation de MD5

          Posté par  . Évalué à 2.

          comme indiqué plus haut, OSEF des possibilités de collisions au sens pouvoir modifier une .iso en mettant ce que tu veux dedans, plus un peu de padding, pour retomber sur la même somme de contrôle.

          parce qu'on peut mettre une deuxieme somme de contrôle à côté et tu devras te lever tôt (très tôt) pour baiser les deux.

          c'est pas ça le vrai problème.

          le vrai problème c'est euh moi qui monterait un mirroir officieux de telle ou telle distribution, sur un site à bonne bande passante pour qu'on vienne même si on me connait pas plus que ça chez les faiseurs de la distrib, et que j'affiche mes fausses isos trafiquées avec ma somme de controle à moi à coté, sur la même page, à coté du lien de téléchargement

          si besoin, je rajoute du contenu à la con, je la francise un poil ou je mets deux fonds d'écran, hop ca fait une nouvelle iso qui semble légitime

          question de confiance, donc, et vive PGP

          (genre les mirroirs proposés par les hébergeurs, ce que je dis est très facile)
      • [^] # Re: Contexte et utilisation de MD5

        Posté par  (site Web personnel) . Évalué à 1.

        MD5 n'est PAS (en pratique) vulnérables aux attaques en seconde préimage, mais vulnérable aux _collisions_.

        Arf, tu as totalement raison, merci de me corriger quand je dis ce genre de bêtise :-) Ca m'apprendra à relire en diagonale.

        En ce qui concerne SHA1 il existe des attaques théoriques mais il est encore très utilisé ne serait-ce que parce qu'il existe encore beaucoup de matériels qui ne supporte que SHA1 (cartes à puces...). Les administrations ont d'ailleurs un temps d'adaptation pour appliquer le RGS.

        La bonne nouvelle c'est que la famille SHA2 résiste mieux que prévu. On pensait après la publication des attaques sur SHA1 que SHA2 suivrait assez vite. Toutefois on peut aussi penser que cette résistance est due au fait qu'aujourd'hui les spécialistes du domaines travaillent plutôt sur les algorithmes candidats au concours SHA3 que sur la cryptanalyse de SHA2.

        http://csrc.nist.gov/groups/ST/hash/sha-3/index.html
        • [^] # Re: Contexte et utilisation de MD5

          Posté par  . Évalué à 2.

          Pourtant il doit être utile de cryptanalyser SHA2 pour améliorer SHA3, non ?

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Contexte et utilisation de MD5

            Posté par  . Évalué à 2.

            Il n'y a pas forcément de parenté conceptuelle entre SHA-n et SHA-(n + 1). En pratique, SHA-1 et SHA-2 sont liés, mais les algorithmes en lice pour SHA-3 sont très divers et viennent de gens n'ayant aucun rapport avec la NSA.
  • # synthèses, réponses et relances

    Posté par  . Évalué à -3.

    A)
    Déjà, merci Etienne Bagnoud. Je confesse publiquement : j'attendais cet éclairage sans chercher par moi-même. Et merci aux autres contributeurs :-)
    A partir du lien proposé [ http://ftp-master.debian.org/keys.html ] je découvre le détail de la pratique chez Debian, la mise à disposition systématique d'une signature authentifiante (si j'ai bien compris : une signature unique générée par deux clé (ha!) pour les versions stables de Debian, l'une des clés privée étant annuellement changée).

    Pour synthétiser cette page en traduisant (sauf expression dédiée - la numérotation en 8 points est de mon fait), ponctuée de mes gémissements (3 commentaires, en italique, derrière "//" ou entre "/*" et "*/"), on trouve :

    1) des informations pour lesquelles il est conseillé de ne pas faire confiance et d'utiliser d'autres moyens pour les vérifier.
    // Je trouve que c'est sage et je demande comment vérifier ces informations.

    2) les distributions stables sont signées par deux clés :
    a) "ftp-master automatic archive signing key in use at the time of the release"
    b) "a per-release stable key"

    3) les autres (proposed-updates, testing, testing-proposed-updates, unstable et experimental - ainsi que "security archive") sont signées par "ftp-master automatic key" uniquement.

    4) les "ftp-master automatic key" sont données dans la section "Active Signing Keys" de la page (pour chaque clé : un fichier conséquent de chiffres hexadécimaux qui correspond à la partie publique de la clé) ainsi que leur "empreinte" (fingerprint) étalée sur 20 octets (40 chiffres hexa). Cela concerne "2009/lenny" et "2010/squeeze" (une clé distincte pour chacune et désormais une nouvelle clé chaque année).
    Pour les "Stable Keys", les empreintes seules sont proposées.
    // Je me questionne : qu'est-ce que l'empreinte d'une clé et à quoi sert-elle ?

    5) la procédure de remplacement des clés :
    a) l'un des "ftpmasters" génère une nouvelle clé
    b) cette clé est alors signée par lui et d'autres "ftpmasters" et membres de l'équipe "ftpteam" (incluant une vérification par appel téléphonique de l'empreinte et d'autres détails de la clé à signer)
    c) la nouvelle clé est préparée, placée sur cette page, mise dans les packages archive concernés, annoncée sur la liste debian-devel-announce bien avant d'être utilisée.
    /* je trouve cette description succinte : on ne sait pas qui est concerné dans le détail. Je me questionne sur la procédure : la nouvelle clé générée est signée par des gens. Cela signifie qu'il existe des signatures PGP de membres officiels Debian qui authentifient cette nouvelle clé. Avec sa copine la "Stable Keys" (jamais révoquée), elles permettront toutes deux de signer (une unique signature ?) une release stable. Il y a juste deux clés privées à voler pour corrompre la sécurité, dont l'une n'est jamais révoquée... */

    6) la procédure de révocation des clés :
    lors de la création d'une clé, un certificat de révocation est produit. Le programme "gfshare" (package libgfshare-bin) (a Shamir's secret sharing scheme implementation) est utilisé pour produire 12 morceaux dont 7 sont nécessaires pour retrouver le certificat de révocation. C'est utile en cas d'urgence seulement (par ex. perte de ftp-master.debian.org et tous les backups, évènement peu probable) car la clé peut normalement être utilisée pour produire son propre certificat de révocation.

    7) la procédure de sauvegarde/restauration de clé (privée) :
    la partie privée d'une clé générée est sauvegardée par l'usage de "gfshare" qui produit 14 morceaux dont 9 sont nécessaires pour retrouver la clé privée.

    8) suivent deux listes de noms : les 12 personnes concernées par la procédure de révocation des clés, puis les 14 personnes concernées par la procédure de restauration des clés privées.


    B)
    Pour ceux qui pratiquent la lecture en diagonale : non, je ne confonds pas signature authentifiante par PGP et "signature" (1) MD5|SHAx de contrôle d'intégrité.
    (1) le mot empreinte a été proposé en remplacement, je trouve ça bien vu, ça permet de distinguer les deux fonctions dès le premier mot.

    C)
    Je rappelle quelques faits qui semblent établis : PGP (ou GPG en version libre) permet de générer une signature qui authentifie un fichier comme étant "approuvé" (rédigé ou simplement validé) par le détenteur de la clé privée (ou un usurpateur, voleur de clé) qui a servi à la génération de la signature authentifiante (dit aussi "hash cryptographique"). Ce mécanisme implique la présence d'une empreinte du fichier "approuvé" dans la signature, pour faire le lien entre les deux, comme l'a confirmé Tanguy Ortolo. D'ailleurs, Etienne Bagnoud a précisé que (de mémoire, dit-il), l'algorithme de hash utilisé par GPG par défaut est SHA1.

    D)
    Pour ce qui concerne les cas que couvrent l'usage d'une empreinte de contrôle d'intégrité, je vois :

    1) la validation d'un fichier une fois reçu, pour mettre en évidence des erreurs de transmission (souvent cité ici - effectivement, MD5 a une utilité pour ce cas)

    2) la validation d'un fichier une fois reçu, pour mettre en évidence des formes de malveillance :
    a) modification à la volée pendant le transfert (man in the middle)
    b) modification dans les fichiers à la "source" (piratage des miroirs officiels)
    c) mise à disposition d'un miroir usurpateur, d'un .torrent falsifié.

    Dans le cas 2), j'estimais que MD5 n'était pas fiable. A la suite des dernières toutes les contributions, il ressort que MD5 est fragile en ce qu'il est possible de générer deux fichiers qui auront la même empreinte MD5 (processus qualifié de "collision de signature"), mais qu'il n'est pas réputé possible de générer un fichier qui ait la même empreinte MD5 qu'un fichier de référence déjà constitué (processus qualifié d' "attaque en seconde pré-image"). Je considère en l'état que je manque d'information qualifiante authentifiée (!) pour faire confiance à MD5 !

    E)
    Concernant SHA-1, il est révélé finalement qu'il est trop faible d'une part ("l'ANSSI recommande (et impose, dans certains cas), l'utilisation de fonctions de hachage ayant une sortie de 256 bits") et a une faille de sécurité (dixit "Vlobulle") d'autre part !

    F)
    Un usage sérieux des empreintes de contrôle d'intégrité implique de les multiplier avec différents algorithmes, car alors le risque de se voir proposer un contenu sciemment altéré - avec plusieurs empreintes valides - diminue drastiquement.

    G)
    Pour finir, quelques questions complémentaires :
    - l'algorithme SHA-2 actuel est disponible ? Sous quel nom ?
    - SHA256 et SHA512 correspondent à du SHA-1 ? Si oui, est-ce fiable, sachant qu'il y a une faiblesse et une faille de sécurité ???
    - Quels sont les autres algo que sait mettre en oeuvre GPG ?
    - Lequel est utilisé par Debian pour signer (authentifier) les fichiers ?
    • [^] # Re: synthèses, réponses et relances

      Posté par  (site Web personnel) . Évalué à 2.

      SHA-256 et SHA-512 sont des sommes de contrôle de la famille SHA2.
    • [^] # Re: synthèses, réponses et relances

      Posté par  . Évalué à 5.

      - l'algorithme SHA-2 actuel est disponible ? Sous quel nom ?
      - SHA256 et SHA512 correspondent à du SHA-1 ? Si oui, est-ce fiable, sachant qu'il y a une faiblesse et une faille de sécurité ???
      - Quels sont les autres algo que sait mettre en oeuvre GPG ?
      - Lequel est utilisé par Debian pour signer (authentifier) les fichiers ?

      Ca te dis de chercher un peu ? Ca m'a pris 3 minutes pour trouver la réponse des 3 première question sur wikipedia (français ou anglais) (Il en faut 5 de plus pour vérifier les sources wikipedia). Pour la troisième ça doit prendre un peu plus de temps mais c'est loin d'être insurmontable.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: synthèses, réponses et relances

      Posté par  (site Web personnel) . Évalué à 3.

      Je t'aide encore un peu (vu que tu n'as toujours pas l'air de connaître "man gpg", wikipedia et google) :

      Le NIST demande de ne plus utiliser SHA-1 après la fin de l'année 2010 : http://csrc.nist.gov/groups/ST/hash/statement.html
      Debian c'est déjà posé la question avant, ça et ça a même été relayé ici : https://linuxfr.org//2009/05/09/25437.html et http://www.debian-administration.org/users/dkg/weblog/48

      Et en lisant la page de wikiepdia https://secure.wikimedia.org/wikipedia/en/wiki/SHA2 tu verrais assez vite que SHA-2 regroupe SHA-224, SHA-256, SHA-384 et SHA-512. Que SHA-512/384 sont des nouvelles fonctions de hachage.

      Ensuite pour savoir quels sont les algos de hash de GPG (sur une Debian testing/unstable) :
      $ gpg --version
      gpg (GnuPG) 1.4.10
      Copyright (C) 2008 Free Software Foundation, Inc.
      License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
      This is free software: you are free to change and redistribute it.
      There is NO WARRANTY, to the extent permitted by law.

      Home: ~/.gnupg
      Algorithmes supportés:
      Clé publique: RSA, RSA-E, RSA-S, ELG-E, DSA
      Chiffrement: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128,
      CAMELLIA192, CAMELLIA256
      Hachage: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
      Compression: Non-compressé, ZIP, ZLIB, BZIP2


      Soit MD5, SHA1, RIPMED160, SHA256, SHA384, SHA512, SHA224 !

      "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

  • # précision

    Posté par  . Évalué à 1.

    pour ceux qui ne comprennent rien a la crypto et qui voudraient suivre la discussion, je me suis dit qu'un petit rappel ne fait pas de mal.

    Pour authentifier l'emeteur d'un fichier, on commence par créer un hash (md5, sha) du fichier, puis l'emeteur chiffre le hash avec sa clef privée. A la reception, le destinataire dechiffre la signature avec la clef publique, et compare le hash avec le hash du fichier qu'il a recu.

    En effet, d'une manière générale, les algo de chiffrements asymétriques sont très gourmand et cela ne serait pas rentable de chiffrer les fichiers en entier. C'est pourquoi on utilise les algo de hash pour identifier le fichier.
    On peut également remarquer que le processus opposé qui consiste à chiffrer un fichier avec une clef publique pour le rendre uniquement lisible au porteur de la clef privée suit le même principe : on ne chiffre pas le fichier en entier, mais on le chiffre d'abord avec un algo symétrique (3DES, AES...) puis on ne chiffre avec la clef asymétrique que la clef utilisée.

    Maintenant on comprend mieux qu'il y a 2 débats dans ce journal : la question des algo dehashage, et la question de l'identification des clefs privées. Sur le second point, il n'y a de toute façon pas de solution "ultime", car il faut bien faire confiance a qqun pour authentifier les clefs publique utilisées. Par exemple, pour les sites en SSL, on fait confiance à l'authorité de certification (verisign,...). Dans le cas de GPG, on fait confiance a des personnes physiques de la communauté. Mais il n'y pas d'algo pour cette confiance là!
    • [^] # Re: précision

      Posté par  . Évalué à 2.

      Merci. Ca m'a bien raffraichi la mémoire tes détails. Je découvre que j'avais l'esprit un peu confus sur les processus d'authentification.
      En passant, pour rajouter à la pédagogie, à la fin de l'avant-dernier paragraphe, lire : "on le chiffre d'abord avec un algo symétrique (3DES, AES...) puis on ne chiffre avec la clef asymétrique que la clef (de chiffrement symétrique) utilisée".

Suivre le flux des commentaires

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