Seguridad de extremo a extremo

Cuando se habla de seguridad real, es importante realizar un seguimiento de dónde comienza y dónde termina la seguridad. La mayoría de personas ha oído hablar del cifrado hoy por hoy, y es posible que muchos sepan qué significan los candados en la barra de ubicación de los navegadores. Muchos también podrán asumir que la mayor parte de nuestra comunicación debe estar cifrada en estos días. Y eso es cierto, hasta cierto punto. La mayoría de nuestras conexiones a los servidores estarán cifradas de una forma u otra. El transporte de datos suele estar algo protegido. Pero el contenido, de remitente a receptor, es una historia diferente. Puedes ver esto de manera más obvia en el caso del correo electrónico, donde utilizamos protocolos como SMTP, IMAP y POP3 para comunicarnos con los servidores de correo, y que los servidores de correo también pueden utilizar para comunicarse entre sí. Cuando tu computadora se comunica usando SMTP e IMAP con el servidor, esa conexión casi siempre estará encriptada. Cuando un servidor de correo se comunica con otro servidor de correo mediante SMTP, en ocasiones esa conexión también estará encriptada . Entonces, algunos de los saltos en la ruta de conexión estarán encriptados. Pero en el medio, cuando los datos se mueven por los servidores de correo, los datos no se cifrarán. Y cuando lleguen a la máquina receptora, tampoco estarán encriptados.

Lo mismo ocurre con muchos protocolos de chat. Como se pudo ver en la sección sobre seguridad en el transporte, CoyIM utilizará una conexión segura con el servidor de chat, incluyendo el intento de actualizar la conexión para usar funciones avanzadas de Tor con el fin de asegurar el transporte aún más. Pero cuando envías un mensaje a una persona, al igual que con el correo electrónico, cualquier servidor intermedio podría leer el mensaje.

En el caso del correo electrónico, las dos soluciones más habituales se denominan OpenPGP y S/MIME. Estas hacen posible que el remitente cifre un mensaje para un receptor específico, y también que lo firme de tal manera que el receptor pueda estar seguro que el remitente es quien dice ser. Para CoyIM, hemos optado por utilizar un protocolo llamado OTR. Este es un protocolo que te permite agregar cifrado y firma a cualquier protocolo de chat. No hay nada específico sobre OTR que lo vincule a XMPP. Usamos nuestra propia implementación de OTR, llamada OTR3.

OTR se compone de tres algoritmos interconectados diferentes. Utiliza una versión de un protocolo llamado SIGMA para el intercambio de claves. Utiliza un protocolo de trinquete para enviar y recibir datos. Y utiliza la prueba de conocimiento cero llamada Protocolo del Socialista Millonario (SMP) para autenticar que estás hablando con la persona que crees que estás hablando. Juntos, estos tres protocolos proporcionan varias características de seguridad importantes.

Varias primitivas de bajo nivel son compuestas para crear estos tres algoritmos. Para las claves de identidad de larga duración, OTR utiliza el algoritmo DSA, con un módulo de 1024 bits y un valor q de 160 bits, lo cual resulta en un nivel de seguridad aproximado de 80 bits. OTR genera nuevas claves públicas y privadas efímeras utilizando el algoritmo Diffie-Hellman. Estas claves son generadas y manipuladas sobre el campo primo definido como Grupo 5 de Diffie-Hellman en RFC3526. Este primo es de 1536 bits, lo que también nos da un nivel de seguridad aproximado de 80 bits. Diffie-Hellman se utiliza tanto en el intercambio de claves inicial, así como también durante el protocolo de trinquete. Para el cifrado simétrico, se utiliza AES-128 con el modo de cifrado CTR. Finalmente, SHA-1 se usa para generar fingerprints y como parte de las construcciones HMAC, mientras que SHA-256 también se usa para el hashing y para la construcción HMAC.

El AKE o intercambio de claves autenticadas es responsable de realizar un intercambio inicial de claves nuevas y aleatorias. Una vez hecho esto, las claves de larga duración de DSA se utilizan para firmar este intercambio de claves, proporcionando autenticación. El intercambio de claves en sí mismo no es negable. Puedes demostrarle a alguien que hablaste con una persona. Sin embargo, el contenido real de la conversación será negable.

El protocolo de trinquete que se utiliza para enviar y recibir información funciona continuamente haciendo nuevos intercambios de claves mientras se mezcla material usado para generar claves de las iteraciones anteriores del trinquete. La forma en que se hace esto implica que si un atacante se apodera de las claves en la memoria en cualquier momento, no podrá descifrar futuras conversaciones (desde el punto del siguiente trinquete), ya que se generarán e intercambiarán nuevas claves. Esta propiedad de seguridad se conoce como seguridad posterior al compromiso. El trinquete de OTR también genera nuevas claves para cada mensaje mediante la generación de hashes del material de las claves utilizado anteriormente. A continuación, desecha este material de las claves antiguo. Lo que esto significa es que el protocolo de trinquete también proporciona secreto hacia adelante. Estas propiedades de seguridad significan que si un atacante se apodera de tu material de claves actual, no podrán usarlo para descifrar mensajes anteriores. Finalmente, cada mensaje se cifrará utilizando AES-128 con el modo de cifrado CTR. A continuación, se calculará un MAC sobre el mensaje, se fijará a este y será enviado. Puede parecer extraño usar esta combinación personalizada de un modo de cifrado que se puede atacar fácilmente con un mensaje autenticado por separado. Sin embargo, este es precisamente el punto de esta construcción. Una vez enviado un mensaje, la clave MAC para ese mensaje será devuelta por la otra parte sin cifrar. Dado que el modo CTR hace que el texto cifrado sea maleable, algún intermediario podría, en teoría, modificar el texto cifrado, sin poder leer el mensaje, y luego generar una nueva MAC válida para el mensaje modificado. Esta es una forma en la que este método otorga negabilidad. Básicamente, después del hecho, no se puede estar seguro de que el mensaje no se modificó, por lo que no se podría usar como prueba. El otro mecanismo para la negabilidad es que ambas partes siempre tendrán las claves necesarias para escribir un mensaje. De esta manera, la otra parte nunca podría probar que no falsificó un mensaje de otra persona. Estas dos características hacen que la negabilidad de OTR sea bastante fuerte.

El protocolo de mensajería OTR proporciona una variedad de propiedades de seguridad, que en conjunto brindan a sus usuarios un nivel de seguridad y privacidad incomparable con otros protocolos. La idea del protocolo es recobrar el mismo tipo de la seguridad que se obtiene al tener conversaciones personales cara a cara sin ningún equipo de grabación.

La implementación que usa CoyIM para OTR se llama OTR3. Está escrito en el lenguaje de programación Go, que reduce el riesgo de enfrentarte a vulnerabilidades de seguridad. La biblioteca también ha sido auditada, tema que cubriremos en otra sección. Un aspecto de la implementación de OTR del que estamos muy orgullosos es que realmente es de tiempo constante. En la mayoría de las implementaciones criptográficas, operar en diferentes claves variará en pequeñas cantidades el tiempo necesario o la cantidad de energía utilizada. Si bien esto puede parecer una vulnerabilidad académica, se ha utilizado en ataques en el mundo real. Una implementación de tiempo constante significa que todas las operaciones sobre datos secretos se realizarán de tal manera que se necesite exactamente la misma cantidad de tiempo, sin importar cuáles sean esos datos secretos. Hasta donde sabemos, la biblioteca OTR3 es la única implementación en tiempo constante de OTR existente, y esto proporciona un nivel de seguridad significativamente mejorado para CoyIM.