¿Cómo se llama este esquema y cómo debería funcionar exactamente?

1

Estaba pensando en la comunicación cliente-servidor y en cómo mantener esto en privado, especialmente de los ataques de intermediarios. Se me ocurrió un esquema que estoy seguro de que ya existe, pero no pude encontrar resultados de búsqueda suficientemente concretos para obtener más información al respecto.

Comencé a pensar que cuando un cliente se conecta al servidor, le gustaría establecer un canal de comunicación seguro, para que el cliente pueda generar un par de claves privada / pública y enviar la clave pública al servidor. El problema es llevar la clave pública al servidor de manera segura (de lo contrario, un hombre en el medio podría descifrar todos los mensajes usando la clave pública que tomó del primer mensaje, adjuntar su propia clave pública al mensaje, usar la clave privada correspondiente para descifrar) la respuesta y, después de almacenar eso, volver a cifrar con la clave pública real del cliente).

Así que pensé en una posible solución: el cliente primero recibe una clave pública del servidor, que utilizará para cifrar su propia clave pública. MitM puede interceptar todos los mensajes, pero no podrá descifrar ninguno de ellos; solo el servidor real puede descifrar la solicitud del cliente y la respuesta solo puede ser descifrada por el cliente real. Una vez que el servidor conoce la clave pública del cliente, la almacenan de forma segura y la utilizan para cifrar cualquier otra comunicación.

Tengo algunas preguntas relacionadas.

  1. ¿Cómo se llama este tipo de seguridad / handshaking?
  2. He escuchado la palabra nonce pero tengo razón en que se trata de prevenir los ataques de repetición y no el problema MitM que estoy tratando de resolver.
  3. La clave inicial que el servidor envía al cliente, ¿debería ser fija y posiblemente publicada en algún lugar, para que los clientes puedan omitir el "dame el paso de tu clave pública" en las sesiones posteriores? ¿O debería ser una clave recién generada para cada cliente en cada nueva solicitud de sesión?
  4. Por el contrario, ¿debería cambiar la clave pública del cliente con cada sesión o puede reutilizar la misma clave una vez que se haya comunicado de forma segura al servidor?
  5. ¿Cuáles son los riesgos de esto, aparte de la falla obvia por parte de una de las partes involucradas de mantener privadas las claves privadas?

Estoy seguro de que esto es bastante común y, probablemente, de la forma en que funcionan muchos esquemas de autenticación, así que en lugar de responder todas estas preguntas por separado, me alegraría que alguien me proporcionara la terminología adecuada (probé algunas combinaciones de palabras clave como "cliente / servidor", "cifrado asimétrico", "establecimiento de sesión", pero son demasiado generales para encontrar algo útil). Y aunque esta es una SE teórica, supongo que al igual que con toda la buena seguridad, uno no debe implementar su propia implementación, por lo que cualquier código de ejemplo de una aplicación cliente / servidor adecuada (por ejemplo, en PHP) que utilice bibliotecas bien establecidas sería bienvenido.

    
pregunta CompuChip 12.05.2018 - 01:07
fuente

1 respuesta

1
  1. La frase específica que está buscando es "intercambio de claves". enlace

Hay algunos esquemas (muchos en desuso) para lograr esto de manera segura, pero si está escribiendo su propio programa (y, por lo tanto, no está tan preocupado por "quién es esta persona en realidad", y casi por cambiar las llaves de manera segura ), Diffie-Helman es un buen lugar para comenzar. enlace

Diffie-Helman está diseñado específicamente para hacer que el intercambio de claves sea seguro, incluso si se observa . Si desea hacer que el intercambio de claves sea seguro contra los ataques MitM, ahí es donde entra los certificados firmados por una CA de confianza. Una CA de confianza no firmará (o no se supone que se supone ) la misma identidad para múltiples partes, por lo que un atacante en el medio que intercepte la clave pública legítima antes de que se le entregue al conversador deseado no podrá incluirla en su propia clave pública, ya que no estará debidamente firmada digitalmente.

  1. De hecho, los Nonces están ahí para asegurarse de que cada mensaje solo se responda una vez, y generalmente dentro de un tiempo establecido. No impiden que un atacante los intercepte, los reenvíe, la respuesta, los reenvíe, etc.

  2. El secreto hacia adelante se considera la mejor práctica ahora. enlace Con los sistemas que implementan el secreto hacia adelante, se generan nuevas claves en cada sesión, de modo que la información de la sesión anterior no se puede comprometer mediante una intercepción de mitm de las nuevas claves. Nota: no está generando nuevas claves privadas a largo plazo en cada sesión, está generando 'claves secretas' nuevas y aleatorias (es decir, la clave utilizada solo durante esa sesión para cifrar el tráfico).

  3. Las claves privadas específicas del usuario que se usan para generar claves seguras por sesión se mantienen, pero esas claves no son las claves que se usan para cifrar y descifrar directamente el tráfico.

  4. Aparte del compromiso de clave privada, nada puede evitar que un mitm altere el tráfico que pueden tocar. Las firmas de CA adecuadas pueden evitar que la cadena de certificados sea válida si hacen manipulan algo, pero eso no protegerá realmente los datos; solo su confiabilidad.

respondido por el Angelo Schilling 12.05.2018 - 02:22
fuente

Lea otras preguntas en las etiquetas