Que signifie vraiment «signer» un fichier?
Je suis un peu nouveau dans le domaine de la sécurité et j'essaie de bien comprendre les concepts.
Je me demande ce que signifie exactement "signer" un fichier (un certificat, un fichier apk ou autre)?
- Signons-nous tout le fichier pour qu'il devienne en quelque sorte crypté?
- Existe-t-il un morceau de texte brut que nous signons et passons, par exemple, un Zip, et que le côté récepteur vérifie ce morceau en fonction d'un protocole particulier avant d'aller plus loin?
- Ou autre chose?
Pour autant que je puisse voir, si nous signons le fichier entier, il peut être plus sécurisé car le contenu serait crypté (ou signé). Mais j'ai également vu/entendu des exemples où vous ne signez qu'un morceau de texte au lieu de tout.
Toutes les idées seraient grandement appréciées.
PS: J'ai déjà vérifié Que signifie la signature de clé?
Malheureusement, les réponses ici qui prétendent que la signature équivaut au chiffrement du résumé du message ne sont pas entièrement correctes. La signature n'implique pas le cryptage d'un résumé du message. S'il est vrai qu'une opération cryptographique est appliquée sur un résumé du message créé par un algorithme de hachage cryptographique et non sur le message lui-même, l'acte de signature est distinct du cryptage.
Extrait de https://www.cs.cornell.edu/courses/cs5430/2015sp/notes/rsa_sign_vs_dec.php :
Dans le monde abstrait des manuels, la signature RSA et le décryptage RSA s'avèrent être la même chose. Dans le monde réel des implémentations, elles ne le sont pas. N'utilisez donc jamais une implémentation réelle du déchiffrement RSA pour calculer les signatures RSA. Dans le meilleur des cas, votre implémentation se cassera d'une manière que vous remarquerez. Dans le pire des cas, vous introduirez une vulnérabilité qu'un attaquant pourrait exploiter.
De plus, ne commettez pas l'erreur de généraliser à partir de RSA pour conclure que tout schéma de cryptage peut être adapté en tant qu'algorithme de signature numérique. Ce type d'adaptation fonctionne pour RSA et El Gamal, mais pas en général.
La création d'une signature numérique pour un message implique l'exécution du message via une fonction de hachage , la création d'un résumé (une représentation de taille fixe) pour le message. Une opération mathématique est effectuée sur le résumé en utilisant une valeur secrète (un composant de la clé privée) et une valeur publique (un composant de la clé publique). Le résultat de cette opération est la signature, et elle est généralement soit attachée au message, soit remise à côté. Tout le monde peut savoir, simplement en ayant la signature et la clé publique, si le message a été signé par une personne en possession de la clé privée. Donc comment ça fonctionne?
Je vais utiliser RSA comme exemple d'algorithme. Tout d'abord, un petit aperçu du fonctionnement de RSA. Le chiffrement RSA consiste à prendre le message, représenté sous forme d'entier, et à le porter à la puissance d'une valeur connue (cette valeur est le plus souvent 3 ou 65537). Cette valeur est ensuite divisée par une valeur publique unique à chaque clé publique. Le reste est le message crypté. C'est ce qu'on appelle opération modulo . La signature avec RSA est un peu différente. Le message est d'abord haché et le condensé de hachage est élevé à la puissance d'un nombre secret , et finalement divisé par la même valeur publique unique dans le Clé publique. Le reste est la signature. Cela diffère du chiffrement car, plutôt que d'élever un nombre à la puissance d'une valeur publique connue, il est élevé à la puissance d'une valeur secrète que seul le signataire connaît.
Bien que la génération de signature RSA soit similaire au déchiffrement RSA sur papier, il existe une grande différence dans son fonctionnement dans le monde réel. Dans le monde réel, une fonctionnalité appelée padding est utilisée, et ce remplissage est absolument vital pour la sécurité de l'algorithme. La façon dont le remplissage est utilisé pour le chiffrement ou le déchiffrement est différente de la façon dont il est utilisé pour une signature. Les détails qui suivent sont plus techniques ...
Pour utiliser manuel RSA comme exemple de cryptographie asymétrique, crypter un message m en texte chiffré c se fait en calculant c ≡ me (mod N) , où e est une valeur publique (généralement un Fermat prime ), et [~ # ~] n [~ # ~] est le produit non secret de deux nombres premiers secrets. La signature d'un hachage m , d'autre part, implique le calcul s ≡ mré (mod N) , où d est l'inverse modulaire de e , étant une valeur secrète dérivée des nombres premiers secrets. Ceci est beaucoup plus proche du décryptage que du cryptage, bien que l'appel du décryptage de signature soit toujours pas tout à fait raison . Notez que d'autres algorithmes asymétriques peuvent utiliser des techniques complètement différentes. RSA est simplement un algorithme assez courant pour être utilisé comme exemple.
La sécurité de la signature vient du fait que d est difficile à obtenir sans connaître les nombres premiers secrets. En fait, la seule façon connue d'obtenir d à partir de [~ # ~] n [~ # ~] consiste à factoriser [~ # ~] n [~ # ~] en ses nombres premiers de composants, p et q , et calculez d ≡ e-1 mod (p - 1) (q - 1) . La factorisation de très grands nombres entiers est considérée comme un problème insoluble pour les ordinateurs classiques. Cela permet de vérifier facilement une signature, car cela implique de déterminer si se ≡ m (mod N) . Cependant, la création d'une signature nécessite la connaissance de la clé privée.
La signature d'un fichier ne le crypte pas. Lorsqu'Alice signe un fichier, elle signe généralement l'intégralité du fichier. Elle calcule donc un hachage de l'ensemble du fichier et ne signe que le hachage avec sa clé privée et attache cette information au fichier.
Bob utilise sa clé publique pour le vérifier et obtient son hachage calculé. Il calcule ensuite lui-même le hachage du fichier (sans la signature bien sûr) et vérifie les deux hachages. S'ils correspondent, c'est la même version exacte du fichier envoyé par Alice. S'ils ne correspondent pas à Mallory, cela aurait pu le changer.
Le fichier lui-même n'est jamais crypté, et bien sûr, vous pouvez simplement supprimer la signature, mais il n'est plus signé (et donc sans valeur).
Pour plus d'informations techniques et détaillées, veuillez vous référer à la réponse des forêts: https://security.stackexchange.com/a/198473/19145
Bien sûr, on peut choisir de signer n'importe quelle (partie des) informations que l'on veut et laisser les autres parties non signées. Mais généralement, lorsque nous disons "signer un fichier", nous nous référons à la signature de l'ensemble du fichier plus les métadonnées du fichier (par exemple, l'horodatage de modification du fichier). C'est ainsi que OpenPGP et GPG fonctionnent.
Mais, s'il ne s'agit pas d'un fichier, disons qu'il s'agit d'une signature XML, vous devez spécifier quelles parties du contenu XML sont réellement couvertes par la signature.
Essayez également de différencier les signatures du chiffrement. Ce sont deux questions indépendantes. Un fichier peut être non chiffré + signé, ou chiffré + non signé, ou toute autre combinaison.
Signer un fichier, ou plus généralement signer du contenu (un e-mail, le corps d'un e-mail, une sous-arborescence d'un document XML, une partie d'un certificat, une prise de contact TLS, etc.), signifie créer une séquence d'octets qui s'appelle la signature. Ce processus a certaines propriétés:
- Il existe une méthode pour vérifier la signature. La vérification de la signature donne un résultat booléen, "c'est une bonne signature du fichier" ou "ce n'est pas une bonne signature du fichier".
- Une bonne signature pour un fichier n'est jamais une bonne signature pour un fichier différent. Par conséquent, une bonne signature garantit que le fichier est authentique . Authenticité, en termes de sécurité, signifie que certaines données proviennent vraiment d'où elles sont censées provenir.
- Il existe une valeur secrète appelée a clé privée ou clé secrète. Il est impossible de créer une bonne signature d'un fichier si vous ne connaissez pas cette valeur secrète.
- Dans un schéma à clé publique, il existe une valeur associée à la clé privée qui est appelée clé publique. Si vous connaissez la clé publique, vous pouvez vérifier les signatures, mais vous ne pouvez pas créer la signature d'un fichier différent.
Il est important de savoir que n'importe qui peut signer un fichier, mais il ne peut le signer qu'avec sa propre clé privée. Vous ne pouvez pas signer un fichier avec la clé privée de quelqu'un d'autre à moins que vous n'arriviez à vous emparer de la clé privée, par exemple en piratant son ordinateur. Donc savoir qu'un fichier est livré avec a une bonne signature ne dit rien: l'important est de savoir qu'il a une bonne signature réalisé avec la clé privée attendue =. Cela signifie que le vérificateur doit connaître la clé publique à l'avance. Si la clé publique est transmise avec la signature et le message, cela ne prouve rien en soi, mais cela peut être utile s'il existe un mécanisme permettant au vérificateur de vérifier la clé publique . Un tel mécanisme est appelé _ infrastructure à clé publique . En d'autres termes, l'opération de signature transforme une promesse de confidentialité de la clé privée, et une promesse d'authenticité de la clé publique, en une garantie d'authenticité du fichier.
Une signature signifie généralement "j'approuve ce contenu". Ce que signifie "approuver" dépend du contexte. Par exemple:
- Lorsque Microsoft distribue une mise à jour Windows signée avec la clé de signature de mise à jour Windows de Microsoft, la signature signifie que cette mise à jour de code particulière a été approuvée par Microsoft. Si quelqu'un veut distribuer des logiciels malveillants et les faire passer pour une mise à jour Windows, il ne pourra pas créer une bonne signature pour celui-ci, et donc l'application de mise à jour Windows rejettera la mise à jour.
- Si vous recevez un courrier signé, cela signifie qu'il a vraiment été écrit par la personne qui l'a signé (ou que sa machine a été compromise). Vous ne recevez pas cette garantie du
From:ligne d'un e-mail en général car n'importe qui peut y écrire ce qu'il veut. (Certains systèmes de distribution compliquent les choses, mais en général sur Internet, il n'y a aucun moyen d'empêcher les gens d'écrire ce qu'ils veulent dans leFrom:ligne.) - Lorsqu'une autorité de certification signe un certificat, ce qu'elle dit, c'est qu'elle a vérifié que le propriétaire du nom de domaine répertorié dans le certificat est le propriétaire de la clé privée pour laquelle la clé publique correspondante se trouve dans le certificat. Ce type de déclaration associant un nom à une clé publique est la base de infrastructures à clé publique .
- Lorsqu'un serveur TLS signe la prise de contact d'une connexion TLS, il permet au client de vérifier qu'il est bien celui qu'il prétend être. Tout le monde peut signer une négociation TLS, mais seul Google peut signer une négociation TLS avec la signature publique pour
google.com.
La signature est une donnée distincte. Il peut être regroupé dans un fichier Zip avec les données signées, ajouté en tant que pièce jointe à un e-mail, ajouté à un fichier XML en tant que nœud distinct, etc. Dans un certificat, la signature est groupée avec les données signées. Dans une négociation TLS, la signature est une partie distincte des messages envoyés par le serveur.
Signons-nous tout le fichier pour qu'il devienne en quelque sorte crypté?
Non. La signature dépend du contenu du fichier, mais vous ne pouvez pas récupérer le contenu du fichier à partir de la signature. Le contenu doit être transmis avec la signature. Le contenu peut être crypté, mais cela est indépendant de sa signature.
Existe-t-il un morceau de texte brut que nous signons et passons, par exemple, un Zip, et que le côté récepteur vérifie ce morceau sur la base d'un protocole particulier avant d'aller plus loin?
Oui, exactement. L'expéditeur transmet le contenu du fichier (le Zip ou le texte ou autre) à signer et la clé privée à la fonction de signature, et récupère la signature. (Le mot "signature" peut faire référence à ce processus ou à la sortie de ce processus.) Le destinataire transmet le contenu et la clé publique à la fonction de vérification et obtient un résultat "c'est bon" ou "c'est mauvais". Généralement, le destinataire refuse de faire quoi que ce soit avec le contenu si la signature est mauvaise.
Pour autant que je puisse voir, si nous signons le fichier entier, il peut être plus sécurisé car le contenu serait crypté (ou signé).
Signer quelque chose ne crypte rien. La signature de l'ensemble du fichier est plus sécurisée que la signature d'une partie d'un fichier dans le sens où la signature ne vous donne qu'une certaine sécurité sur la partie signée. Si vous signez une partie d'un fichier, la partie non signée peut être n'importe quoi.