Protocolo de Diffie-Hellman CA, confuso

Diffie-Hellman (DH) es un algoritmo de acuerdo de clave , utilizado para establecer material de clave simétrica compartida .

A veces se le llama "protocolo Diffie-Hellman", pero es un poco engañoso. Para DH se deben tomar ciertos pasos para utilizar elementos de datos específicos, como las claves públicas. Sin embargo, el protocolo DH no especifica exactamente cuando esos pasos deben tomarse ni la representación a nivel de bits de esos pasos. Peor aún, hay diferentes formas de realizar DH también. Para obtener solo una idea, puede consultar NIST SP 56 revisión 3 esquemas.

INTERLUDE: Si lees este documento, verás que en realidad es posible autenticarse usando DH. Para eso, una clave pública de confianza debe estar disponible en el lado que realiza la autenticación. Eso significa usar un par de claves static para la entidad que se va a autenticar. En general, esto se puede hacer utilizando un certificado DH (o ECDH). Sin embargo, estos apenas se encuentran en la vida real; la mayoría de los certificados se basan en firmas digitales en lugar de en el establecimiento de la clave DH.

Si y cómo se confía en una entidad, se basa en el protocolo de nivel superior , por ejemplo. un protocolo de transporte como TLS. En la última versión 1.3 de TLS, el obligatorio debe utilizarse para el llamado acuerdo efímero-efímero de clave Diffie-Hellman. En ese caso, el acuerdo clave se separa de la parte de autenticación: los parámetros de DH se incluyen simplemente en la autenticación final, pero el acuerdo en sí mismo no desempeña un papel en ella.

Esto también significa que la presencia de un certificado de CA de confianza solo se puede detectar mirando la fase de autenticación basada en X.509v3 que ocurre después de el establecimiento de la clave DH. Es decir: si DH tiene lugar en absoluto, por supuesto. Usted lo esperaría por ejemplo. la autenticación del servidor, pero también se pueden implementar otros métodos de autenticación.

Respuesta corta después de la explicación larga: sí, debe especificarla junto con el resto del protocolo de nivel superior que intenta implementar.

  

si los participantes tienen su propia clave privada y una clave pública generada

Diffie-Hellman no tiene una clave pública y privada. Imaginemos que estás en una habitación con al menos tres personas: Alice, Bob y Eve. Alice y Bob quieren hablar en privado (y entrar en una habitación diferente es demasiado fácil), por lo que Alice propone usar Diffie-Hellman:

Alice: Hagamos un intercambio de claves DH. Elige un número al azar y aumenta 5 a la potencia de ese número. Divide el resultado por 23 y dime el resto.

Alice elige 16, 5**16=152587890625 , y el resto cuando se divide por 23 es 3.

Bob elige 25, 5**25=298023223876953125 , y el resto cuando se divide por 23 es 10.

Bob: 10.

Alice: obtuve 3. Ahora subo mi número a la potencia de ese número de nuevo, y divídelo entre 23 nuevamente, y toma el resto.

Alice eleva los 10 de Bob al poder 16, 10**16=10000000000000000 , y toma el resto cuando divide por 23, 10000000000000000%23=4

Bob eleva el Alice 3 al poder 25, 3**25=847288609443 , y toma el resto cuando divide por 23, 847288609443%23=4

Obtuvieron el mismo resultado. Tienen un número común que Eva no conoce. Eve solo escuchó que Alice le envió 3 a Bob y que Bob le envió 10 a Alice. Ella no puede calcular el número 4.

Alice: ¡Ahora usa esta clave para AES y hablemos encriptados!

Por supuesto, en el mundo real, los números son mucho más grandes. Adivinar que la contraseña para AES es "4" no es muy difícil.

  

¿Necesitamos especificarlo, poner una firma digital en los mensajes o podemos asumir la autenticación cuando hay una clave pública involucrada?

En el ejemplo anterior, Alice y Bob podrían verse entre sí. Si Alice habló, Bob pudo ver que era Alice. En Internet, este no es el caso. Es más como comunicarse por carta: cualquier persona que entregue correo podría inyectar cartas falsas.

Por lo tanto, aún debe firmar este intercambio digitalmente, para asegurarse de que un (wo) hombre en el medio no inyecte nada en la conversación. Diffie-Hellman no puede hacer esto, por lo que necesita un algoritmo adicional: uno que use claves públicas y privadas. Los sistemas más populares para hacer esto son el algoritmo RSA y la criptografía de curva elíptica.

El modo en que funcionan las firmas digitales se explica abundantemente en otros lugares. Simplemente aplique firmas digitales a la conversación anterior (donde Alice proporciona los parámetros 5 y 23, donde Bob dice 10 y donde Alice dice 3) y usted tiene un protocolo de intercambio de claves autenticado.

Pero para intercambiar claves públicas, tiene el mismo problema: ¿cómo sabe que nadie en el medio cambió la clave pública real por su propia clave pública? Para eso se usan las Autoridades de Certificación (CA): son un tercero de confianza y ponen una firma digital en la clave pública. Otra forma de resolver esto es TOFU: Trust On First Use. Esto tiene la desventaja de que, si su primera comunicación ya fue interceptada, entonces su comunicación se ve comprometida. Pero tiene la ventaja de que no se necesita un sistema de CA, y por lo tanto no hay un CA que pueda ser comprometido.