autenticación mutua entre dos clientes

"Cliente" y "Servidor" son solo nombres formales para roles en situaciones donde existe una asimetría natural. A saber, uno habla primero: ese es el "cliente".

Así es como va en SSL : el protocolo está definido para operar en un medio de transporte bidireccional. Una de las entidades habla primero y envía un mensaje ClientHello . No hay un requisito absoluto de que la noción de "cliente" y "servidor" que utiliza SSL coincida con las nociones de "cliente" y "servidor" para la conexión subyacente cuando esa conexión es un socket TCP a través de Internet. Sucede que es así.

En general, cualquier protocolo de autenticación entre dos sistemas (llamémoslos "A" y "B") funciona mediante el envío de mensajes entre sí, y uno de los sistemas será el primero en hablar. Siempre que A y B sepan quién debe hablar primero, mediante alguna convención , entonces el protocolo funcionará. La convención es fácil de obtener cuando hay una asimetría, p. Ej. el software en una máquina no es el mismo que el software en la otra máquina. Por ejemplo, para la Web, un sistema usa un navegador web (por ejemplo, Firefox) mientras que el otro usa un servidor web (por ejemplo, Apache), y los estándares definen lo que se supone hacer.

Imagina una llamada telefónica . Alguien marca el número del otro. El comportamiento normal es que la persona que recibe la llamada hablará primero (y dirá "hola"). Ese es exactamente el concepto que quieres. Si estos dos interlocutores desean ejecutar algún protocolo de autenticación, deberán acordar sus respectivos roles (pueden llamarse a sí mismos "cliente" y "servidor" si así lo desean). Usar la asimetría del marcador / receptor es una forma natural de iniciar esa convención. Pero podrían usar cualquier otra convención; por ejemplo, podrían usar el orden lexicográfico de sus nombres (Alice es el "cliente" y Bob el "servidor" porque 'A' está antes de 'B' en el alfabeto); o su fecha de nacimiento; o pueden intentar aleatoriamente; o lo que sea.

Dicho esto, en el caso específico de SSL, normalmente hay certificados y la máquina con el rol de "servidor" muestra un certificado al "cliente"; el "cliente" también puede mostrar un certificado al "servidor". Los certificados prueban los enlaces entre claves e identidades, pero esto tiene algún valor solo si la identidad tiene algún significado. Es decir, cuando el servidor muestra su certificado al cliente, el punto importante es que el certificado del servidor contiene el nombre del servidor , y el cliente espera un nombre de servidor muy específico (el de la URL). De manera similar, cuando el cliente muestra su certificado al servidor, esto hace una autenticación útil solo si el servidor puede encontrar en el certificado alguna noción de identidad que tenga sentido para él.

Una situación más interesante con SSL es SRP : con esta variante, ningún certificado. El cliente y el servidor se autentican entre sí en relación con su conocimiento de un secreto compartido (una contraseña). ¡Todavía deben ponerse de acuerdo sobre quién habla primero! Y hay un punto adicional, que es la entidad con el rol de "servidor" que no necesita almacenar la contraseña en sí misma, solo una versión con hash de la misma (con alguna estructura algebraica). En ese sentido, quién asume el rol de "servidor" no es completamente arbitrario con respecto a la seguridad: incluso en un protocolo de autenticación mutua , las características de seguridad logradas en ambos lados pueden diferir.

La forma más sencilla es que cada parte cifre su comunicación con su clave privada. Si puede descifrar mi mensaje con mi clave pública, entonces I debe haberlo cifrado. Por supuesto, eso depende de que usted tenga una copia de mi clave pública en la que confía haber venido de mí. Si necesitamos una comunicación segura y autenticada continua, entonces el primer mensaje es la mitad clave. Cifro una mitad de clave con tu clave pública y tú cifras una mitad de clave con mi clave pública: intercambiamos las mitades de las claves cifradas y combinamos las claves para crear una clave de sesión, luego usamos criptografía con clave simétrica para mantener la seguridad.

Hay demasiadas incógnitas en tu pregunta. Hacer Alice & ¿Bob tiene una comunicación fuera de canal? ¿Se conocen, es esta su primera transacción? ¿Qué tan segura debe ser la autenticación? ¿Qué tan resistente?

Investigue Diffie-Hellman Key exchange o Internet Key Exchange Protocol , o Key Agreement protocol . Todos estos están estrechamente relacionados con el problema que sugieres.

También puedes intentar la confianza transitiva: este es el antiguo estilo pgp en el que si mi clave está avalada por suficientes personas, es muy probable que yo sea yo.

Todo lo que dice great bear también es cierto.

Pero quiero advertirle: el 90% del error de cualquier sistema criptográfico no es el protocolo, es la implementación. El hecho de que alguien haya implementado un SSL / TLS con seguridad adecuada no significa que el suyo será.