Comment fonctionne l'ICP SSL / TLS?

Question

Nous avons beaucoup de questions qui traitent de parties de SSL/TLS en ce qui concerne l'ICP, mais aucune d'entre elles ne semble tout rassembler. Une réponse canonique sur laquelle nous pouvons diriger les gens, je pense, serait très utile.

Nous avons Comment fonctionne SSL/TLS? qui donnera une bonne base et contient une section sur les certificats clients. Il doit être lu avant d'essayer de comprendre l'ICP.
Nous avons ne approche différente de l'ICP qui explique certains problèmes avec les idées globales de l'ICP.
Il y a Comment fonctionne l'authentification client SSL? , ce qui est une question et une réponse assez terribles. Explication facile des certificats clients SSL pour un développeur est un peu mieux, mais laisse à désirer.
Il y a pas mal de questions et réponses sur réellement implémentation d'une PKI , mais c'est un peu hors de la portée de cette question.

Je pense que les principales questions auxquelles il faut répondre semblent être la source d'une certaine confusion parmi les affiches (toutes en ce qui concerne SSL/TLS):

Quelle est la différence entre l'infrastructure à clé publique et la cryptographie à clé publique? Comment sont-ils liés?
Quel est le principal cas d'utilisation de l'ICP?
Comment les certificats clients sont-ils utilisés dans PKI?
Quel est le rôle d'une autorité de certification dans l'ICP?

Tom Leek · Accepted Answer

Cryptographie à clé publique désigne la classe d'algorithmes cryptographiques qui inclut le cryptage asymétrique (et son échange de clés cousin) et les signatures numériques. Dans ces algorithmes, il y a deux opérations qui correspondent l'une à l'autre (chiffrer -> déchiffrer, ou signer -> vérifier) avec la caractéristique qu'une des opérations peut être effectuée par tout le monde tandis que l'autre est mathématiquement restreinte au propriétaire d'un particulier secret. L'opération publique (crypter un message, vérifier une signature) utilise un paramètre public appelé clé publique; l'opération privée correspondante (décryptage de ce qui a été crypté, signature de ce qui peut être vérifié) utilise un paramètre privé correspondant appelé clé privée. La clé publique et la clé privée proviennent d'un objet mathématique sous-jacent commun et sont appelées ensemble une paire de clés publique/privée. La magie de la cryptographie asymétrique est que, bien que les parties publique et privée d'une paire de clés correspondent, la partie publique peut être rendue publique, et cela ne révèle pas la partie privée. Une clé privée ne peut être calculée à partir d'une clé publique que par le biais d'un calcul beaucoup trop coûteux pour être envisagé avec la technologie existante.

Pour faire court, si vous connaissez la clé publique d'une entité (un serveur, un utilisateur humain ...), vous pouvez établir un tunnel de données sécurisé avec cette entité (par exemple avec SSL/TLS dans un contexte connecté, ou le cryptage e-mails avec S/MIME).

Le problème, maintenant, est l'un des distribution des clés. Lorsque vous souhaitez vous connecter à un serveur appelé www.example.com, comment vous assurez-vous que la clé publique que vous vous apprêtez à utiliser appartient vraiment à ce serveur? Par "appartenir", nous voulons dire que la clé privée correspondante est sous le contrôle de ce serveur (et de personne d'autre).

Les infrastructures à clé publique sont une solution à ce problème. Fondamentalement:

Le objectif d'une PKI est de fournir aux utilisateurs une garantie vérifiable quant à la propriété des clés publiques.
Les signifie d'une PKI sont des signatures numériques.

En ce sens, une PKI est un système de support pour l'utilisation de la cryptographie à clé publique, et elle-même utilise la cryptographie à clé publique.

Le concept de base d'une PKI est celui d'un certificat . Un certificat contient une identité (par exemple, un nom de serveur) et une clé publique, qui est censée appartenir à l'entité désignée (ce serveur nommé). L'ensemble est signé par une Autorité de Certification . L'AC est censée "s'assurer" d'une certaine manière que la clé publique appartient réellement à l'entité nommée, puis délivre (c'est-à-dire signe) le certificat; l'AC possède également sa propre paire de clés publique/privée. De cette façon, les utilisateurs (par exemple, les navigateurs Web) qui voient le certificat et connaissent la clé publique de l'autorité de certification peuvent vérifier la signature sur le certificat, gagner ainsi en confiance dans le contenu du certificat, et ainsi apprendre le mappage entre l'entité désignée (le serveur dont nom est dans le certificat) et sa clé publique.

Prenez cinq minutes pour saisir les petits détails de ce mécanisme. Une signature, en soi, ne rend pas quelque chose de fiable. Lorsqu'un message [~ # ~] m [~ # ~] est signé et que la signature est vérifiée avec succès avec la clé publique [~ # ~] k [~ # ~]_p, la cryptographie vous indique que le message [~ # ~] m [~ # ~] est exactement comme il était, jusqu'au dernier bit, lorsque le propriétaire de la clé privée correspondante [~ # ~] k [~ # ~]_s calculé cette signature. Cela ne vous dit pas automatiquement que le contenu de [~ # ~] m [~ # ~] est vrai. Ce que fait le certificat, c'est qu'il déplace le problème de distribution des clés : initialement votre problème était celui de connaître la clé publique du serveur; maintenant, il s'agit de connaître la clé publique de l'autorité de certification, avec le problème supplémentaire que vous devez également faire confiance cette autorité de certification.

Comment l'ICP peut-elle alors aider? Le point important concerne les nombres. Une autorité de certification donnée peut émettre des certificats pour des millions de serveurs. Ainsi, par action de l'AC, le problème de distribution des clés a été modifié de deux manières:

De "connaître les clés publiques de centaines de millions de certificats de serveur", il a été réduit à "connaître les clés publiques d'un millier de CA".
À l'inverse, une exigence de confiance supplémentaire est apparue: vous devez non seulement connaître les clés de l'autorité de certification, mais vous devez également leur faire confiance: l'autorité de certification doit être honnête (elle ne signera pas sciemment un certificat avec une mauvaise association nom/clé) et également compétent (il ne sera pas sans le savoir signer un certificat avec une fausse association nom/clé).

La PKI devient une véritable infrastructure lorsque la récursivité est appliquée: les clés publiques de CA sont elles-mêmes stockées dans des certificats signés par des über-CA. Cela réduit encore le nombre de clés qui doivent être connues a priori par les utilisateurs; et cela augmente également le problème de confiance. En effet, si CA2 signe un certificat pour CA1, et CA1 signe un certificat pour le serveur S, alors l'utilisateur final qui veut valider ce serveur S doit faire confiance à CA2 pour être honnête et compétent, et aussi pour en quelque sorte en prenant soin de ne pas délivrer de certificat à une CA incompétente ou malhonnête. Ici:

CA1 dit: "la clé publique du serveur [~ # ~] s [~ # ~] est xxx". CA1 fait pas dire "serveur [~ # ~] s [~ # ~] est honnête et digne de confiance".
CA2 dit: "la clé publique de CA1 est yyy ET que CA est digne de confiance".

Si vous parcourez le processus, vous vous retrouvez avec une poignée de autorité de certification racine (appelées "ancres de confiance" dans la terminologie X.509 ) qui sont connus a priori par les utilisateurs finaux (ils sont inclus dans votre système d'exploitation/navigateur), et qui sont considérés comme fiables à tous les méta-niveaux. C'est à dire. nous faisons confiance à une autorité de certification racine pour identifier correctement l'autorité de certification intermédiaire et pour pouvoir vérifier leur fiabilité, y compris leur capacité à déléguer eux-mêmes cette fiabilité.

Que la centaine d'autorités de certification racine que Microsoft a jugé bon d'inclure par défaut dans Windows soit si fiable est une question ouverte. L'ensemble de la structure PKI tient en raison des caractéristiques suivantes:

La profondeur de l'ICP est limitée. Une chaîne de certificats depuis une autorité de certification racine vers un certificat de serveur SSL comprendra au maximum 3 ou 4 certificats.
Les CA sont très jaloux de leur pouvoir et ne délivreront pas de certificats à tout CA intermédiaire en herbe. La délégation de cette "autorité CA" est spécifiée dans le certificat. Lorsqu'une autorité de certification délivre un certificat à une sous-autorité de certification, avec cette marque spécifique, elle ne le fait que dans un contexte lourd (contrats, assurances, audits et beaucoup de dollars). En fin de compte, la confiance est assurée par la peur. Les AC fautifs sont sévèrement punis.
Personne n'a vraiment intérêt à briser le système, car il n'y a pas de substitut facilement disponible.

Notez que, sur toute la chaîne, le serveur [~ # ~] s [~ # ~] est vérifié comme possédant réellement une clé publique spécifique, mais personne ne dit que le serveur est honnête. Lorsque vous vous connectez à https://www.wewillgraballyourmoney.com/ et voyez le cadenas vert emblématique, l'ensemble de l'ICP vous garantit que vous parlez vraiment à ce serveur spécifique; cela ne vous dit pas que leur envoyer votre numéro de carte de crédit serait une bonne idée.

De plus, tout cela est une association entre le nom du serveur tel qu'il apparaît dans l'URL cible et une clé publique. Cela ne s'étend pas au nom voulu par l'utilisateur, car ce nom ne vit que dans le cerveau de l'utilisateur. Si l'utilisateur souhaite se connecter à www.Paypal.com mais suit vraiment une URL vers www.paaypaal.com, alors l'ICP et le navigateur ne pourront en aucun cas remarquer que l'utilisateur voulait vraiment parler à Paypal, et non à un autre serveur avec un nom à peu près similaire (mais pas identique).

Le cas d'utilisation principal pour une PKI distribue des clés publiques pour de nombreuses entités. Dans le cas des navigateurs Web et SSL, l'utilisateur du navigateur doit pouvoir vérifier que le serveur auquel il essaie de parler est bien celui qu'il pense être; cela doit fonctionner pour des centaines de millions de serveurs, dont certains ont vu le jour après le navigateur a été écrit et déployé. Réduire ce problème à la connaissance d'une centaine de clés d'autorité de certification racine le rend gérable, car une peut inclut en effet une centaine de clés publiques dans un navigateur Web (c'est un million de fois plus facile que d'inclure une centaine de millions de clés publiques dans un navigateur Web).

Les certificats clients sont une fonctionnalité spécifique à SSL. Dans tout ce qui précède, nous avons parlé d'un client SSL (navigateur Web) essayant d'authentifier un serveur SSL (serveur Web avec HTTPS). SSL prend également en charge l'autre sens: un serveur SSL qui veut s'assurer qu'il parle à un client nommé spécifique. Le même mécanisme peut être utilisé, avec des certificats.

Un point important à noter est que le certificat de serveur et le certificat client vivent dans des mondes différents. Le certificat de serveur est validé par le client. Le certificat client est validé par le serveur. Les deux validations sont indépendantes l'une de l'autre; ils sont effectués par des entités distinctes et peuvent utiliser une autorité de certification racine distincte.

La principale raison pour laquelle les serveurs SSL ont des certificats est que les clients ne peuvent pas connaître à l'avance les clés publiques de tous les serveurs: ils sont trop nombreux et de nouveaux sont créés à chaque minute qui passe. En revanche, lorsqu'un serveur veut authentifier un client, c'est parce que ce client est un utilisateur enregistré. Habituellement, les serveurs connaissent tous leurs utilisateurs, c'est pourquoi la plupart peuvent utiliser un mécanisme d'authentification basé sur un mot de passe plus simple. Les certificats clients SSL sont donc plutôt rares dans la pratique, car le principal avantage des certificats (authentification d'entités sans connaissance préalable) n'est pas une fonctionnalité recherchée par la plupart des serveurs.

Rahil Arora · Answer

Quelle est la différence entre l'infrastructure à clé publique et la cryptographie à clé publique? Comment sont-ils liés?

Je pense que la différence entre Infrastructure à clé publique et Cryptographie à clé publique est assez claire à partir de leurs définitions Wikipedia (citées après le tldr). [~ # ~] tldr [~ # ~] : La cryptographie à clé publique est un autre nom pour les algorithmes asymétriques, tandis que PKI est une infrastructure qui résout l'un des problèmes clés de la cryptographie à clé publique.

Cryptographie à clé publique : (alias cryptographie asymétrique) est une classe de protocoles cartographiques basés sur des algorithmes qui nécessitent deux clés distinctes, dont l'une est secrète (ou privé) et dont l'un est public. Les utilisations les plus courantes incluent: le cryptage à clé publique (le message est crypté avec la clé publique d'un destinataire) et les signatures numériques (le message est signé avec la clé privée de l'expéditeur et peut être vérifié par toute personne ayant accès à la clé publique de l'expéditeur). Il s'agit d'une technique qui permet aux utilisateurs de communiquer en toute sécurité sur un réseau public non sécurisé et de vérifier de manière fiable l'identité de l'utilisateur via des signatures numériques.

Infrastructure à clé publique : est un ensemble de matériel, de logiciels, de personnes, de politiques et de procédures nécessaires pour créer, gérer, distribuer, utiliser, stocker et révoquer certificats numériques et gérer chiffrement à clé publique. Autrement dit, cela implique la gestion de la cryptographie à clé publique, mais ne se limite pas à cela.

Pour comprendre la relation, il faut comprendre le problème central avec la Cryptographie à clé publique, qui est: confiance/preuve qu'une clé publique particulière est authentique , en ce qu'il est correct et appartient à la personne ou à l'entité revendiquée, et n'a pas été falsifié ou remplacé par un tiers malveillant. Infrastructure à clé publique est l'une des approches de ce problème. Il tend à résoudre le problème en introduisant le concept de autorités de certification aka de confiance troisième parties, pour certifier la propriété des paires de clés. Une autre approche de ce problème est quelque chose appelé Web of Trust , qui décentralisera cette authentification des clés publiques par un mécanisme central, et remplace les avenants individuels du lien entre l'utilisateur et la clé publique.

Quel est le principal cas d'utilisation de l'ICP?

Le plus commun cas d'utilisation pour PKI, auquel je peux penser, est (d'après l'article de wikipedia): pour lier les clés publiques avec les respectives identités des utilisateurs au moyen d'une autorité de certification (CA) . L'identité de l'utilisateur doit être unique dans chaque domaine d'autorité de certification. L'autorité de validation (VA) tierce peut fournir ces informations au nom de l'AC. La liaison est établie à travers le processus d'enregistrement et de délivrance. Selon le niveau d'assurance de la liaison, cela peut être effectué par logiciel dans une autorité de certification ou sous supervision humaine. Le rôle PKI qui assure cette liaison est appelé autorité d'enregistrement (RA). L'AR est responsable d'accepter les demandes de certificats numériques et d'authentifier la personne ou l'organisation qui fait la demande.

Ce cas d'utilisation peut être appliqué dans une variété de scénarios tels que (encore une fois, formulaire article wikipedia ):

Chiffrement et/ou authentification de l'expéditeur des messages électroniques (par exemple, en utilisant OpenPGP ou S/MIME)
Cryptage et/ou authentification des documents (par exemple, les normes XML Signature ou XML Encryption si les documents sont codés en XML)
Authentification des utilisateurs sur les applications (par exemple, ouverture de session par carte à puce, authentification client avec SSL)
Amorçage des protocoles de communication sécurisés, tels que l'échange de clés Internet (IKE) et SSL.

Comment les certificats clients sont-ils utilisés dans PKI?

Cela dépend vraiment du scénario d'utilisation spécifique mentionné ci-dessus. Les certificats clients peuvent être utilisés différemment dans différents scénarios, mais ils servent tous le même objectif: pour vérifier qu'une clé publique particulière appartient à une certaine entité (client/serveur/utilisateur).

Par exemple: SSL/TLS prend en charge les certificats côté client. Ce cas d'utilisation a été couvert dans cette réponse de Thomas Pornin . Les avantages/inconvénients de l'utilisation des certificats clients pour l'authentification ont également été couverts par cette réponse de Bruno .

Quel est le rôle d'une autorité de certification dans l'ICP?

La meilleure réponse à cela peut être trouvée dans la citation article wikipedia (encore une fois):

Le rôle principal de l'AC est de signer numériquement et de publier la clé publique liée à un utilisateur donné. Cela se fait à l'aide de la propre clé privée de l'autorité de certification, de sorte que la confiance dans la clé utilisateur repose sur sa confiance dans la validité de la clé de l'autorité de certification. Lorsque l'AC est un tiers distinct de l'utilisateur et du système, il s'agit alors de l'autorité d'enregistrement (RA), qui peut ou non être distincte de l'AC. La liaison utilisateur-clé est établie, selon le niveau d'assurance de la liaison, par logiciel ou sous supervision humaine.

Ali · Answer

Comme phrase d'introduction: PKI (Public Key Infrastructure) et PKC (Public Key Cryptography) avec ensemble sont considérés comme PKT (Public Key Technology).

Réponses courtes: pour lire l'image, ouvrez-la dans une nouvelle fenêtre

enter image description here

Il est maintenant temps de répondre aux questions.

 1. What is the difference between Public Key Infrastructure and Public Key Cryptography?

Je pense que la principale différence et relation entre eux a été cachée derrière les définitions et l'histoire:

Par conséquent, selon les explications ci-dessus, La cryptographie à clé publique prend uniquement en charge les opérations mathématiques asymétriques sur les données; il ne fournit pas en soi une connexion à des applications ou des environnements tels que le commerce électronique, le courrier électronique ou le Web. Pour fournir une telle connexion, plusieurs éléments supplémentaires sont nécessaires. Ces éléments supplémentaires constituent la définition d'une infrastructure à clé publique - une "infrastructure" qui met la technologie à clé publique à la disposition des applications et des environnements qui souhaitent l'utiliser.

Selon cet article quelques exemples de systèmes PKI par rapport à ces caractéristiques sont: X.509, PGP, AADS/X9.59, SPKI

 2. What is the main use case for PKI?

TLS: Selon le livre "Cellular Authentication for Mobile and Internet Services" et RFC2246, l'un des plus grands cas d'utilisation existants pour PKI provient de l'utilisation de certi ﬁ cates dans le Transport Layer Security (TLS) et TLS prend en charge le certificat client.
Signature de code: Avec les récentes violations de données largement diffusées, la signature de code est devenue l'un des cas d'utilisation les plus populaires pour l'ICP. Les signatures numériques fournissent à la fois l'authenticité et l'intégrité des données et des messages. La capacité de prouver mathématiquement que les données n'ont pas changé depuis le moment précis où la signature des données s'est produite est un outil très puissant. Cela permet de faire confiance aux documents, programmes et autres objets de données signés numériquement. Une maison de développement de logiciels doit signer son code d'application afin que les utilisateurs finaux puissent vérifier que le code a non seulement été distribué par une source fiable, mais qu'il n'a pas été altéré ou infecté de quelque manière que ce soit. Le même concept peut être appliqué aux signatures numériques et est important pour la gestion des documents, tels que les documents juridiques (contrats, dépôts, etc.), les factures et les rapports . [Re f]
SSL intranet, authentification 802.1x, S/MIME, IPSec, authentification des utilisateurs d'entreprise: et selon ce document les fonctionnalités de sécurité de PKI sont utiles dans plusieurs cas d'utilisation courants dans les environnements de réseau d'entreprise tels que SSL intranet, authentification 802.1x, S/MIME, IPSec, authentification des utilisateurs d'entreprise.
```
 3. How are client certificates used in PKI? 
```
La définition et les différences entre le certificat client et le certificat serveur SSL montrent l'utilisation:
Certificat client: Un certificat de transport qui peut être des partenaires externes et des partenaires internes. Si le transport sortant est HTTPS et que l'authentification client est requise, vous aurez besoin d'un certificat client SSL. Dans la plupart des cas, le certificat client SSL doit être signé et émis par une autorité de certification (autre rôle de l'autorité de certification). Si le certificat est utilisé dans un environnement de test, il peut être auto-signé. En d'autres termes, les certificats clients, comme leur nom l'indique, sont utilisés pour identifier un client ou un utilisateur et jouent un rôle essentiel pour garantir la sécurité des personnes en ligne et sont utilisés pour identifier un client ou un utilisateur, authentifiant le client auprès du serveur et établissant précisément qui il est. Ils sont destinés à authentifier le client auprès du serveur. il n'est pas utilisé pour le chiffrement ou le déchiffrement des données, mais représente une identité d'utilisateur et fournit une fonctionnalité d'authentification d'utilisateur. Ils consistent en la partie clé publique du certificat et une clé privée détenue uniquement par l'entité à laquelle le certificat est délivré. L'autorité de certification peut être une organisation publique bien connue qui fournit des services de certificats dans le cadre de ses activités, ou elle pourrait être un serveur interne que seule votre entreprise utilise. Dans les deux cas, le certificat client contiendra certaines informations permettant d'identifier l'utilisateur individuellement ou en tant que membre d'un groupe. le serveur peut également être configuré pour effectuer un mappage du certificat avec un compte d'utilisateur. Il peut s'agir d'un mappage un à un, où le certificat spécifique est mappé à un seul compte d'utilisateur, ou d'un mappage plusieurs à un, où le serveur utilise certains champs dans les informations de certificat pour mapper tout certificat correspondant à un compte d'utilisateur désigné. Lorsqu'un mappage est utilisé, le certificat permet à l'utilisateur de se voir accorder ou refuser l'accès aux ressources en tant qu'utilisateur particulier. Lorsque vous utilisez des certificats clients de cette manière, vous n'avez pas besoin d'utiliser une autre méthode d'authentification.
Certificat de serveur SSL: sont utilisés pour identifier un serveur. En règle générale, ils sont attribués à des noms d'hôte, qui peuvent être un nom d'ordinateur (comme "PIIS-SVR01") ou un en-tête d'hôte (comme "www.example.com"). Les certificats de serveur SSL offrent des fonctionnalités de cryptage et de sécurité et permettent l'authentification du serveur SSL. L'autorité de certification du certificat de serveur SSL doit être échangée entre les participants.

La seule similitude entre eux est le mot-clé "Certificat". Ils contiennent tous deux des clés publiques et privées. D'ailleurs, chaque certificat contient une clé publique et une clé privée. il n'est pas possible d'utiliser un certificat de serveur comme certificat client ou vice-version.

 4. What is a Certificate Authority's role in PKI?

Dans le modèle Diffie et Hellman d'origine, les clés publiques seraient récupérées à partir d'un référentiel sécurisé. La sécurité de ce référentiel a servi à lier la clé publique à d'autres attributs du propriétaire de la clé. Pour soutenir la production et la distribution de liaisons hors ligne, Kohnfelder a introduit la notion de certificat ( Towards a Practical Public-key Cryptosystem ), par lequel une clé publique et un identifiant (par exemple, un nom) étaient placés dans un structure de données signée par une autorité de certification (CA) et mise à disposition dans un référentiel non sécurisé.

Par conséquent, en résumé, puisqu'il n'existe aucune confiance directe entre un expéditeur de données et un destinataire de données, PKI s'appuie sur un système de point de confiance tiers où l'autorité de certification joue le rôle d'arbitre de confiance. L'AC établit d'abord sans aucun doute l'identité d'un propriétaire de clé publique-privée, puis atteste de l'identité du propriétaire en incorporant la clé publique du propriétaire à l'intérieur d'un certificat portant la signature de l'AC. Toute personne qui fait confiance à cette autorité de certification peut vérifier la signature de l'autorité de certification et, par conséquent, l'identité du propriétaire du certificat.

enter image description here

Ali · Answer

J'ai conçu une image comme réponses courtes aux questions: pour lire les textes de l'image ouvrir l'image dans un nouvel onglet

enter image description here

pour plus de détails, consultez ma réponse précédente.

amenzar · Answer

Je répondrai à cela dans une approche à deux niveaux: réponse à terme général et clarification spécifique SSL/TLS dans les citations.

La cryptographie à clé publique (PKC) résout le problème de l'échange sécurisé d'informations sans qu'il soit nécessaire de convenir au préalable d'une clé secrète. Pour faire partie de PKC, chaque agent doit avoir un Clé privée (qui ne doit être conservé que par le propriétaire) et un Clé publique (qui pourrait être partager avec tout le monde) où le premier décrypte le contenu crypté par le second et vice versa. Par conséquent, chaque agent qui souhaite communiquer avec Alice de manière sécurisée doit crypter * ses messages avec la clé publique d'Alice afin de s'assurer que seule Alice (le propriétaire de la clé privée) peut lire le message.

En SSL/TLS, lors de l'établissement d'une connexion, le serveur envoie son certificat (essentiellement la clé publique avec certaines métadonnées) et le client l'utilise pour crypter une clé symétrique qu'ils utiliseront tout au long de la conversation. Cela est dû au fait que la cryptologie symétrique est plus rapide qu'asymétrique. Par la suite, lorsque le serveur reçoit la clé symétrique chiffrée, le serveur utilise sa clé privée pour la déchiffrer, puis l'utiliser pour le reste de la conversation.

À ce stade, tout semble simple et clair, cependant a priori on n'a pas chaque clé publique d'agent. Ainsi, afin d'établir une communication sécurisée avec quelqu'un, il doit d'abord échanger des clés publiques; et c'est là que réside la faiblesse de PKC. Comment pourrais-je savoir que la clé publique qui m'a été donnée provient bien de qui je veux communiquer et non d'un homme du milieu (MITM)?

C'est le problème que l'infrastructure à clé publique (PKI) résout.

L'infrastructure à clé publique (PKI) consiste à ajouter une autre personne à la conversation. Cet autre agent est l'autorité de certification (CA) , qui agit en tant que juge neutre auquel les deux autres participants de la conversation font confiance. Cette autorité de certification (qui possède également ses clés publique et privée) est celle qui signe la clé publique de tout utilisateur PKI après avoir certifié qu'il est bien la personne qu'il prétend être. Par conséquent, chaque fois qu'un agent de l'ICP reçoit une clé publique, il vérifie si elle a été signée par l'une de ses autorités de certification de confiance.

Avant d'établir une connexion SSL/TLS, le client doit être sûr que le certificat reçu est valide. Pour ce faire, le client vérifie non seulement l'authenticité de sa clé publique mais également les autres métadonnées qui lui sont associées (pour comprendre cela, il est important de connaître les contenu d'un certificat numérique typique ):

La signature vérifie. Cela garantit que le certificat n'a été modifié d'aucune façon.

Le certificat n'a pas expiré. Lorsque le certificat est délivré par l'autorité de certification, une date d'expiration lui a été accordée.

Le sujet du certificat correspond au nom d'hôte. Le certificat est émis pour un serveur spécifique. Ainsi, le nom du sujet du certificat doit correspondre à l'URL que le client tente de se connecter.

Il n'a pas été révoqué. Parfois, les certificats peuvent être révoqués par leurs émetteurs dans tous les cas nécessaires (par exemple, la clé privée associée a été exposée, d'où le certificat devient invalide).

Il a été signé par une autorité de certification de confiance. Pour prouver l'authenticité du certificat, nous devons obtenir le certificat de l'autorité de certification et vérifier sa fiabilité. Néanmoins, dans l'ICP, il existe un concept de chaîne de confiance , de sorte que le certificat d'autorité de certification aurait pu être émis par d'autres autorités de certification. Par conséquent, nous devons obtenir ce certificat d'un autre CA et le valider. Et ainsi de suite ... Ergo, pour faire confiance à un certificat, nous devons remonter jusqu'à la racine CA. Enfin, si nous faisons confiance à l'AC racine, il est sûr de dire que nous faisons confiance à toute la chaîne.

Dans l'ensemble, une PKI est nécessaire lorsque la PKC est utilisée et tous les participants ne peuvent pas être déterminés à l'avance.

C'est pourquoi nous n'avons pas besoin d'une autorité de certification pour les autorités de certification racine. Il n'y en a que quelques-uns qui sont déjà connus et approuvés par votre système informatique. Ils sont venus installés par défaut dans votre système d'exploitation/navigateur (ou peuvent également être installés manuellement). Cependant, pour le reste des serveurs ou des AC intermédiaires, nous ne pouvons pas connaître leurs certificats à l'avance (en raison du nombre important d'entre eux), puis nous utilisons PKI pour vérifier leur authenticité en suivant la chaîne de confiance jusqu'à ce qu'un Racine CA (que nous pourrions finir par faire confiance ou non).

Afin de répondre à toutes vos questions, je vais maintenant répondre brièvement sur les certificats clients. Les certificats clients sont les mêmes que les certificats serveurs. Cependant, ils sont couramment utilisés par les serveurs comme méthode d'authentification client. Ce type de solution est valable lorsqu'il y a peu de clients connus du serveur.

user47604 · Answer

Jusqu'au début des années 1970, la seule façon de chiffrer et de déchiffrer les messages était d'utiliser des algorithmes symétriques, dans lesquels la même clé était utilisée pour les deux opérations. La clé doit être échangée en toute sécurité par certains moyens avant que deux parties puissent communiquer en privé.

La cryptographie à clé publique, ou asymétrique cryptage, est une nouvelle façon de crypter et décrypter les messages à l'aide de deux clés - une qui est gardée secrète et une qui est partagée. Deux parties peuvent échanger des clés publiques pour communiquer en toute sécurité sans jamais se rencontrer, même si la connexion est surveillée.

Une analogie avec le cryptage à clé publique est un coffre-fort et une clé. Vous pouvez envoyer à quiconque un coffre-fort ouvert - votre clé publique - et le sceller, et vous seul pouvez le déverrouiller à l'aide de votre clé privée. De même, dans un cryptosystème asymétrique, les messages chiffrés avec une clé privée peuvent être vérifiés par la clé publique correspondante pour prouver l'authenticité, comme une signature.

Cependant, il faut encore vérifier qu'une clé publique appartient vraiment au prétendu propriétaire. Après tout, un attaquant peut modifier la connexion et insérer sa propre clé publique à la place de la clé légitime.

Par exemple, la première fois que vous vous connectez à un nouveau serveur, votre client vous demandera si vous faites confiance à l'empreinte digitale de la clé publique du serveur, que vous êtes censé vérifier à partir d'un terminal local. Ou la première fois que vous démarrez une conversation OTR, vous devez vérifier l'empreinte digitale des autres par la voix ou en personne.

Une autre façon consiste simplement à avoir une autorité désignée "garant" pour les autres, connue comme une infrastructure à clé publique. La clé publique est incluse dans le cadre d'un certificat avec d'autres informations telles que le nom de l'émetteur, le sujet et l'expiration, puis est signée numériquement à l'aide d'un chiffrement asymétrique par la clé privée d'une autorité ou sa propre clé privée.

Chaque système d'exploitation et de nombreuses applications définissent une liste de certificats de confiance. Celles-ci sont communément appelées autorités de certification racine. Ils délèguent souvent des autorités de certification intermédiaires qui signent les certificats des serveurs et des clients dans une infrastructure à clé publique.

Les certificats clients ne sont pas si différents des certificats serveurs. Les serveurs peuvent leur demander d'authentifier les clients, par exemple, au lieu de demander aux utilisateurs de taper un nom d'utilisateur et un mot de passe.

munchkin · Answer

Puisque nous devrions tous être familiers avec les couches à la manière du modèle OSI: PKI se trouve au sommet de la crypto à clé publique. Le public auquel il est fait référence ici est un terme impropre, en ce sens qu'il ne s'agit pas vraiment d'un public généralisé, mais que les clés, ou du moins la clé publique, peuvent être à l'air libre et, par extension, pouvoir être librement distribuées, bien qu'en réalité ce ne soit pas le cas. La cryptographie à clé publique dans les RFC fait spécifiquement référence aux formats sur disque, aux chiffrements de clés, aux formats de transfert et aux protocoles de prise de contact/transfert.

L'infrastructure mentionnée ici et spécifiquement dans les RFC, est le cadre par lequel les clés sont manipulées, distribuées, vérifiées par un tiers et généralement utilisées dans des environnements du monde réel - les aspects techniques de toute façon, pas tellement la partie commerciale.