web-dev-qa-db-fra.com

Quelle est la différence entre DH et DHE?

J'ai lu SSL et TLS à l'épreuve des balles

Diffie Hellman est un mécanisme d'échange de clés, dans lequel chacun du serveur et du client partage un secret, c'est-à-dire gx et gy respectivement entre eux où g est générateur d'un certain groupe. Ils calculent le secret S = (gy)x et (gx)y respectivement. Notez qu'un attaquant au milieu ne peut pas obtenir la valeur de S de gx et gy, car le logarithme discret est un problème difficile. Mais, un attaquant actif peut masquer et tromper le serveur et le client.

DHKE

Maintenant dans RSA_DH, la valeur que le serveur envoie au client, c'est-à-dire gx est fixe et stocké dans le certificat. Le message "ServerKeyExchange" n'est donc pas envoyé. Maintenant, le client envoie son gy valeur dans le message "ClientKeyExchange" et celle-ci est chiffrée avec l'algorithme de cryptographie à clé publique RSA dont le serveur de certificats a déjà envoyé le message "Certificat".

Dans RSA_DHE, le message "ServerKeyExchange" a lieu lorsque le serveur envoie gx au client.

TLS Handshake

Maintenant, ma question est quelle est la différence entre les deux? Étant donné que le secret prémaster est calculé à partir de la valeur (gx)yPar conséquent, même dans RSA_DH, si le client envoie un g différenty valeurs dans chaque session, puis (gx)y la valeur sera différente. (Je pense que même s'il ne tient toujours pas mon argument). Par conséquent, il obtiendra le secret de transmission comme dans RSA_DHE. Et le pauvre attaquant ne pourra pas obtenir de secret prémaster même après avoir obtenu la valeur de gy en compromettant la clé privée du serveur. Donc, dans les deux cas, il ne sera pas en mesure de calculer le secret prémaster. Alors pourquoi l'un éphémère (RSA_DHE) est censé atteindre le secret avancé et l'autre non?

21
prakharjain

Diffie-Hellman est un algorithme asymétrique, avec une clé publique et une clé privée.

Dans une suite de chiffrement "DH_RSA", la paire de clés "permanente" du serveur est une paire de clés DH. La clé publique se trouve dans le certificat du serveur. Ce certificat, comme tout certificat, a été signé par une autorité de certification et cette autorité de certification utilise une paire de clés RSA (c'est ce que signifie le "RSA" dans "DH_RSA").

Dans une suite de chiffrement "DHE_RSA", la paire de clés permanente du serveur a le type RSA; la clé publique RSA est dans le certificat du serveur (la suite de chiffrement ne dit rien sur le type de clé utilisé par l'autorité de certification émettrice, mais il s'agit généralement de RSA également). Lorsqu'un client se connecte, le serveur génère une paire de clés DH transitoire et envoie la clé publique au client sous la forme d'un message ServerKeyExchange; le serveur signe ce message avec sa clé privée RSA permanente.

Forward secrecy est une propriété définie relativement au vol ultérieur de secrets de serveur. Les suites de chiffrement "DHE_RSA" fournissent une confidentialité de retransmission car le secret d'échange de clé réel (la clé privée DH) est transitoire, donc pas enregistré par le serveur - si le serveur n'enregistre pas cette clé sur son disque, il doit donc être à l'abri des vols ultérieurs. Inversement, "DH_RSA" implique que la clé privée DH est stockée quelque part sur le disque dur du serveur, et si cette clé est volée, la session enregistrée passée peut être décryptée.

Il faut noter que certains serveurs conserveront leurs paires de clés DH pendant un certain temps, généralement en RAM; ils ne font pas une nouvelle paire de clés DH pour chaque client. Ce comportement présente certains avantages en termes de performances mais affaiblit légèrement le secret de transmission, par définition. Cela dépend vraiment du modèle que vous utilisez pour définir le "vol ultérieur": parlez-vous de récupérer un vieux disque dur dans une benne à ordures, ou d'un malware qui inspecte le contenu RAM?

18
Thomas Pornin

Mais je n'ai pas pu comprendre pourquoi le simple RSA_DH ne prend pas en charge le secret de retransmission.

Disons qu'Alice est le client et Bob le serveur et utilise les noms de variables de votre diagramme.

En dh non emphéré, b fait partie du certificat, ce qui signifie que B est un secret à long terme. Eve enregistre la session, y compris la valeur de a.

Quelque temps plus tard, Eve met la main sur B, peut-être qu'elle a piraté le serveur, peut-être qu'elle a appelé ses amis des forces de l'ordre qui ont forcé l'administrateur du serveur à le lui remettre. Eve peut alors calculer unB et donc calculer le secret de la session et décrypter la session.

Avec empreal dh B n'est qu'un secret à court terme. Ainsi, le compromis ultérieur d'Eve sur le serveur est beaucoup moins susceptible de le révéler.

3
Peter Green