Una forma segura de cifrar una conexión entre 2 clientes que protegen contra adversarios tanto pasivos como activos

No puede tener una clave privada codificada en el software que se distribuye.

Las dos opciones que veo son:

1. Haga que cada cliente genere un par de claves único que usen para comunicarse con el servidor. Bob enviaría su clave pública al servidor cuando se conecte inicialmente. El servidor luego cifrará los mensajes a Bob con su clave pública. La primera comunicación entre el servidor y Alice será el servidor que le pedirá a Alice su clave pública para poder utilizarla en futuras comunicaciones. El servidor puede pasar una clave simétrica encriptada con sus claves públicas a cada uno de Bob y Alice para usar en futuras comunicaciones.
2. Dale al servidor un par de claves. Cuando Bob se conecta por primera vez con el servidor, Bob crea una clave simétrica que cifra con la clave pública del servidor. El servidor y Bob usan esto para encriptar más comunicaciones. Cuando el servidor se pone en contacto por primera vez con Alice, le pasa su clave pública. Alice responde creando una clave simétrica y enviándola al servidor, cifrada con la clave pública del servidor. El servidor puede comunicarse con Alice utilizando esta clave.

La opción 1 anterior utiliza lo que llamaré el modelo SSH donde los clientes generan pares de claves únicos para cada servidor. La opción 2 usa lo que llamaré el modelo SSL donde los servidores tienen el par de claves (aunque SSL comunica la clave pública en un certificado firmado).

Si haces lo anterior tendrás muy buena seguridad. Dicho esto, no será perfecto. El problema es que todavía serás vulnerable a los ataques MiTM .

Para poder trabajar de manera segura, SSH requiere que valide la huella digital de la clave pública del servidor la primera vez que se conecte con ella. El protocolo no explica cómo validar esto. La mayoría de los usuarios solo dicen que está bien sin validar, pero existe la posibilidad de que MITM esté allí.

SSL valida automáticamente la clave pública del servidor al validar la cadena de certificados. Esto solo funciona porque hay un almacén de claves con certificados de raíz de confianza preinstalados con su sistema operativo, navegador u otro cliente. Sin esa validación, la clave pública en el certificado del servidor se puede falsificar sin detección.

No creo que pueda hacerlo mucho mejor a menos que use una infraestructura de seguridad existente. Por ejemplo, puede hacer que su servidor ejecute SSL y que el cliente valide el certificado aprobado en el protocolo de enlace SSL.

No veo esto como un problema, ya que estará tan seguro como SSH cuando el cliente no valide correctamente la clave pública del servidor. OMI, eso es bastante bueno.

Este es un problema muy bueno. ¡Disfruta!

PD: No es necesario que te disculpes por tu inglés. Es tan bueno como un hablante nativo.

Dependiendo de dónde te encuentres, diría que este es un gran proyecto para la escuela secundaria. La ruta ipsec + dnssec + pki + tls / ssl es en gran medida una faceta basada en el protocolo de este ejercicio. Tal vez le gustaría plantear el aspecto de seguridad física de las cosas también. Por ejemplo, se muestra la ubicación de los puntos finales como un factor de mitigación. Después de todo, los esquifes de nivel Fips para equipos no están ahí para nada.

Fundamental a la pregunta, es si el punto final no está asegurado, se pueden obtener las claves, lo que sea que puedan ser, por lo que para las transacciones seguras de punto final, el propio terminal está bajo la supervisión del propietario, por ejemplo. cajeros automáticos, puntos de efectivo, etc.

Buen proyecto, pero como siempre no deberías reinventar la rueda. Escribir tales protocolos para el uso de producción es una mala idea en casi todos los casos. Recomiendo leer el libro de ingeniería de criptografía de Bruce Schneier. No es una lectura ligera, pero definitivamente eliminará todas sus preguntas. En primer lugar, creo que quemar claves en ejecutables es una idea terrible. Debe ser una clave que proteja sus datos confidenciales, no el método (consulte el principio de Kerckhoff). También hace clave la gestión de un PITA. ¿Por qué involucra al servidor en la negociación de claves, es un requisito? Si no me equivoco, usa esa tecla "1234" para la autenticación de pares. Simplemente puede hacer que los clientes lo firmen y verifiquen en el lado del servidor utilizando las claves de cliente. Usted escribió "Una vez que se decida una clave común, use esta clave o un hash de esta clave". Una vez más, la fortaleza clave debe proporcionar seguridad, no el método. Los métodos se pueden reproducir, las claves no.

En general, creo que deberías usar un protocolo bien conocido en lugar de inventar el tuyo. Si solo es un proyecto para aprender protocolos criptográficos, primero recomiendo buscar otros que funcionen.

La respuesta (al menos para mi trabajo) es IPsec host to site o host to host con PKI autenticación y protección de las claves privadas en hardware.