Outils de développement · Calculateur de hachage SHA
Une somme de contrôle correspondante n'est pas une signature : intégrité ou authenticité
· Pourquoi c'est important
sha-256 cryptographie sécurité
Un SHA-256 publié permet aux utilisateurs de détecter un téléchargement corrompu, mais si l'attaquant contrôle la page, il contrôle également la somme de contrôle. Cet article sépare l'intégrité de l'authenticité et explique ce que les signatures ajoutent.
La somme de contrôle sur la même page que le téléchargement : pourquoi elle protège contre la corruption mais pas contre un hôte compromis
Une version logicielle est publiée avec une somme de contrôle SHA-256 sur la même page que le téléchargement. Les utilisateurs peuvent récupérer l'archive, la hacher et comparer le résultat à la valeur publiée. S'ils correspondent, le téléchargement n'est pas corrompu. Il s’agit d’une vérification d’intégrité, et c’est une vérification réelle et utile. Cependant, si un attaquant compromet le serveur Web hébergeant la version, il peut remplacer le binaire, recalculer son SHA-256 et mettre à jour la somme de contrôle sur la page. L'utilisateur vérifie la somme de contrôle et le malware de l'attaquant semble provenir de l'éditeur. Le système a fonctionné exactement comme prévu, mais il n’a pas réussi à répondre à la question que l’utilisateur pensait se poser.
Il ne s'agit pas d'un échec de la somme de contrôle elle-même. Il s’agit d’une observation correcte de ce qu’une somme de contrôle fait et ne fait pas. Une somme de contrôle prouve que deux copies de données sont identiques. Cela ne prouve pas qui a créé les données. C’est la distinction entre intégrité et authenticité, et les confondre est l’une des erreurs de sécurité les plus courantes lors de la vérification des versions. De nombreux systèmes sont en panne, non pas parce que leurs sommes de contrôle sont erronées, mais parce que les utilisateurs leur font confiance pour répondre à des questions auxquelles ils ne peuvent pas répondre.
Ce qu'un hachage prouve : que deux entrées sont les mêmes octets, et rien sur qui les a produits
L'intégrité est une propriété des données elles-mêmes. Si vous avez un fichier et son SHA-256, et que le fichier n'a pas été modifié, le hachage correspond. Le hachage prouve que chaque octet est inchangé depuis son calcul. Si le fichier a été corrompu par une erreur de transmission, une panne de disque ou un bit inversé sur un câble réseau, le hachage ne correspondra pas. C'est ce que font bien les sommes de contrôle. Ils sont excellents pour détecter les accidents et la corruption aléatoire. Ils échouent face à un adversaire qui peut également calculer des hachages.
L'authenticité est une propriété de la déclaration concernant la personne qui a produit les données. La question « ce fichier provient-il de l'éditeur en qui j'ai confiance ? » est fondamentalement différente de la question « ce fichier a-t-il été modifié ? Un hachage en lui-même ne peut pas répondre à la question d’authenticité car n’importe qui peut calculer un hachage. L'attaquant qui modifie le fichier peut calculer le nouveau hachage et le publier aussi facilement que l'éditeur légitime. Le hachage est symétrique ; le défenseur et l'attaquant ont la même capacité de calcul.
L'exigence d'un canal de confiance : pourquoi une somme de contrôle est aussi fiable que l'endroit où vous l'avez obtenue
L'exigence d'un canal de confiance est l'information clé. Une somme de contrôle est aussi fiable que le canal par lequel elle est transmise. Si vous téléchargez le binaire du logiciel depuis le CDN officiel de l'éditeur et téléchargez la somme de contrôle depuis le même serveur, ils ont parcouru le même chemin. Compromettre le serveur signifie qu'un attaquant contrôle les deux. La somme de contrôle offre une protection contre la corruption lors de la livraison (un fichier endommagé ne correspondra pas), mais pas contre un attaquant contrôlant la source. La somme de contrôle et le fichier partagent un seul point de défaillance.
Si la somme de contrôle a été publiée séparément, sur un serveur différent, avec des contrôles d'accès différents, elle offre alors plus de défense. Un attaquant qui compromettrait le site principal devrait compromettre les deux emplacements pour simuler une paire correspondante. C’est mieux, mais cela repose toujours sur deux points de contrôle indépendants qui restent sécurisés. L’attaquant doit désormais pénétrer dans deux systèmes au lieu d’un seul, ce qui augmente le coût de l’attaque. Mais ce n’est toujours pas une preuve d’authenticité ; c'est juste une attaque plus coûteuse.
Les signatures lient un hachage à une identité : comment signer le résumé avec une clé privée ajoute de l'authenticité
Une signature numérique résout ce problème en liant les données à une identité à l'aide de la cryptographie. L'éditeur génère une paire de clés : une clé privée qu'il garde secrète et une clé publique qu'il publie. Ils signent le fichier en calculant un résumé, puis en chiffrant ce résumé avec leur clé privée. Le résultat est la signature. Un utilisateur vérifie la signature en la déchiffrant avec la clé publique de l'éditeur et en vérifiant que le résultat correspond au résumé calculé du fichier reçu. La cryptographie crée une asymétrie que la somme de contrôle ne peut pas atteindre.
Si cela fonctionne, deux choses sont prouvées : les données correspondent au résumé signé par l'éditeur et la clé privée utilisée pour le signer correspond à la clé publique publiée. Cela prouve que c’est l’éditeur qui l’a créé, et pas seulement un attaquant. La clé publique doit provenir d'un canal sécurisé (généralement un certificat émanant d'une autorité de certification de confiance), mais une fois que vous disposez de la clé publique, vous pouvez vérifier indéfiniment les signatures de cet éditeur. L’attaque nécessite désormais de voler la clé privée, ce qui est bien plus difficile que de compromettre un serveur Web.
Exemple concret : trois scénarios de menace (miroir corrompu, page compromise, initié malveillant) et quelle somme de contrôle et quelle signature chaque capture
Trois scénarios de menace illustrent la différence. Premier scénario : le miroir de téléchargement est corrompu par une erreur aléatoire. La somme de contrôle l'attrape ; la signature l'attrape. Les deux fonctionnent aussi bien car ni l’un ni l’autre n’a besoin de vaincre un attaquant. Scénario 2 : le miroir est compromis par un attaquant qui remplace le fichier et la somme de contrôle. La somme de contrôle ne parvient pas à protéger ; la signature fonctionne toujours, car l'attaquant ne dispose pas de la clé privée et ne peut pas falsifier une signature valide. L'attaquant peut publier n'importe quoi, mais la signature prouve qu'il ne s'agit pas de l'éditeur.
Scénario 3 : le CDN est compromis mais la signature a été publiée via un autre canal. La somme de contrôle sur le CDN n'est pas fiable, mais la vérification de la signature fonctionne toujours, car la vérification de l'intégrité est cryptographiquement liée à la clé de l'éditeur et non au canal. L'attaquant doit maintenant falsifier une signature, ce qui nécessite la clé privée. La signature est la seule vérification qui survit à la compromission du serveur. C'est pourquoi les signatures sont nécessaires pour l'authenticité ; ils sont le seul outil qui prouve l’identité malgré la compromission du canal.
Le rôle de TLS et ses limites — la sécurité du transport protège le téléchargement en vol, pas le serveur de l'éditeur
La sécurité du transport protège la connexion à l'hôte nommé par le certificat. Cela peut empêcher un observateur sur le chemin de remplacer les octets de téléchargement, mais cela ne peut pas rendre honnête l'origine d'un éditeur compromis. Si cette origine sert une archive modifiée et une somme de contrôle fraîchement calculée sur un TLS valide, les deux arrivent intacts et décrivent toujours le contenu contrôlé par l'attaquant.
C'est pourquoi le transport, l'intégrité et l'authenticité sont des couches distinctes. TLS sécurise un canal, un résumé compare les octets et une signature lie un résultat de vérification au contrôle d'une clé privée. Aucune couche ne doit être décrite comme prouvant la propriété fournie par une autre, même lorsqu'un flux de travail de publication combine judicieusement les trois.
Ce que cela ne couvre pas : la distribution des clés et les racines de confiance, qui constituent la partie la plus difficile des signatures
La distribution des clés est la limite stricte que ce calculateur de résumé ne franchit pas. Un vérificateur de signature a toujours besoin d’une clé publique ou d’une chaîne de certificat authentique ainsi que d’une politique de rotation, de révocation et d’algorithmes acceptables. Une signature mathématiquement valide sous une clé non fiable prouve uniquement que le détenteur de cette clé non fiable a signé les octets.
En conséquence, les scénarios travaillés s'arrêtent là où une clé de confiance est déjà disponible. Ils ne prescrivent pas l’épinglage des certificats, l’infrastructure à clé publique ou les cérémonies de libération des clés. Ces choix de déploiement nécessitent leur propre conception révisée ; ToolAcre fournit le résumé simple qui peut être signé, et non la racine de confiance utilisée pour valider une identité.
À retenir : sommes de contrôle pour l'intégrité, signatures pour l'authenticité – le calculateur de hachage ToolAcre SHA calcule les résumés ; vérifier qui les a publiés est une étape distincte
Le calculateur de hachage ToolAcre SHA calcule le côté intégrité de cette vérification. Utilisez-le pour hacher le fichier téléchargé et vérifier par rapport à une valeur publiée. S'ils correspondent, le téléchargement n'est pas corrompu. Mais s’ils correspondent parce qu’un attaquant a réécrit les deux, la vérification de l’intégrité ne suffira pas à la détecter. L'outil est honnête sur cette limitation et ne prétend pas vérifier l'authenticité. Pour l’intégrité uniquement, les sommes de contrôle sont rapides et bonnes. Pour l'authenticité, vous avez besoin de signatures. TLS assure la sécurité du transport pour le téléchargement lui-même. La connexion au serveur est cryptée et authentifiée, donc un attaquant sur le réseau ne peut pas modifier le fichier en transit. Cependant, TLS n'aide pas si le serveur lui-même est compromis. Un serveur compromis peut servir n’importe quel fichier via n’importe quelle connexion TLS sécurisée. C'est pourquoi la vérification au niveau des applications (sommes de contrôle et signatures) est importante séparément de la sécurité du transport.
Un modèle courant dans les versions logicielles consiste à publier à la fois les sommes de contrôle et les signatures. Les sommes de contrôle sont pratiques ; les utilisateurs peuvent les vérifier rapidement avec une commande shell sur une seule ligne. Les signatures garantissent l'authenticité des utilisateurs disposant de la clé publique de l'éditeur. Un utilisateur peut d'abord vérifier la somme de contrôle pour un test d'intégrité rapide, puis vérifier l'authenticité de la signature par rapport à une clé stockée dans son trousseau GPG. Les deux contrôles servent à des fins différentes et peuvent être superposés pour une défense en profondeur. La partie la plus difficile des signatures est la distribution des clés et la confiance. Vous avez besoin de la clé publique de l’éditeur et vous devez être sûr qu’elle lui appartient réellement. C’est le problème que les autorités de certification doivent résoudre : elles signent les certificats des éditeurs et les certificats de l’autorité de certification racine sont préchargés dans les navigateurs et les systèmes d’exploitation. Pour un projet plus petit, vous pouvez publier une clé GPG sur un site Web distinct et renforcé ou sur un serveur de clés publiques. La somme de contrôle est peu coûteuse à vérifier ; les signatures nécessitent la gestion des racines de confiance. La complexité supplémentaire est le prix de l’authenticité.