¿Cuáles son las implicaciones de MitM de una clave privada robada del lado del cliente?

0

Muchos teléfonos VoIP admiten la autenticación SSL del lado del cliente para el autoaprovisionamiento. Desafortunadamente, algunos dispositivos deben programarse con sus teclas del lado del cliente. (Las claves generadas en dispositivos de baja entropía son deficientes, pero no discutamos ese detalle).

Para esta pregunta, tenemos tres jugadores:

  1. El dispositivo (un teléfono)
  2. El servidor (algún servidor HTTPS autenticado del lado del cliente)
  3. Eve, que ha interceptado o robado la clave del cliente.

Si Eve intercepta una clave privada del lado del cliente durante la instalación de la clave inicial, ciertamente, Eve puede hacerse pasar por el cliente.

Para fortalecer aún más la posición de Eve, asuma que el dispositivo acepta cualquier certificado autofirmado presentado por el servidor de aprovisionamiento (algunos dispositivos no tienen una manera de programar CA personalizados). También asuma que Eve puede redirigir todas las conexiones a través de ella misma.

Dado esto, ¿puede Eve aprovechar un ataque MitM completo, como el siguiente:

Dispositivo {Clave de cliente} = > {CA2} Eve {Clave de cliente} = > {CA1} Servidor

Creo que la respuesta es sí y que la única forma de evitar un MitM es que el dispositivo valide el certificado del servidor a través de una CA de confianza. Por favor confirme o refute. Estoy interesado en detalles técnicos aquí.

    
pregunta ewheelerinc 03.12.2013 - 20:39
fuente

3 respuestas

2

Si el cliente acepta cualquier certificado como un certificado de servidor válido, un atacante activo puede hacerse pasar por el servidor cuando habla con el cliente.

Si el atacante puede robar una copia de la clave privada del cliente, entonces puede hacerse pasar por el cliente cuando habla con el servidor.

Si se cumplen ambas condiciones, entonces el atacante puede ejecutar un ataque de Man in the Middle , por definición: un ataque MitM no es más que doble personificación simultánea. El atacante se hace pasar por el cliente cuando habla con el servidor, y como el servidor cuando habla con el cliente; él transmite el tráfico en ambas direcciones, inspeccionando y modificando los datos a voluntad.

Si el cliente puede asegurarse de que usa el certificado del servidor original (ya sea a través de la validación de una CA raíz de confianza conocida, o quizás porque el cliente recuerda el certificado del servidor de una conexión anterior), entonces el cliente rechazará el intento de suplantación y MitM no funcionará. El atacante, que ha robado la clave privada del cliente, aún podrá reemplazar al cliente, por ejemplo. secuestrar llamadas entrantes, pero eso no será un verdadero MitM (el atacante tendrá que imitar la voz del propietario del cliente normal).

Tenga en cuenta que si el atacante no tiene una copia de la clave privada del cliente, y el servidor valida la clave pública del cliente de alguna manera (por ejemplo, el servidor recuerda el la clave pública del cliente después de un paso de configuración inicial), entonces el atacante no podrá hacerse pasar por el cliente. La autenticación del cliente en SSL es tal que incluso si el atacante se hace pasar por el servidor, no puede reutilizar los mensajes de un cliente crédulo para engañar al verdadero servidor. Técnicamente, el cliente utiliza su clave privada para firmar un "desafío" que es un valor de cálculo calculado sobre todo lo que el cliente y el servidor se han enviado hasta el momento, y esto incluye el certificado del servidor; por lo tanto, en el caso de MitM, el cliente firmará los mensajes que contengan la clave pública del atacante (el certificado falso del servidor enviado por el atacante), no el certificado enviado por el verdadero servidor, y la firma no coincidirá con lo que espera el verdadero servidor.

Por lo tanto, si el cliente puede asegurarse de que usa el certificado del servidor verdadero, o el servidor puede asegurarse de que usa el certificado del cliente verdadero, o ambos , entonces un intento completo de MitM debe fallar. Sin embargo, incluso sin un MitM, la suplantación (una "mitad-MitM") todavía es posible:

  • Si el atacante roba la clave privada del servidor, o el cliente no puede validar el certificado del servidor, entonces el atacante puede hacerse pasar por el servidor.
  • Si el atacante roba la clave privada del cliente, o el servidor no puede validar el certificado del cliente, entonces el atacante puede hacerse pasar por el cliente.

Finalmente, si el atacante tiene una copia de la clave privada del servidor , y el conjunto de cifrado SSL / TLS es uno de los conjuntos RSA que no son DHE, entonces el el atacante puede descifrar todos los datos después de una intercepción puramente pasiva, y también puede secuestrar la conexión en cualquier momento después del apretón de manos, lo que permite, de nuevo, un MitM. Lo mismo no es válido para una clave privada robada de cliente ; En SSL / TLS, el certificado de cliente y la clave privada se usan solo para la autenticación, no para el intercambio de claves, y no tienen ninguna influencia en el secreto resultante que se usa para el cifrado de datos real.

    
respondido por el Thomas Pornin 03.01.2014 - 13:37
fuente
1

Sí, pero parcialmente no.

Eve puede realizar cualquier solicitud al servidor haciéndose pasar por el dispositivo móvil y puede VER la respuesta del servidor (ya que se conocen la clave pública y privada). Sin embargo, Eve no puede cambiar la respuesta que el servidor envía para que se vea diferente al dispositivo móvil a menos que se use un algoritmo de hash débil que sea susceptible de ataques de colisión para generar la firma.

    
respondido por el Squirrel 03.01.2014 - 13:17
fuente
0

Creo que, por definición, un "ataque MiTM completo" solo puede ocurrir cuando un atacante (Eve en este caso) puede determinar TANTO el cliente y la clave del servidor. ¿Es esa la definición de la que estás trabajando también?

Aunque el cliente (dispositivo móvil) es muy ingenuo en este caso, no veo cómo Eve puede usar cualquiera de sus ventajas anteriores para obtener la clave privada del servidor. ¿Puedes ver algo que me falta?

Lo único en lo que puedo pensar es que Eve reemplace (y almacene) el teléfono y las claves públicas del servidor y los mensajes de intercepción, y los envíe simulando que realmente proceden de ella. Una vez que recibe una respuesta (que se habría cifrado con la clave pública de Eve), podría usar la clave pública del destinatario para cifrar el mensaje y luego transmitirla. Sin embargo, esto no significa que se obtenga la clave privada del servidor.

    
respondido por el jkovba 03.12.2013 - 20:50
fuente

Lea otras preguntas en las etiquetas