Quelle est la valeur des sommes de contrôle MD5 si le hachage MD5 lui-même aurait potentiellement également été manipulé?

39

Les téléchargements sur les sites Web ont parfois une somme de contrôle MD5, permettant aux utilisateurs de confirmer l'intégrité du fichier. J'ai entendu dire que cela permet non seulement d'identifier instantanément les fichiers corrompus avant qu'ils ne causent un problème, mais également de détecter facilement les modifications malveillantes.

Je suis la logique en ce qui concerne la corruption de fichier, mais si quelqu'un souhaite délibérément télécharger un fichier malveillant , il peut générer une somme de contrôle MD5 correspondante et l'afficher sur le site de téléchargement avec le fichier modifié. Cela tromperait quiconque téléchargerait le fichier et penserait qu'il était inchangé.

Comment les sommes de contrôle MD5 peuvent-elles fournir une protection contre les fichiers délibérément altérés s’il n’est pas possible de savoir si la somme de contrôle elle-même a été compromise?

Austin '' Danger '' Powers
la source
3
Si nous nous en remettons à l'hôte du site Web pour remarquer des écarts d'horodatage subtils au lieu du hachage MD5 agissant comme un sceau d'authenticité ... alors la protection fournie par la somme de contrôle s'est quasiment évaporée.
Austin '' Danger '' Powers
4
@ BigChris Je ne suis pas sûr de ce que vous voulez dire, mais ça sonne mal. Les algorithmes de hachage cryptographiques tels que MD5 concernent complètement les données de message. Deux messages aléatoires de la même longueur auront presque certainement des hachages différents.
Matt Nordhoff
3
@ MattNordhoff exactement. Si une somme de contrôle MD5 n'est pas générée sur la base des données de fichier, sur quoi est- elle basée?
Austin '' Danger '' Powers
2
Les données de hachage MD5 seraient construites sur les données, oui, mais cela ne demanderait pas trop d'effort de créer un fichier malveillant avec le même hachage. Comme dit, il n'y aurait aucun moyen de vérifier si le fichier était malveillant ou non. Lire: mscs.dal.ca/~selinger/md5collision
Kinnectus
2
Parfois, les hachages sont publiés sur le serveur propriétaire alors que les téléchargements réels sont hébergés sur des miroirs tiers et / ou des CDN.
el.pescado

Réponses:

89

J'ai entendu dire que c'est pour permettre [...] que toute modification malveillante soit également détectée.

Eh bien, vous avez mal entendu alors. Les sommes de contrôle MD5 (ou SHA ou autre) sont fournies (à côté des liens de téléchargement, en particulier ) uniquement pour vérifier un téléchargement correct. La seule chose qu'ils visent à garantir est que vous avez le même fichier que le serveur. Ni plus ni moins. Si le serveur est compromis, vous êtes SOL. C'est aussi simple que ça.

Daniel B
la source
31
+1 Ils sont principalement utilisés pour protéger contre la corruption accidentelle (erreurs de transfert de réseau, secteurs défectueux sur le disque, etc.). Pour se protéger contre la corruption malveillante, la somme de contrôle doit provenir d’un emplacement de confiance non connecté. Même chose avec les messages signés PGP / GPG / similaires: ils assurent uniquement le contenu si vous avez confiance en l’où vous avez obtenu la clé publique.
David Spillett
1
Vous pouvez également vouloir ajouter à votre réponse que les signatures difitales répondent à cette limitation (en supposant que vous faites confiance au certificat / à l'autorité de certification)
atk
2
C'est encore pire: si quelqu'un peut altérer votre trafic vers / depuis le serveur, alors même si le serveur n'est pas compromis, il peut modifier à la fois le fichier et la somme de contrôle que vous recevez.
cpast
3
Pour développer: Si elle a fait la garantie que vous avez eu le même fichier que le serveur avait, ce serait une mesure de sécurité légitime, parce que cela signifie que vous ne devez pas faire confiance au réseau. C’est exactement ce que font les MAC dans TLS - prouvez que ce que vous obtenez est ce que le serveur a envoyé, mais TLS ne peut rien faire pour un serveur compromis non plus. Si un hachage correct est transmis via une connexion sécurisée, il peut fournir une sécurité (dérivée de la connexion sécurisée); si elle est envoyée sur la même connexion que le fichier, alors il est inutile , car il est plus inviolable que le fichier lui - même était.
cpast
2
C'est faux. Parfois, les sommes de contrôle sont fournies de manière sécurisée, mais le téléchargement ne l’est pas. Comme MD5 est cassé, les sommes de contrôle de sécurité MD5 fournies sont plus faibles que les sommes de contrôle plus sécurisées, mais avant que MD5 ne soit cassé, un MD5 fourni de manière sécurisée (par exemple, un ordinateur signé ou envoyé de HTTP) correspondant au MD5 du téléchargement constituait une preuve solide que le Le téléchargement reçu était celui que le serveur rendait disponible. Je vais ajouter une réponse avec plus de détails ci-dessous maintenant.
Matthew Elvey
15

La solution utilisée par certains systèmes de gestion de paquets tels que dpkg consiste à signer le hachage : utilisez-le en tant qu'entrée pour l'un des algorithmes de signature à clé publique. Voir http://www.pgpi.org/doc/pgpintro/#p12

Si vous avez la clé publique du signataire, vous pouvez vérifier la signature, ce qui prouve que le hachage n’a pas été modifié. Cela vous laisse simplement avec le problème d'obtenir la bonne clé publique à l'avance, bien que si quelqu'un altère une fois la distribution de la clé, il doit également altérer tout ce que vous pourriez vérifier, sinon vous remarquerez qu'il se passe quelque chose d'étrange.

pjc50
la source
9

Votre hypothèse est correcte. Il y a une exception cependant. Si le serveur fournissant le fichier et la page contenant le hachage ne sont pas gérés par la même entité. Dans ce cas, le développeur de logiciel peut vouloir dire "hé les gens téléchargent ça depuis cet endroit mais ne croient que si hash = xxxx". (Cela pourrait être utile pour les CDN à titre d'exemple). Je suppose que c'est la raison pour laquelle quelqu'un l'a fait en premier lieu. Que d'autres ont juste suivi en pensant à quel point il serait cool de montrer le hash. Ne pensant même pas à quel point il est utile que le fichier et le hachage ne se trouvent pas tous deux au même endroit.

Cela dit, cela en vaut la peine. Ne présumez pas trop de la sécurité, comme d’autres l'ont déjà dit. Si et seulement si vous pouvez avoir une confiance absolue dans le hachage original, le fichier est bon. Sinon, un attaquant disposant de suffisamment de motivation et de connaissances peut altérer à la fois le fichier et le hachage, même s'ils se trouvent sur des serveurs différents et gérés par des entités différentes.

nsn
la source
8

Parfois, les sommes de contrôle sont fournies de manière sécurisée, mais le téléchargement ne l’est pas. Depuis que MD5 est cassé , les sommes de contrôle de sécurité MD5 fournies sont plus faibles que les sommes de contrôle plus sécurisées, mais avant que MD5 ne soit cassé, un MD5 sécurisé (par exemple, signé avec PGP ou GPG ou Gatekeeper, ou récupéré via HTTPS) correspondant au MD5 de le téléchargement était une preuve solide que le téléchargement reçu était celui que le serveur rendait disponible.

J'écris sur le lamentable manque de sommes de contrôle sécurisées depuis des années, ici .

Les utilisateurs ne doivent pas télécharger des exécutables non fiables sur des réseaux non fiables et les exécuter, en raison du risque d'attaques MITM. Voir, par exemple, "Insécurités dans les systèmes de mise à jour automatique" de P. Ruissen, R. Vloothuis.

Addendum 2014: Non, ce n'est PAS faux "que les sommes de contrôle postées sur des pages Web servent à détecter des modifications malveillantes", car c'est un rôle qu'ils peuvent jouer. Ils aident à protéger contre la corruption accidentelle et, s'ils sont servis via HTTPS ou avec une signature vérifiée (ou mieux encore, les deux), aident à protéger contre la corruption malveillante! J'ai obtenu des sommes de contrôle sur HTTPS et vérifié qu'elles correspondaient plusieurs fois aux téléchargements HTTP.

De nos jours, les fichiers binaires sont souvent distribués avec des hachages signés et automatiquement vérifiés, même si cela n’est pas parfaitement sécurisé .

Extrait du lien ci-dessus: "L’application KeRanger a été signée avec un certificat de développement d’application Mac valide; elle a donc pu contourner la protection du portier de Apple." ... "Apple a depuis révoqué le certificat abusé et mis à jour la signature antivirus XProtect, et Transmission Project a supprimé les installateurs malveillants de son site Web. Palo Alto Networks a également mis à jour le filtrage des adresses URL et la prévention des menaces afin d'empêcher KeRanger de nuire aux systèmes. Analyses techniques

Les deux programmes d’installation de Transmission infectés par KeRanger étaient signés avec un certificat légitime délivré par Apple. Le développeur répertorié ce certificat est une société turque portant l'ID Z7276PX673, qui était différent de l'ID de développeur utilisé pour signer les versions précédentes du programme d'installation de Transmission. Dans les informations de signature de code, nous avons constaté que ces installateurs avaient été générés et signés le matin du 4 mars. "

Addenda 2016:

@ Cornstalks: Re. votre commentaire ci-dessous: Mauvais. Comme indiqué dans l'article de Wikipédia sur l'attaque par collision auquel vous vous associez, "En 2007, une attaque par collision à préfixe choisi a été détectée contre MD5" et "l'attaquant peut choisir deux documents arbitrairement différents, puis ajouter différentes valeurs calculées aboutissant à l'ensemble. documents ayant une valeur de hachage égale ". Ainsi, même si le MD5 est fourni de manière sécurisée et qu'un attaquant ne peut pas le modifier, un attaquant PEUT toujours utiliser une attaque par collision à préfixe choisi avec un préfixe choisi contenant un malware, ce qui signifie que MD5 n'est PAS sécurisé à des fins de cryptographie. C’est en grande partie pourquoi US-CERT a déclaré que MD5 "devrait être considéré comme cassé de manière cryptographique et impropre à une utilisation ultérieure".

Quelques autres choses: CRC32 est une somme de contrôle. MD5, SHA, etc. sont plus que des sommes de contrôle; ils sont destinés à être des hachages sécurisés. Cela signifie qu'ils sont censés être très résistants aux attaques par collision. Contrairement à une somme de contrôle, un hachage sécurisé et sécurisé communique une protection contre une attaque de type "homme au milieu" (MITM) lorsque le MITM se situe entre le serveur et l'utilisateur. Il ne protège pas contre une attaque où le serveur lui-même est compromis. Pour se protéger contre cela, les utilisateurs s’appuient généralement sur quelque chose comme PGP, GPG, Gatekeeper, etc.

Matthew Elvey
la source
J'aime cette réponse car elle met en évidence une partie fondamentale d'une somme de contrôle : il s'agit simplement d' une métrique, parmi bien d'autres, permettant de vérifier la validité du contenu d'un fichier. Si le réseau lui-même n’est pas fiable, il n’est pas impossible d’imaginer celui qui remplace les hachages MD5 et corrige les binaires à la volée (comme nous l’avons déjà vu sur certains nœuds de sortie Tor) ... Bien entendu, MD5 ne fournit aucune protection contre fichiers délibérément modifiés car vous faites déjà confiance au fournisseur de ces fichiers pour commencer.
Percée
2
MD5 n'est pas totalement cassé: l'attaque est une attaque par collision , pas une pièce jointe de pré-image (ce qui serait bien pire). Si le MD5 est fourni de manière sécurisée et qu'un attaquant ne peut pas le modifier, un attaquant ne peut pas utiliser d'attaque par collision (et doit utiliser une attaque de pré-image), ce qui signifie que MD5 est toujours assez sécurisé à cet effet. MD5 mérite d’être supprimé progressivement en raison de sa vulnérabilité de collision, mais il n’a pas de vulnérabilité de pré-image (connue), il n’est donc pas totalement défectueux. Juste à moitié cassé.
Cornstalks
+1! Mais ... Un hachage signé est-il vraiment aussi sécurisé ( confiance ) qu'un hachage non signé récupéré sur https (ssl / tls)? Je pense qu'il est toujours préférable que le hash lui-même soit signé de toute façon ...
matpop
4

C’est la raison précise pour laquelle les sommes de contrôle publiées comportent souvent une clause de non-responsabilité indiquant «Cela ne peut pas protéger contre une modification malveillante du fichier». Donc, la réponse courte est "ils ne peuvent fournir aucune protection contre un fichier délibérément modifié" (bien que, si la page est transmise via HTTPS, HTTPS lui-même protège contre les modifications; si le fichier n'est pas livré via HTTPS, la somme de contrôle est, alors cela pourrait aider certains, mais ce n’est pas un cas courant). La personne qui vous a dit que les sommes de contrôle affichées sur les pages Web sont utilisées pour détecter les modifications malveillantes était fausse, car ce rôle ne peut pas être rempli. ils ne font que protéger contre la corruption accidentelle et la corruption malveillante paresseuse (si quelqu'un ne s'ennuie pas d'intercepter la page en vous donnant la somme de contrôle).

Si vous souhaitez vous protéger contre toute modification délibérée, vous devez empêcher les utilisateurs de manipuler la somme de contrôle ou empêcher toute autre personne de générer une somme de contrôle valide. Le premier peut impliquer de le donner en personne ou similaire (donc on fait confiance à la somme de contrôle elle-même); le dernier utilise les algorithmes de signature numérique (où vous devez obtenir votre clé publique en toute sécurité pour le téléchargeur; dans TLS, cela se fait en faisant finalement confiance aux autorités de certification et en leur demandant de vérifier tout le monde; cela peut également être fait sur un réseau de confiance , mais le fait est que quelque chose doit être transféré en toute sécurité à un moment donné, et le simple fait de publier quelque chose sur votre site ne suffit pas.

cpast
la source
2
Les hachages peuvent protéger contre les modifications malveillantes si on sait via une source indépendante quelle devrait être la valeur de hachage attendue d'une version digne de confiance d'un fichier. Le fait que le site Web dresse la liste des valeurs de hachage de ses fichiers ne permet pas aux personnes qui téléchargent des fichiers depuis un site de vérifier le hachage du fichier téléchargé par rapport au même site, mais bien aux personnes qui le savent depuis une autre source le hachage du fichier qu'ils veulent , savoir si le fichier en question correspondra avant de le télécharger. BTW, une chose que je voudrais voir ...
Supercat
... serait une forme d'URL / URI contenant une valeur de hachage attendue (probablement SHA plutôt que MD5), et préciserait qu'un navigateur ne devrait accepter un fichier que si le hachage correspond à ce qui est spécifié. Dans les cas où de nombreuses personnes auront besoin d'accéder au même fichier volumineux, il pourrait être plus efficace de donner à toutes ces personnes une URL via https: //, mais le télécharger à partir d'un proxy pourrait s'avérer plus efficace. directement depuis la source.
Supercat
@supercat C'est ce que je voulais dire par "empêcher les gens de jouer avec la somme de contrôle" - quelque chose doit être transféré de manière sécurisée, et si c'est la somme de contrôle, la somme de contrôle peut aider à protéger contre la falsification malveillante du fichier.
cpast
Une somme de contrôle MD5 transmise par un autre chemin que le fichier lui-même offrirait une protection contre la falsification, sauf si le fichier a été créé délibérément pour faciliter cette falsification. En revanche, quelque chose comme CRC32 n'offrirait presque aucune protection contre la falsification, même si la source d'origine du fichier était digne de confiance et que le CRC32 était livré en toute sécurité.
Supercat
4

C'est vraiment un problème. Afficher des sommes de contrôle sur le même site que le fichier à télécharger n’est pas sécurisé. Une personne qui peut modifier le fichier peut également modifier la somme de contrôle. La somme de contrôle doit être affichée dans un système complètement séparé, mais cela n’est guère faisable, car il est facile de dire à l’utilisateur, de manière sûre, où trouver la somme de contrôle.

Une solution possible consiste à utiliser des fichiers signés.

(BTW: MD5 est dangereux n'importe où et ne devrait plus être utilisé.)

remue-marais
la source
2

Comment les sommes de contrôle MD5 peuvent-elles fournir une protection contre les fichiers délibérément altérés s’il n’est pas possible de savoir si la somme de contrôle elle-même a été compromise?

Vous avez tout à fait raison. Le but serait alors de rendre votre "si" faux - si nous savons qu'une empreinte cryptographique sécurisée d'un fichier n'est pas compromise, nous savons que le fichier ne l'est pas non plus.

Par exemple, si vous publiez le hachage d'un fichier sur votre site Web, puis que vous créez un lien vers une copie du fichier sur un serveur miroir tiers (pratique courante dans la distribution de logiciel libre à l'ancienne), vos utilisateurs peuvent être protégés contre certains types. des attaques. Si le serveur miroir est malveillant ou compromis, mais que votre site Web est correct, le miroir ne pourra pas subvertir votre fichier.

Si votre site Web utilise HTTPS, ou si vous signez le hachage gpg, votre fichier peut également (en grande partie) être protégé contre les attaquants du réseau, tels que les points d'accès Wi-Fi malveillants, les nœuds de sortie non fiables de Tor ou NSA.

Matt Nordhoff
la source
1
En ce qui concerne gpg: rappelez-vous que cela pose des problèmes similaires si vous n’êtes pas entièrement convaincu que la clé publique n’a pas été remplacée par une clé compromise et que le contenu signé avec la clé privée correspond à cette clé.
David Spillett
1

Vous ne pouvez pas modifier la somme de contrôle MD5 sans modifier également le fichier. Si vous téléchargez le fichier, puis téléchargez le hachage, votre calcul du fichier ne correspond pas à ce qui est donné, le hachage ou le fichier est incorrect ou incomplet.

Si vous souhaitez "lier" le fichier à un élément externe, tel qu'un auteur, une machine, etc., il doit être signé , à l'aide d'un processus de type PKI avec des certificats. L’auteur du fichier, etc., peut signer le fichier avec sa clé privée et vous pouvez vérifier les signatures avec la clé publique. Cette clé doit être accessible au public, elle-même signée par une autorité de certification, vous et son auteur, et téléchargeable, de préférence à partir de. plusieurs emplacements.

La modification du fichier rendrait la signature invalide, ce qui permet également de vérifier l'intégrité du fichier.

LawrenceC
la source
1

Les hachages indiquent si votre version du fichier (le "téléchargement") diffère de la version du serveur. Ils n'offrent aucune garantie quant à l'authenticité du fichier.

Les signatures numériques (cryptage asymétrique + fonction de hachage) peuvent être utilisées pour vérifier que le fichier n'a pas été modifié par quiconque ne possédant pas la clé privée correspondante.

Le créateur du fichier hache le fichier et le chiffre en utilisant sa clé privée (secrète). De cette manière, toute personne possédant la clé publique correspondante (non secrète) peut vérifier que le hachage correspond au fichier, mais tant que le contenu du fichier peut être modifié, personne ne peut remplacer le hachage correspondant par un qui correspond au fichier (une fois que le hachage est déchiffré à l'aide de la clé publique) - à moins qu'ils ne parviennent à forcer brutalement la clé privée, ou y aient accès d'une manière ou d'une autre.

Qu'est-ce qui empêche M. "A.Hacker" de modifier simplement le fichier, puis de le signer avec sa propre clé privée?

Pour valider le fichier, vous devez comparer son hachage à celui obtenu en déchiffrant la signature numérique associée. Si vous pensez que le fichier provient de "IMAwesome", vous déchiffrez le hachage à l'aide de sa clé et le hachage ne correspond pas au fichier car le hachage a été chiffré à l'aide de la clé de A.Hacker.

Les signatures numériques permettent donc de détecter les modifications accidentelles et malveillantes.

Mais comment pouvons-nous obtenir la clé publique de IMAwesome? Comment pouvons-nous nous assurer que lorsque nous avons obtenu sa clé, celle-ci n'était pas réellement servie par un serveur compromis ou une attaque de type "man-in-the-middle"? C’est là que les chaînes de certificats et les certificats racine de confiance entrent en jeu. Aucune de ces solutions n’est parfaitement sûre [1], et les deux devraient probablement être bien expliquées sur Wikipedia et sur d’autres questions relatives aux SO.

[1] Lors de l'inspection, les certificats racine fournis avec le système d'exploitation Microsoft sur mon ordinateur de travail incluent un certificat du gouvernement des États-Unis. Toute personne ayant accès à la clé privée correspondante à la toux NSA toux peut donc transmettre du contenu à mon navigateur Web qui passe le contrôle "y a-t-il un cadenas dans la barre d'adresse"? Combien de personnes prendront la peine de cliquer sur le cadenas pour voir qui est la paire de clés utilisée pour "sécuriser" la connexion?

Mark K Cowan
la source
Il suffit d’une personne qui contrôle la chaîne de certificats pour provoquer un scandale. Si vous pensez que la NSA utiliserait une clé d’autorité de certification gouvernementale pour MITM plutôt que celle volée à une autorité de certification privée ou, mieux encore, étrangère (ce qui fournirait un refus crédible), j’ai un pont pour vous vendre.
Charles Duffy
Je suggérais la possibilité que cela pourrait être utilisé pour cibler un MITM sur un utilisateur particulier. Pour ce qui est de savoir si c'est réellement probable, c'est pour les gens de papier d'aluminium à débattre sur
Mark K Cowan
Je ne me demande pas si un MITM ciblé est probable. Je me demande s’il est improbable d’utiliser une clé de CA facilement identifiée et attribuée. En particulier dans le cas d’une cible de valeur suffisante, le trafic net sortant est susceptible d’être enregistré avec suffisamment de détails pour inclure des métadonnées jusqu’à la partie publique de la négociation SSL, de sorte que même si l’utilisateur ne regarde pas, son personnel de sécurité ou une infrastructure automatisée pourrait le faire en analyse rétrospective.
Charles Duffy
1

Comment les sommes de contrôle MD5 peuvent-elles fournir une protection contre les fichiers délibérément altérés s’il n’est pas possible de savoir si la somme de contrôle n’a pas été compromise non plus?

C'est une très bonne question. En général, votre évaluation de la manipulation du MD5 est parfaite. Mais je crois que la valeur des sommes de contrôle MD5 sur les téléchargements est au mieux superficielle. Après avoir téléchargé un fichier, vous pourrez peut-être vérifier le contenu du MD5 par rapport à un site Web, mais j’ai tendance à considérer le stockage MD5 côte à côte comme un «reçu» ou quelque chose d’agréable, mais qui n’est pas fiable. En tant que tel, je ne me suis généralement jamais soucié des sommes de contrôle MD5 des fichiers téléchargés, mais je peux parler de mon expérience de la création de processus MD5 ad-hoc basés sur serveur.

En gros, ce que j’ai fait quand un client veut balayer un système de fichiers pour des sommes de contrôle MD5, c’est de les générer dans des fichiers CSV qui mappent le nom de fichier, le chemin, le MD5 et d’autres informations de fichier diverses dans un format de données structuré que j’ai ensuite ingéré. dans une base de données pour la comparaison et le stockage.

En utilisant votre exemple, alors qu'une somme de contrôle MD5 peut être placée à côté d'un fichier dans son propre fichier texte, la somme de contrôle MD5 de l'enregistrement d'autorité serait stockée dans un système de base de données non connecté. Donc, si quelqu'un piratait un système de partage de fichiers pour manipuler des données, cet intrus n'aurait aucun accès aux notices d'autorité MD5 ni à l'historique connecté.

Récemment, j'ai découvert un logiciel d'archivage de bibliothèque appelé ACE Audit Manager, qui est en fait une application Java conçue pour rester assis et observer les modifications apportées à un système de fichiers. Il enregistre les modifications via les modifications MD5. Et il fonctionne sur une philosophie similaire à celle de mon processus ad-hoc - stocker les sommes de contrôle dans une base de données - mais il va encore plus loin en créant une somme de contrôle MD5 de sommes de contrôle MD5 appelée arbre de hachage ou arbre de Merkle .

Alors disons que vous avez 5 fichiers dans une collection. Ces 5 fichiers dans ACE Audit Manager obtiendraient alors un autre contrôle, appelons-le «parent», qui est un hachage généré à partir des 5 sommes de contrôle MD5 de chaque fichier. Donc, si quelqu'un manipulait un seul fichier, le hachage pour le fichier serait modifié, de même que le hachage pour l'ensemble de la collection «mère».

En général, vous devez examiner les sommes de contrôle MD5 et les hachages d’intégrité associés, à moins qu’ils ne soient connectés à un stockage non direct pour les hachages MD5 eux-mêmes, ils peuvent être corrompus. Et leur valeur en tant qu’outil d’intégrité des données à long terme équivaut à une serrure bon marché livrée «gratuitement» sur un nouveau bagage; si vous êtes sérieux au sujet du verrouillage de vos bagages, vous obtiendrez un verrou qui ne peut pas être ouvert en 5 secondes avec un trombone.

JakeGould
la source
"La somme de contrôle MD5 des sommes de contrôle MD5" est appelée arbre Merkle .
pjc50
@ pjc50 Merci! Edité la réponse pour faire référence à cela.
JakeGould
0

la vitesse

Les gens trouvent souvent qu'il est beaucoup plus rapide de (a) télécharger un fichier volumineux à partir d'un réseau de diffusion de contenu (CDN) "proche" non approuvé, d'un site miroir, de pairs torrent, etc., ainsi que de télécharger le fichier de somme de contrôle court correspondant (souvent SHA256; logiciel plus ancien souvent utilisé MD5) provenant de quelques sources fiables. Ils trouvent qu'il est extrêmement lent de (b) télécharger l'intégralité du fichier volumineux directement à partir d'une source fiable.

validation

Souvent, cette personne trouve que tout est valable: les sources (de confiance et non fiables) sont d’accord sur la même somme de contrôle et exécuter shasum (ou md5sum) avec l’un de ces courts fichiers de somme de contrôle (peu importe lequel, quand ils sont tous identiques ) indique que le fichier volumineux a une somme de contrôle correspondante.

modification

Vous avez raison de dire que lorsque Mallory modifie de manière malveillante un fichier volumineux stocké sur un site de téléchargement, il est facile pour Mallory d’utiliser également la somme de contrôle de ce fichier sur le même site de téléchargement, de sorte que shasum (ou md5sum) exécuté sur ce fichier de contrôle malveillant semblent valider le gros fichier. Mais ce fichier de somme de contrôle n'est pas le (seul) fichier que le téléchargeur devrait utiliser pour la validation.

Lorsque le téléchargeur compare ce fichier de total de contrôle malveillant aux fichiers de total de contrôle téléchargés à partir de sources fiables, si la somme de contrôle d'origine passe même une fois, le téléchargeur verra que tout ne se valide pas et saura que quelque chose s'est mal passé.

Comme cpast l’a déjà dit, si une bonne somme de contrôle cryptographique est transmise sur une connexion sécurisée, elle peut fournir une sécurité (qui découle de la connexion sécurisée).

Comme Supercat l’a déjà dit, les fichiers de somme de contrôle d’un site n’aident pas les personnes qui téléchargent des fichiers volumineux à partir du même site et de la même manière qu’ils téléchargent les fichiers de somme de contrôle; ils aident les personnes qui souhaitent télécharger des fichiers d’un autre site.

"En termes de sécurité, les hachages cryptographiques tels que MD5 permettent l'authentification des données obtenues à partir de miroirs non sécurisés. Le hachage MD5 doit être signé ou provenir d'une source sécurisée (une page HTTPS) d'une entreprise de confiance." - https://help.ubuntu.com/community/HowToMD5SUM

Les totaux de contrôle cryptographiques constituent une partie importante des signatures de clé publique pratiques (telles que mises en œuvre dans GnuPG et d'autres logiciels compatibles OpenPGP). Les signatures à clé publique présentent certains avantages par rapport aux sommes de contrôle seules.

David Cary
la source
0

J'ai entendu dire que la [somme de contrôle MD5] permettait [...] également de détecter facilement les modifications malveillantes.

Eh bien, vous n'avez pas entendu totalement tort . La signature numérique est en réalité ce qui est utilisé pour détecter les modifications malveillantes. Pour des raisons importantes, le hachage est un élément fondamental de la signature numérique, en ce sens que seul le hachage est réellement signé , et non le fichier original dans son intégralité.

Cela étant dit, si la source ne fournit pas la signature du hachage et un moyen fiable de le vérifier , vous avez raison, aucune protection n'est donnée contre les fichiers délibérément modifiés , mais le hachage reste utile comme somme de contrôle contre les accidents. la corruption .

Voici un exemple du monde réel qui peut clarifier le tout. Le passage suivant est particulièrement significatif à ce sujet:

Pour les versions de CD archivées plus anciennes, seules les sommes de contrôle MD5 ont été générées [...] Pour les versions plus récentes, des algorithmes de somme de contrôle plus récents et plus puissants (SHA1, SHA256 et SHA512) sont utilisés.

matpop
la source