¿Cómo compartir de forma segura la clave entre dos dispositivos remotos?

Lo que está buscando es un par de claves pública / privada también conocido como SSL en el mundo de la computadora.

Un certificado SSL como mencionaste es suficiente seguridad ya que para saber qué se está enviando, necesitas la clave privada del certificado y no puedes obtenerlo sin entrar en el servidor.

Si no desea usar SSL, otra opción sería usar un par de claves públicas / privadas codificadas en el cliente / servidor que actuaría como SSL pero sin tener un certificado firmado.

Secure Sockets Layer (SSL) parece ser la respuesta que está buscando. Aquí hay una cita de la página Wikipedia :

  

Utilizan certificados X.509 y, por lo tanto, criptografía asimétrica para asegurar la contraparte con la que se están comunicando e intercambiar una clave simétrica . Esta clave de sesión se utiliza para cifrar los datos que fluyen entre las partes. Esto permite la confidencialidad de los datos / mensajes y los códigos de autenticación de mensajes para la integridad de los mensajes y, como subproducto, la autenticación de mensajes.

Sin embargo, también puede que desee echar un vistazo a RSA y Diffie-Hellman que se pueden usar en un cliente / Modelo de servidor para intercambiar claves de forma segura. Sin embargo, tienen muchos tipos de ataques adjuntos; el man-in-middle es uno de ellos, en el que un intruso podría simplemente intervenir y robar la llave. Otro ataque posible es el brute-force , en el cual un intruso puede adivinar la clave que eres tratando de transferir.

Si desea intercambiar claves de forma segura utilizando estos algoritmos, asegúrese de hacerlos con MD-5 o SHA-X . Incluso puede cifrarlos si tiene espacio, utilizando DES / Double DES / Triple DES , o AES- 128/192/256 algoritmos de cifrado.

Lee esto:

  

Antes de que un cliente y un servidor puedan comenzar a intercambiar información protegida por TLS, deben intercambiar de forma segura o acordar una clave de cifrado y un cifrado para usar al cifrar datos. Entre los métodos utilizados para el intercambio / acuerdo de claves se encuentran: claves públicas y privadas generadas con RSA (denotadas TLS_RSA en el protocolo de protocolo de enlace de TLS), Diffie-Hellman (denotadas de TLS_DH en el protocolo de protocolo de enlace de TLS), efímeras Diffie-Hellman protocolo de protocolo de enlace), curva elíptica Diffie-Hellman (denotada TLS_ECDH), curva efímera elíptica Diffie-Hellman (TLS_ECDHE), anónimo Diffie-Hellman (TLS_DH_anon) y PSK (TLS_PSK).   El método de acuerdo de clave TLS_DH_anon no autentica el servidor o el usuario y, por lo tanto, rara vez se utiliza. Solo TLS_DHE y TLS_ECDHE proporcionan secreto de reenvío.   Los certificados de clave pública utilizados durante el intercambio / acuerdo también varían en el tamaño de las claves de cifrado públicas / privadas utilizadas durante el intercambio y, por lo tanto, en la solidez de la seguridad proporcionada. En julio de 2013, Google anunció que ya no usaría claves públicas de 1024 bits y que cambiaría a claves de 2048 bits para aumentar la seguridad del cifrado TLS que proporciona a sus usuarios.

Ambas respuestas han identificado SSL / TLS, pero considere agregar la autenticación del cliente a la mezcla. Esto garantizará que el servidor solo acepte conexiones para clientes autenticados / conocidos. El inconveniente de esto es que:

• a) Cada cliente debe emitirse con su propio certificado de autenticación de cliente (aunque no necesariamente de la misma CA que el servidor).
• b) Cada cliente debe almacenar la clave privada correspondiente. Es probable que esté en el software (aunque se puede almacenar en una tarjeta inteligente o en un token USB PKI).
• c) Cada cliente debe estar registrado con el servidor, aunque esto puede variar según la implementación del servidor. Algunos servidores pueden permitir la confianza basada en certificados de CA raíz conocidos. Algunos servidores pueden aceptar certificados basados en un enfoque de lista blanca. Algunos pueden ser una mezcla de ambos o alternativas.

El servidor debe poder configurarse para aceptar únicamente conexiones autenticadas por el cliente. En algunos servidores web, esta configuración se puede aplicar a recursos individuales en el servidor.

Consulte la página de Wikipedia para obtener detalles del protocolo TLS autenticado por el cliente:

Autenticación del cliente TLS

Si la pregunta se entiende correctamente, lo que realmente se pregunta aquí es cómo hacer un intercambio de claves .

Habiendo implementado esto de la misma manera discutida para un producto de seguridad, el siguiente enfoque general funciona independientemente del protocolo de transporte subyacente (y además no hace ninguna suposición sobre su seguridad subyacente):

1. El cliente genera una clave de transacción (aleatoria) usando un algoritmo pseudoaleatorio bueno (presumiblemente) bueno y (supuestamente) adecuado para el cifrado AES256 (o mejor).

2. El cliente genera una clave de respuesta simétrica (nueva aleatoria) utilizando el mismo proceso que en el paso (1).

3. El cliente cifra la clave de respuesta (2) con la clave de transacción de (1) ... usando AES256 o cualquier algoritmo preferido.

4. A través de PKI , el cliente (utilizando la clave privada del cliente) cifra de forma asimétrica la clave de transacción (1) para el servidor (destinatario) utilizando la clave pública del cliente. Esto asegurará que solo el destinatario deseado pueda leer la clave de transacción (1).

5. Genera una carga útil en la que se identifica al cliente (remitente), asociado con su clave pública en el lado del servidor (receptor). En esta carga útil estará la clave de transacción (PKI encriptada) (1) y la clave de respuesta (encriptada AES) (2). Hay más en esto, como los contenidos de hash para garantizar el no repudio, etc. - pero concentrémonos en el intercambio de claves ...

6. El cliente envía la carga útil al servidor. Se recomienda que se haga a través de TLS, etc., pero esto no es estrictamente necesario ya que el cifrado es suficiente para proteger las claves. Sin embargo, estar seguro de que el cliente está enviando la carga útil al servidor [correcto] (receptor) sin escuchas ilegales mejora la seguridad del intercambio de claves.

7. El servidor busca la clave pública del cliente. A través de PKI, (usando la clave privada del servidor), descifra la primera parte de la carga útil: la clave de transacción.

8. Al usar la clave de transacción, la clave de respuesta se descifra usando AES256 (debe ser el mismo algoritmo que se usa para el cifrado de clave de respuesta, debe ser parte de la carga).

9. En este punto, el cliente espera una respuesta del servidor.

10. El servidor, utilizando la clave de respuesta que el Cliente conoce (la generó) para esta transacción, puede cifrar cualquier contenido enlazado para el Cliente simplemente utilizando AES256 (algún algoritmo simétrico).

11. El cliente utiliza un algoritmo simétrico y una clave de respuesta para descifrar la respuesta del servidor.

Siempre que no se comprometan las claves secretas de PKI, se usan buenas sales, IV, etc. ... este proceso es muy sólido (utilizado por las organizaciones de seguridad de todo el mundo).

Tenga en cuenta que CUALQUIER criptografía se puede romper EVENTUALMENTE. El uso de este proceso basado en transacciones con nuevas (pseudoaleatorias de clave es importante) (grandes) claves pseudoaleatorias para cada par de solicitud / respuesta, es muy difícil comprometer la conversación.

Usando este método, incluso si UNA clave de transacción está comprometida, limita mucho la exposición ya que el acceso solo se obtendría de una sola transacción a la vez.

Estoy simplificando la respuesta de Darrell Teague, y también corrigiendo algunos puntos (especialmente 7 y 4), esto también debería responder las preguntas de Eric B.

1. El Cliente genera una clave compartida (aleatoria) utilizando un algoritmo pseudoaleatorio bueno (presunto) bueno y (presumiblemente) adecuado para el cifrado simétrico (por ejemplo, AES).

2. El Cliente genera una carga útil en la que se identifica al Cliente (remitente), asociado con su clave pública en el lado del servidor (receptor). Esta carga útil también incluirá la clave compartida (PKI encriptada) (1).

3. A través de PKI, el cliente cifra de forma asimétrica la carga útil del servidor (destinatario) mediante la clave pública del servidor. Esto asegurará que solo el destinatario deseado (el Servidor, que conoce la clave privada del Servidor) pueda leer la carga útil que contiene la clave compartida (1).

4. El cliente envía la carga útil al servidor.

5. A través de PKI, utilizando la clave privada del servidor, el servidor descifra la carga útil que contiene los datos de identificación del cliente y la clave compartida (1). Ahora tanto el Cliente como el Servidor conocen la clave compartida.

6. En este punto, tanto el Cliente como el Servidor pueden usar la clave compartida para una mayor comunicación.

7. En algún punto, la sesión ha terminado y la clave compartida se elimina. Cada sesión requiere una nueva clave compartida.