Comment fonctionnent les processus de certificats numériques, signatures et SSL?
J'ai essayé de comprendre comment fonctionne SSL. Au lieu d'Alice et Bob, considérons la communication client-serveur. Le serveur possède un certificat numérique acquis auprès d'une autorité de certification. Il dispose également de clés publiques et privées. Le serveur souhaite envoyer un message au client. La clé publique du serveur est déjà disponible pour le client.
En supposant que la prise de contact SSL est terminée.
Serveur à Client:
- Le serveur attache sa clé publique au message.
- Exécute la fonction de hachage (message + clé publique). Les résultats sont connus sous le nom de HMAC.
- Chiffrez HMAC en utilisant sa clé privée. Le résultat est appelé signature numérique.
- Envoyez-le au client avec le certificat numérique.
- Le client vérifie le certificat et constate qu'il provient du serveur attendu.
- Décrypte HMAC à l'aide de la clé publique du serveur.
- Exécute la fonction de hachage (message + clé publique) pour obtenir le message d'origine.
client à serveur
- Le client exécute la fonction de hachage (message + clé publique), puis chiffre à l'aide de la même clé publique.
- Le serveur déchiffre à l'aide d'une clé privée, exécute la fonction de hachage sur les données résultantes pour obtenir le message.
Veuillez me faire savoir si ma compréhension est correcte.
Il y a quelques confusions dans votre message. Tout d'abord, HMAC n'est pas un fonction de hachage . Plus d'informations sur HMAC plus tard.
Fonctions de hachage
Une fonction de hachage est un algorithme complètement public (pas de clé en cela) qui écrase les bits d'une manière qui est vraiment impossible à démêler: n'importe qui peut exécuter la fonction de hachage sur toutes les données, mais trouver le les données de retour de la sortie de hachage semblent être bien au-delà de notre esprit. La sortie de hachage a une taille fixe, généralement 256 bits (avec SHA-256) ou 512 bits (avec SHA-512). La fonction SHA- * qui produit 160 bits est appelée SHA-1, pas SHA-160, car les cryptographes laissés à eux-mêmes ne peuvent rester raisonnables que pendant aussi longtemps, et certainement pas au-delà de la cinquième pinte.
Algorithmes de signature
Un algorithme signature utilise une paire de clés, qui sont mathématiquement liées entre elles, la clé privée et la clé publique ( recalculer la clé privée à partir de la clé publique est théoriquement faisable mais trop difficile à faire dans la pratique, même avec Really Big Computers, c'est pourquoi la clé publique et être rendue publique tandis que la clé privée reste privée). En utilisant la structure mathématique des clés, l'algorithme de signature permet:
- pour générer une signature sur certaines données d'entrée, en utilisant la clé privée (la signature est un objet mathématique qui est raisonnablement compact, par exemple quelques centaines d'octets pour une signature RSA typique);
- à vérifier une signature sur certaines données d'entrée, en utilisant la clé publique. La vérification prend comme paramètres la signature, les données d'entrée et la clé publique, et renvoie soit "parfait, mec!" ou "mec, ceux-ci ne correspondent pas".
Pour un algorithme de signature sécurisé, il est supposé impossible de produire une valeur de signature et de saisir des données telles que l'algorithme de vérification avec une clé publique donnée dit "bon", sauf vous connaissez la clé privée correspondante, auquel cas c'est simple et efficace. Notez les petits caractères: sans la clé privée, vous ne pouvez pas conjurer certaines données et une valeur de signature qui fonctionne avec la clé publique, même si vous pouvez choisir les données et la signature comme vous le souhaitez.
"Censément irréalisable" signifie que tous les cryptographes intelligents du monde y ont travaillé pendant plusieurs années et n'ont pourtant pas trouvé de moyen de le faire, même après la cinquième pinte.
La plupart (en fait, tous) les algorithmes de signature commencent par traiter les données d'entrée avec une fonction de hachage, puis travaillent uniquement sur la valeur de hachage. Cela est dû au fait que l'algorithme de signature a besoin d'objets mathématiques dans certains ensembles donnés dont la taille est limitée, de sorte qu'ils doivent travailler sur des valeurs qui ne sont "pas trop grandes", telles que la sortie d'une fonction de hachage. En raison de la nature de la fonction de hachage, les choses fonctionnent très bien (la signature de la sortie de hachage est aussi bonne que la signature de l'entrée de hachage).
Échange de clés et chiffrement asymétrique
Un protocole d'échange de clés est un protocole dans lequel les deux parties se lancent des objets mathématiques, chaque objet étant éventuellement lié à des valeurs secrètes qu'ils gardent pour eux, d'une manière très similaire à public/paires de clés privées. À la fin de l'échange de clés, les deux parties peuvent calculer une "valeur" commune (encore un autre objet mathématique) qui échappe totalement à la compréhension de celui qui a observé les bits qui ont été échangés sur le fil. Un type courant d'algorithme d'échange de clés est cryptage asymétrique. Le chiffrement asymétrique utilise une paire de clés publique/privée (pas nécessairement du même type que pour un algorithme de signature):
- Avec la clé publique, vous pouvez - crypter une donnée. Ces données sont généralement limitées en taille (par exemple pas plus de 117 octets pour RSA avec une clé publique de 1024 bits). Le résultat du chiffrement est, devinez quoi, un objet mathématique qui peut être codé en une séquence d'octets.
- Avec la clé privée, vous pouvez décrypter, c'est-à-dire effectuer l'opération inverse et récupérer les données d'entrée initiales. On suppose que sans la clé privée, pas de chance.
Ensuite, le protocole d'échange de clés s'exécute ainsi: une partie choisit une valeur aléatoire (une séquence d'octets aléatoires), la chiffre avec la clé publique de l'homologue et l'envoie. Le pair utilise sa clé privée pour déchiffrer et récupère la valeur aléatoire, qui est le secret partagé.
Une explication historique des signatures est: "chiffrement avec la clé privée, déchiffrement avec la clé publique". Oubliez cette explication. Il est faux. Cela peut être vrai uniquement pour un algorithme spécifique (RSA), et, encore une fois, uniquement pour une version bâtarde de RSA qui ne parvient pas à avoir une sécurité décente. Donc non , les signatures numériques ne sont pas un chiffrement asymétrique "à l'envers".
Cryptographie symétrique
Une fois que deux parties ont une valeur secrète partagée, elles peuvent utiliser cryptographie symétrique pour échanger d'autres données de manière confidentielle. On l'appelle symétrique car les deux parties ont la même clé, c'est-à-dire la même connaissance, c'est-à-dire la même puissance. Plus de dichotomie privé/public. Deux primitives sont utilisées:
- Cryptage symétrique : comment manipuler les données et les démêler plus tard.
- Message Authentication Codes : une "somme de contrôle à clé": seules les personnes connaissant la clé secrète peuvent calculer le MAC sur certaines données (c'est comme un algorithme de signature dans lequel la clé privée et la clé publique sont identiques - donc la clé "publique" vaut mieux ne pas être publique!).
HMAC est une sorte de MAC qui est construit sur les fonctions de hachage de manière intelligente, car il existe de nombreuses façons non intelligentes de le faire, et qui échouent en raison de détails subtils sur ce que fournit une fonction de hachage et ne fournit PAS.
Certificats
Un certificat est un conteneur pour une clé publique. Avec les outils expliqués ci-dessus, on peut commencer à imaginer que le serveur aura une clé publique, que le client utilisera pour effectuer un échange de clé avec le serveur. Mais comment le client s'assure-t-il qu'il utilise la clé publique du bon serveur, et non celle d'un attaquant sournois, un méchant qui usurpe l'identité du serveur? C'est là que les certificats entrent en jeu. Un certificat est signé par une personne spécialisée dans la vérification des identités physiques; on l'appelle Autorité de certification. L'AC rencontre le serveur "dans la vraie vie" (par exemple dans une barre), vérifie l'identité du serveur, obtient la clé publique du serveur du serveur lui-même et signe le tout (identité du serveur et Clé publique). Il en résulte un ensemble astucieux qui est appelé un certificat. Le certificat représente la garantie par l'autorité de certification que le nom et la clé publique correspondent (si tout va bien, l'autorité de certification n'est pas trop crédule, donc la garantie est fiable - de préférence, l'autorité de certification fait pas signe les certificats après sa cinquième pinte).
Le client, en voyant le certificat, peut vérifier la signature sur le certificat par rapport à la clé publique de l'autorité de certification, et ainsi gagner en assurance que la clé publique du serveur appartient vraiment au serveur prévu.
Mais, me diriez-vous, qu'avons-nous gagné? Il faut encore connaître une clé publique, à savoir la clé publique CA. Comment vérifions-nous celui-là? Eh bien, nous pouvons utiliser un autre CA. Cela ne fait que déplacer le problème, mais cela peut aboutir au problème de savoir a priori un unique ou une poignée de clés publiques d'über-CA qui ne sont signées par personne d'autre. Pensivement, Microsoft a intégré une centaine de ces "clés publiques racine" (également appelées "ancres de confiance") au plus profond d'Internet Explorer. C'est là que la confiance naît (précisément, vous avez perdu la base de votre confiance à la firme de Redmond - vous comprenez maintenant comment Bill Gates est devenu le gars le plus riche du monde?).
[~ # ~] ssl [~ # ~]
Maintenant, mettons tout cela ensemble, dans le protocole SSL, qui est maintenant connu sous le nom de TLS ("SSL" était le nom du protocole quand il était une propriété de Netscape Société).
Le client souhaite parler au serveur. Il envoie un message ("ClientHello") qui contient un tas de données administratives, telles que la liste des algorithmes de cryptage pris en charge par le client.
Le serveur répond ("ServerHello") en indiquant quels algorithmes seront utilisés; le serveur envoie ensuite son certificat ("Certificat"), éventuellement avec quelques certificats CA au cas où le client en aurait besoin (pas de certificats racine, mais des certificats CA intermédiaires sous-jacents).
Le client vérifie le certificat du serveur et en extrait la clé publique du serveur. Le client génère une valeur aléatoire ("secret pré-maître"), la chiffre avec la clé publique du serveur et envoie ça au serveur ("ClientKeyExchange").
Le serveur déchiffre le message, obtient le pré-maître et en dérive des clés secrètes pour le chiffrement symétrique et MAC. Le client effectue le même calcul.
Le client envoie un message de vérification ("Terminé") qui est crypté et MACé avec les clés dérivées. Le serveur vérifie que le message Terminé est correct et envoie son propre message "Terminé" en réponse. À ce stade, le client et le serveur disposent de toutes les clés symétriques dont ils ont besoin et savent que la "prise de contact" a réussi. Les données d'application (par exemple une requête HTTP) sont ensuite échangées, en utilisant le cryptage symétrique et MAC.
Aucune clé publique ou certificat n'est impliqué dans le processus au-delà de la prise de contact. Cryptage symétrique (par exemple 3DES, AES ou RC4) et MAC (normalement HMAC avec SHA-1 ou SHA-256).
Après beaucoup de lutte. J'ai la compréhension ci-dessous des différences entre SSL, cryptage à clé asymétrique, certificat numérique (DC) et signature numérique (DS).
Qu'est-ce que le certificat numérique, également appelé certificat de clé publique?
DC est un document électronique qui utilise une signature numérique pour lier une clé publique avec des informations d'identité telles que le nom, l'adresse, etc.
Contenu du certificat: certificat de clé publique
Le plus important étant, l'algorithme de signature, l'émetteur et la clé publique.
Qu'est-ce qu'un cryptage à clé asymétrique et une signature numérique?
Expliqué au moyen d'un exemple.
Les deux machines ont une paire de clés cryptographiques - une clé de cryptage publique et une clé de décryptage privée.
Machine-A a accès à la clé publique et au certificat de Machine-B.
Machine-B a accès à la clé publique et au certificat de Machine-A.
Machine-A à Machine-B
Chez Machine-A:
- Hash_function (Data) = Hash
- Chiffrer (hacher) à l'aide de la clé privée de Machine-A = DS
- Attacher des données à DS et DC = Data + DS + DC
- Chiffrez (Data + DS + DC) à l'aide de la clé publique de Machine-B.
- Envoyez-le à Machine-B.
Chez Machine-B:
- Déchiffrez (Data + DS + DC) à l'aide de la clé privée de Machine-B.
- Vérifiez DC pour authentifier la Machine-A.
- Déchiffrer (DS) à l'aide de la clé publique de Machine-A = Hash # 1
- Hash_function (Data) = Hash # 2
- if (Hash # 1 == Hash # 2) Les données et la signature sont valides.
Machine-B à Machine-A
Le processus est maintenant exactement l'inverse de ce qui précède.
Qu'est-ce que SSL/TLS?
Le protocole TLS permet aux applications client/serveur de communiquer sur un réseau d'une manière conçue pour empêcher l'écoute et la falsification. Dans la plupart des communications client-serveur, seul le serveur doit être authentifié. TLS rationalise le cryptage des clés asymétriques pour utiliser efficacement ce phénomène. Secure Sockets Layer
Exemple client et serveur.
Le serveur possède un certificat numérique acquis auprès d'une autorité de certification. Il dispose également de clés publiques et privées.
L'utilisateur clique sur une URL commençant par
https: //
Une connexion sécurisée est nécessaire pour cette session. Le navigateur établit une connexion TCP sur le HTTPS TCP Port 443.
- Client> Serveur: SYN
- Client <serveur: SYN + ACK
Client> Serveur: ACK
Prise de contact SSL sur la nouvelle connexion TCP:
Client> Serveur: CLIENT_HELLO
Le client envoie une commande CLIENT_HELLO au serveur, qui comprend:
- La version SSL et TLS la plus élevée prise en charge par le client.
- Chiffres pris en charge par le client. Les chiffres sont classés par ordre de préférence.
- Méthodes de compression des données prises en charge par le client.
- L'ID de session. Si le client démarre une nouvelle session SSL, l'ID de session est 0.
- Données aléatoires générées par le client pour être utilisées dans le processus de génération de clés.
Client <serveur: SERVER_HELLO
Le serveur envoie une commande SERVER_HELLO au client, qui comprend:
- La version SSL ou TLS qui sera utilisée pour la session SSL.
- Le chiffre qui sera utilisé pour la session SSL.
- Méthode de compression des données qui sera utilisée pour la session SSL.
- ID de session pour la session SSL.
- Données aléatoires générées par le serveur pour être utilisées dans le processus de génération de clés.
Client <Serveur: CERTIFICAT (CLÉ PUBLIQUE)
Le serveur envoie la commande CERTIFICATE. Il comprend le certificat des serveurs.
Client <serveur: SERVER_DONE
Le serveur envoie la commande SERVER_DONE. Cette commande indique que le serveur a terminé cette phase de la négociation SSL.
Client> Serveur: CERTIFICATE_VERIFY
Le client informe le serveur qu'il a vérifié le certificat du serveur
Client> Serveur:
À l'aide de toutes les données générées jusqu'à présent dans la poignée de main, le client (avec la coopération du serveur, selon le chiffrement utilisé) crée le secret pré-maître pour la session, le chiffre avec la clé publique du serveur (obtenue à partir du certificat du serveur ), puis envoie le secret pré-maître chiffré au serveur.
Le serveur utilise sa clé privée pour déchiffrer le secret pré-maître, puis effectue une série d'étapes pour générer le secret maître.
Le client effectue également la même série d'étapes sur le secret pré-maître pour générer le même secret maître.
Remarque: dans les situations où le client doit être authentifié, le client signe également une autre donnée unique à cette poignée de main et connue du client et du serveur. Dans ce cas, le client envoie à la fois les données signées et son propre certificat au serveur avec le secret pré-maître chiffré.
Client <> Serveur:
Le client et le serveur utilisent le secret principal pour générer les clés de session, qui sont des clés symétriques utilisées pour crypter et décrypter les informations échangées pendant la session SSL et pour vérifier leur intégrité.
Remarque: Désormais, c'est le cryptage à clé symétrique.
Client> Serveur:
Le client envoie un message au serveur l'informant que les futurs messages du client seront cryptés avec la clé de session.
Client> Serveur: FINI
Le client envoie ensuite un message séparé (chiffré) indiquant que sa partie de la prise de contact est terminée.
Client <serveur:
Le serveur envoie un message au client l'informant que les futurs messages du serveur seront cryptés avec la clé de session.
Client <serveur: TERMINÉ
Le serveur envoie un message distinct (chiffré) indiquant que sa partie de la négociation est terminée.
La prise de contact SSL est maintenant terminée et la session commence. Le client et le serveur utilisent les clés de session pour crypter et décrypter les données qu'ils s'envoient mutuellement et pour valider leur intégrité.
Pour une explication plus détaillée "sous le capot", je peux également suggérer l'article suivant: Les premières quelques millisecondes d'une connexion HTTPS par Jeff Moser. L'article utilise des captures de paquets d'une session de communication HTTPS pour illustrer le fonctionnement du protocole. Il est intéressant de voir les choses dont nous parlons en action et cela efface de nombreux points "sombres".
Pas assez; les certificats n'entrent en jeu que lors de la négociation SSL initiale ou lors d'une renégociation SSL. Après cela, un chiffrement symétrique tel que AES, (3) DES ou RC4 sera utilisé. La cryptographie à clé publique est généralement plus chère que la cryptographie symétrique, elle est donc généralement utilisée pour convenir d'une clé symétrique au début.