Distribución de claves e intercambio de claves para una implementación sencilla y segura de FTP

2

Estoy desarrollando un protocolo de transferencia de archivos simple y seguro para un proyecto de la Universidad usando openssl.

Tengo un cliente (sea C) y un servidor (sea S).

C enviará a S mensajes como get , put , cd ,… y S enviará rutas o archivos según los mensajes que haya recibido.

Creé un par de claves (públicas, privadas). El cliente tiene la clave pública y el servidor tiene la clave privada.

Al comienzo de mi software hay un intercambio de claves simétricas generadas por el cliente. Como me gustaría cifrar los mensajes enviados por el cliente y los mensajes enviados por el servidor, ¿es mejor usar la misma clave privada o dos claves diferentes?

    
pregunta Edge7 09.06.2013 - 17:03
fuente

2 respuestas

2

Lo que está intentando recrear es TLS / SSL, que se publicó por primera vez en 1994 (SSL), y desde entonces se ha sometido a varias revisiones, con la especificación más reciente de 2011 (TLS): ¡17 años de desarrollo!

En TLS hay claves separadas para enviar y recibir (vea esta pregunta: Separe las claves de lectura y escritura en el material de clave TLS ), por lo que le parecerá sensato que haga lo mismo. Las partes también generan lectura y escritura de IV para su uso con cifrados de bloques.

TLS hace todo lo posible para combatir ataques conocidos, como incluir el envío y la recepción de recuentos de paquetes y números de secuencia como parte de HMAC. Algunos de los ataques conocidos se analizan en la RFC ( 5246 TLS 1.2 ), por lo que es posible que desee leerlos antes. empiezas a trabajar en tu propio protocolo.

También necesitará alguna forma de verificar la clave del servidor (o certificado, como se conoce en TLS) y esto requerirá un conocimiento a priori del lado del cliente, como su huella dactilar SHA. También necesitará que el servidor pruebe que es el titular de la clave privada correspondiente enviando algún tipo de desafío (en TLS, esto se describe en la sección F.1.1.2 del RFC vinculado anteriormente).

    
respondido por el Truthserum 09.06.2013 - 23:24
fuente
2

Tiene razón al generar claves simétricas al comienzo de la sesión. Más precisamente, el método normal es generar una clave simétrica (una clave de sesión), con un protocolo que asegure que ambas partes generen la misma clave, de modo que esta clave compartida se pueda usar en ambos lados. Un protocolo popular para dicho intercambio de claves es Diffie-Hellman . (A pesar del nombre, este no es un intercambio de claves simétricas: es un intercambio de claves públicas DH, lo que hace que las dos partes puedan generar el mismo material secreto). No necesita que ninguna de las partes tenga un par de claves asimétricas para hacer esto y establecer un canal seguro.

Cuando necesite al menos uno de los lados para tener una clave privada y el otro para tener la clave pública correspondiente, es para la autenticación. Con Diffie-Hellman, las dos partes pueden estar seguras de que ninguna tercera parte va a violar su comunicación, pero no pueden conocer la identidad de la otra parte, por lo que es posible un ataque de hombre en el medio: todo el atacante tiene Lo que hay que hacer es ejecutar el protocolo de inicio de sesión con el cliente y el servidor de forma independiente y, a partir de ese momento, transmitir mensajes (o no).

Si una de las partes no está dispuesta a comunicarse con cualquiera, debe autenticar a las otras partes. Existen dos métodos principales para hacer esto: con un secreto compartido (una contraseña) o con criptografía de clave pública. La autenticación de contraseña no es sencilla porque si, por ejemplo, el cliente envía su contraseña al servidor, esto es peligroso a menos que el cliente esté seguro de que se está comunicando con el servidor legítimo. De lo contrario, en caso de un ataque de hombre en el medio, el atacante obtendría la contraseña y podría enviarla al servidor para hacerse pasar por el cliente.

La criptografía de clave pública resuelve este problema. Para que el cliente autentique el servidor, debe conocer la clave pública del servidor. El cliente puede enviar un mensaje cifrado con esa clave pública; Sólo el servidor legítimo podrá descifrar el mensaje. Un simple protocolo es para que el cliente envíe su contraseña, más algún material clave, en este mensaje cifrado.

Es posible que ambas partes utilicen un par de claves pública / privada. En este caso, cada parte tendrá su propia clave privada. Las claves privadas nunca se comparten entre las partes, de lo contrario no tendría sentido no usar cifrados simétricos.

Ejercicios sugeridos:

  1. Implemente lo que cree que es un protocolo de canal seguro.
  2. Una vez que tu implementación funcione, juega con ella. Describa su protocolo por escrito o con diagramas. Intente encontrar una situación en la que se rompa su implementación, donde le permita a un tercero escuchar la comunicación entre el cliente y el servidor, suplantar a una de las partes o inyectar comandos o respuestas ilegítimos. La criptografía es difícil, así que no se desanime si se equivoca, eso es casi el punto del ejercicio.
  3. Se dice que cualquiera puede construir un protocolo criptográfico que no pueda romper si se esfuerza lo suficiente. Entonces, si no puede romper su propio protocolo, consulte la documentación sobre TLS , que es el estándar de la industria para canales seguros . Encuentre una característica en TLS que proteja contra algo que usted no. Averigua cómo romper tu protocolo de esa manera.
respondido por el Gilles 10.06.2013 - 19:54
fuente

Lea otras preguntas en las etiquetas