¿Es seguro este escenario?

Question

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

El servidor tiene la clave1 (Privada) desde el principio y el cliente tiene la clave1 (pública)

Así que aquí está el escenario:

1. el cliente genera la clave2
2. el cliente se conecta al servidor
3. enviando clave2 (público) encriptado con clave1 (público)
4. a partir de ahora, 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 el mismo hash de datos
7. el cliente verifica que los datos sean correctos

Hasta donde puedo ver, esto debería evitar un ataque de hombre en el medio, ¿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 cifrar, ya que nadie más que el servidor puede descifrar la clave2 (pública).

Si hay algo que se pueda hacer para mejorar la seguridad, dígamelo.

Answer 1

Lo mejor que puede hacer para mejorar la seguridad es usar un diseño existente y no intentar reinventar la rueda. No digo que lo que has hecho esté necesariamente mal, sino que mucha gente mucho más inteligente que tú y yo hemos pasado mucho tiempo pensando en este problema. Utilice TLS en su lugar.

Answer 2

Siempre que la clave1 (privada) no haya sido interceptada de alguna manera por un tercero, su escenario se ve seguro.

Creo que vi esto en algún lugar de un periódico en realidad. En ella, 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), la cerró y la envió de vuelta a Alice. Luego, Alice abre la caja (clave 1 privada), y ahora puede sellar de manera segura las cajas que Bob acaba de darle.

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

Answer 3

Estoy de acuerdo, solo use TLS.

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

- MarkusQ

Answer 4

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 preparar 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 simplemente comenzar allí?

---

@ Petoj & # 8212; el problema en el que me estaba centrando era el del servidor que confiaba en los mensajes que recibe; su propuesta no proporciona ninguna seguridad allí. Sin embargo, si está preocupado por la confidencialidad, todavía tiene un problema, porque el MITM podría pasar los mensajes de un lado a otro sin alterarlos 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. Has desarrollado 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 5

Estoy de acuerdo con Greg en que estás reinventando la rueda . Lo que esencialmente está describiendo es alguna forma básica de intercambio de claves . Por cierto, para garantizar que sea seguro contra ataques de intermediarios, también debe estar seguro de la identidad del servidor, es decir, asegurarse de que el cliente pueda saber con certeza lo que realmente cree que es público (clave1). el servidor y no el intermediario (p. ej., usar una CA o tener el servidor público (clave1) en un almacenamiento seguro en el lado del cliente)

Además, hay consideraciones adicionales que debe tener en cuenta desde el punto de vista de los sistemas, tales como:

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