¿Es seguro este escenario?

Question

Estoy usando RSA para cifrar la comunicación entre un servidor y un cliente. Digamos que tenemos 2 llaves asimétricas, clave 1 y clave2.

El servidor tiene key1 (Privado) desde el principio y el cliente tiene la key1 (público)

Así que aquí está el panorama:

1. el cliente genera clave2
2. cliente se conecta al servidor
3. enviar clave2 (público) cifrada con key1 (público)
4. a partir de ahora en el servidor enviará todos los datos cifrados con la clave2 (público)
5. el cliente envía algunos datos aleatorios al servidor
6. el servidor devuelve los mismos datos hash
7. el cliente verifica que los datos es correcta

Por lo que yo puedo ver esto debe prevenir un hombre -en el medio ataque, o me estoy perdiendo algo? En el punto 7, el cliente debe saber si alguien está tratando de darle al servidor la clave incorrecta para encriptar, ya que nadie más que el servidor puede descifrar key2 (público).

Si hay algo que se pueda hacer para mejorar la seguridad, por favor dígame.

Answer 1

Lo mejor que puede hacer para mejorar la seguridad es utilizar un diseño existente y no intentar reinventar la rueda. No estoy diciendo que lo que has hecho sea necesariamente incorrecto, pero solo que mucha gente mucho más inteligente que tú y yo hemos pasado mucho tiempo pensando en este problema. Use TLS en su lugar.

Answer 2

Mientras key1 (privado) no haya sido interceptado de alguna manera por un tercero, su escenario se ve seguro.

Creo que vi esto en algún lugar del periódico. En él, Alice le dio a Bob una caja desbloqueada (clave 1 pública), luego Bob puso un montón de sus propias cajas (clave 2 pública) en él, lo bloquea y se lo envía a Alice. Luego, Alice abre la caja (clave 1 privada) y ahora puede cerrar con seguridad las cajas que Bob acaba de darle.

A pesar de la analogía de la caja, eso es esencialmente lo que estás haciendo, por lo que diría que es seguro.

Answer 3

No, este protocolo no es seguro.

Un hombre en el medio puede interceptar los datos enviados por el cliente y enviar lo que quiera al servidor, ya que no ha especificado ningún mecanismo para que el servidor autentique al cliente o verifique la integridad de los mensajes recibe

Claro, podría cambiar su protocolo para solucionar estos problemas evidentes, pero habría otros. Si alguna vez los arreglas todos, tendrías algo que se asigna a TLS o SSH, entonces ¿por qué no comenzar allí?

---

@Petoj — el problema que se centraba en que era del servidor confiando los mensajes que recibe; su propuesta no proporciona ninguna seguridad allí.Sin embargo, si le preocupa la confidencialidad, todavía tiene un problema, porque el MITM podría pasar mensajes sin cambios hasta que vea lo que quiere encontrar porque no tiene privacidad en los mensajes del cliente.

Su propuesta parece estar dirigida a garantizar la integridad de los mensajes del cliente. Desarrolló el protocolo hasta el punto en que el cliente no puede distinguir entre un ataque y una falla de la red. En lugar de tratar de ayudar al cliente a determinar si el servidor actuó en un mensaje manipulado, permita que el servidor verifique la integridad del mensaje antes de actuar sobre él.

Answer 4

Acepto, solo use TLS.

Además, ¿qué valor ofrecen los pasos 5 a 7? Un MITM que desee realizar un ataque que funcione después de los pasos 1 a 4 (por ejemplo, DoS de algún tipo al pasar n transacciones y luego detenerse, forzando un reintento desde el principio) podría hacerlo también después de 5-7. ¿Qué agregan?

- MarkusQ

Answer 5

Estoy de acuerdo con Greg que está reinventar la rueda. Lo que esencialmente está describiendo es alguna forma básica de key exchange. Por cierto, para garantizar que sea seguro contra los ataques de hombre en el medio, también debe estar seguro de la identidad del servidor, es decir, asegurarse de que el cliente pueda saber con certeza que lo que cree que es público (clave1) realmente es del servidor y no el hombre-en-el-medio de (por ejemplo, utilizando una CA o tener pública del servidor (key1) en lugar seguro en el lado del cliente.)

por otra parte, hay consideraciones adicionales debe ser consciente desde un punto de vista de sistemas, tales como:

• cifrado de clave asimétrica es más lento que el cifrado de clave simétrica, que es una de las razones por qué las soluciones existentes, como TLS, usarán el cifrado de clave asimétrica solo para negociar una clave simétrica temporal, que luego se utilizará para el cifrado del canal.
• si el análisis de tráfico realizado por un tercero tiene éxito al descifrar una clave simétrica temporal, no ha comprometido su par de claves asimétricas. Está animado a renegociar la clave temporal con relativa frecuencia por este motivo. Podría decirse que generar un nuevo key2 en su escenario mitigaría este aspecto.