Quelle est la valeur des sommes de contrôle MD5 si le hachage MD5 lui-même aurait potentiellement également été manipulé?
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 non seulement les fichiers corrompus pouvaient être identifiés instantanément avant qu'ils ne causent un problème, mais aussi que toute modification malveillante soit facilement détectée.
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'envoyer. que 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 délibérément des fichiers altérés s’il n’ya aucun moyen de savoir si la somme de contrôle elle-même a été compromise?
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, plus précisément ) uniquement pour vérifier le 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 cela.
La solution utilisée par certains systèmes de gestion de paquets tels que dpkg consiste à signer le hachage : utiliser le hachage 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.
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 ceci à partir de 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. Je ne pense même pas à quel point il est utile que le fichier et le hachage ne se trouvent pas au même emplacement.
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 si ceux-ci se trouvent sur des serveurs différents et sont gérés par des entités différentes.
Parfois, les sommes de contrôle sont fournies de manière sécurisée, mais le téléchargement ne l’est pas. Puisque MD5 est cassé , les sommes de contrôle de sécurité MD5 sont plus faibles que les sommes de contrôle plus sûres, mais avant que MD5 ne soit cassé, un MD5 fourni en toute sécurité (par exemple, un signé avec PGP ou GPG ou Gatekeeper, ou récupéré via HTTPS) correspondant au MD5 du téléchargement constituait 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", parce que cela IS 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, vérifiés automatiquement, et pourtant, même 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 Apple." ... "Apple a depuis révoqué le certificat abusif 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.
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.
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 réalisable, 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é.)
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 n'est pas un cas commun). 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 à 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 (de sorte que la somme de contrôle elle-même est digne de confiance); 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.
Comment les sommes de contrôle MD5 peuvent-elles fournir une protection contre délibérément les fichiers altérés s’il n’ya aucun moyen 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'un hachage cryptographique sécurisé d'un fichier n'est pas compromis, nous savons que le fichier isn pas compromis 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 fonctionne correctement, le miroir ne pourra pas subvertir votre fichier.
Si votre site web utilise HTTPS ou que vous signez le hachage avec gpg , votre fichier peut également être (principalement) protégé des attaquants du réseau, tels que des points d'accès Wi-Fi malveillants. , noeuds de sortie Tor non autorisés ou NSA.
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 type d'infrastructure à clé publique. processus 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.
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 disposant de 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 (après 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 "I.M.Awesome", 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 I.M.Awesome? 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 PC de travail incluent un certificat du gouvernement des États-Unis. Toute personne ayant accès à la clé privée correspondante 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 et de voir qui est la paire de clés utilisée pour "sécuriser" la connexion?
Comment les sommes de contrôle MD5 peuvent-elles fournir une protection contre délibérément les fichiers altérés s’il n’ya aucun moyen 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 peu 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.
Dans 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’autorité est 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 joli logiciel d'archivage de bibliothèque appelé ACE Audit manager , qui est essentiellement une application Java conçue pour rester assis et regarder 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 .
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 règle générale, 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é, offerte "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.
la vitesse
Souvent, les gens trouvent 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 fiable, 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 installé sur un site de téléchargement, il est facile pour Mallory de contrôler également de manière malveillante 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 somme de contrôle malveillant semblerait valider le fichier volumineux. 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 somme de contrôle malveillant aux fichiers de somme 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 n'est pas validé , et saura que quelque chose a mal tourné.
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.
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 mal . La signature numérique est en fait 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é , pas tout le fichier original.
Cela étant dit, si la source ne fournit pas la signature du hachage et un moyen sûr de le vérifier , alors vous avez raison, non la protection est donnée contre délibérément les fichiers modifiés , mais le hachage est toujours utile comme somme de contrôle contre accidentel la corruption.
Voici un exemple du monde réel qui peut tout clarifier. 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 nouvelles versions, des algorithmes de somme de contrôle plus récents et plus puissants (SHA1, SHA256 et SHA512) sont utilisés.