Comment l'échange de clés Diffie-Hellman non éphémère est-il compromis dans SSL lorsque la clé privée RSA est divulguée?
D'après ma compréhension, l'une des principales raisons pour lesquelles nous recommandons Diffie-Hellman Ephemeral (par exemple DHE ou ECDHE) par rapport à DH non éphémère, pour SSL/TLS, est que la compromission de la clé privée RSA (c'est-à-dire un certificat privé) permettrait à un attaquant de décrypter les conversations précédemment capturées. En revanche, l'éphémère devrait empêcher le décryptage à moins que l'attaquant ne soit en possession de la clé à l'époque de la conversation.
Comment fonctionne ce déchiffrement de l'échange de clés Diffie-Hellman non éphémère dans ce contexte? S'agit-il simplement d'observer les primitives non chiffrées qui sont échangées sur le fil? Dans l'affirmative, quel est l'intérêt d'utiliser DH, s'il n'offre aucune sécurité supplémentaire sur le chiffrement de la clé avec RSA, et que RSA fournit déjà l'authentification du serveur?
Soyons d'abord sûrs que nous parlons de la même chose. Dans SSL , il existe des "suites de chiffrement DH éphémères" (DHE) et des "suites de chiffrement DH non éphémères" (DH).
Avec DHE, la clé privée du serveur (la permanente, celle qui est stockée dans un fichier, et dont la clé publique est dans le certificat du serveur) est de type RSA (DHE_RSA cipher suites) ou DSS = (Suites de chiffrement DHE_DSS), et n'est utilisé que pour les signatures . Le serveur génère une nouvelle paire de clés DH aléatoire (la clé privée sera pas être stocké, c'est ainsi que secret de transmission parfait est obtenu: une clé privée ne peut pas être volée par la suite si elle n'a jamais été stockée), et envoie la clé publique au client, en un message que le serveur signe avec son RSA ou DSS clé privée.
Avec les suites de chiffrement DH, la clé privée du serveur permanent est une clé privée DH. Le certificat de serveur contient la clé publique DH. Le serveur ne peut pas voir sa clé RSA volée car le serveur ne possède pas de clé RSA. Le serveur ne dispose que d'une clé DH. Lorsqu'une suite de chiffrement est appelée "DH_RSA", cela signifie "la clé du serveur est une clé DH et le certificat du serveur a été émis (c'est-à-dire signé) par une autorité de certification qui utilise une clé RSA " .
Le vol de la clé privée DH d'une partie impliquée dans un échange de clé DH permet une reconstruction ultérieure du secret partagé, tout comme RSA. Dans "DH éphémère", la PFS est obtenue par "éphémère", pas par "DH". Techniquement, il serait possible d'avoir un "RSA éphémère" mais cela ne se fait pas dans la pratique (*) car générer une nouvelle paire de clés RSA est un peu cher, alors que produire une nouvelle paire de clés DH est bon marché.
(*) Les clés RSA éphémères étaient possibles avec les anciennes versions de SSL dans le cadre des suites de chiffrement "export", censées être conformes aux réglementations d'exportation américaines d'avant 2000: le serveur pouvait avoir une signature 1024 bits - Clé RSA, et génère une paire de clés RSA éphémère 512 bits pour l'échange de clés, utilisée en mode de cryptage. Je ne me souviens pas avoir déjà vu cela dans la nature, cependant, et c'est un point discutable depuis la levée des réglementations américaines sur les tailles clés.
Des suites de chiffrement DH non éphémères existent pour permettre aux serveurs avec des certificats DH de fonctionner. Les clés DH dans le certificat existent parce que dans les temps anciens, RSA était breveté mais pas DH, donc les organismes de normalisation, en particulier NIST, faisaient de DH la norme incontournable.
La réalité a rattrapé cela, cependant. Je n'ai jamais vu de serveur SSL utilisant un certificat DH. Tout le monde utilise RSA. Le brevet RSA a expiré de toute façon il y a dix ans.
Pour SSL/TLS, nous avons besoin de 2 choses:
1) client needs to authenticate the server.
2) client and server need to compute a symmetric session key.
Quelques façons de faire les deux:
Le plus courant: TLS_RSA_WITH_AES _...
RSA is used for both 1 (authentication) and 2 (computing symmetric key).
préféré: TLS_DHE_RSA_WITH_AES _... ou TLS_ECDHE_RSA_WITH_AES _...
RSA is used for 1 (authentication) and for signing the DHE keys.
DHE is used for 2 (computing symmetric key).
Préféré, car vous bénéficiez de Perfect Forward Security (PFS)
Pas commun: DH_RSA _... (c'est le DH non éphémère dans la question de OP)
DH is used for both 1 (Authentication) and 2 (computing symmetric key).
Le cas auquel vous faites référence est le 3ème ("Pas commun") et comme vous pouvez le voir, RSA n'est utilisé ni pour 1 (Authentification) ni pour 2 (calcul de clé symétrique) et il n'est donc pas question de fuite de clé privée RSA . Le RSA dans DH_RSA pourrait être trompeur, mais comme Tom Leek l'a mentionné, l'administrateur du serveur fournira les informations d'identification et leur clé publique DH à une autorité de certification (CA) qui signera ensuite la clé publique DH avec la clé privée RSA de l'autorité de certification.