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:
- Implemente lo que cree que es un protocolo de canal seguro.
- 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.
- 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.