¿Por qué un ataque de hombre en el medio no puede ocurrir con RSA?

Este es el problema de la distribución de claves, y es difícil. En general, Alice ya debe saber que la llave le pertenece a Bob, o que alguien en quien ella confíe confirme que le pertenece a él.

Para HTTPS esto se logra mediante una Infraestructura de clave pública (PKI), donde Autoridades de certificación (CA) certifican que una clave pertenece a un determinado dominio o conjunto de dominios. Este esquema se desmorona rápidamente si cualquier CA ampliamente confiable no es digna de la confianza depositada en él, y desafortunadamente esto ha sucedido varias veces en el pasado ( WoSign , Symantec ).

SSH lo mitiga almacenando la clave de host para cada servidor con el que te conectas, luego te advierte si la clave de host cambia para futuras conexiones (esto se llama trust en el primer uso ). También le advierte y le permite verificar la huella dactilar de la clave cuando se conecta por primera vez, pero esto requiere obtener la huella dactilar por otros medios, por lo que no resuelve el problema sino que se lo pasa al usuario.

No te equivocas, en sentido estricto. Las garantías de confidencialidad y autenticidad ofrecidas por el cifrado asimétrico presuponen que todas las partes tienen copias auténticas de las claves públicas de sus homólogos. Si un adversario se hace pasar por tu contraparte y te engaña para que aceptes su propia clave no auténtica como el verdadero, todo se derrumba.

La ventaja de la criptografía asimétrica es que esta autenticación puede ocurrir en algún canal que sea visible para todo el público. Piénselo de esta manera: toda criptografía requiere que los participantes usen algún tipo de canal seguro intermitente en algún momento para configurar la criptografía para más adelante. La criptografía simétrica pura requiere un canal confidencial y auténtico para que los participantes establezcan las claves secretas compartidas. La criptografía asimétrica mejora eso porque solo requiere un canal auténtico ; puede autenticar las claves públicas de sus homólogos a plena vista de los espías.

El problema que describió puede efectivamente ocurrir: nada en RSA (o cualquier otro esquema de encriptación) lo previene. Esto se llama por ejemplo. "problema de distribución de claves".

Sí, intercambiar la clave sobre un canal seguro , en lugar del inseguro del mensaje, es una forma de resolverlo. Dependiendo del caso de uso, puede haber otras formas útiles (o no).

En TLS, esto se evita al tener algo del otro lado: los certificados públicos de varias CA, preinstalados con el sistema operativo o el navegador. Puede usarse para verificar la firma de la clave pública transmitida, que una CA realizó primero.

(No es realmente relevante para esta pregunta, pero nadie cifra los mensajes directamente con RSA. Por ejemplo, porque es lento. Cifrar los mensajes con AES y luego solo la clave AES con RSA es mucho más común, pero no es así. cambia el problema aquí).

¿Por qué afirma que no puede suceder con RSA? Por supuesto que sí.

En caso de que la clave pública sea falsa. Supongamos que A solicita la clave pública de B. A se refiere al host de destino por nombre. Si el atacante pone en peligro el DNS de A, A puede obtener la IP del host comprometido, lo que le proporciona un certificado falso. Toda la cadena de certificados puede ser comprometida. A obtiene una clave pública y cree que esta es una clave de B, mientras que en realidad es una clave de C. Luego sucede lo que usted ha descrito. C está en el medio y lee todo el tráfico.

Lea acerca de la fijación de claves públicas. Es una de las posibles medidas contra el hombre en los ataques medios en PKI, no limitado a RSA.

  

Ahora, cuando A envía un mensaje cifrado usando lo que él cree que es B   clave pública (pero en realidad es C), C interceptará este mensaje,   descifre y luego vuelva a cifrarlo utilizando la clave pública real de B.

     

¿Esto funcionaría? ¿Si no, porque no? ¿Es solo cuestión de usar una   ¿Red segura para enviar la clave pública?

Sí, esto "funcionaría" en cierto sentido. Este es un ataque MITM bien conocido en criptografía de clave asimétrica. Esta técnica no solo es utilizada por los "malos". Por ejemplo, esto es exactamente lo que hacen los dispositivos de seguridad de red de ciertos proveedores para "inspeccionar" el tráfico de red cifrado y bloquear el tráfico "malo".

Entonces, ¿por qué puse "funcionaría" entre comillas? Bueno, por ejemplo, si un malintencionado de MITM sustituye su propio certificado por un certificado de sitio web HTTPS conocido, lo más probable es que ese certificado no haya sido firmado por una CA de confianza (a menos que el MITM pueda haber engañado a la CA de confianza para que firme un certificado que declaró que él era el sitio web conocido). En este caso, un navegador web que vaya al sitio web HTTPS que recibe el certificado MITM enviará una alarma y le dirá al usuario que no proceda porque el nombre de dominio no coincide o no coincide pero el certificado no fue firmado por una CA de confianza.

Los certificados de CA confiables están integrados en su sistema operativo cuando los compra. Estos son tipos como Verisign, etc. Puede ver sus certificados de CA confiables utilizando las utilidades del sistema operativo. Puede eliminarlos si lo desea, pero luego todos los sitios web que visite aparecerán sin un bonito símbolo de bloqueo verde.

Creo que te perdiste el rol de la Autoridad de certificación (CA) en la creación / distribución de certificados.

El concepto de infraestructura de clave pública ha evolucionado para ayudar a resolver estos problemas y otros. Una infraestructura de clave pública (PKI) consta de elementos de software y hardware que un tercero de confianza puede usar para establecer la integridad y la propiedad de una clave pública.

La parte de confianza, denominada entidad de certificación (CA), normalmente lo logra emitiendo certificados binarios firmados (encriptados) que afirman la identidad del sujeto del certificado y vinculan esa identidad a la clave pública contenida en el certificado. La CA firma el certificado utilizando su clave privada. Emite la clave pública correspondiente a todas las partes interesadas en un certificado CA autofirmado. Cuando se utiliza una CA, el ejemplo anterior se puede modificar de la siguiente manera:

1. Suponga que la CA ha emitido un certificado digital firmado que contiene su clave pública. La CA autofirma este certificado usando La clave privada que corresponde a la clave pública en el certificado.
2. Alice y Bob aceptan usar la CA para verificar sus identidades.
3. Alicia solicita un certificado de clave pública de la CA.
4. La CA verifica su identidad, calcula un hash del contenido que hará su certificado, firma el hash usando el privado Clave que corresponde a la clave pública en la CA publicada. certificado, crea un nuevo certificado concatenando el contenido certificado y el hash firmado, y hace que el nuevo certificado públicamente disponible.
5. Bob recupera el certificado, descifra el hash firmado usando el Clave pública de la CA, calcula un nuevo hash del certificado. contenido, y compara los dos hashes. Si los hashes coinciden, el La firma se verifica y Bob puede asumir que la clave pública en el El certificado pertenece a Alicia.
6. Bob usa la clave pública verificada de Alice para cifrar un mensaje para ella.
7. Alice usa su clave privada para descifrar el mensaje de Bob.

En resumen, el proceso de firma de certificado permite a Bob verificar que la clave pública no haya sido manipulada o dañada durante el tránsito. Antes de emitir un certificado, la entidad emite el contenido, firma (cifra) el hash utilizando su propia clave privada e incluye el hash cifrado en el certificado emitido. Bob verifica el contenido del certificado descifrando el hash con la clave pública de CA, realizando un hash separado del contenido del certificado y comparando los dos hashes. Si coinciden, Bob puede estar razonablemente seguro de que el certificado y la clave pública que contiene no se han alterado.

Fuente: enlace