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 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?

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.

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.

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.

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.

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.

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é.)

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.

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.

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?

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.

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.

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.