Comment fonctionne le processus de vérification de signature numérique?
Je ne comprends pas comment la signature numérique est vérifiée. Je sais que la signature numérique sera jointe au message et envoyée par l'expéditeur au destinataire. puis le récepteur utilise la clé publique est utilisée pour le vérifier. Voici mes questions:
- d'où vient cette clé publique?
- et comment il est distribué au récepteur?
- comment la clé publique est-elle identifiée pour la signature numérique spécifique?
- et quel est le rôle de l'autorité de certification dans ce processus?
D'accord, la réponse jusqu'à présent est fondamentalement sur la bonne voie, mais je vais essayer de répondre à vos questions au fur et à mesure:
* where did this public key come from?
Une clé publique fait partie d'une paire de clés utilisée en cryptographie asymétrique. Il existe de nombreux algorithmes de chiffrement, mais se résume à une clé publique et une clé privée qui sont mathématiquement liées. Ils peuvent être utilisés de cette façon:
Crypter (clé publique, données d'origine) -> données cryptées
Déchiffrer (clé privée, données chiffrées) -> données originales
La nature de la relation mathématique entre clé privée et clé publique est liée à l'algorithme cryptographique et devient rapidement un bon sujet pour Math Overflow. :)
La partie essentielle est que leur est une paire de clés qui ont été générées ensemble.
Ensuite, pour traiter une signature numérique, l'expéditeur envoie:
- les données d'origine, les données chiffrées, la clé publique et les informations sur la façon de vérifier la signature (par exemple, quel algorithme est utilisé)
Le vérificateur effectue l'opération de décryptage ci-dessus et compare sa sortie avec les données d'origine. Si les deux sont identiques, il sait que le message n'a pas été falsifié, car seul l'expéditeur possède la clé privée et il n'existe aucun moyen raisonnable de déterminer la clé privée à partir de la clé publique.
ce qui dérange un peu ...
* and what is the role of the certification authority in this process?
Tout le monde peut créer une paire de clés privée/publique. C'est une tâche assez facile, compte tenu des boîtes à outils d'aujourd'hui. Donc, vous donner ma clé publique, ainsi que les données cryptées et la signature décrites sont à peu près aussi fiables que vous donner une carte de visite que j'avais imprimée chez Staples pour 50 $. Pour vraiment croire que je suis ce que je dis, et que je suis donc digne de confiance, vous avez besoin que quelqu'un signe mon identité (comme vérifier un permis de conduire).
C'est le travail de l'autorité de certification (CA pour faire court). L'autorité de certification possède sa propre paire de clés et utilise sa clé privée pour signer un certificat numérique pour le détenteur de la clé. Le certificat comprend clé publique, ainsi qu'un tas d'informations sur la personne ou l'objet détenant cette clé privée. C'est comme si mon gouvernement me faisait une jolie carte d'identité avec une photo qui ne peut pas être facilement truquée sans équipement spécial - vous pouvez croire mes informations parce que vous faites confiance au gouvernement ... non parce que vous me faites confiance.
Habituellement, lorsqu'un système vérifie une signature, il vérifie non seulement que les données chiffrées correspondent aux données d'origine, mais également qu'un certificat qui garantit l'identité de le détenteur de la clé publique est également correctement signé par une source de confiance. Les systèmes d'AC sont généralement organisés en chaînes d'AC qui proviennent d'une racine. Une collection des autorités de certification racine les plus importantes (qui sont auto-signées, c'est-à-dire signées par leurs propres clés privées), se trouve dans votre navigateur.
Pour les systèmes hautement sécurisés, des vérifications supplémentaires des informations d'état jusqu'à la minute peuvent être effectuées. Tout dépend de l’importance d’être absolument sûr du statut de l’expéditeur.
* and how is it (the public key) distributed to the receiver?
Double vérification ici - voulez-vous dire le destinataire du certificat ou le détenteur de la clé?
L'expéditeur (détenteur de la clé) peut obtenir une paire de clés et un certificat de différentes manières. Le moyen le plus simple consiste à les créer localement, puis à demander à l'autorité de certification un certificat en soumettant les données de clé publique. Dans d'autres cas, les clés peuvent être fabriquées de manière centrale et distribuées par des canaux sécurisés aux détenteurs de clés.
Dans la plupart des cas de signature, la paire de clés est faite par le détenteur de la clé, car elle limite le potentiel d'exposition de la clé privée.
Lorsqu'une signature est créée et envoyée à un destinataire, il est typique que la clé publique soit également jointe au message (par exemple, une norme pour cela est XMLDSIG où un champ facultatif dans l'élément est un certificat numérique, qui inclut le Clé publique).
Dans les cas où la bande passante est un problème, les clés publiques peuvent être conservées dans un référentiel central - comme une base de données des employés, ou souvent un Active Directory ou un autre serveur LDAP. Ensuite, la signature peut référencer l'identité de l'expéditeur et le processus de vérification peut inclure une demande au référentiel pour récupérer la clé publique.
* how the public key is identified for the specific digital signature?
Généralement via un certificat numérique.
Lorsque l'expéditeur va créer une signature numérique, il a généralement des règles associées aux paires de clés qu'il peut utiliser à quelles fins. Dans la norme de certificat X509, les certificats identifient un champ d'utilisation de clé qui définit des objectifs spécifiques pour la paire de clés décrite par le certificat. L'une de ces utilisations se trouve être la signature numérique, et de nombreux systèmes logiciels ne vous permettent pas de créer une signature sans ce paramètre dans le certificat.
L'Autorité de certification détermine réellement ces paramètres avant de signer le certificat. Dans de nombreuses politiques de sécurité, certains paramètres d'utilisation des clés ne peuvent pas être accordés sans processus d'authentification spécifiques, de sorte que la responsabilité de le déterminer incombe à l'autorité de certification et aux personnes en charge (généralement les autorités de certification, les autorités d'enregistrement).
Si, pour une raison quelconque, vous avez un système qui n'utilise pas de certificats numériques, il peut y avoir d'autres façons de déterminer quelle paire de clés. En fin de compte, cela revient aux politiques de sécurité en place et à ce qui est jugé approprié pour l'activité donnée qui a nécessité la signature.
Le problème auquel vous faites référence (comment distribuer les clés publiques?) Est exactement ce que les infrastructures à clés publiques sont censées résoudre, et l'ICP est, essentiellement, un groupe d'autorités de certification.
Dans une configuration simple, nous aurions un répertoire central des clés publiques de tout le monde; imaginez-le comme une grande dalle de marbre au milieu d'un parc public, avec les clés publiques gravées dessus. N'importe qui peut y jeter un coup d'œil et être sûr que c'est "la vraie chose" car on ne peut pas simplement peindre sur quelque chose qui a été gravé.
Une partie publique n'est pas bien connectée à Internet dans son ensemble, et les ordinateurs ne peuvent pas "voir" que certaines informations sont gravées et donc "garanties correctes". En outre, il pourrait y avoir des milliards de porte-clés, ce qui nécessiterait un assez gros morceau de pierre. Ainsi, la traduction dans le monde entièrement informatisé est le certificat.
Un certificat est une petite structure qui contient, dans un format conventionnel:
- un identité (le nom du propriétaire de la clé);
- a clé publique (prétendument détenu par cette personne);
- un signature numérique calculé sur les deux parties précédentes par un Autorité de Certification.
Le rôle de l'AC est d'émettre précisément des certificats, c'est-à-dire de les signer. Vous pouvez considérer un certificat comme le morceau de la grande plaque de marbre qui contient une clé publique spécifique. Pour utiliser la clé publique, vous devez d'abord vous assurer qu'elle contient des informations correctes; pour ce faire, vous vérifiez la signature du certificat, en utilisant la clé publique de l'autorité de certification. Si cette signature est correcte, vous savez que l'AC did signe ce certificat, et puisque l'AC ne signe que des certificats après avoir vérifié l'identité du propriétaire de la clé (via un protocole physique unique avec eux, par exemple le propriétaire de la clé a montré un ID), vous pouvez être "convaincu" que la clé publique du certificat appartient vraiment au propriétaire identifié.
Vous pouvez maintenant me dire que nous n'avons pas résolu le problème du tout, nous l'avons juste déplacé: pour vérifier le certificat, vous devez connaître la clé publique de l'AC; comment savez-vous que clé? La réponse est dans les chiffres: une autorité de certification donnée peut signer plusieurs certificats, peut-être des millions d'entre eux. Il pourrait donc y avoir, disons, cent CA, qui délivrent des certificats pour le monde entier. En sachant que cent clés publiques, vous pouvez potentiellement vérifier le certificat any. Dans d'autres mondes, nous n'avons pas seulement déplacé le problème, nous avons aussi concentré le: nous avons transformé le problème de la distribution de milliards de clés publiques en problème de la distribution d'une centaine d'entre elles .
Et voilà! c'est précisément ainsi que cela se fait pour le site Web HTTPS. Lors des phases initiales de la connexion entre votre navigateur et le serveur Web, le serveur envoie son certificat. Le navigateur vérifie ensuite le certificat par rapport à sa liste de clés publiques CA codées en dur (qui ont été fournies avec l'aimable autorisation du navigateur ou du fournisseur du système d'exploitation). Une fois que le navigateur a vérifié le certificat, il connaît la clé publique du serveur et l'utilise pour établir le tunnel confidentiel avec le serveur.
Les signatures numériques sont généralement réalisées en deux étapes. La première étape consiste à utiliser un algorithme de hachage sécurisé sur les données. Les algorithmes SHA-2 en seraient un exemple. La deuxième étape consiste à chiffrer la sortie résultante avec la clé de signature privée.
Ainsi, lorsqu'une signature est vérifiée par la clé publique, elle déchiffre en un hachage correspondant au message. Ce hachage ne peut être déchiffré à l'aide de la clé publique que s'il a été chiffré avec la clé de signature privée.
Les clés publiques sont créées par le propriétaire de la paire de clés. Les autorités de certification signent le certificat de la clé publique. Les propriétaires de serveurs installent ce certificat signé. Dans SSL (dont je suppose que vous parlez), le certificat, y compris la clé et la signature de l'autorité de certification, est transmis par le serveur auquel vous êtes connecté. Votre logiciel vérifie que le site auquel il se connecte correspond aux données du certificat et valide le certificat en vérifiant sa signature par rapport à la clé de l'autorité de certification. Les autorités de certification utilisent leurs clés pour la signature et les serveurs utilisent leurs clés pour le chiffrement.
Vous savez ce qu'est une clé publique - privée, non?
Vous voulez crypter quelque chose dans bob. Vous aurez donc besoin de sa clé publique. Vous allez le chercher sur Internet, mais vous ne pouvez pas être sûr que la clé publique que vous avez obtenue lui appartient vraiment.
Vous adoptez donc une approche différente: obtenez la clé de quelqu'un qui peut vous assurer qu'une clé spécifique appartient à bob. C'est exactement ce que fait l'AC.
Comment l'AC fait-elle cela? Facile. bob s'identifie auprès de l'AC et leur envoie sa clé publique. De cette façon, l'autorité de certification a quelque chose qui relie "l'identité" de bob avec cette clé publique. Et vous pouvez être sûr que la clé publique que vous avez obtenue appartient vraiment à bob.