Pourquoi l'échange de clés est-il nécessaire?
Disons que "Alice" et "Bob" veulent communiquer entre eux sur un réseau non sécurisé.
En utilisant l'échange de clés Diffie – Hellman, ils peuvent enfin obtenir la même clé symétrique . Cependant, si je comprends bien, ils n'ont pas du tout à obtenir la même clé symétrique , car ils peuvent simplement utiliser clé asymétrique sans échange de clé.
Avec l'algorithme RSA, Alice et Bob peuvent simplement partager leurs clés publiques (public_a, public_b) et conserver leurs clés privées (private_a, private_b). Alice peut simplement envoyer à Bob les messages chiffrés par public_b, et Bob peut les déchiffrer par private_b. Ils peuvent toujours communiquer sur un réseau non sécurisé, sans échange de clé Diffie – Hellman du tout.
Je sais que je peux me tromper, mais je ne sais pas où je me suis trompé. Quelqu'un at-il des idées sur pourquoi et quand l'échange de clés Diffie – Hellman (ou tout échange de clés) est nécessaire? Convient-il à la situation que j'ai mentionnée ci-dessus?
Si l'attaquant est capable de capturer passivement des données et accède plus tard à la clé privée des certificats (c'est-à-dire vol, attaque de cœur ou application de la loi), l'attaquant pourrait décoder toutes les données précédemment capturées si la clé de chiffrement est uniquement dérivée du certificat lui-même.
L'échange de clés DH permet de créer une clé indépendante du certificat. De cette façon, la connaissance du certificat ne suffit pas à elle seule pour décoder les données précédemment capturées. C'est ce qu'on appelle le secret avancé. Voir Wikipedia pour plus d'informations.
En plus de transmettre le secret avec DH, il existe d'autres raisons d'utiliser la cryptographie symétrique au lieu d'utiliser simplement les clés privées RSA. Ainsi, même si vous n'utilisez pas DH pour l'échange de clés, TLS créera une clé symétrique, qui est ensuite dérivée du certificat. Pour plus de détails, pourquoi utiliser la clé privée directement pour chiffrer n'est pas une bonne idée, voir Pourquoi PGP utilise-t-il le chiffrement symétrique et RSA? .
De nombreuses étapes sont nécessaires pour comprendre les raisons et je vais essayer de vous guider à travers chacune.
1) Utilisez le cryptage correctement ...
Avec l'algorithme RSA, Alice et Bob peuvent simplement partager leurs clés publiques (public_a, public_b) et conserver leurs clés privées (private_a, private_b). Alice peut simplement envoyer à Bob les messages chiffrés par private_a, et Bob peut les déchiffrer par public_a. Ils peuvent toujours communiquer sur un réseau non sécurisé, sans échange de clés Diffie – Hellman.
Cette partie est tout simplement fausse. Ce que vous faites dans cette partie est la signature, pas le cryptage. Puisque public_key_a est public, vos messages ne seraient pas du tout chiffrés. Au lieu de cela, A devrait chiffrer les messages avec public_key_b, puis B peut les déchiffrer avec private_key_b. Puisque private_key_b n'est connu que de B, A sait que seul B peut le déchiffrer.
La signature numérique prouve qu'un message provient d'une personne en particulier. Le chiffrement prouve que seuls vous, le détenteur de la clé et la personne qui a chiffré le message, l'expéditeur du message, connaissez le message. Vous devez avoir à la fois le chiffrement et la signature lors de l'utilisation du chiffrement asymétrique. Cryptage pour protéger la confidentialité du message et signature pour prouver que vous êtes bien celui qui a envoyé ce message.
Mais, il y a encore plus ... Par exemple, vous devez toujours vous protéger contre les attaques par rejeu.
2) Bob n'a généralement pas de clé publique
Disons que Alice (A) est le serveur et Bob (B) est le client. Habituellement, le client n'a pas de clé publique. Par exemple, connaissez-vous une clé publique? La réponse est très probablement NON. Par conséquent, Bob peut recevoir un message d'Alice et vérifier qu'ils viennent vraiment d'Alice, mais Alice ne peut pas être sûre que tout ce qu'il reçoit de Bob provienne vraiment de Bob.
Ce problème est l'une des causes profondes pour lesquelles nous avons ajouté un protocole d'échange de clés comme Diffie-Hellman.
3) RSA est limité à un bloc.
Il existe une technique utilisée pour crypter les longs messages qui s'appelle enchaînement de blocs de chiffrement . Malheureusement, cette technique ne peut pas être utilisée avec RSA. Ce n'est pas que c'est totalement impossible mais plutôt que personne ne sait si c'est vraiment sûr si nous le faisons. Par conséquent, il limite le chiffrement RSA à un bloc. D'un autre côté, les algorithmes de chiffrement symétriques comme AES fonctionnent comme un charme avec le chaînage de blocs et c'est la raison pour laquelle nous les utilisons.
Pour en savoir plus: https://crypto.stackexchange.com/a/126/16369
4) Diffie-Hellman est un protocole d'échange de clés
Diffie-Hellman est juste un moyen de "créer et partager" une clé qui peut ensuite être utilisée pour le chiffrement symétrique. La force de Diffie-Hellman est que toute la conversation pour créer cette clé peut se dérouler en texte brut et la clé serait toujours privée.
Remarque : Diffie-Hellman ne résout pas le problème des attaques MitM car il ne peut pas authentifier les parties communiquant entre elles. Ce problème est plutôt résolu avec signature numérique .
5) Diffie-Hellman éphémère offre un secret parfait avant
Éphémère Diffie-Hellman est juste un nom de fantaisie pour dire que vous générez de nouvelles paires de clés Diffie-Hellman à chaque session et que vous ne les stockez pas. Comme vous ne les stockez jamais, un attaquant ne peut jamais les récupérer.
Voir cette très bonne réponse pour plus de détails: https://security.stackexchange.com/a/38142/50051
6) Éphémère Diffie-Hellman vous protège contre les attaques par rejeu
Un très bon effet secondaire de l'utilisation d'Ephemeral Diffie-Hellman est qu'il vous protège également contre les attaques par rejeu. Étant donné que le serveur et le client choisissent une nouvelle clé DH privée aléatoire à chaque session, vous ne pouvez pas relire le message d'une autre session pour emprunter l'identité du serveur ou du client.
Conclusion
Il s'agit d'un très bref aperçu du fonctionnement de TLS et de toutes ces pièces nécessaires pour fournir une connexion sécurisée. Sans cryptage symétrique, vous ne pouvez pas crypter un long message et sans cryptage asymétrique, vous ne pouvez pas partager la clé de cryptage et fournir un secret de transmission parfait.
Vous supposez qu'Alice et Bob peuvent échanger de manière fiable des clés publiques sur un réseau non sécurisé.
Sans protocole d'échange de clés, Alice et Bob pensez cela se produit: (A = clé publique d'Alice, B = clé publique de Bob)
Alice ---------- A --------------> Bob
Alice <----------- B ------------- Bob
quand c'est ce qui se passe vraiment (M = clé publique de Mallory)
Alice ----- A ------> Mallory --------- M ------> Bob
Alice <---- M ------- Mallory <-------- B ------- Bob
Bob et Alice pensent maintenant qu'ils chiffrent les messages l'un pour l'autre; ils sont vraiment juste des messages de chiffrement pour Mallory, qui déchiffre, lit et recrypte les messages en utilisant les destinataires réels
L'utilisation de RSA pour tous les messages n'est pas souhaitable car l'algorithme est coûteux en calcul. L'utilisation de RSA pour négocier une clé symétrique vous permet d'envoyer des messages supplémentaires beaucoup moins cher en termes d'utilisation du processeur.