¿Qué tan seguro es este chat de comunicación?

Question

¿Qué tan seguro es este chat de comunicación?

#1 de forest (2 votos)
#2 de Jonathan Cross (-1 votos)

2

He creado un chat entre dos partes (usando c #), y me pregunto qué tipo de debilidades he pasado por alto.

Descripción de su funcionalidad: Existen dos aplicaciones individuales: Cliente (2 instancias de TcpClient son las partes comunicantes) y Servidor (TcpListener, el relator de mensajes cifrados).

Nota: Supongo que las dos computadoras que contienen la aplicación cliente son seguras y no contienen ningún malware o virus que pueda alterar / monitorear la memoria, ingresar claves, hacer capturas de pantalla, etc. Por otra parte la aplicación del servidor puede estar en cualquier computadora que pueda estar potencialmente "comprometida" por falta de un término mejor.

Ahora, la funcionalidad de los Clientes es registrar el mensaje desde el teclado del usuario, cifrarlo (utilizando AES256 c # clases) y enviar los datos al servidor. Aunque antes de que pudieran enviarse los mensajes, los clientes intercambian claves públicas de acuerdo con el algoritmo de intercambio de claves Diffie Hellman , pero toda la comunicación entre los clientes funciona a través del servidor. Esencialmente, el servidor es una puerta de enlace, un puente entre los clientes, [1] , después de que el intercambio de claves y el servidor de generación de claves secretas solo recibe mensajes cifrados, no se molesta con su contenido, solo transmite el mensaje al otro cliente, que lo desencripta localmente. [2] .

He estado pensando en envolver mi NetworkStream en un SslStream, para hacer que el canal de comunicación sea más seguro, pero incluso si alguien puede "leer" el flujo, no puede leer el cifrado de todos modos, así que no creo que esto sea un error. falla crítica para mantener a salvo el MENSAJE SECRETO

No estoy protegiendo mi archivo .exe de ninguna manera (ni en el servidor ni en los clientes) ya que no creo que haya una protección del 100% si la computadora ya ha sido comprometida. En otras palabras, el chico malo puede descompilar mi .exe, ¿qué tan malo es esto e incluso debo tomar alguna clase de precauciones? Aunque las claves secretas generadas por DH se guardan localmente en las computadoras (se generan cada vez que se establece una conexión entre los clientes), ya que asumo que la computadora del Cliente es segura, no debería haber ningún problema con esto, ¿verdad?

Debilidades que he notado:

[1]: tiene acceso directo a la información de los clientes (dirección IP, cuándo se envió el mensaje, incluso cuántos caracteres contenía el mensaje (~ de 8 bytes)).

[2]: La aplicación del servidor puede modificarse para imitar al segundo cliente y capturar el canal, enviar su propia clave pública y recibir la clave pública de otro cliente, tomando el lugar del segundo cliente. Esto se puede resolver fácilmente si las partes intercambian un saludo en cualquier otro software de comunicación (skype, etc.) y confirman que están conectados entre sí (los mensajes se reciben al mismo tiempo que se envían, etc.).

P.S. Soy consciente de algunas de las debilidades que he mencionado anteriormente, pero no son críticas, me gustaría saber si hay fallas importantes que he omitido, y ¿cómo calificaría esta configuración de 0-10? ¿Qué puedo agregar / cambiar para mejorar lo que ya tengo / corregir fallas?

encryption aes .net server client

pregunta Arman Papikyan 31.10.2017 - 21:32

fuente

2 respuestas

-1

El intercambio Diffie-Hellman por sí mismo no proporciona autenticación de las partes comunicantes y por lo tanto, es vulnerable a un ataque de hombre en el medio .

Este es el motivo por el cual el secreto compartido debe verificarse en persona, si es posible o mediante otro canal de comunicación (menos seguro).

respondido por el Jonathan Cross 01.11.2017 - 00:27

fuente

Lea otras preguntas en las etiquetas encryption aes .net server client

Marcadores seguros y portátiles Extensiones TLS: Omitir mensajes de enlace de TLS

score 2 · Accepted Answer

Este protocolo de comunicación es bastante débil, ya que no proporciona autenticidad o integridad . Hay una serie de ataques a los que es vulnerable. Los más graves en los que puedo pensar según lo que dijiste son:

Ataque de reproducción : un ataque de repetición involucra a un atacante que envía una copia de Cualquier parte de los datos encriptados. El destinatario no sabrá que el mensaje es una reproducción de un mensaje anterior. El atacante no necesita conocer el contenido del mensaje para realizar este ataque.
Ataque de maleabilidad : no mencionó el modo de operación que estaba usando. Suponiendo que sea CTR o CBC, un atacante podrá modificar el texto cifrado para cambiar el texto sin formato de manera predecible. La única solución para esto es usar una construcción de integridad como un HMAC .
Ataque de hombre en el medio : un ataque MITM es posible ya que Diffie-Hellman no está autenticado. Para proporcionar autenticación, necesitaría usar un par de llaves adicional, como RSA o DSA. El intercambio de claves DH debe estar firmado por estas claves para garantizar la autenticidad. Las huellas dactilares de las claves de firma privadas pueden intercambiarse por separado o intercambiarse y almacenarse de modo que todas las conexiones posteriores lo estén utilizando (una técnica llamada TOFU o Trust-On-First-Use).
Inseguridad semántica : si está utilizando el modo ECB (o si está utilizando incorrectamente el modo CBC, o un modo no diseñado para este fin como XTS ), los cifrados del mismo texto simple pueden dar como resultado información de filtración a través de duplicaciones visibles en el texto cifrado.
Fuga de metadatos : la longitud de los mensajes de texto revela una sorprendente cantidad de información valiosa. A menos que esté rellenando sus mensajes a una longitud específica, o al menos rellenándolos hasta un múltiplo, está permitiendo que un atacante obtenga información sobre la conversación basándose en la longitud del texto cifrado. El relleno en este contexto no está relacionado con el relleno en criptografía.

Como puede ver, hay muchas variables que entran en juego al escribir un sistema criptográfico. Los protocolos criptográficos reales son bastante complejo . Esta complejidad es absolutamente necesaria para mitigar una variedad de ataques comunes y no tan comunes. Como solicitó una escala de calificación de 0-10, le daría a este protocolo un valor de 3. Si usa el modo ECB o genera las claves AES de manera incorrecta (por ejemplo, utilizando un PRNG deficiente), sería aún más bajo. Si desea escribir una aplicación que haga chat encriptado, sugeriría usar la biblioteca OTR , llamada libotr . La biblioteca proporciona una comunicación y repudio encriptado seguro de extremo a extremo (denegación plausible en lo que respecta al contenido del mensaje), y más.