Comment une clé publique vérifie-t-elle une signature?


174

J'essaie de mieux comprendre le fonctionnement des clés publiques / privées. Je comprends qu'un expéditeur peut ajouter une signature numérique à un document en utilisant sa clé privée pour essentiellement obtenir un hachage du document, mais ce que je ne comprends pas, c'est comment la clé publique peut être utilisée pour vérifier cette signature.

Ma compréhension était que les clés publiques chiffrent, les clés privées déchiffrent ... quelqu'un peut-il m'aider à comprendre?


3
Bonne question. :)
Suraj Jain

Je ne voulais pas ajouter cela comme réponse et risquer les flammes qui s'ensuivent, mais si vous utilisez le mot «comment» signifie vraiment «comment vérifier une signature», alors une possibilité est de télécharger gpg4win. Une fois installé, vous pouvez cliquer avec le bouton droit sur un fichier et le vérifier. C'est une suite de produits qui s'intègrent dans le shell Windows. L'un de ces utilitaires est Kleopatra qui recherchera les certificats en ligne pour effectuer la validation.
Newclique

Réponses:


211

Votre compréhension de «les clés publiques chiffrent, les clés privées déchiffrent» est correcte ... pour le chiffrement des données / messages. Pour les signatures numériques, c'est l'inverse. Avec une signature numérique, vous essayez de prouver que le document signé par vous provient de vous. Pour ce faire, vous devez utiliser quelque chose que vous seul possédez: votre clé privée.

Une signature numérique dans sa description la plus simple est un hachage (SHA1, MD5, etc.) des données (fichier, message, etc.) qui est ensuite chiffré avec la clé privée du signataire. Puisque c'est quelque chose que seul le signataire a (ou devrait avoir), c'est de là que vient la confiance. TOUT LE MONDE a (ou devrait avoir) accès à la clé publique du signataire.

Ainsi, pour valider une signature numérique, le destinataire

  1. Calcule un hachage des mêmes données (fichier, message, etc.),
  2. Déchiffre la signature numérique à l'aide de la clé PUBLIC de l'expéditeur, et
  3. Compare les 2 valeurs de hachage.

S'ils correspondent, la signature est considérée comme valide. S'ils ne correspondent pas, cela signifie soit qu'une clé différente a été utilisée pour la signer, soit que les données ont été modifiées (intentionnellement ou non).

J'espère que cela pourra aider!


13
Ma compréhension était que les clés n'étaient pas symétriques ... c'est-à-dire que les objets chiffrés avec une clé publique peuvent être déchiffrés par la clé privée, mais que cette relation ne fonctionnait pas inversement ... plus précisément, je ne pensais pas que les objets chiffré avec la clé privée pourrait être déchiffré par la clé publique. Si tel est effectivement le cas, cela répond définitivement à ma question.
jcampos8782

63
Les touches fonctionnent inversement les unes par rapport aux autres. Quelque chose a chiffré avec votre clé publique? Décryptez-le avec votre clé privée. Inversement, si vous avez chiffré quelque chose avec votre clé privée, vous le déchiffrez avec votre public. Telle est la nature de la cryptographie asymétrique.
Shadowman

20
Symétrique signifie simplement que la même clé est utilisée pour crypter / décrypter. Asymétrique signifie qu'une clé crypte et une clé différente décrypte (et que l'inverse est également vrai).
gtrig

8
@Jodimoro, Techniquement, un message n'est PAS "Secret" s'il est chiffré avec une clé privée. S'il est chiffré avec une clé privée, toute personne disposant de la clé "publique" disponible publiquement peut déchiffrer le message.
RayLoveless

4
@Jodimoro La seule raison pour laquelle le hachage est chiffré avec une clé privée dans une signature est de s'assurer que le hachage n'est pas changé ... pas de s'assurer qu'il est "secret".
RayLoveless

73

Les touches fonctionnent inversement:

La clé publique crypte, la clé privée décrypte (cryptage):

openssl rsautl -encrypt -inkey public.pem -pubin -in message.txt -out message.ssl
openssl rsautl -decrypt -inkey private.pem       -in message.ssl -out message.txt

Chiffrement de la clé privée, déchiffrement de la clé publique (signature):

openssl rsautl -sign -inkey private.pem       -in message.txt -out message.ssl
openssl rsautl       -inkey public.pem -pubin -in message.ssl -out message.txt

Vous trouverez ci-dessous un exemple de script pour tester l'ensemble de ce flux openssl.

#!/bin/sh
# Create message to be encrypted
echo "Creating message file"
echo "---------------------"
echo "My secret message" > message.txt
echo "done\n"

# Create asymmetric keypair
echo "Creating asymmetric key pair"
echo "----------------------------"
openssl genrsa -out private.pem 1024
openssl rsa -in private.pem -out public.pem -pubout
echo "done\n"

# Encrypt with public & decrypt with private
echo "Public key encrypts and private key decrypts"
echo "--------------------------------------------"
openssl rsautl -encrypt -inkey public.pem -pubin -in message.txt         -out message_enc_pub.ssl
openssl rsautl -decrypt -inkey private.pem       -in message_enc_pub.ssl -out message_pub.txt
xxd message_enc_pub.ssl # Print the binary contents of the encrypted message
cat message_pub.txt # Print the decrypted message
echo "done\n"

# Encrypt with private & decrypt with public
echo "Private key encrypts and public key decrypts"
echo "--------------------------------------------"
openssl rsautl -sign    -inkey private.pem -in message.txt          -out message_enc_priv.ssl
openssl rsautl -inkey public.pem -pubin    -in message_enc_priv.ssl -out message_priv.txt
xxd message_enc_priv.ssl
cat message_priv.txt
echo "done\n"

Ce script génère les éléments suivants:

Creating message file
---------------------
done

Creating asymmetric key pair
----------------------------
Generating RSA private key, 1024 bit long modulus
...........++++++
....++++++
e is 65537 (0x10001)
writing RSA key
done

Public key encrypts and private key decrypts
--------------------------------------------
00000000: 31c0 f70d 7ed2 088d 9675 801c fb9b 4f95  1...~....u....O.
00000010: c936 8cd0 0cc4 9159 33c4 9625 d752 5b77  .6.....Y3..%.R[w
00000020: 5bfc 988d 19fe d790 b633 191f 50cf 1bf7  [........3..P...
00000030: 34c0 7788 efa2 4967 848f 99e2 a442 91b9  4.w...Ig.....B..
00000040: 5fc7 6c79 40ea d0bc 6cd4 3c9a 488e 9913  _.ly@...l.<.H...
00000050: 387f f7d6 b8e6 5eba 0771 371c c4f0 8c7f  8.....^..q7.....
00000060: 8c87 39a9 0c4c 22ab 13ed c117 c718 92e6  ..9..L".........
00000070: 3d5b 8534 7187 cc2d 2f94 0743 1fcb d890  =[.4q..-/..C....
My secret message
done

Private key encrypts and public key decrypts
--------------------------------------------
00000000: 6955 cdd0 66e4 3696 76e1 a328 ac67 4ca3  iU..f.6.v..(.gL.
00000010: d6bb 5896 b6fe 68f1 55f1 437a 831c fee9  ..X...h.U.Cz....
00000020: 133a a7e9 005b 3fc5 88f7 5210 cdbb 2cba  .:...[?...R...,.
00000030: 29f1 d52d 3131 a88b 78e5 333e 90cf 3531  )..-11..x.3>..51
00000040: 08c3 3df8 b76e 41f2 a84a c7fb 0c5b c3b2  ..=..nA..J...[..
00000050: 9d3b ed4a b6ad 89bc 9ebc 9154 da48 6f2d  .;.J.......T.Ho-
00000060: 5d8e b686 635f b6a4 8774 a621 5558 7172  ]...c_...t.!UXqr
00000070: fbd3 0c35 df0f 6a16 aa84 f5da 5d5e 5336  ...5..j.....]^S6
My secret message
done

2
Merci d'avoir ajouté le script - a certainement aidé à clarifier les choses.
Pat

Merci beaucoup, c'est toujours plus facile pour moi de comprendre avec ecample
Simon

16

La clé publique crypte et seule la clé privée peut la décrypter, et l'inverse est vrai. Ils chiffrent tous les deux à des hachages différents, mais chaque clé peut déchiffrer le chiffrement de l'autre.

Il existe plusieurs façons de vérifier qu'un message provient d'un expéditeur attendu. Par exemple:

L'expéditeur envoie:

  1. Le message

  2. Le hachage du message chiffré avec leur clé privée

Le récepteur:

  1. Déchiffre la signature (2) avec la clé publique pour obtenir un message, supposément le même message que (1) mais on ne sait pas encore. Nous avons maintenant deux messages dont nous devons vérifier qu'ils sont identiques. Pour ce faire, nous les chiffrerons tous les deux avec notre clé publique et comparerons les deux hachages. Alors nous allons ...
  2. Crypter le message d'origine (1) avec la clé publique pour obtenir un hachage
  3. Cryptez le message déchiffré (3) pour obtenir un deuxième hachage et comparez-le à (4) pour vérifier qu'ils sont identiques.

S'ils ne sont pas identiques, cela signifie que le message a été falsifié ou qu'il a été signé avec une autre clé et non celle que nous pensions ...

Un autre exemple serait que l'expéditeur utilise un hachage commun que le destinataire sait peut-être également utiliser. Par exemple:

L'expéditeur envoie:

  1. Un message
  2. Prend un hachage connu du message, puis chiffre le hachage avec la clé privée

Le récepteur:

  1. Déchiffre (2) et obtient une valeur de hachage
  2. Hache le message (1) avec le même hachage utilisé par l'expéditeur
  3. Compare les deux hachages pour s'assurer qu'ils correspondent

Cela garantit à nouveau que le message n'a pas été falsifié et qu'il provient de l'expéditeur attendu.


6

Si je devais reformuler votre question à partir de la façon dont je la comprends, vous posez la question suivante:

Si la cryptographie à clé publique garantit qu'une clé publique peut être dérivée d'une clé privée, mais qu'une clé privée ne peut pas être dérivée d'une clé publique, alors vous pourriez vous demander comment une clé publique peut décrypter un message signé avec une clé privée sans l'expéditeur. exposer la clé privée dans le message signé au destinataire? (relisez cela plusieurs fois jusqu'à ce que cela ait du sens)

D'autres réponses ont déjà expliqué comment la cryptographie asymétrique signifie que vous pouvez soit :

  1. Crypter avec la clé publique, décrypter avec la clé privée correspondante (pseudocode ci-dessous)
var msg = 'secret message';

var encryptedMessage = encrypt(pub_key, msg);

var decryptedMessage = decrypt(priv_key, encryptedMessage);

print(msg == decryptedMessage == 'secret message'); // True
  1. Crypter avec la clé privée, décrypter avec la clé publique correspondante (pseudocode ci-dessous)
var msg = 'secret message';

var encryptedMessage = encrypt(priv_key, msg);

var decryptedMessage = decrypt(pub_key, encryptedMessage); // HOW DOES THIS WORK???

print(msg == decryptedMessage == 'secret message'); // True

Nous savons que les exemples n ° 1 et n ° 2 fonctionnent. L'exemple n ° 1 a un sens intuitif, tandis que l'exemple n ° 2 pose la question initiale .

Il s'avère que la cryptographie à courbe elliptique (également appelée «multiplication de courbe elliptique») est la réponse à la question initiale. La cryptographie à courbe elliptique est la relation mathématique qui rend les conditions suivantes possibles:

  1. Une clé publique peut être générée mathématiquement à partir d'une clé privée
  2. Une clé privée ne peut pas être générée mathématiquement à partir d'une clé publique (c'est-à-dire "fonction de trappe")
  3. Une clé privée peut être vérifiée par une clé publique

Pour la plupart, les conditions n ° 1 et n ° 2 ont du sens, mais qu'en est-il du n ° 3?

Vous avez deux choix ici:

  1. Vous pouvez descendre un terrier de lapin et passer des heures et des heures à apprendre comment fonctionne la cryptographie à courbe elliptique ( voici un excellent point de départ ) ... OU ...
  2. Vous pouvez accepter les propriétés ci-dessus - tout comme vous acceptez les 3 lois du mouvement de Newton sans avoir besoin de les dériver vous-même.

En conclusion, une paire de clés publique / privée est créée à l'aide de la cryptographie à courbe elliptique, qui, par nature, crée une clé publique et privée qui sont mathématiquement liées dans les deux sens, mais pas mathématiquement dérivées dans les deux sens . C'est ce qui vous permet d'utiliser la clé publique d'une personne pour vérifier qu'elle a signé un message spécifique, sans qu'elle vous expose sa clé privée.


Vos 3 conditions expliquent tout. Je viens de lire ce terme 'courbe elliptique' et j'étais comme wtf
Simon

5

Je pensais que je fournirais une explication supplémentaire à tous ceux qui recherchent quelque chose de plus intuitivement révélateur.

Une grande partie de cette confusion provient de la dénomination des «clés publiques» et des «clés privées» en tant que telles, car la façon dont ces choses fonctionnent réellement est en contradiction directe avec la façon dont une «clé» est comprise.

Prenons le cryptage par exemple. Cela pourrait être considéré comme fonctionnant comme ceci:

  • Les parties qui souhaitent pouvoir lire les messages secrets gardent chacune une clé cachée (c'est-à-dire une clé privée)
  • Les parties qui souhaitent pouvoir envoyer des messages secrets ont toutes la possibilité d'obtenir un verrou déverrouillé (c'est-à-dire un verrou public)
  • Ensuite, envoyer un message secret est aussi simple que de le verrouiller avec une serrure déverrouillée, mais le déverrouiller par la suite ne peut être fait qu'avec l'une des clés cachées.

Cela permet d'envoyer des messages secrets entre les parties, mais d'un point de vue intuitif ici, «verrou public» est un nom plus approprié que «clé publique».

Cependant, pour l'envoi de signatures numériques, les rôles sont quelque peu inversés:

  • La partie qui souhaite signer des messages est la seule à avoir accès aux verrous déverrouillés (c'est-à-dire un verrou privé)
  • Les parties qui souhaitent vérifier la signature ont toutes la possibilité d'obtenir une clé (c'est-à-dire une clé publique)
  • Ensuite, le signataire crée deux messages identiques: celui que tout le monde peut lire et celui qui l'accompagne, mais qu'il verrouille avec l'un de ses verrous privés.
  • Ensuite, lorsque le destinataire reçoit le message, il peut le lire, puis utiliser la clé publique pour déverrouiller le message verrouillé et comparer les deux messages. Si les messages sont les mêmes, ils savent que:

    1. Le message déverrouillé n'a pas été falsifié pendant le voyage et,

    2. Le message doit provenir de la personne qui possède le verrou correspondant à sa clé publique.

  • Et enfin, tout ce système ne fonctionne que si quiconque souhaite valider la signature d'un signataire dispose d'un endroit faisant autorité pour obtenir la clé correspondante aux serrures du signataire. Sinon, n'importe qui peut dire "Hé, voici la clé du verrou privé de tel et tel", vous envoyer un message prétendant être eux mais le verrouiller avec leur verrou privé, vous effectuez toutes les étapes ci-dessus et pensez que le message doit réellement être de la personne à laquelle vous pensiez, mais vous êtes dupe parce que vous avez été induit en erreur quant au véritable propriétaire d'une clé publique.

Tant qu'il existe une source de confiance pour récupérer la clé publique d'un signataire, vous saurez qui est le propriétaire légitime d'une clé publique et pourrez valider sa signature.


4
Changer «clé» en «verrou déverrouillé» ne fait qu'ajouter à la confusion.
Marquis of Lorne

@EJP Je ne change pas la clé en «verrou déverrouillé». Il a changé pour «verrouiller». «Déverrouillé verrouillé» n'est utilisé que dans le but d'exprimer l'utilisation de l'objet. En tout cas, c'est votre opinion, et si vous avez une expérience à long terme dans la communauté cryptographique, elle est probablement extrêmement biaisée car les termes existants vous permettent de comprendre la technologie. Pourquoi ne laissez-vous pas les gens qui commencent tout juste déterminer si l'analogie est utile ou non?
chaussure

1
Je pense que l'analogie avec les serrures et les clés est assez bonne pour fournir une première compréhension de cette question. Une fois que vous visualisez les verrous et les clés, ils peuvent être échangés différents entiers qui sont assemblés à des clés rsa (ou autre type de).
Andreas Lundgren

Je pense personnellement que cette idée est la meilleure que j'ai lue jusqu'à présent. Et voyez certainement comment l'ajout d'un verrou au lieu de la clé pour privé / public rend tout le système intuitivement explicite pour les nouveaux arrivants réguliers. Alors que pour le moment ce n'est pas du tout. Nous sommes des développeurs chevronnés (sans aucun contact direct avec la cryptographie jusqu'à présent) et nous nous sommes disputés sur le but du public / privé pendant un certain temps. Je disais que privé est utilisé pour crypter, alors qu'il disait que public est utilisé pour crypter: D
jayarjo

0

À votre question - je regardais la mise en œuvre RSA. Et obtenu plus de clarté sur la façon dont une clé publique est utilisée pour vérifier la signature à l'aide d'une clé privée. Sans aucun doute, la clé privée n'est pas exposée. Voici comment...

L'astuce ici est de cacher la clé privée dans une fonction. Dans ce cas,(p-1)*(q-1).

Considérez p comme la clé privée et e comme la clé publique. «p» est encapsulé dans une autre fonction pour le rendre caché.

E.g., `d = (p-1)(q-1); d * e = 1` (d is the inverse of e - public key)

Données envoyées = [cryptées (hachage), message] = [m ^ d, message]; où m est le message Supposons que 'Données envoyées' = y Pour vérifier l'intégrité, nous trouvons y ^ e pour obtenir m. Puisquem ^(d*e) = m ^1 = m .

J'espère que cela t'aides! :)

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.