Cómo tener cifrado de cliente sin clave de cifrado del servidor

1

Quiero crear un servicio donde las personas puedan enviarse mensajes a través de su dispositivo móvil para que cifren toda su información en su dispositivo y no en mi servidor. Básicamente, quiero que dos personas se envíen mensajes de forma segura y confíen en que mis servidores y nadie más puede tener ningún conocimiento o acceso a sus datos sin sus permisos. Estoy especialmente preocupado por prevenir los ataques de mitm.

Actualmente, todos mis mensajes se ejecutan a través de mis servidores rabbitmq en los EE. UU., pero quiero que los mensajes de datos que pasan a través de rabbitmq se cifren antes de llegar a mis servidores mq. Entiendo que esto es básicamente lo que es SSL, pero ¿es realmente la mejor opción, especialmente si los servidores de certificados están basados en los Estados Unidos? ¿Es posible tener claves de cliente generadas dinámicamente solo almacenadas en dispositivos móviles que yo no pueda descifrar? Lo que temo es que el gobierno solicite mis claves de cifrado para descifrar el tráfico de mis clientes en caso de una demanda inminente.

    
pregunta encryption man 05.03.2016 - 22:39
fuente

3 respuestas

4

Primero: la primera regla de criptografía: ¡No lance su propio criptográfico!

Segundo: ¿Por qué quieres configurar este servicio? Señal (+ OTR o Axolotl ) hace todo esto para: Está abierto: source, permite la verificación entre pares, ofrece encriptación de extremo a extremo, ofrece almacenamiento encriptado del lado del cliente y en el que confían todos los criptógrafos conocidos.
Divulgación: sí utilizo Signal y estoy convencido de su calidad, no estoy trabajando para OpenWhisperSystems o de otra forma afiliada.

Pero ahora, vayamos a responder sus preguntas:

  

Entiendo que esto es básicamente lo que es SSL, pero es realmente el   La mejor opción que existe, especialmente si los servidores de certificados son los EE.UU.   basado?

SSL (o, más moderno, denominado TLS ) generalmente proporciona seguridad de transporte entre los usuario y sus servidores. No hace nada por sí mismo más allá de eso. Podría permitir a los clientes establecer sesiones TLS entre ellos (lo que resultaría en un buen cifrado de extremo a extremo), sin embargo, TLS está más diseñado para ser un protocolo de seguridad en tiempo real (algo). En cuanto a los certificados, si utiliza algo más que el intercambio de claves RSA , una fuga de la clave privada no permitirá el descifrado de datos TLS (si eliminó el efímero (EC) DHE teclas) pero permitiría ataques de hombre en el medio (esto supone que se usa DHE anónimo / efímero (EC)). Adaptar un estilo de estilo TOFU u otro mecanismo de actualización de claves podría hacer que la conexión sea resistente al hombre en los ataques medios después de la conexión inicial.

  

¿Es posible tener claves de cliente generadas dinámicamente solo almacenadas   en dispositivos móviles que no pueden ser descifrados por mí?

Absolutamente. OTR ya incluye dicha funcionalidad. Básicamente, usted desea terminar como una retransmisión de los mensajes que transmiten los clientes (como la infraestructura de Internet estándar) mientras negocian de forma segura un secreto compartido a través de sus servidores. Puede verificar su compañero comparando los hashes del secreto compartido de Diffie-Hellman (o la clave pública de la otra parte utilizada para autenticar las claves públicas de Diffie-Hellman) out-of-band .

    
respondido por el SEJPM 05.03.2016 - 23:22
fuente
2

Parece que podría adoptar un esquema similar al que ProtonMail utiliza para el correo electrónico cifrado de extremo a extremo seguro.

ProtonMail afirma que no tiene acceso a la información de los usuarios. Cada usuario genera un par de claves en su propio dispositivo, y ProtonMail tiene la clave pública de cada usuario. Los mensajes están cifrados en el lado del cliente, y solo los mensajes cifrados se envían a través de los servidores de ProtonMail. Para obtener más información, consulte enlace .

    
respondido por el mti2935 05.03.2016 - 23:09
fuente
0

Aunque algunos en este hilo dicen no rodar tu propio sistema de cifrado, argumentaré de lo contrario que es necesario para facilitar el verdadero aprendizaje. Dicho esto, es mejor usar una solución sólida revisada por otros expertos como lo mencionó la gente en este foro.

Lo que está buscando es el cifrado del lado del cliente utilizando un cifrado de clave asimétrico. A medida que avanza el esquema, intercambias las claves públicas con quien quieras hablar. Un buen algoritmo a utilizar es la clave pública RSA. Con las claves públicas de RSA, puede hacer cosas como ... firmas digitales para autenticar a la persona que realmente tiene un par de claves privadas con la clave pública que tiene.

Lo que puede hacer es hacer que su aplicación genere un lado del cliente de par de claves, y le dé la clave pública a su servidor. Cuando alguien más quiere hablar con su cliente, su servidor entregará esa clave pública a ese cliente y ahora puede intercambiar mensajes cifrados a través de RSA.

He pasado por alto algunos detalles, pero así es como construirías un protocolo resistente a MITM. Si hay algo que debería obtener de esto, ...

La clave pública RSA solo debe usarse para cifrar, mientras que la clave privada solo se usa para descifrar. Nunca entregue la clave privada a nadie, incluido su servidor. Dicen que RSA 2048 es lo suficientemente seguro, pero normalmente lo hago RSA 4096 solo porque

    
respondido por el Dr.Knowitall 12.01.2018 - 22:04
fuente

Lea otras preguntas en las etiquetas