Envío de claves de cifrado / descifrado a través de HTTPS

0

Soy un novato en el mundo criptográfico, así que tengan paciencia conmigo.

Pensando en una estrategia (para asegurar los datos P2P) en la que el servidor está generando una clave que debe usarse para el cifrado AES entre clientes y enviarla a múltiples clientes (Android, iOS, web). Me preguntaba si debería usar el cifrado al enviar esta clave a través de la red https a los clientes o https puede encargarse de esto. Entiendo que el intercambio de claves de Diffie Hellman se realiza por la misma razón, pero ¿es una exageración?

    
pregunta amitchhajer 04.05.2018 - 06:52
fuente

3 respuestas

1

HTTPS (o TLS en general) se puede usar para enviar el secreto a los clientes de forma segura, es decir, protegido contra la detección y modificación. Pero, debe tener algún tipo de autenticación para protegerse contra los ataques de los hombres en el medio (que pueden oler o modificar el secreto). La autenticación generalmente se realiza con un certificado que el cliente debe conocer por adelantado o donde el cliente puede obtener la confianza porque fue firmado por un emisor de confianza.

Diffie-Hellman solo no es suficiente para intercambiar la clave, ya que falta la parte de autenticación. De hecho, TLS comúnmente (pero no siempre) utiliza Diffie-Hellman como intercambio de claves, pero también realiza la autenticación del servidor.

    
respondido por el Steffen Ullrich 04.05.2018 - 10:21
fuente
0

El intercambio inicial de claves públicas se realiza a través de un canal inseguro. Una vez que ambas partes tienen la clave pública de la otra parte, pueden usar criptografía asimétrica para acordar una clave simétrica. Después de eso, toda la comunicación es cifrada simétricamente. Pero tenga en cuenta que esto depende del intercambio inicial de claves públicas sobre una conexión insegura. ¿Cómo saber si un tercero no ha interceptado la clave pública de una de las partes, ha sustituido su propia y posteriormente ha enviado mensajes entre las dos partes?

Una solución es que las dos partes legítimas conozcan las claves públicas de cada una (o el hash de las claves públicas de la otra) de antemano. Eso es más seguro, pero inusual en 2018.

Otra solución es que ambas partes confíen en una entidad externa, como una autoridad de certificación. Los navegadores y sistemas operativos vienen preempaquetados con una cantidad sustancial de autoridades de certificación confiables. Una cantidad muy sustancial. Y esas autoridades de certificación suelen ser empresas (empresas comerciales con presencia física y oficinas y cuentas bancarias) que operan bajo las gracias de los gobiernos que tienen jurisdicción pertinente sobre ellas. Si dicho gobierno obligara a una autoridad de certificado raíz a emitir un certificado intermedio falso al gobierno, entonces cualquier navegador web que ya confíe en la autoridad de certificación raíz confiaría en ese certificado. Y como señalé, hay MUCHAS autoridades de certificados raíz de confianza en su navegador y / o en su sistema operativo. Cada uno de ellos es vulnerable a la coerción impuesta por el gobierno (o posiblemente al crimen organizado, dependiendo de su impunidad relativa en ese país). En realidad, un compromiso como este ha ocurrido, especialmente en 2011, a una autoridad de certificación llamada DigiNotar. Esto condujo a violaciones de seguridad masivas a nivel de estado-nación.

Por último, existe la solución de contar con una versión más pequeña del sistema de autoridad de certificación compuesta por círculos de confianza, entidades que comúnmente son reconocidas por las partes comunicantes como confiables pero seleccionadas de manera deliberada por adelantado y no instaladas en el navegador de manera predeterminada. Las claves públicas podrían ser firmadas por una entidad de confianza mutua antes de que se intercambien a través del intercambio Diffie Hellman.

El desafío es intercambiar esas claves públicas de manera confiable antes de que ocurra cualquier comunicación encriptada posterior. Diffie Hellman NO es una panacea.

    
respondido por el vrtjason 04.05.2018 - 16:33
fuente
-1

Supongo que debe utilizar cualquier algoritmo de intercambio de claves para realizar el intercambio de claves, independientemente de la sobrecarga (todos los algoritmos criptográficos principales tienen una complejidad de tiempo alta). El HTTPS no puede ayudarlo en este contexto, porque HTTPS solo verificará el origen de la clave (Su servidor). No se garantiza que la clave no haya sido copiada o robada por nadie.

El Diffie-Hellman utilizado en HTTPS para el intercambio de claves, se usa para intercambiar las claves enviadas por la autoridad de certificación al cliente, que descifra la carga útil recibida del servidor y, por lo tanto, lo autentica.

Lea esto para obtener más detalles.

    
respondido por el Penguine 04.05.2018 - 08:17
fuente

Lea otras preguntas en las etiquetas