método de encriptación contra el hombre en el ataque central

2

Digamos que hay 3 computadoras: Alice, Bob, Carol. Carol es proveedor de la red, por lo que todo, desde Alice hasta Bob y viceversa, pasa a través de Carol. Carol puede modificar los mensajes entre Alice y Bob. ¿Existe algún algoritmo o método para la comunicación segura entre Alice y Bob, incluso si Carol puede modificar los paquetes? Para Diffie-Hellman encontré esto :

  

En términos generales, la idea básica es la siguiente. Antes de la ejecución de   El protocolo, las dos partes Alice y Bob obtienen cada uno un   Par de claves públicas / privadas y un certificado para la clave pública. Durante   El protocolo, Alice calcula una firma en ciertos mensajes, cubriendo   El valor público ga mod p. Bob procede de una manera similar. Aunque   Carol todavía puede interceptar mensajes entre Alice y Bob, ella   no se pueden falsificar firmas sin la clave privada de Alice y la privada de Bob   llave. Por lo tanto, el protocolo mejorado derrota al hombre en el medio   ataque.

¿Alguien puede explicar con un ejemplo?

Editar: A es cliente, y B es servidor, A usa inicio de sesión / contraseña para autenticar.

    
pregunta torayeff 07.10.2012 - 16:03
fuente

2 respuestas

9

Necesitas una definición . A saber, ¿qué es "Bob" a la vista de Alicia? Si "Bob" es "quien responde", entonces Carol sería un buen Bob; en ese caso, no hay un ataque real, solo Alice está hablando con "alguien" que es Carol.

Si hay una noción definida de Bobness que Alice puede usar, entonces hay algoritmos que se basan en eso. Así es como funciona SSL . Imagina que eres Alicia, Bob es un sitio web que conoces por su nombre (por ejemplo, "www.paypal.com"), y Carol es tu ISP malvado. No desea hablar solo con nadie , desea hablar con un Bob / servidor específico que tenga un nombre. Certificados de clave pública puede usar firmas para darle alguna garantía sobre el enlace entre el nombre (" Bob ", también conocido como" www.paypal.com ") y una clave pública: la garantía proporcionada por todo el sistema es que una clave pública dada es realmente" propiedad "de una entidad que lleva el nombre" www.paypal.com ", donde "poseer" significa "tener el control exclusivo de la clave privada correspondiente", y de manera que Carol no pueda obtener una garantía similar.

Una vez que haya una clave pública de un servidor conocido, el intercambio de claves se puede proteger contra MitM. Nuevamente, vea cómo se hace con SSL.

En el caso de los certificados X.509, Alice debe tener un conocimiento a priori de una clave pública de autoridad de certificado raíz (aquí "ancla de confianza"). Para otro modelo, considere SSH . Aquí, asumimos que Alice podría establecer, en algún momento, una conexión sin Carol hacia Bob (o una conexión que Carol no se molestó en modificar). Luego, Alice recuerda la clave de Bob, y la usa nuevamente para todas las conexiones subsiguientes. Así es como suele funcionar SSH: para la primera conexión, el cliente solicita la confirmación explícita del usuario y luego almacena la clave pública en el archivo .ssh/known_hosts de Alice. Lo ideal sería que, para la primera confirmación, Alice verificara con algún mecanismo fuera de banda la clave pública del servidor (su huella digital) antes de aceptarla por primera vez (por ejemplo, haciendo una llamada al administrador del sistema y comprobando con él la clave). huella dactilar).

    
respondido por el Thomas Pornin 07.10.2012 - 16:52
fuente
1

Respuesta posible: cuando se comunicó a través de una conexión segura como SSH, SCP, SFTP y me gusta, y siempre que su caja de Linux (cliente) no se vea comprometida, básicamente estará a salvo del ataque "Man in the middle". El protocolo TLS / SSL se considera seguro. Certificado autofirmado si lo firmó usted mismo, también es seguro.

Vea también enlace

    
respondido por el Rahul Gautam 07.10.2012 - 16:30
fuente

Lea otras preguntas en las etiquetas