Quelques lacunes dans la compréhension du flux de travail de l'infrastructure à clé publique

Question

Récemment, je suis tombé sur la compréhension de base du processus de travail en action de l'ICP. J'ai consulté les principaux articles sur les principes, mais je me sens encore un peu bête pour comprendre ce processus. Je comprends que l'ICP n'est pas pour "mon blog", mais pour simplifier les choses, prenons un exemple simple "ma boutique en ligne" (par exemple apache et php) et des concepts simples. J'ai écrit quelques déclarations qui peuvent être vagues ou même fausses mais c'est ce que je veux savoir sur le processus de PKI :

1. "Ma boutique en ligne, en tant que société, doit être "certifiée" par une autorité de certification tierce. Cela signifie que je dois acheter une sorte d'adhésion d'un an à cette autorité de certification, qui enregistrera "Ma boutique en ligne" dans ses systèmes et me délivrera des éléments tels qu'un certificat et une paire de clés publiques et privées uniques. Recevrai-je un fichier de certificat ?

2. Le certificat émis est rempli avec mes informations et ma clé publique et stocké dans un fichier sur mon serveur web. Le certificat vérifie que "Mon e-shop" n'est pas un bureau de voleurs.

3. Chaque fois que les utilisateurs accèdent à "Mon e-shop" par "https", leur navigateur vérifie "silencieusement" le certificat présenté de "Mon e-shop" avec celui qui est enregistré à l'AC.

   1. Qu'en est-il des utilisateurs ? Leurs navigateurs génèrent-ils des clés publiques+privées locales lorsqu'ils entrent dans "Mon e-shop" via https ?

4. Lorsqu'un utilisateur entre dans "My e-shop" via https, il se passe ce qui suit : "Mon e-shop" (serveur web) obtient la clé publique (PK1) de l'utilisateur. Le serveur présente silencieusement le certificat de "Mon e-shop" à l'utilisateur, de sorte que les utilisateurs obtiennent la clé publique (PK2) de "Mon e-shop". Après quelques vérifications silencieuses, le navigateur de l'utilisateur valide le certificat présenté et une connexion sécurisée est établie.

5. Lorsqu'un utilisateur envoie une demande via un tuyau sécurisé, les demandes sont cryptées avec la clé publique de "My e-shop". Ensuite, le serveur web décrypte la demande avec sa clé privée. Ensuite, le serveur web envoie une réponse cryptée avec une clé publique de l'utilisateur. A la fin, le navigateur de l'utilisateur déchiffre la réponse avec sa clé privée.

Answer 1

Je les prends question par question :

(1) "My e-Shop" en tant qu'entreprise doit être "certifiée" par une autorité de certification tierce. Cela signifie que je dois acheter une sorte de d'adhésion d'un an à cette autorité de certification, et ensuite, ils enregistreront "Ma boutique en ligne" dans leur système et me délivreront des des trucs comme un certificat et une paire de clés publiques et privées uniques. Recevrai-je un fichier de certificat ?

Oui. De plus, cela varie d'un CA à l'autre - pour certains CA, une adhésion d'un an et une carte de crédit valide suffisent (ce n'est pas difficile à obtenir, même si vous êtes une bande de voleurs), d'autres CA exigent un certain nombre de documents pour vérifier que vous êtes bien celui que vous prétendez être. La qualité d'un CA dépend de son processus de vérification des clients. En général, plus le processus est onéreux, meilleur est le CA (et plus cher).

Une fois que vous avez payé votre argent et fait vos démarches, vous et l'autorité compétente allez générer au moins deux choses :

• Une paire de clés publiques/privées. Souvent, cette paire est générée par VOUS, et non par l'autorité de certification. La qualité de la façon dont vous avez généré et stocké votre paire de clés est également un facteur qui détermine dans quelle mesure une autre entité peut faire confiance à votre site web. En général, pour les certificats d'identification (comme les certificats de serveur SSL), il est préférable que le client (My e-Shop) génère la clé.
• Vous enverrez une demande de certificat dans un format standard (exemple : PKCS10) à l'autorité de certification. Elle comprendra un certain nombre d'informations sur My e-Shop et la clé publique.
• La société CA vérifiera vos papiers et s'assurera que vous êtes bien vous. Ensuite, elle utilisera son autorité de certification pour signer numériquement un certificat pour vous. Ce certificat contient un ensemble d'informations que vous venez de fournir, des informations supplémentaires que le fournisseur de l'autorité de certification définit pour vous, votre clé publique et la signature numérique générée par la liaison cryptographique de toutes les données susmentionnées avec la clé privée de l'autorité de certification.

Vous récupérez l'une des deux choses suivantes :

• juste le certificat (si vous avez généré votre propre paire de clés)
• le certificat et la paire de clés - si l'AC a généré la paire de clés pour vous

(2) Le certificat délivré est rempli avec mes coordonnées. informations et ma clé publique et stocké dans un fichier sur mon serveur web. Le site certificat vérifie que "Mon e-shop" n'est pas un bureau de voleurs.

Oui... en quelque sorte. Votre serveur web aura besoin à la fois du certificat signé ET de la paire de clés. La paire de clés est utilisée dans le cadre de la poignée de main SSL avec l'utilisateur final, et cet échange prouve que vous êtes en possession de la paire de clés, et non pas une bande de voleurs qui ont mis la main sur le certificat. C'est pourquoi il faut protéger la paire de clés.

(3) Chaque fois que les utilisateurs accèdent à "Mon e-shop". par "https", leurs navigateurs vérifie "silencieusement" le certificat présenté présenté de "Mon e-boutique" avec le certificat celui qui est enregistré auprès de l'AC.

Pour une certaine définition de "silencieux". Un navigateur de base vérifie que le certificat : - est actuellement valide - est signé par une autorité de certification à laquelle le navigateur fait confiance (sinon, il refuse l'accès ou affiche une popup ennuyeuse).

Les extensions des navigateurs iront plus loin et feront des choses comme la vérification du chemin complet (jusqu'à la racine auto-signée) et la vérification du statut du certificat. Plus le risque que l'information soit partagée sur le tuyau est élevé, plus la vérification doit être poussée.

(4) Lorsqu'un utilisateur entre dans "Mon e-shop". via https, il se passe ce qui suit : "Mon e-shop" (serveur web) obtient la clé publique publique (PK1) de l'utilisateur. Le serveur présente silencieusement le certificat de "Mon e-boutique" à l'utilisateur, ainsi le l'utilisateur obtient la clé publique (PK2) de "Mon e-boutique". Après une vérification silencieuse vérification du navigateur de l'utilisateur valide le certificat présenté et un lien sécurisé est établi.

• Qu'en est-il des utilisateurs ? Leurs navigateurs génèrent-ils des clés publiques+privées locales lorsqu'ils entrent dans "Mon e-shop" via https ?

OK - ça part en vrille ici.

Pour plus de détails, consultez le protocole SSL - la section sur la poignée de main vous donnera des informations précises.

Le navigateur et le serveur web échangent des informations qui leur permettent de créer une clé de cryptage de session. Le navigateur génère bien un matériel de départ utilisé pour établir la session, mais il ne s'agit pas de "la clé publique de l'utilisateur (PK1)". L'utilisateur n'a pas besoin de disposer d'informations d'identification PKI À MOINS que le serveur n'ait été configuré pour l'authentification du client. Dans une boutique en ligne ordinaire, le serveur dispose d'un identifiant PKI, le navigateur génère des clés à la volée pour cette seule session. Le serveur n'a absolument aucune idée de l'identité de l'utilisateur du navigateur, du point de vue du SSL - toute l'identification de l'utilisateur provient d'un mot de passe ou d'un autre élément au niveau de l'application.

NOTE : Il s'agit d'une transaction commerciale ordinaire. Plus le risque est élevé, plus la protection est importante. Les transactions à haut risque nécessitent souvent une authentification du client.

(5) Lorsqu'un utilisateur envoie une demande par l'intermédiaire de tuyau sécurisé, la demande est cryptées avec la clé publique de "My e-shop". Ensuite, le serveur web décrypte la demande avec sa clé privée. Ensuite, le serveur web envoie une réponse chiffrée réponse cryptée avec une clé publique de l'utilisateur l'utilisateur. A la fin, le navigateur de l'utilisateur utilisateur décrypte la réponse avec sa clé privée.

Pas tout à fait. Voici les mauvaises herbes - un développeur d'une application web est relativement abstrait de tout cela. Mais le contenu de la session n'est pas chiffré à l'aide de clés asymétriques, ce qui exigerait une utilisation intensive du processeur. L'ICP du serveur et les données de prise de contact générées à la volée par le navigateur sont utilisées pour échanger la clé de chiffrement de la session. En partie, le client sélectionne et envoie une clé secrète cryptée dans la clé publique du serveur. Comme seul le serveur dispose de la clé privée, seul le serveur peut décrypter les données envoyées par le client.

Cette clé secrète est symétrique (l'algorithme exact fait également partie de la poignée de main) et est utilisée pour le reste de la session.

Answer 2

Vos démarches sont incorrectes à plusieurs niveaux. Permettez-moi de les reformuler, en espérant qu'elles soient claires.

1. Votre site doit avoir un certificat SSL d'un de confiance CA tierce partie (Verisign, etc.). Vous devrez l'acheter auprès d'eux. Vous devrez générer la paire de clés publique/privée, leur fournir votre clé publique (elle fait partie de la demande de certificat) et ils généreront le certificat.

2. Le certificat contient le nom de domaine de votre site, votre clé publique et quelques autres informations supplémentaires. Il ne vérifie rien, et surtout pas que votre site n'est pas "un bureau de voleurs". Tout ce qu'il certifie généralement, c'est que vous êtes propriétaire du nom de domaine pour lequel vous demandez un certificat. Cela ne signifie en aucun cas que votre site est digne de confiance.

3. Lorsqu'un utilisateur accède à votre site via HTTPS, votre Le serveur enverra le certificat au navigateur du client. À aucun moment le client ne communique avec l'autorité de certification pour valider votre certificat.

3.1. En général, les utilisateurs finaux (clients, consommateurs) n'ont pas besoin de leurs propres certificats et clés privées. C'est ce que l'on appelle le SSL à authentification mutuelle, qui implique les deux parties (vos clients, vos consommateurs, etc.). y votre site) ayant un certificat. Ceci est rarement (voire jamais) utilisé dans les sites de commerce électronique.

1. Lorsqu'un utilisateur accède à votre site via HTTPS, votre serveur envoie le certificat au navigateur du client. Le client l'utilisera pour effectuer un Handshake SSL. Cette poignée de main entre le navigateur et votre site est ce qui établit le tunnel sécurisé. Les spécificités du protocole de poignée de main sont plus techniques que nécessaire.

2. Lorsqu'une demande est envoyée au serveur via le tunnel SSL, le serveur la traite de la même manière que toute autre demande. La seule différence est que la communication entre vos clients et votre serveur est cryptée. Votre serveur Web se chargera probablement du décryptage des données de la demande et les présentera à votre serveur Web pour traitement. De même, les données de la réponse sont renvoyées au client sous une forme cryptée via le tunnel SSL.

Mieux ?

Answer 3

Concernant le point 3 :

Pour autant que je sache, ce n'est pas tout à fait correct. Comme il n'y a pas vraiment d'infrastructure de test en direct établie (en comparaison avec des services comme le DNS), le serveur web enverra la chaîne complète de certificats au navigateur. D'autre part, le navigateur ou le système d'exploitation est livré avec un ensemble de certificats racine de confiance (qui doivent parfois être mis à jour, mise à jour de Windows, nouvelles versions du navigateur, etc.)

Et oui, le navigateur sera censé générer une paire de clés "non fiable", puisque dans des circonstances normales, un utilisateur standard ne générera pas son propre certificat.

Concernant le point 5 :

De plus, ce n'est pas tout à fait la vérité. Le calcul du cryptage asynchrone demande beaucoup de temps. L'algorithme RSA n'est donc utilisé que pour échanger des clés pour des normes de cryptage synchrone plus rapides (par exemple AES, 3TES).