Comunicaciones secretas en Internet – 2da Parte

Continuamos con la segunda parte del trabajo de Rafael Bonifaz sobre los métodos para comunicarse de manera secreta a través de Internet, particularmente trataremos en este segundo reportaje el correo electrónico y chat.

Correo Electrónico Secreto
 
El correo electrónico es una de las formas de comunicación más comunes de Internet. Su desarrollo data de antes de la creación de la red de redes. Funciona de manera federada donde muchos servidores de correo tienen cuentas de usuarios y estos pueden interactuar con usuarios registrados en otros servidores de manera transparente. Es por esto que una cuenta de correo electrónico creada en el servicio de Yahoo puede comunicarse con una de Gmail o con un servidor alojado de forma autónoma por una organización.
 
Para el funcionamiento del correo electrónico existe una red de servidores que se comunican entre sí a través del protocolo SMTP.  Si Alice envía un correo desde [email protected] a [email protected] este correo quedará almacenado en el servidor del proveedor de correo de Bob. Bob podrá acceder a su correo electrónico a través de los protocolos POP3 o IMAP.
 
Si los servidores de correo electrónico no están correctamente configurados el tráfico de estas comunicaciones no es cifrado. Esto quiere decir que algún punto intermedio entre los usuarios y los servidores de correo se podría interceptar contraseñas, correos o incluso modificar los contenidos. Para proteger la comunicación entre servidores de correo y sus respectivos clientes se utilizan protocolos como TLS o  STARTTLS. La EFF inició el proyecto “STARTTLS Everywhere” con el objetivo de masificar el uso del cifrado en el transporte de correo electrónico.
 
Este trabajo no pretende explicar cómo configurar correctamente un servidor de correo. En el mismo se asume que los servidores están correctamente configurados y el tráfico viaja cifrado. Incluso si los servidores están bien configurados los administradores de los mismos podrían espiar las comunicaciones. El administrador de correo de una organización fácilmente podría leer los mensajes de los usuarios del servidor que administra.
 
Se quiere que Alice y Bob se puedan comunicar sin que esto implique que el administrador del servidor pueda leer sus correos o incluso sepan que los dos se están comunicando.
 
El cifrado extremo a extremo sirve para ocultar el contenido de las comunicaciones. La creación de seudónimos a través de Tor sirve para tener anonimato con respecto al proveedor del servicio de correo electrónico.
 
Cuando se combina el anonimato con cifrado entre extremos, Alice y Bob pueden comunicarse sin evidenciar que lo están haciendo. El administrador del servidor sabrá que 2 personas que usan Tor se están comunicando pero no tendrá información sobre quiénes son ni el contenido de la comunicación. El proveedor local de Internet sabrá que Alice y Bob están usando Tor pero no para que.
 
En la siguientes secciones  se explicará el funcionamiento de OpenPGP para el cifrado entre extremos; el uso de seudónimos para las comunicaciones secretas y el uso de los servicios cebolla para correo electrónico; por último se hará un análisis de comunicaciones secretas con correo electrónico.
 
Cifrado Extremo a Extremo con OpenPGP
 
Existen dos estándares que permiten proteger el contenido de los correos a través del cifrado extremo a extremo: S/MIME y OpenPGP. Los dos funcionan de forma similar al utilizar criptografía asimétrica para cifrar y firmar los mensajes. La diferencia principal es que S/MIME requiere de una autoridad certificadora y que OpenPGP utiliza una cadena de confianza para autenticar a los usuarios o en su defecto autenticación manual.
 
Este trabajo busca herramientas y estrategias que permitan tener comunicaciones secretas, para lo cual el anonimato es importante. Utilizar una entidad certificadora significa autenticarse ante un tercero y de esa manera se pierda la posibilidad de ser anónimo. La cadena de confianza del protocolo OpenPGP tampoco es una opción ya que esta técnica puede exponer públicamente una red de contactos.
 
El estándar OpenPGP utiliza una combinación de cifrado asimétrico, simétrico y hashing. Existen varias implementaciones de OpenPGP, en el presente trabajo se probó GPG y OpenPGP.js. La primera es la plataforma utilizada por gran parte de los clientes de correo electrónico de escritorio mientras que la segunda es utilizada para permitir cifrado en correo web directamente en el navegador mediante Javascript.
 
El proyecto GPG tiene una guía en su sitio web donde se explica el funcionamiento del protocolo. Para cifrar el mensaje Alice consigue la llave pública de Bob. Con la llave pública cifra una llave simétrica con la que se cifra el mensaje. Para descifrar el mensaje Bob utiliza su llave privada con la que descifra la llave simétrica y con esta puede leer el mensaje.
 
Para autenticar el mensaje, Alice se genera un hash del contenido del mismo y lo cifra con su llave privada. Cuando Bob recibe el mensaje genera el hash con el mismo algoritmo que Alice utilizó y descifra el hash  generado por Alice con la llave pública de ella. Si los dos hashes coinciden entonces el mensaje no ha sido modificado y se sabe que Alice es la remitente.
 
Si bien el mensaje ha sido cifrado correctamente y se puede verificar con la firma de Alice ¿Cómo sabe Bob que Alice es quién dice ser? Para esto Alice debe validar la clave pública de Bob. La forma común de hacerlo es verificar manualmente la huella digital de la clave que consiste de un hash de la llave pública compuesto por 40 caracteres. Tradicionalmente se utilizaba los últimos 8 como el identificador de la clave, sin embargo esta práctica ya no se recomienda porque se ha mostrado que es fácil generar colisiones con este identificador.
 
Para que la autenticación funcione, la validación de las claves se debe hacer de forma presencial o buscar algún canal alternativo que sea seguro para compartir. Podría ser una llamada telefónica, un mensaje de chat cifrado o publicar la huella digital completa en una cuenta de una red social donde se ha demostrado tener control; por ejemplo una cuenta de Twitter. La última opción puede poner en riesgo el anonimato si no se hace con cuidado.
 
Para solucionar el problema de la autenticación OpenPGP utiliza el concepto de red de confianza. En este caso Alice se encuentra con Bob en persona; con su llave privada firma la llave pública de Bob; él hace lo misma con la llave pública de ella. Podría darse el caso de Carlos que quiere contactar a Bob pero nunca lo conoció en persona; Carlos conoce a Alice quién firmó la clave de Bob y además confía en la capacidad de ella para validar las claves OpenPGP. Entonces Carlos puede descargar la clave pública de Bob, verificar la firma de Alice y de esta manera escribir a Bob con la certeza de que es la persona correcta. Si más conocidos de Carlos firmaron la clave de Bob, entonces mayor seguridad de que esa llave pública pertenece a Bob.
 
Esto funciona bien en organizaciones donde no se requiere el anonimato. Por ejemplo, para el proyecto Debian es un requisito para ser desarrollador tener la clave firmada por uno o más miembros de la red de confianza del proyecto de manera presencial.
 
En el caso de proyectos como Debian tiene sentido porque se quiere saber quiénes son los desarrolladores. En el caso de comunicaciones secretas, tener la llave pública firmada por miembros de una red de confianza es una forma de exponer metadatos. Por esto el autor recomienda no firmar la clave ni subirla a los servidores de llaves públicas. Es preferible compartir la llave solamente con las personas con las que se quiere establecer comunicación y validar las claves de manera manual.
 
Un problema importante que se debe destacar es que en el caso del correo electrónico para tener autenticación de un mensaje es mandataria la firma electrónica por lo que se tiene la característica de no repudio. Esta es una función deseable en comunicaciones públicas pero es un problema en comunicaciones secretas porque se deja una prueba criptográfica de que Alice envió ese correo.  El uso de seudónimos ayuda a mejorar en algo esta situación.        
 
Otro problema con OpenPGP es que todos los mensajes se cifran con la misma clave, es decir que no existe secreto perfecto hacia adelante. Si un adversario consigue la clave privada de Alice y tiene sus mensajes cifrados podría leer todos los correos de ella.
 
En el capítulo siguiente sobre chat secreto se verán protocolos como OTR, Signal y otros que proveen autenticación, repudio y secreto perfecto hacia adelante. Por lo pronto se analizará lo que se puede hacer con correo electrónico.
 
Correo Secreto con Seudónimos
 
Una estrategia para que Alice y Bob se comuniquen de forma secreta es crear cuentas anónimas en servidores de terceros a través de Tor y acceder a las mismas solo por esta red. Los mensajes enviados deben ser cifrados siempre de extremo a extremo. En la siguiente imagen se puede ver como gracias a Tor alguien que espíe las comunicaciones en el servidor solo sabrá que dos cuentas anónimas se comunican entre sí a través de correos cifrados.

magen: Correo secreto con seudónimos

Mediante la estrategia de seudónimos Alice y Bob esconden sus nombres; a través de Tor ocultan su ubicación geográfica; y mediante OpenPGP el contenido de los mensajes. Cabe notar que generalmente el asunto de los mensajes no va cifrado. Es por esto que en el correo, Alice pone un asunto sin sentido.
 
Al momento de crear la cuenta de correo  hay que considerar que servicios como Gmail, Yahoo u Outlook, son gestionados por empresas que aparecen en el programa PRISM de la NSA. Además para crear una cuenta de correo estos servicios requiere un número telefónico. Esto es un problema para el anonimato ya que en varios países de América Latina el número de teléfono tiene que ser asociado al documento de identidad, incluso para telefonía prepaga. En el anexo uno se puede ver un listado de proveedores de correo electrónico que permiten crear cuentas de forma anónima.
 
Dos de estos servicios son Protonmail y Mailfence que dan la posibilidad de utilizar OpenPGP directamente desde el webmail en el navegador Tor. Esto resulta conveniente porque no se necesita utilizar software adicional. En el caso de Protonmail el código fuente de su interfaz web es libre por lo que puede ser auditado, además son de los principales mantenedores de la librería OpenPGP.js utilizada por varios proyectos de software libre.
 
Hay que tomar en cuenta que al crear una cuenta en los servidores de Protonmail no existe garantía que esté utilizando el mismo código Javascript que el que publican en sus repositorios. ¿Cómo saber que este código no fue modificado para robar la llave privada de los usuarios?
 
Considerando este riesgo se decidió hacer pruebas para crear una cuenta anónima con Protonmail. Este es el nivel más bajo de seguridad que se presentará en este documento pero el más sencillo. Por otro lado, que el código fuente sea libre y público es una ventaja si se quiere implementar un servidor propio. Gran parte de las características disponibles por este servicio podrían ser gestionadas de manera autónoma.
 
Protonmail asegura que todos los correos enviados entre usuarios de Protonmail están siempre cifrados entre extremos a través de OpenPGP utilizando la librería OpenPGP.js. Se puede enviar los correos cifrados a otros usuarios por fuera del servicio de Protonmail mediante OpenPGP. Por último tiene la opción de cifrar mensajes con una llave simétrica para enviar correos cifrados a gente que no usa OpenPGP. Esto último resulta conveniente si se quiere enviar un correo cifrado a alguien que no tiene un cliente que soporte cifrado entre extremos.
 
Protonmail asegura tener “cero acceso al cifrado” de la información almacenada. Dicen que si un mensaje llega sin estar cifrado, una vez que se lo almacena en el buzón del usuario se cifra con la llave pública y se elimina el mensaje en texto plano.Hay que tomar en cuenta que no hay como demostrar que esto sea así y que ellos podrían leer los correos.
 
Más allá de la confianza del sistema y de que Protonmail haga lo que dice hacer, toda la seguridad del sistema depende de la contraseña de la cuenta. Esta contraseña sirve para validar el usuario pero también genera un hash que se utiliza para tener acceso al buzón de correo cifrado. Es posible mejorar la seguridad activando el modo de doble contraseña, una para la cuenta de usuario y otra para el buzón. Además en las pruebas de laboratorio se probó el factor de doble autenticación provisto por Protonmail que utiliza una contraseña de una sola vez. Esto es mejor que sistemas que utilizan número de teléfono porque no ponen en riesgo el anonimato.
 
La creación de la cuenta en Protonmail desde Tor de manera anónima resulta sencilla pero existieron inconvenientes. Para protegerse del abuso, el servicio utiliza herramientas como captcha, cuenta de correo de verificación, envío de SMS o donación. Para conservar el anonimato es importante no dar un número de tarjeta de crédito o telefónico para el SMS.  Lo ideal es resolver el captcha ya que no se requiere dar ningún dato.  Se podría utilizar un correo alterno siempre y cuando este se lo creo de manera anónima.
 
En la imagen siguiente imagen se puede ver que dependiendo del nodo por el cual se accede a Protonmail se presentará las distintas opciones de protección de abuso. En caso de no presentarse la opción de captcha o correo se puede utilizar la opción de “crear nuevo circuito Tor para este sitio” del navegador Tor hasta que obtener la opción deseada.

Imagen : Protecciones contra abuso de Protonmail.
 
Es importante notar que al momento de escribir este documento es posible crear una cuenta anónima con Protonmail, esto no quiere decir que vaya a ser así siempre. Por esto es importante siempre estar pendiente de alternativas.
 
Protonmail tiene la posibilidad de enviar correos cifrados efímeros  mediante una clave simétrica. De esta manera, por ejemplo, una fuente anónima podría enviar un correo cifrado a un periodista que no sabe proteger sus correos electrónicos.  En la  siguiente imagen se puede ver un ejemplo de un mensaje cifrado con clave simétrica.

Imagen: Mensaje cifrado con clave simétrica con Protonmail
 
Esta es una opción interesante cuando Protonmail no es un posible adversario; entonces una cuenta anónima dentro de esta plataforma puede dar un nivel aceptable de anonimato y secreto en las comunicaciones. El sitio de Protonmail no recomienda el uso de este servicio para información sensible y si el adversario es un agencia gubernamental como la NSA.
 
Anonimato y Cifrado con Cliente Externo
 
Si se ejecuta un cliente de correo electrónico de forma local, la llave privada se la gestiona localmente y le será difícil al proveedor del servicio  robarla. Para esto se debe buscar proveedores de correo electrónico que permitan utilizar protocolos como IMAP o POP3 seguros y sean amigables con Tor.
 
De manera similar a como se creó la cuenta con Protonmail, la cuenta de correo electrónico se la debe crear a través de Tor.  Luego se debe buscar los datos de configuración para acceder a la misma mediante  POP3 o IMAP seguro. Es preferible utilizar POP3 en lugar de IMAP ya que no crea carpetas en el servidor y es fácil de configurar para borrar los mensajes del servidor. Mientras menos información se quede en el servidor mejor.
 
Una vez configurada la cuenta se utilizará un cliente remoto que pueda acceder a los correos a través de Tor. Una forma fácil y segura de hacer esto es utilizar la distribución Tails. Alternativamente se hicieron pruebas con Thunderbird más los complementos Torbirdy para acceder a la red Tor y Enigmail para soporte de OpenPGP.
 
Una vez configurada la cuenta de correo en el cliente externo solo se accederá a la interfaz web del proveedor del correo para tareas como la actualización de contraseña. La administración del correo electrónico se realizará siempre desde el cliente. De esta manera la única información que tiene el proveedor del correo electrónico son los metadatos de las comunicaciones siguiendo el esquema de la imagen donde vemos el esquema del correo secreto con seudónimos.
 
Correo Electrónico y Servicios Ocultos
 
Con el esquema anterior se tiene anonimato y secreto en las comunicaciones pero no se tiene autonomía. Un servidor de correo electrónico propio brinda autonomía, sin embargo el nivel de anonimato no será bueno ya que el dominio estará asociado a la tarjeta de crédito de quién lo compró y  se necesita una dirección IP pública.
 
Para tener anonimato en las comunicaciones y autonomía a la vez se puede configurar un servidor de correo electrónico como un servicio oculto de Tor o I2P. De esta manera Alice y Bob pueden comunicarse de manera segura sin revelar su ubicación, con cifrado extremo a extremo y utilizando infraestructura propia.
 
Ejecutar un servidor propio y publicarlo como servicio cebolla se lo puede hacer en hardware de pocos recursos como un Raspberry PI o una computadora vieja. Además al ser un servicio oculto no es necesario tener una dirección IP pública ni usar DNS. El servicio oculto puede ser autónomo para un grupo de gente que requiere comunicarse entre sí de forma segura, como es el caso de una organización
 
En las pruebas de laboratorio se logró federar los servidores de correo electrónicos a través de Tor sin necesidad de usar servidores de DNS. De esta manera Alice puede tener su servidor y Bob el suyo como se puede ver en la siguiente imagen. Claro que si los dos servidores no están conectados a la vez se tendrá problemas con la entrega de correos.
 
No se explicará como configurar un servidor de correo electrónico ya que esta fuera del alcance de este documento y existe mucha documentación en línea al respecto. Lo que se  explicará es la configuración básica de servicios cebolla.

Imagen: Correo federado con servicios cebolla
 
La primera opción es crear un servicio oculto para acceder a través de webmail que soporte cifrado entre extremos. En este laboratorio se utilizó la interfaz de Roundcube pero lo ideal sería utilizar algo como Protonmail ya que brinda cifrado extremo a extremo de manera transparente. La configuración más sencilla de Tor en el archivo /etc/tor/torrc sería algo como:
 
HiddenServiceDir /var/lib/tor/correo
HiddenServicePort 80 127.0.0.1:80
HiddenServicePort 25 127.0.0.1:25
 
La primera línea dice donde se guardará las llaves criptográficas del servicio oculto; la segunda dice que el puerto 80 local (127.0.0.1) será publicado como servicio cebolla para el acceso por webmail. La tercera línea es útil si este servidor se conectará a otros servidores de correo.
 
En la carpeta /var/lib/tor/correo se crearán dos archivos. El primero llamado private_key que contiene el par de llaves públicas y privadas del servicio. El segundo se llama hostname que tiene la dirección ".onion" del servicio oculto.
 
Si el servidor de correo electrónico y el servidor web están configurados para escuchar solamente en 127.0.0.1, entonces en la red local no se podrá saber que se está ejecutando un servidor de correo electrónico. Se podrá saber que una máquina está generando tráfico dentro de la red Tor pero no para que.
 
En la siguiente imagen se puede ver el resultado de la configuración cuando se accede a la interfaz de webmail. Si bien está publicada en el puerto 80 la comunicación es cifrada a través del servicio oculto de Tor.

Imagen: Acceso a webmail mediante servicio oculto de Tor

En este caso se utiliza el mismo servicio oculto para la interfaz web y  correo electrónico. Se puede configurar dos servicios ocultos diferentes, una para el correo electrónico y otro para el servidor web cada uno con su propia dirección “.onion”. De esta manera la dirección de correo electrónico no revela ninguna información sobre como acceder al correo web. La configuración sería la siguiente:
 
HiddenServiceDir /var/lib/tor/correo
HiddenServicePort 25 127.0.0.1:25
HiddenServiceDir /var/lib/tor/web
HiddenServicePort 80 127.0.0.1:80
 
Se pueden utilizar los servicios ocultos para acceder a las cuentas de correo electrónico a través de POP3 o IMAP. En este caso la configuración sería la siguiente:
 
HiddenServiceDir /var/lib/tor/correo
HiddenServicePort 25 127.0.0.1:25
HiddenServiceDir /var/lib/tor/envioRecepcion
HiddenServicePort 110 127.0.0.1:110
HiddenServicePort 587 127.0.0.1:587
 
Un cliente de correo electrónico con la capacidad de acceder a la red Tor se lo puede configurar con el hostname del segundo servicio oculto para enviar correos a través del puerto 587 y recibir correos a través del puerto 110. En este caso no se está utilizando STARTTLS o TLS porque el servicio oculto cifra y autentica el canal.
 
Análisis Correo Electrónico
 
Existen varias formas en las que se puede tener comunicaciones secretas a través del correo electrónico. La primera opción que se vio es el uso de servicios como Protonmail que bien utilizados pueden dar una buena expectativa de anonimato pero requieren tener confianza total en el proveedor del servicio.
 
La segunda opción fue utilizar proveedores de servicios que permitan crear cuentas accesibles a través de POP3 o IMAP seguro. En este caso se debe acceder siempre a la cuenta a través de Tor y cifrar siempre los mensajes.
 
La última opción es configurar un servidor propio de correo electrónico y publicarlo como servicio oculto. En este caso se gana autonomía pero se debe confiar en el administrador del servidor de correo electrónico ya que quién administre el mismo podría saber a quién pertenecen las cuentas. En el caso de organizaciones en lugar de confiar en un desconocido deben depositar la confianza en alguien que pertenece a la misma organización o que al menos es conocido de la misma.
 
Es importante notar que si bien el uso de seudónimos permite tener cierto nivel de repudio en el envío de mensajes firmados, estos están criptográficamente asociados el seudónimo de quien envía el mensaje. Si se logra demostrar que Alice es dueña de la [email protected] entonces todos los mensajes firmados serán asociados a Alice.
 
Otra debilidad del cifrado para mensajes de correo electrónico es que todos los mensajes se cifran con la misma llave. Es por esto que se recomienda rotar la llave periódicamente, lo cual no siempre es una tarea sencilla ya que se debe volver a distribuir la llave pública.
 
Chat Secreto
 
La mensajería instantánea, también conocida como chat, permite comunicarse de una forma rápida a través de mensajes cortos de texto. Uno de los primeros protocolos que todavía se utiliza es IRC; este fue creado en 1988 y llegó a ser un estándar RFC en el año 1993. Desde sus inicios el protocolo fue federado donde varios servidores forman redes a las que se pueden conectar las personas.
 
Con el tiempo esto cambió y sistemas de chat como ICQ, MSN Messenger, chat de Yahoo y otros se convirtieron en sistemas centralizados. Un usuario de MSN Messenger no podría chatear con uno de Yahoo. En la actualidad la comunicación por chat se ha vuelto popular a través de los teléfonos móviles mediante servicios centralizados como Whatsapp o Telegram.
 
En 1998 Jeremie Miller desarrolló el sistema Jabber, hoy conocido como XMPP, para ser una alternativa descentralizada a los sistemas utilizados en la época. En 1999 se empezó a trabajar para que Jabber se convirtiera en un estándar IETF. En 2004 se publicaron los RFC 3920 y 3921 de la especificación, los mismos que fueron revisados en 2011 y constan como los RFC 6120, 6121 y 6122. En la actualidad existen millones de personas que se comunican a través de XMPP.
A pesar de que XMPP es un protocolo estándar de la IETF y que tiene varias implementaciones libres para clientes y servidores no es tan utilizado como plataformas centralizadas. Para enero de 2018 eran más de mil quinientos millones las personas con cuenta registrada en Whatsapp. Según Pavel Durov, fundador de Telegram, en marzo de 2018 esta plataforma tenía doscientos millones de usuarios activos.
 
Para registrar un usuario en los servicios de Whatsapp o Telegram es necesario utilizar un número celular. Esto es un problema para el anonimato ya que en países como Argentina, Ecuador y otros el número celular se asocia al documento de identidad.
 
Empresas proveedoras de servicios como Whatsapp o Telegram pueden recolectar los metadatos de cientos de millones de personas, incluso sin conocer el contenido de los mensajes. En los servicios federados son los administradores de cada servidor los que pueden recolectar el contenido de las comunicaciones y sus metadatos. Mientras existan menos usuarios por servidor, menor poder tendrán los proveedores de los servicios.
 
A diferencia del correo electrónico, las comunicaciones por chat no están estandarizadas por lo que existen varias soluciones para comunicaciones secretas. El objetivo de este trabajo no es analizar todas las  soluciones, sino demostrar que es posible chatear de manera secreta en Internet.
 
Por este motivo se priorizó el protocolo de chat XMPP en combinación con Tor para el anonimato y OTR para cifrado extremo a extremo. En la sección siguiente sección se explicará brevemente el funcionamiento de XMPP y la forma en la que se puede crear una cuenta anónima. Más adelante en la misma sección se verá como implementar un servicio oculto de XMPP para tener autonomía.
 
A continuación se verá el protocolo OTR para la protección del contenido de las comunicaciones;, el protocolo Signal y su adaptación para funcionar con XMPPm se revisarán los protocolos Ricochet y Briar que funcionan de manera descentralizada por lo que permiten la comunicación entre pares (P2P por sus siglas en inglés) sin la necesidad de servidores.  Así se elimina el riesgo de tener un administrador de servicio como adversario y por último en este apartado se verá Delta Chat que utiliza OpenPGP y los protocolos de correo electrónico como una forma de mensajería instantánea.
 
Anonimato con XMPP
 
En 1999 se creó el protocolo XMPP que fue aprobado como norma IETF en el año 2004. El protocolo tiene características similares a la del correo electrónico; una cuenta XMPP es del tipo de [email protected]  y se utilizan registros especiales de DNS para conectar los servidores entre sí.
 
En la siguiente imagen  se puede ver el esquema de federación de XMPP. Nótese que en el mismo se encuentra Google Talk, el sistema de chats que utilizó Google hasta 2013 cuando lo cambió por Hangouts. Hasta ese entonces las cuentas de correo de Gmail funcionaban también como cuentas de chat XMPP.

Imagen: Federación en XMPP

A pesar de que empresas como Google ya no soporten este protocolo; existen cientos de servidores que sí lo hacen y en muchos de ellos se pueden crear cuentas de forma anónima.
 
Cuentas Anónimas de chat con XMPP
 
Se utilizará la estrategia de seudónimos a través de Tor para tener anonimato con respecto al proveedor del servicio. La lógica es similar a la de correo electrónico descrita en la anterior imagen donde se describe el correo secreto con pseudónimos,  con la diferencia de que los mensajes de chat no contienen asunto.
 
Dependiendo del proveedor y el cliente de chat se puede crear la cuenta a través del navegador Tor o desde la aplicación. En el anexo 3 se puede ver un listado de aplicaciones compatibles con XMPP y el soporte de cifrado entre extremos.
 
Para crear la cuenta de forma anónima se recomienda utilizar la distribución Tails. Como se mencionó en el capítulo tres, esta distribución envía todo su tráfico a través de la red Tor. Adicionalmente viene con el cliente de chat Pidgin que soporta varios protocolos de chat, entre los que se incluye XMPP. Tails trae este cliente configurado para funcionar con el protocolo de cifrado entre extremos OTR que se describirá en la siguiente sección “Cifrado Extremo a Extremo con OTR”
 
Alternativamente a Tails, una buena opción para utilizar XMPP con anonimato es el cliente de escritorio multiplataforma CoyIM que está disponible para Windows, Linux y Mac. Este aplicativo tiene la característica de enviar su tráfico por la red Tor y utilizar OTR de manera predeterminada. CoyIM permite registrar cuentas de forma anónima en por lo menos cuatro proveedores como se puede ver en la siguiente imagen.
 
Además de los servidores provistos por aplicaciones como CoyIM, existen listados en la web de otros servidores públicos donde se puede crear cuentas. Tails y CoyIM son dos opciones con las que se puede crear cuentas anónimas, pero no las únicas

Imagen: Crear cuenta de chat desde CoyIM

XMPP como Servicio Cebolla
 
XMPP funciona a través de TCP por lo que puede funcionar como un servicio cebolla. En la materia de Redes I, el autor en colaboración de dos compañeros maestrantes implementaron un sistema de chat XMPP publicado como servicio cebolla.
 
Si bien se requiere conocimientos técnicos en Linux, una implementación básica del sistema resultó simple. Se instaló el servidor libre Ejabberd y se lo configuró para que escuchara exclusivamente en la dirección IP 127.0.0.1. Es decir que el servicio es accesible solamente de manera local  por lo que no será visible en la red LAN.
 
La lógica para configurar el servicio oculto es la misma que la de correo electrónico donde se define los puertos a publicar. XMPP utiliza el puerto 5222 para comunicarse con los clientes. Ejabberd utiliza el puerto 5280 para su configuración. Además resulta conveniente poder acceder al servidor a través del protocolo SSH para la administración. En el archivo de configuración /etc/tor/torrc se añadieron las siguientes líneas.
​

#Servicio oculto de chat
      HiddenServiceDir /var/lib/tor/xmpp/
      HiddenServicePort 5222 127.0.0.1:5222
 
#Servicio oculto para administración
      HiddenServiceDir /var/lib/tor/xmpp-admin/
      HiddenServicePort 5280 127.0.0.1:5280
      HiddenServicePort 22 127.0.0.1:22
​

​El primer servicio oculto sirve para ingresar con las cuentas de chat desde clientes como Pidgin o CoyIM a través de la dirección “.onion”; la misma deberá ser distribuida entre todos los usuarios. El segundo servicio oculto será accesible solamente por los administradores del servicio. En la siguiente imagen se puede ver la interfaz de configuración de Ejabberd desde el navegador Tor.

Imagen: Interfaz administrativa de Ejabberd a través de dirección “.onion”

Para acceder al servicio oculto, basta con utilizar un cliente XMPP que se conecte a la red Tor. Adicionalmente a Pidgin y CoyIM, existen clientes para Android como Conversations o Pix-Art Messenger a través de Orbot. En la imagen inferior se puede ver la configuración del cliente para Android Conversations.
 
Ambas imágenes corresponden a una misma prueba de laboratorio. Como se puede observar el dominio para acceder a la interfaz de administración es distinto al utilizado para ingresar con la cuenta.
 
Tener un servicio oculto de Tor para XMPP es una buena opción para organizaciones que quieren tener independencia en sus comunicaciones. ¿Pero qué pasa si Alice trabaja en la organización X y Bob trabaja en la organización Y? ¿Es posible federar el protocolo XMPP a través de servicios ocultos?

Imagen: Configuración Conversations y servicio cebolla

Sobre este punto no se realizaron pruebas pero es importante destacar que existe software que dice soportar esta funcionalidad. Este es el caso del módulo mod_onions disponible para el servidor XMPP libre Prosody. De esta manera [email protected] podría comunicarse con [email protected] de forma transparente con un esquema similar al que se puede ver en la imagen sobe el Correo federado con servicios cebolla.
 
Tanto Alice como Bob deben confiar en el administrador del servidor, salvo que Alice y Bob gestionen sus propios servicios ocultos. Thijs Alkemade, desarrollador del cliente de chat Adium, en 2013 propuso la idea de que clientes de chat como Adium o Pidgin tengan complementos que permitan embeber un servidor XMPP federado con servicios ocultos de Tor.
 
Si se llegara a implementar esta solución ya no existiría un administrador de servidor de quién defenderse. Adicionalmente tanto Alice como Bob deben estar conectados de manera simultánea para poder chatear. Más adelante en este capítulo se verán soluciones como Briar y Ricochet que permiten comunicarse sin la necesidad de servidores.
 
XMPP no cifra los mensajes entre extremos de manera predeterminada. Hasta ahora se ha visto como crear cuentas anónimas, en  la próxima sección se verá el protocolo OTR para el secreto en el contenido de los mensajes
 
Cifrado Extremo a Extremo con OTR
 
El protocolo OTR permite añadir cifrado entre extremos a sistemas que no tienen esta funcionalidad; cómo es el caso de XMPP pero podría ser otro protocolo. A diferencia de OpenPGP, OTR tiene la propiedad de secreto perfecto hacia adelante. Es decir cada mensaje se cifra con una clave diferente. Para lograr esto en lugar de cifrar los mensajes con la llave pública se negocia una llave simétrica efímera para cada mensaje a través de Diffie Hellman. De esta manera, si un adversario logra acceder a la llave de cifrado del mensaje, solo podrá leer este mensaje y ninguno más.
 
El protocolo se basa en establecer el cifrado de los mensajes desde la primera interacción; así estos no estén autenticados. Una vez que la sesión de chat se inició, se utilizan llaves públicas para la autenticación de las partes de la conversación. Cada mensaje, a más del contenido de la comunicación, incluye la negociación Diffie Hellman para el próximo mensaje.
 
Utilizar criptografía asimétrica para autenticar los extremos de la conversación y criptografía simétrica para cifrar los mensajes permite tener comunicaciones autenticadas y repudio de manera simultánea.
 
En este caso Alice puede conversar con Bob y si verificaron sus llaves públicas tienen la certeza de que se están comunicando entre sí. Alguien que logre interceptar las comunicaciones no podrá probar criptográficamente que el mensaje enviado por Alice fue enviado por ella, ni siquiera Bob lo puede hacer. Esta es una diferencia importante si se compara con OpenPGP donde un adversario o Bob tendrán mensajes firmados criptográficamente por Alice.
 
Cuando se inicia una conversación cifrada en una aplicación cliente, se muestra un mensaje de que la sesión de chat es cifrada pero no autenticada como se puede ver en la siguiente imagen. A la izquierda se muestra un ejemplo con el cliente de chat para Android Conversations y a la derecha el cliente Tor Messenger. 

Imagen: Verificación de mensajes de OTR.
 
Una vez que se inició la conversación cifrada la forma común de autenticar es verificando la huella digital de la llave pública que consiste de un hash. Adicionalmente aplicaciones como Pidgin permiten abstraer esta verificación utilizando pregunta y respuesta o secreto compartido. De esta manera Alice pregunta a Bob algo que solo los dos conocen y si la respuesta es correcta Alice sabe que está hablando con Bob. Bob deberá hacer lo mismo para autenticar a Alice.  El secreto compartido consiste en una frase que tanto Alice y Bob se pusieron de acuerdo previamente. Esta verificación se debe hacer solamente la primera vez que Alice conversa con Bob.
 
En la siguiente imagen se puede ver captura de pantalla de Tor Messenger donde se muestra a la izquierda la validación por huella digital y a la derecha la opción de pregunta y respuesta.
 
Las características de repudio como secreto perfecto pueden ver vulneradas cuando se conservan los mensajes de manera local. Si bien los mismos no están firmados como sucedería en el correo electrónico, sí están almacenadas y podrían ser leídos por un tercero con acceso físico al dispositivo. Este problema se agrava cuando a más de registrar conversaciones se las respalda en la nube.

Imagen: Autenticación OTR

Este es el caso de la aplicación Whatsapp que de manera predeterminada está configurada para respaldar periódicamente las conversaciones en los servidores de la empresa. Es probable que Alice borre sus mensajes y no los respalde en la nube, esto no quiere decir que sus contactos hagan lo mismo.
 
Cabe recordar que Whatsapp pertenece a Facebook y este último es parte del programa PRISM de la NSA.
           
Al momento de escribir este documento se encuentra avanzado el desarrollo de la versión 4 de OTR.  Sofía Celi, una de las desarrolladoras de la versión 4 de el estándar, explica en la lista de correo de desarrolladores de OTR que en esta versión se añade la opción de mensajes asincrónicos, se actualizan las primitivas criptográficas y otras mejoras.
 
Más allá de la parte técnica, es importante destacar que la versión 4 de OTR y CoyIM son proyectos desarrollados con gente de América Latina. El desarrollo es liderado por la organizaciónCentro de Autonomía Digital, con sede en Ecuador y España, que trabaja “con el propósito de hacer de Internet un lugar más seguro para todas las personas.”
 
Signal y Derivados

Signal es una aplicación de chat seguro con cifrado entre extremos para teléfonos celulares que también se puede utilizar en computadoras. Según la página web de la aplicación, personajes como Edward Snowden, Laura Poitras, Bruce Schneider y Matt Green recomiendan utilizar Signal para comunicaciones seguras.
 
Signal es una aplicación cliente servidor que adapta el protocolo OTR y entre otras mejoras permite iniciar sesiones de chat de manera asincrónica. Este es un beneficio importante para la usabilidad de chat a través de dispositivos móviles. Además el protocolo permite tener chats grupales con cifrado entre extremos.
 
Es una aplicación buena para ocultar el contenido de los mensajes pero mala para proteger el anonimato. En primer lugar es un servicio centralizado en el cual el proveedor tiene la capacidad de monitorear y registrar los metadatos de la comunicación.
 
En segundo lugar Signal utiliza el número de teléfono para autenticar la cuenta de los usuarios. En países como Ecuador y Argentina es necesario   asociar el número telefónico con el documento de identidad. Esto es un problema para el anonimato porque los administradores del servicio Signal podrían estar espiando el tráfico.
 
Incluso si los administradores del servicio de Signal tienen un fuerte compromiso para proteger el anonimato, este se pone en riesgos en los chats grupales. Si Alice vive en un país totalitario y utiliza los grupos de Signal para organizarse entonces cualquier persona dentro del grupo va a conocer los números de teléfonos de todos los demás miembros. Si hay un infiltrado dentro del mismo, este podrá saber quién es el dueño de cada número de teléfono y llevar un registro de qué es lo que dicen en el grupo. De poco sirve el secreto futuro perfecto en estas situaciones. En la siguiente imagen se puede ver el ejemplo de un mensaje enviado a un grupo de Signal donde se muestra el número telefónico de quién envía el mensaje.

Imagen: Mensaje enviado a un chat grupal de Signal

Existen trucos para evitar utilizar el número de teléfono de la operadora local mediante un número de teléfono desechable o utilizar un número telefónico de voz sobre IP como lo explica Micah Lee en su artículo para The Intercept.  
 
No es objetivo de este trabajo describir como crear una cuenta anónima con Signal pero vale la pena destacar que es posible utilizar un número telefónico distinto al de la operadora para activar una cuenta; esto aplica también para sistemas como Telegram o Whatsapp.
 
Protocolo Signal

La baja expectativa de anonimato que provee Signal no la hace recomendable para este trabajo; sin embargo vale la pena analizar su protocolo. El mismo es utilizado por soluciones propietarias como Whatsapp, Skype, Google o Facebook; pero también se lo ha adaptado en soluciones libres como OMEMO, Matrix y Wired.
 
Moxie Marlinspike, creador de Signal, explicaba en el año 2013 que protocolos como OTR proveen la propiedad de secreto perfecto hacia adelante y que funcionan bien en mensajería sincrónica. La mensajería en aplicaciones celulares funciona de manera asincrónica más que sincrónica. Es por esto que uno de los aportes importantes es el poder iniciar una sesión de chat sin la necesidad de que las dos aplicaciones estén conectadas a la vez.
 
Marlinspike sostenía en 2013 que para tener chat seguro en dispositivos móviles se debía escoger entre secreto perfecto adelante o conversaciones asincrónicas. Citaba como ejemplo a aplicaciones como Threema que usan un esquema similar al de OpenPGP donde todas los mensajes se cifran con la misma llave; de esta manera es fácil tener comunicaciones asincrónicas pero se sacrifica el secreto  perfecto hacia adelante.
 
Para solucionar este problema, un usuario de Signal crea su par de llaves públicas y privadas con las que firma 100 prenegociaciones Diffie Hellman que son subidas a un servidor. Si Alice quiere contactar a Bob descarga una  prenegociación Diffie Hellman firmada con la llave pública de Bob, envía su parte de la negociación firmada y el mensaje cifrado sin la necesidad de que Bob este conectado. Es importante verificar las llaves públicas ya que las firmas en las prenegociaciones sirven para protegerse de ataques de hombre en el medio.
 
Las claves de prenegociación se utilizan una sola vez y se actualizan periódicamente. Para el funcionamiento correcto del protocolo Signal es necesario tener un servidor de confianza que almacene las llaves públicas de los usuarios así como sus lotes de prenegociación Diffie Hellman.
 
Otro aporte importante del protocolo Signal es la capacidad de tener grupos de chat con comunicación cifrada extremo a extremo. Además la información de los grupos no se guarda en el servidor sino que es distribuida entre los miembros de los mismos.
 
El código fuente de la aplicación Signal es libre y en el caso de Android permiten verificar que el mismo corresponde al binario que se distribuye a través de Google Play o al que se puede descargar desde su página web.Esto es bueno porque se puede comprobar que el software hace lo que dice hacer.
 
El código fuente del servidor también es libre y se lo puede descargar desde GitHub. A diferencia del cliente, no se puede verificar que la implementación de los servidores de Signal corresponden al código fuente publicado.
 
Los protocolos utilizados para el funcionamiento de Signal están documentos y además existen librerías en Java, C y Javascript que permiten adaptar el mismo a otros sistemas de chat. Este es el caso de OMEMO para XMPP, OLM para Matrix y para aplicaciones como Wired.
 
Se invita al lector a investigar sobre estas herramientas, en el caso de este trabajo se hablará sobre OMEMO ya que permite añadir los beneficios vistos en Signal a un protocolo federado como XMPP.
 
OMEMO: Multi-End Message and Object Encryption
 
OMEMO es una adaptación del protocolo Signal para ser utilizado en el estándar XMPP. Su funcionamiento es parecido al de los grupos de Signal. Según una auditoría realizada al protocolo, cada dispositivo es un participante del grupo. De esta manera Alice podría tener un teléfono y una computadora conectadas a una sesión de OMEMO, mientras que Bob está conectado desde un celular. Alice puede seguir la conversación de forma transparente desde cualquier de los dispositivos.
 
En la siguiente imagen se puede ver un gráfico en el que Alice tiene conectado una computadora y un celular a un servidor XMPP, mientras que Bob tiene conectado solo el celular. Si Bob quisiera añadir su computador a la sesión debería subir un identificador al servidor en conjunto con la llave pública y las prenegociaciones de Diffie Hellman.

Imagen: Funcionamiento OMEMO

La capacidad de tener varios dispositivos conectados a una solo cuenta es positivo desde el punto de vista de movilidad y usabilidad. Alice podría iniciar una conversación en su computadora y cuando sale de casa la puede continuar desde su celular. La auditoría sostiene que esto tiene implicaciones de seguridad. El hecho de que varios dispositivos puedan compartir el historial de una conversación trae el riesgo de que si un dispositivo este comprometido se compromete la seguridad de toda las conversaciones del usuario.
 
Hay que tomar en cuenta que al utilizar XMPP los administradores de los servidores podrían saber los metadatos de las comunicaciones de sus usuarios. Esto se puede resolver creando cuentas anónimas a través de Tor en servidores públicos o implementando servidores propios de chat XMPP como ya se vio.
 
A diferencia de OTR, OMEMO tiene que estar soportado por el servidor y para esto se deben buscar servidores que tengan esta funcionalidad. En caso de implementar un servidor XMPP propio, el mismo debe soportar las extensiones XEP-0163 y XEP-OMEMO para su correcta implementación.
 
OMEMO se diferencia de OTR tiene la capacidad de utilizar  múltiples dispositivos, conversaciones grupales cifradas e iniciar chats de forma asincrónica. Por su parte OTR tiene la ventaja de que se puede añadir cifrado entre extremos a cualquier protocolo de chat.
 
Ricochet
 
Ricochet es un sistema de chat donde la comunicación es anónima y cifrada entre extremos. En su sitio web se destacan las siguientes características: no existen metadatos que puedan ser espiados por un tercero; no se puede saber a quién pertenece una cuenta, salvo que se identifique; existe anonimato porque no se sabe la ubicación de los participantes de la comunicación; por último no se requiere configurar nada para que el chat sea secreto y anónimo.
 
Cada cliente de manera transparente implementa un servicio oculto de Tor y el identificador en lugar de ser un número telefónico o un nombre de usuario, es el hostname de la dirección del servicio oculto que se escribe de la siguiente manera: ricochet:sa3usfhhca7kkhgp. Es por esto que la comunicación es siempre autenticada. Sin embargo existe el inconveniente de que los nombres no son fáciles de recordar.
 
Otra característica a destacar es que la comunicación es P2P y que el chat se realiza directamente entre clientes sin la necesidad de un servidor intermedio como se puede ver en la siguiente imagen. Con la cual se elimina el riesgo de tener un administrador que pueda monitorear el tráfico.

Imagen : Ricochet cliente P2P

Más allá de que los nombres no sean fáciles de recordar la Interfaz de uso de Ricochet es simple y recuerda a la de cualquier cliente de mensajería instantánea. Una vez que se añade un contacto se pone un alias fácil de identificar para saber con quién se está chateando. En la siguiente imagen  se puede ver la Interfaz de lista de contactos junto a una conversación.
 
Ricochet es bueno para tener secreto y anonimato en las comunicaciones sin mayor interacción por parte del usuario. Se debe considerar que no se puede tener conversaciones asincrónicas ni grupales;  además no existen clientes móviles.

Imagen : Captura de pantalla Ricochet

Otra tema a considerar es que la última versión estable al momento de escribir este documento es del 5 de noviembre de 2016. Al no tener un desarrollo activo es probable que tenga fallas de seguridad. Sin embargo el concepto de un medio de comunicación cifrado entre extremos que no requiere servidores es algo que se debe tomar en cuenta.
 
Briar
 
Briar es una aplicación libre para Android que provee mensajería instantánea y otros servicios de manera descentralizada sin la necesidad de servidores. Al igual que Ricochet, Briar utiliza servicios ocultos de Tor para permitir la comunicación entre las partes. Adicionalmente es posible comunicarse a través de la red Wifi, Bluetooth, e incluso se tiene planificado permitir sincronizar las comunicaciones a través de medios alternativos como memorias USBs u otros.
 
Según el manual de Briar y pruebas realizadas se explicará el funcionamiento de este sistema. Al crear una cuenta se pide un alias y una contraseña. La contraseña sirve para cifrar la cuenta y todo se guarda de manera local en el teléfono; no se crea un registro en ningún servidor. Por este motivo la información no es accesible por terceros pero si se extravía el teléfono o se olvida la contraseña se pierde el acceso a la cuenta y hay que empezar de nuevo.
 
Existen dos formas en las que se puede añadir contactos en Briar. La primera es en persona, en este caso Alice y Bob se reúnen y al utilizar de manera conjunta los códigos QR y la conexión de Bluetooth del celular intercambian las llaves públicas. Es así como Alice y Bob autentican su cuenta al momento de presentarse y evitan ataques de hombre en el medio.
​
Si bien esta medida limita la capacidad de un ataque de hombre en el medio, genera un problema a la hora de añadir contactos ya que se deben encontrar en persona. Como opción alternativa Briar se puede presentar contactos. Si Alice conoce a Bob y a Carol los puede presentar para que ellos puedan comunicarse a través de Briar como se puede ver en la siguiente imagen.

​Imagen: Presentación de contactos en Briar

Torsten Grote, desarrollador de Briar, explica en su conferencia sobre esta aplicación en el CCC 2017 que esta es la forma en la que funciona la sociedad. Lo normal es que seamos presentados por las personas que conocemos. Se conocen a otras personas porque esas personas son presentados por amigos, familiares o cualquier otro conocido.
 
Una característica interesante descrita por Grote es que Briar puede añadir distintas formas de comunicación. Es por esto que se puede enviar mensajes a través de Tor, la red local o Bluetooth. Se está trabajando para que incluso se pueda enviar mensajes de manera asincrónica a través de memorias USB.
 
Bromea Grote, en la conferencia, que se podría hacer cosas como enviar mensajes cifrados en una memoria USB utilizando una paloma mensajera.
 
Al igual que Signal y OTR se puede tener secreto adelante. Sin embargo como el sistema considera importante que los mensajes puedan viajar de forma asincrónica con demoras que en unos casos pueden durar minutos y en otros incluso días; se decidió no negociar una clave nueva en cada mensaje sino que las claves caducan con un valor de tiempo fijo que lo puede configurar el usuario.
 
Delta Chat
 
Delta chat es un cliente de mensajería instantánea para celular que funciona a través de cuentas de correo electrónico para enviar y recibir mensajes; funciona con OpenPGP de manera transparente.
 
Para el intercambio de llaves utiliza Autocrypt que es un estándar para hacer accesible el uso de correo cifrado con OpenPGP. Este estándar se encuentra en desarrollo y se divide en tres niveles de los cuales el primero es el único implementado. En este nivel las llaves públicas se comparten automáticamente en todoslos mensajes por lo que empezar a cifrar las comunicaciones es sencillo.
 
Delta Chat permite autenticar las partes verificando manualmente las llaves públicas como se puede ver en la siguiente imagen. Esta validación es  similar a como lo harían aplicaciones de chat como Signal.
 
El uso OpenPGP permite tener comunicaciones asincrónicas sacrificando la propiedad de secreto perfecto. Tiene la ventaja sobre herramientas como Signal de no requerir un identificador fuerte como el número de teléfono. Todo el funcionamiento de correo electrónico visto anteriormente funciona con Delta Chat. Es decir se pueden crear cuentas anónimas en servidores públicos o usar un servidor de chat publicado en un servicio oculto. 

Imagen: Verificación de llaves con Delta Chat
 
Más allá del anonimato, Delta Chat es útil para organizaciones que quieren ganar independencia en las comunicaciones y que ya cuentan con un servidor de correo electrónico que funcione con IMAP seguro.  En este caso basta con instalar Delta Chat en los celulares y tendrán mensajería instantánea de manera similar al uso que se le da hoy en día a Whatsapp.
 
Análisis Chat
 
Es posible tener comunicaciones secretas de chat con la combinación de Tor, XMPP y OTR. Esta no es una única solución y por eso se presentó un análisis adicional de otras opciones con sus ventajas y desventajas.
 
Se eligió XMPP por ser un protocolo estándar y tener varios clientes soportados. Este protocolo permite federar y además es fácil de implementar como un servicio cebolla. Para el cifrado de los mensajes se puede elegir entre OTR y OMEMO. OMEMO es menos seguro y más versátil porque permite sincronizar las conversaciones entre varios dispositivos.
 
Briar y Ricochet tienen la característica de no requerir servidores centralizados. Para que Ricochet funcione se requiere que las dos personas estén conectadas a la vez por lo que no se puede tener conversaciones asincrónicas.
 
Briar funciona de una manera diferente al resto ya que para añadir un contacto hay que encontrarse en persona o deben ser presentados por un contacto en común. Esto puede limitar que tenga una base grande de usuarios de forma rápida. Por otro lado organizaciones de personas que trabajan juntos podría utilizarlo fácilmente sin necesidad de infraestructura de servidores.
 
Delta Chat tiene la ventaja de que puede utilizar infraestructura existente, permite tener conversaciones grupales y asincrónicas. Tiene la desventaja de no soportar secreto perfecto hacia adelante ni repudio.

Autor: Rafael Bonifaz
 
Si queréis saber más sobre Software libre, criptografía o privacidad podéis entrar en mi blog pulsando aquí. También puedes descargar el trabajo original con todas las referencias, enlaces y bibliografía que sustentan al mismo pulsando en este enlace de archive.org

Puedes acceder a la primera parte pulsando aquí.

Te puede interesar: CiberSeguridad, Curiosidades De La Tecnología, Internet, Seguridad Informática, Sociedad, Taller