Verificación DHE

(Los certificados no están "cifrados", están firmados . Las firmas no son lo mismo que el cifrado. Describir las firmas como "cifrado con la clave privada" es una analogía defectuosa que no funciona con -Los algoritmos de firma RSA, y tampoco funciona bien con RSA, y solo genera confusión. Usemos la terminología apropiada.

En DHE, el servidor SSL tiene un certificado emitido (firmado) por una CA y que contiene una clave pública que es apta para firmas (por ejemplo, RSA, DSA, ECDSA ...). El servidor envía ese certificado al cliente, junto con los parámetros DH recién generados, que el servidor firma con esa clave.

En DH estático, el cliente verifica que la clave pública de DH forma parte de un certificado firmado por la CA y que lleva el nombre del servidor deseado. Con DHE, el cliente verifica que la clave pública de DH esté firmada en relación con una clave pública de firma, que se encuentra en un certificado firmado por la CA y que lleva el nombre del servidor deseado. DHE implica un nivel más de firma, pero en última instancia, enlaza con el sistema de CA.

(En la práctica, el DH estático es extremadamente raro; todos usan RSA para los certificados).

Puede ser más razonable referirse a ElGamal en este punto, que se puede considerar como "Diffie-Hellman retrasado" y hace lo que usted describe como "Diffie-Hellman estático". La forma en que funciona es básicamente la siguiente

You generate secret/public long-term keypair LTsec and LTpub

Envías LTpub a una CA, que puede contactarte por teléfono o cualquier otra cosa para verificar que realmente eres tú. Una vez realizada la verificación firman LTpub. Eso significa que obtienes un certificado firmado que consta de tu clave pública y la firma de la AC:

(new) LTpub = (LTpub, CAsig of LTpub)

Luego, puede usar eso para autenticarse usted mismo o su servidor o lo que desee. Por ejemplo, puede permitir que su servidor web en www.example.com se autentique con ese certificado. Cuando John se conecta a ese servidor y desea usar el Acuerdo de clave DH que ocurre (simplificado):

John genera un nuevo par de llaves DH efímero (Jpub, Jsec) y envía la parte pública al servidor web

 John  -----       Jpub     -----> Webserver

El servidor web genera un nuevo par de llaves DH efímeras (Wsec, Wpub) y envía la parte pública a John. También firma Wpub con LTsec desde arriba.

                   Wpub
 John  <---- SIGN_LTsec(Wpub) ---- Webserver
                   LTpub

Ahora John puede hacer ciertas cosas:

• John ahora puede verificar que Wpub fue generado por alguien que posee LTsec (¡importante!).
• John también puede verificar que el que posee LTsec es el que generó LTpub.
• John también puede verificar que una CA haya verificado LTpub.
• John ahora puede asumir que una CA verificó la información en LTpub mediante una llamada telefónica (o lo que sea) y que el emisor es quien se propone ser (aquí: www.example.com)
• Finalmente, John puede asumir razonablemente que comparte una clave (Wpub ^ Jsec) con www.example.com

Por supuesto, esto es solo una descripción muy básica de la relación de confianza y los detalles técnicos.

Después de todo, eche un vistazo más de cerca a ElGamal para obtener más información técnica.