Desde hace algún tiempo, muchos de los clientes de XMPP sobre Android, disponen de la característica de poder guardar un fichero de respaldo con la configuración de la cuenta o cuentas junto con las claves OMEMO correspondientes. Ignoro si en iOS existe lo mismo, en su cliente Monal.

Esta característica está pensada para facilitar la migración de cuentas de un dispositivo a otro, es decir para usar una cuenta con sus claves en un dispositivo y DEJAR de utilizarla en el anterior.

Creación de copia de respaldo

Necesitamos saber la o las contraseñas de nuestra cuenta o cuentas.

Para hacer la copia de respaldo, nos dirigimos al menú de configuración o ajustes. Desde allí buscamos la categoría de “Copia de seguridad” o “Respaldo y restauración” o similar. Entre las opciones relacionadas, tendremos una para seleccionar el destino donde guardar la copia, otra para programar copias desatendidas y una para hacer copias puntuales.

Seleccionaremos la opción de copia puntual y se creará un fichero en el destino actualmente seleccionado con la configuración de la o las cuentas. La aplicación mostrará una ventana informando de que se está creando la copia y que se emitirá una notificación cuando termine.

Cuando haya terminado, lo más conveniente es sacar ese fichero del móvil para llevarlo a un ordenador u otro dispositivo, usando bluetooth o cable... Si se avería el móvil y queda inutilizado antes de extraer la copia de respaldo, perderíamos los datos de configuración, y tendríamos que hacer lo que está descrito en el primer párrafo.

Una copia de respaldo proporciona disponibilidad de los datos. Además está cifrada por seguridad.

Recuperación o restauración de la copia de respaldo

Necesitamos saber la o las contraseñas de nuestra cuenta o cuentas.

Cuando tengamos el móvil nuevo, como precaución, deberíamos apagar el viejo, o al menos desactivar la cuenta. No hacerlo puede provocar problemas durante la activación en el nuevo dispositivo.

El primer paso que recomiendo es traspasar el fichero de copia de respaldo al nuevo dispositivo. Realmente se puede hacer en cualquier momento previo a la configuración de la aplicación de XMPP.

Después instalamos FDroid y la aplicación XMPP, tal como se explica en esta otra publicación. Aunque en esta publicación se menciona a Conversations, se haría para igual para otras (monocles, Cheogram...).

Cuando esté instalada la abrimos, asegurándonos antes de que tenemos el fichero de copia de respaldo, y que en el anterior dispositivo, no está activa la cuenta. Después de varias pantallas de bienvenida y explicaciones se nos ofrecerá:

• Crear una cuenta
• Registrar un cuenta existente
• Restaurar una copia de respaldo

Es posible, depende de la aplicación e incluso de la versión, que la última opción esté en otro menú, como en un menú de tres puntos en la parte superior, es una cuestión de interfaz de usuario.

Necesitamos la opción de restaurar, al lanzarla podremos buscar y seleccionar el fichero de copia de respaldo que hemos traspasado al móvil. Se iniciará el proceso de restauración pero para que continúe necesitamos teclear la contraseña de la cuenta, de esta forma solo quien sepa la contraseña puede restaurar los datos.

Cuando termine, tendremos la cuenta registrada en el nuevo dispositivo, con la clave OMEMO que tenía en el anterior, pero desactivada, para poder usarla tendremos que dirigirnos a la gestión de cuentas y activarla.

Los mensajes que nos hayan enviado en el transcurso de crear y restaurar la copia de respaldo no se podrán descifrar en el nuevo dispositivo, con lo que se hace interesante hacer la copia de respaldo con cierta frecuencia o incluso programarla, para después extraerla del dispositivo.

La enmienda presentada por el Partido Pirata, exige que el escaneo de comunicaciones privadas se limite estrictamente a usuarios individuales o grupos de usuarios que sean investigados por una autoridad judicial.

Según Patrick Breyer del Partido Pirata, es el resultado de la acción ciudadana con llamadas y correos electrónicos pidiendo a los representantes, tanto de la Comisión como del Parlamento, que protegieran su privacidad en las comunicaciones. Todos los gobiernos de la Unión deben respetar el voto del Parlamento.

El próximo 4 de abril, las grandes plataformas como Meta, Google, Microsoft y otras deben dejar de escanear de forma indiscriminada las comunicaciones de los ciudadanos europeos, tal como autorizaba el reglamento provisional 2021/1232 de la Unión Europea, que decae precisamente ese día.

¿Qué aprendizaje sacar de todo este proceso?, yo diría que debemos apreciar más nuestra privacidad para protegerla, esto implica aprender técnicas, enseñarlas también y muy importante, conocer y reconocer a quienes quieren que no lo podamos hacer, e incluyo ahí a todas esas plataformas tóxicas tan utilizadas, tanto por particulares como por gobiernos e instituciones.

También hemos aprendido como de democrático es el talante de la Comisión Europea y la Unión Europea en general; mientras desea espiar a todos sus ciudadano en nombre de la protección de la infancia, mira para otro lado cuando esa infancia muere asesinada en Gaza, Irán y otros sitios, permite que niños acaben en la calle desahuciados, permite que...

La situación de partida es que no tenemos cuenta de XMPP ni software cliente instalado Primero explicaré la instalación, después la configuración de una cuenta, y después la interlocución con otro usuario.

Instalación del software cliente

Conversations se puede instalar desde Google Play, pero recomiendo hacerlo desde Fdroid, que es una especie de Google Play pero con software con licencias más o menos libres. Para hacerlo así, es necesario instalar precisamente Fdroid.

Instalación de Fdroid

Para poder instalarlo, hay que configurar Android para poder instalar aplicaciones de terceros o configurar las aplicaciones para que puedan instalar programas también de terceros. Esto se hace en “Ajustes-Seguridad y Privacidad-Orígenes desconocidos” en versiones más antiguas de Android, en las más actuales es necesario conceder permiso por aplicaciones en “Ajustes-Aplicaciones-nombre de aplicación”, por ejemplo, si la descargamos con el navegador, tenemos que otorgar dicho permiso al navegador para instalarlo, pero como después Fdroid tiene que instalar aplicaciones, es necesario otorgarle también el mismo permiso.

La instalación de fdroid se puede hacer desde el enlace oficial.

Una vez instalado, al entrar la primera vez, se descargará el repositorio de aplicaciones disponibles, entre las que está Conversations.

Volvemos a la instalación del software cliente.

Estamos todavía dentro de Fdroid y ya se han actualizado los repositorios. En la pantalla inicial de la aplicación, en la parte de abajo, hay un botón con la lupa de buscar, buscamos «Conversations» y cuando aparezca lo seleccionamos para instalar, cuando termine la instalación salimos de Fdroid, buscamos la aplicación y ejecutamos por primera vez.

Creación de cuenta en Conversations.

Como recordatorio, la situación inicial es sin cuenta de XMPP. En la primera ejecución de Conversations, el programa pedirá configurar una cuenta, y puede ser con una cuenta existente o creando una cuenta, es decir crear cuenta o usar cuenta existente. Existe también la opción en el menú de 3 puntos de cargar una copia de respaldo de una cuenta.

Recordando: la situación de partida es que no tenemos ninguna cuenta XMPP.

Hay servidores que permiten la creación de cuentas desde la propia aplicación o desde su web, los hay que solo ofrecen la creación desde la aplicación, hay que tener en cuenta también, que hay servidores que han desactivado la posibilidad de creación de cuentas desde aplicaciones porque en algunos se han estado creando masivamente de forma programada, si ese es el caso, seremos advertidos.

Elegimos la opción de crear cuenta y a continuación en la siguiente pantalla nos pregunta si queremos una cuenta en el servidor conversations.im, puesto en marcha por el creador del programa o utilizar un servidor de nuestra elección, elegimos esta segunda opción.

En la siguiente pantalla se nos pide el identificador y la contraseña, por ejemplo: ejemplo@chapril.org y debajo la contraseña, cuando le demos a continuar, el servidor nos enviará un captcha de esos para verificar que somos humanos.

Si va todo bien (el usuario no existía, el captcha está bien escrito), se creará la cuenta y veremos una pantalla con un recuadro de color y una inicial mayúscula que corresponde a la inicial del usuario que hemos escogido, es para elegir una imagen para esta cuenta, y no es necesario hacerlo en en este momento, así que le podemos dar al botón de Omitir y dar por terminado el proceso de registro de cuenta en Conversations.

Descripción del entorno

La pantalla principal o inicial en Conversations, es la de la lista de chats abiertos. Si estamos en cualquier otra pantalla: gestión de cuentas, configuración, dentro de un chat, veremos en la parte superior el título de dicha pantalla y una flecha hacia la izquierda al lado izquierdo de dicho título. Es decir, el nivel superior es el de la lista de chats.

Creación de contactos

Evidentemente, si queremos conversar con alguien, necesitamos su contacto, que será de la misma estructura que nuestro identificador, pero no tienen porque estar en el mismo servidor que nuestra cuenta.

Necesitamos conocer la cuenta del interlocutor, de la misma manera que necesitaríamos conocer una cuenta de correo electrónico para enviar mensajes.

Podemos iniciar un chat con alguien desde Conversations, desde la lista de chats. Dependiendo del servidor en el que hayamos creado la cuenta, puede que tengamos ya algún chat, del tipo de ayuda a usuarios o de bienvenida. Si no los vamos a usar los podemos cerrar deslizándolos hacia la derecha. Pinchando en el botón «Iniciar un chat», a continuación pasaríamos a una pantalla con la lista de contactos, ya sean individuales o grupos y un botón para añadir más. Saldrán varias opciones: crear un contacto, crear un grupo privado, crear un canal público, unirse a un canal público y descubrir canales. Vamos a crear un contacto.

Si en algún momento la aplicación pregunta por integrar los contactos XMPP en la aplicación Contactos, yo diría que no.

La siguiente pantalla que nos sale tiene dos campos uno para elegir que cuenta propia usar para chatear con el nuevo contacto; hay que tener en cuenta que Conversations, y otros, pueden gestionar más de una cuenta; el siguiente campo es para introducir el identificador de la cuenta de nuestro interlocutor, escribimos el identificador que nos ha proporcionado y le damos al botón «Añadir».

En ese momento se abrirá una pantalla de chat con dicho interlocutor, en ese momento el indicador de estado en esa pantalla será de color negro, porque no ha aceptado todavía ser añadido a nuestros contactos.

Si el contacto no acepta ser añadido, no habrá chat, pero si acepta, el indicador pasará a estar en color verde y podremos chatear.

Las claves estarán en estado de confianza ciega y tendremos que validarlas en algún momento tanto nosotros como el otro extremo.

Variante: otro nos añade a nosotros como contacto

Voy a explicar ahora que pasaría si es otro el que quiere añadirnos como contacto. La situación es la siguiente: hemos registrado la cuenta en Conversations, pero no hemos añadido a nadie.

Alguien nos envía un primer mensaje, en el momento de la recepción nos aparece en la lista de chats, si entramos, veremos el texto del mensaje y un texto advirtiendo de un contacto nos quiere añadir a su lista y la opción de «AÑADIR DE VUELTA», mientras que no aceptemos, no estará autorizado el chateo al igual que lo explicado más arriba.

Variante: contactos cara a cara.

Otra variante para añadir contactos, es hacerlo cara a cara. supongamos que ya hemos registrado nuestra cuenta en Conversations, pero estamos con un contacto que también usa Conversations.

Si entramos desde el menú de tres puntos en la gestión de cuentas, veremos una lista con la cuentas o cuentas que tengamos registradas, además podríamos desactivarlas o desconectarlas. Si pulsamos en una cuenta veremos más datos y opciones, y entre ellas la de mostrar un código QR. Se puede encontrar en el menú superior desde el icono de compartir, que mostrará un menú con diferentes opciones para compartir el contacto, una de ellas es mostrar código QR. También, más abajo en esa pantalla, a la altura de la «Huella digital OMEMO» hay un icono en forma de QR, mostrará la misma información.

Cuando estemos mostrando el código, nuestro contacto, desde el menú inicial de Conversations (el que muestra la lista de chats) puede leerlo con la opción que tiene en la parte superior de la pantalla al lado del título. Al hacerlo, se incorpora a la lista de contactos y se abre un chat, y además nuestra huella OMEMO queda directamente verificada, no pasa por la fase confianza ciega.

Solo faltaría hacerlo lo mismo pero en el otro sentido: nuestro contacto muestra el código QR de su cuenta y nosotros lo leemos y ya tendríamos abierta una interlocución con claves verificadas.

Realmente, para cifrar en XMPP se puede usar OpenPGP (sistema de cifrado de clave pública utilizado también en el correo electrónico) y OMEMO. Depende del programa cliente que estemos usando: hay algún cliente que no usa OpenPGP.

Cifrado con OpenPGP

Está basado en cifrado de clave pública, como en el correo electrónico. El par de claves utilizado tiene que tener asignada la identidad correspondiente al usuario de XMPP o JID, también las claves públicas de los interlocutores. Es un sistema de cifrado centrado en las identidades de las partes. Cada cliente tiene su forma de seleccionar este tipo de cifrado y de selección de claves, pero generalmente consiste en un menú en el área de chat.

Cifrado con OMEMO

El cifrado OMEMO también tiene fundamento en el sistema de clave pública, pero tiene variantes que lo hacen interesante para el cifrado en mensajería instantánea.

Características

No esta basado en identidad únicamente, si no también en dispositivo. Hay que entender el dispositivo en este ámbito, no como el “aparato” (PC, móvil, tablet), si no la combinación de identidad (JID), “aparato” y software cliente (Conversations, monocles...): si tienes dos aplicaciones diferentes en un móvil con una misma cuenta, serían dos dispositivos y cada uno tendría sus claves y huellas. Actualmente se están implementando mecanismos en determinados programas cliente para poder hacer copia de respaldo de las claves y según qué clientes, también para migrar las claves de un programa a otro.

Otra característica es la gestión de claves: en un primer contacto entre interlocutores, se intercambian las claves, pero después cuando uno envía un mensaje cifrado, envía también la próxima clave a utilizar por el interlocutor para cifrar su mensaje.

Sería como si, no muy bien comparado y simplificado al máximo, pudiéramos enviar con cada mensaje, una clave pública nuestra diferente. Así los interlocutores disponen de claves diferentes para cifrar los siguientes mensajes.

De esta forma, si alguien consigue descifrar un mensaje por medio de interceptación, los mensajes anteriores a ese no estarían comprometidos, es lo que se llama “perfect forward secrecy” o “secreto hacia delante”.

Utilización

Al igual que se hace en el cifrado PGP, es necesario que los interlocutores intercambien sus claves públicas, también es necesario verificarlas para comprobar que son las claves que esperábamos.

En el ámbito de la mensajería XMPP, se usa un mecanismo para verificación que se llama «confianza a ciegas antes de verificar», que consiste en confiar en la clave obtenida en el primer intercambio y dejar la verificación pendiente, una de las formas de hacer la verificación es por medio de códigos QR (muchos clientes son capaces de mostrar la huella de nuestra clave pública en QR para ser leída y también de leer los QR de las huellas de otros para verificarlas), lo que implica cierta cercanía física, pero también se podría publicar dicho código en nuestra página web, por ejemplo, también se puede compartir en forma de enlace especialmente conformado para representar la huella y poder verificar.

Este mecanismo lo usan muchos programas cliente, hay alguno que la verificación solo permite hacerla “manualmente”, en lugar de leer un código QR. El usuario, necesita en estos casos, leer la huella de la clave que ha recibido de forma segura (teléfono por ejemplo) y compararla con la que tenemos guardada y si coincide, de forma manual, generalmente un control deslizante o un menú, decidir sobre la validez.

Una vez verificada la huella de las claves de los interlocutores, cuando alguno de ellos cambie o añada otro dispositivo para el mismo identificador de usuario, cuando recibamos un mensaje, el cliente nos avisará de que la huella es otra y que tenemos que tomar alguna decisión acerca de nuestra confianza sobre la misma, y ya no habrá confianza a ciegas.

Diferentes opciones de compartir nuestra huella para verificar

La forma o formas de compartir nuestra la huella de nuestra clave, depende de la implementación de los clientes. Todos los clientes Android basados en Conversations ofrecen los mismos mecanismos:

• presentación y envío de código QR

• generación de un enlace con formato basado en una extensión de XMPP (XEP-0147), que puede ser enviado al interlocutor y leído por él. Tendría un aspecto como el siguiente(los signos de sumar son para enmascarar y preservar la privacidad):

  xmpp:cuenta@servidor.org?omemo-sid-+++8579+++++=++e389df9b+++cf5a9+++5a6a13+++21fd9b2697c+++b4c6d2f9+++05;omemo

• generación de un enlace similar al anterior con base en conversations.im y conteniendo no solo la huella de la clave en ese dispositivo si no la de la misma cuenta en otros dispositivos si están disponibles. Sería algo parecido a(los signos de sumar son para enmascarar y preservar la privacidad):

  http s://conversations.im/i/cuenta@servidor.org?omemo-sid-+++857++++=c++++389df9b++++dcfh5a9b++++6a134c83b21++++2697c8544b++++2f9f++++&omemo-sid-11+++66++++=++++66f93761++++99ec119905++++3ca4ab21++++8566d91f7967++++450

  En este caso son dos huellas de dos dispositivos.

¿Qué tiene que ver con la privacidad? Pues se puede utilizar sin cifrar, pero también puede usarse con verdadero cifrado extremo a extremo y se puede usar incluso el ya conocido PGP.

¿Y que más?, pues la ventaja de la capacidad de agencia que proporciona disponer de toda la especificación del protocolo y que nos permite poder poner en marcha clientes y servidores, federando unos con otros, evitando entrar en servidores únicos que resultan ser jardines vallados y aislados.

¿Qué es la federación?

La federación sería la capacidad de relacionarse dos o más servicios o servidores a través de protocolo o protocolos comunes. Un ejemplo de ello es el correo electrónico, existen muchos servicios diferentes en muchos sitios pero con protocolos comunes (SMTP) pueden relacionarse para hacer llegar mensajes desde un servidor a otro. En sentido contrario, NO sería entendible a estas alturas que un servicio de correo, digamos Google, solo gestionara mensajes de cuentas de él mismo y que no pudiera enviar a cuentas de Yahoo (por ejemplo).

Un poco de historia.

Por si pareciera que esto es algo nuevo, aquí va un poco de historia: En 1998 Jeremie Miller, empezó a trabajar en un desarrollo que dio lugar, en 1999, a un software de servidor de mensajería, jabberd, y a una especificación de un protocolo basado en un estándar llamado XML..

Posteriormente se sometió una descripción del protocolo a la IETF, que es un organismo internacional de normalización de ingeniería en el ámbito de internet. Está continuamente en desarrollo de funcionalidad y de extensiones de protocolo (XEP, Extension de Protocolo XMPP)

Para añadir un poco de contexto al momento: lo más parecido a un smartphone era la Blackberry que era un teléfono que integraba el correo electrónico, en 2007 se presentó el primer móvil iPhone y al año siguiente, en 2008 se presentó el primer móvil Android. Whatsapp no apareció hasta 2009.

XMPP apareció antes que los teléfonos móviles que conocemos actualmente, era algo para utilizar en ordenadores.

Google Talk utilizó el estándar hasta que desmanteló el servicio para crear Hangouts, con un diseño propietario y cerrado. Facebook Chat también estuvo usándolo.

En fin, que nuevo no es.

¿Cómo funciona esto?

Los servidores XMPP funcionan en base al modelo cliente-servidor, como en los servidores de correo electrónico, incluso el esquema de nombre de usuario en un servidor XMPP es igual que en los de correo: usuario@servidor. Internamente, el tráfico de datos entre cliente y servidor se denomina c2s (client to server, de un cliente a un servidor) y el tráfico entre servidores, s2s (server to server, de un servidor a otro servidor). Se pueden tener cuentas diferentes en varios servidores.

¿Esto lo utiliza alguien?

Pregunta interesante, porque siempre tenemos el típico argumento de que «ahí no hay nadie» o «todos están en...», y con esto que parece algo nuevo aunque no lo es, pues más todavía.

Pues esto se usa en el chat entre jugadores de un juego que se llama Fortnite, en Nintendo Switch para notificaciones y en algunos otros juegos.

Whatsapp usa una modificación propietaria de XMPP, Zoom también lo usa con extensiones propietarias, Grindr también, e incluso MOKA, que es una aplicación de la Policía Federal alemana.

Se usa en eso que se llama «Internet de las cosas» IoT, por ejemplo en sistemas de domótica y control remoto.

Y en muchos otros proyectos, es decir que sí tiene una base de uso verdaderamente grande. Hay mucha información en la página de XMPP.

¿Cómo usarlo?

Es muy parecido a como usar el correo electrónico: se elige un servidor, se registra una cuenta, se elige un cliente y se usa.

Dependiendo del servidor que queramos usar, es posible que tengamos que registrar la cuenta desde el propio cliente, es lo que se llama registro in-band.

Hay listas de servidores para poder elegir uno, esta es bastante buena y esta otra también. Podemos optar si nos apetece por montarnos nuestro propio servidor.

Las cuentas son todas de la forma nombre@dominio.com igual que la del correo electrónico y se llama JID (Jabber ID), también hace falta una contraseña.

Una vez que tenemos una cuenta en un servidor, la tenemos que registrar en el cliente, igual que hacemos con una cuenta de correo. Podemos elegir diversos clientes: para PC, con Windows, con Linux, con FreeBSD, para dispositivos móviles con Android y con iOS. Hay servidores que ofrecen un cliente web con toda la funcionalidad, como si fuera correo web. Podemos tener abierta la misma cuenta en más de un dispositivo o tener más de una cuenta en un dispositivo.

Una vez que tenemos usuario registrado en el cliente, para conversar necesitamos los identificadores o JIDs de los interlocutores, como si fuera correo electrónico, que necesitamos saber las direcciones de otros.

Se pueden crear grupos de chat, los crea un usuario en su servidor y después invita a otros al mismo, aunque el resto de usuario sean de otros servidores.

Esto es una explicación muy resumida, hay distintas configuraciones y procedimientos para validar claves de interlocutores, activación de cifrado y selección de tipo y otras cosas, que dependen del software que estemos usando.

Algunos clientes para XMPP:

• Para PC/Mac
  • Gajim (https://gajim.org), Windows y Linux
  • Dino.im(https://dino.im), Linux, *BSD
  • Monal (https://monal.im), Mac
  • Profanity(https://profanity-im.github.io/), Linux, Windows, Mac, en terminal.
• Para Android
  • Conversations (https://conversations.im/), es el origen de otros clientes para Android.
  • Monocles (https://monocles.de), forma parte de un conjunto más amplio de servicio, incluso un servidor de XMPP, Se puede instalar el cliente para Android desde Fdroid.
  • Cheogram (https://cheogram.com/) se puede instalar desde Fdroid
• Para iPhone
  • Monal (https://monal.im), es el mismo programa de Mac pero en iPhone.

¿Por qué utilizar esto?

Un motivo importante es la resiliencia consecuencia del diseño descentralizado de XMPP y coincidente con el diseño original de internet: si cae un servidor, el resto sigue funcionando, pero si cae Whatsapp, por ejemplo, se quedan sin servicio todos sus usuarios.

Importante es también la protección de nuestra privacidad y nuestros datos: XMPP tiene extensiones que le permiten cifrar extremo a extremo.

Un par de referencias

• Web oficial(en inglés)
• XMPP en Wikipedia

Por otra parte, estuve leyendo una publicación en Privay Guides, que nos invita a abandonar la mentalidad del todo o nada, con el nada se asume que no vale la pena cualquier esfuerzo que hagamos para proteger nuestra privacidad, la otra es la de que hagamos lo que hagamos si no conseguimos privacidad y seguridad totales no vale de nada.

Puedes ir al artículo pinchando aquí, está en inglés y me sugiere una pequeña dosis de optimismo necesaria para seguir adelante y abandonar el derrotismo.

Generalmente se usan plataformas que dicen que respetan nuestra privacidad, que cifran extremo a extremo (es el cifrado que efectúa el remitente antes de enviar para que descifre solo el destinatario, como lo ya explicado), se supone que nadie lee los mensajes, mira las imágenes ni escucha los audios...

Estas plataformas implementan (ponen en marcha) sus propios protocolos de comunicación, muchas veces no se conocen, no son interoperables, es decir que no “hablan” unos con otros, con lo que el entrar en cualquiera de estas plataformas es entrar en grandes jardines vallados pertenecientes a grandes empresas tecnológicas.

Y el código, hay veces que está disponible el de la parte cliente pero no el de la parte del servidor, otras veces ninguno de los dos, total que no hay certeza ninguna de qué es lo que hacen, qué datos guardan, durante cuánto tiempo, el cifrado...

Hay varias de estas plataformas que requieren, para poder hacer uso de las mismas, que se vincule la identidad del usuario con una SIM, hacerlo así compromete el anonimato (algo diferente a la privacidad), que es el mantenimiento de una identidad en secreto. Para mi, el que sea necesario tener una SIM es un punto en contra de tales plataformas.

Antes de seguir, creo que es necesario explicar brevemente algunos conceptos o ideas:

Protocolo

Un protocolo es un sistema de reglas para relacionar dos o más entidades entre ellas. Es una descripción o especificación. Salvando las distancias, sería la receta escrita de alguna comida, la puedes leer y planificar desde lejos de la cocina.

Implementación de protocolo

La puesta en marcha del protocolo, leer la receta anterior y hacer la comida. Lo necesario para hacerlo: programas, ordenadores, servidores, base de datos. Se puede implementar el protocolo completo o solo alguna parte, por ejemplo en los diseños cliente-servidor se puede implementar el servidor y por otra parte el cliente, tal como hace Whatsapp, también hay quién implementa un cliente y posteriormente un servidor.

Cliente-servidor

Diseño de software y de protocolo también, en el que las tareas se reparten entre dos intervinientes, uno, el cliente, pide cosas al otro, el servidor y este cumple la petición, si es que es posible y puede. Un ejemplo de esta disposición es el correo electrónico: por una parte tenemos un servidor en el que tenemos registrada una cuenta y por otro lado podemos tener uno o más clientes configurados para dicha cuenta. No quisiera que el ejemplo que voy a poner se interprete como publicidad: Yahoo tiene un servicio de correo electrónico y un servidor para el mismo, luego cada persona con cuenta en Yahoo puede tener varios clientes, por ejemplo uno en el móvil, otro diferente en el ordenador de mesa y otro en un portátil, todos ellos configurados con la misma cuenta. Desde el cliente se puede pedir al servidor que nos pase nuestros correos nuevos, o que haga una carpeta, o que haga lo necesario para enviar un correo electrónico. Si el cliente está bien hecho, el servidor entenderá qué es lo que se le está pidiendo.

Anonimato

El anonimato es el secreto sobre el autor de algo. En ciertas situaciones puede ser vital, como en las de disidencias en regiones represivas, pero también puede ser utilizado de forma abusiva. En Internet no es posible el anonimato total.

Mi opinión con estos conceptos es que necesitamos disponer de protocolos libres, con toda su información disponible para implementarlo, y si no lo vamos a hacer nosotros, que dispongamos también de programas libres, que podamos saber qué hace, no digo que lo hagamos, si no que al menos tengamos esa posibilidad.

¿Qué podríamos o deberíamos pedir a un servicio de mensajería instantánea?. Yo pediría cierto apoyo al anonimato, que siga un protocolo o protocolos libres y que contemplen la privacidad en las comunicaciones, aunque deberíamos ser los interlocutores los que nos encarguemos de ello, como en el cifrado de correo.

Empezando por el anonimato, yo descartaría todos los servicios que vinculan el registro de usuario con una SIM. Se puede alegar que en el uso normal de algunos de estos servicios, los interlocutores no pueden ver el número de teléfono, pero me preocupa más que lo tenga el titular del servicio. Así que yo evitaría servicios como Whatsapp, Telegram; Signal no requiere SIM, pero sí un número de teléfono, yo no lo uso, pero puede ser una opción a tener en cuenta.

En cuanto a protocolos y sus implementaciones, podemos encontrar que los hay con pocas especificaciones (o ninguna), pero yo veo que los servicios centralizados, con un solo servidor, se convierten en jardines cerrados: una vez que estás allí solo es posible comunicarse con otros que estén también allí, en el mismo servidor. Además existen implementaciones, en ocasiones en la parte cliente y siempre en la parte de servidor de la que no se dispone de información de cómo funcionan ni de qué datos guardan, cuánto tiempo ni nada. También descartaría estos servicios.

En cuanto al cifrado, hay servicios que anuncian que ofrecen cifrado punto a punto, pero sin tener acceso a la especificación del protocolo ni el código fuente no tenemos ninguna certeza de que efectivamente estemos cifrando, o incluso que no se esté observando lo que escribimos antes de cifrar. También evitaría estos servicios.

En definitiva, que el o los protocolos utilizados sean libres y estén disponibles para cualquiera es una de las claves para elegir una mensajería instantánea (o cualquier otro servicio).

Ya he mencionado que no soy modélico en el uso de mensajería, solo uso una mensajería basada en un protocolo libre, consolidado, mantenido y ampliado. El carácter libre de este protocolo, XMPP, permite que pueda haber diferentes y variadas implementaciones y diferentes servicios montados sobre estas implementaciones. El cifrado de las conversaciones se hace punto a punto, pero además se puede comprobar dado el carácter libre del código de la mayoría de las implementaciones.

Hay otras mensajerías interesantes como delta.chat que se basa en protocolos estándar ya utilizados en correo electrónico como SMTP , IMAP, OpenPGP, es decir cosas que son libres, y que están disponibles para todo el mundo, no hay secretos, no hay oscuridad.

El mismo artículo pone fuera de la ley las comunicaciones anónimas, requiriendo a todos lo ciudadanos verificación de edad, poniendo en riesgo a denunciantes, periodistas, activistas y otros.

También hay previsto en el artículo 6, arresto digital domiciliario, medidas punitivas, vamos.

Tenemos que aprender a cifrar por nosotros mismos (PGP, OMEMO...), enseñar a cifrar y hacerlo para todo. O darnos por vencidos y espiados.

Si Orwell resucita, se cae de culo.

Todo lo que hagas será insignificante, pero es muy importante que lo hagas. Mahatma Ghandi

Es algo personal. Es privado. Y no le incumbe a nadie más que a ti. Quizás estés planeando una campaña política, hablando de tus impuestos o teniendo una relación extramarital. O tal vez te estés comunicando con un disidente político en un país represivo. Sea lo que sea, no quieres que nadie más lea tu correo electrónico privado ni tus documentos confidenciales. No hay nada de malo en defender tu privacidad. La privacidad es un derecho fundamental.

El derecho a la privacidad está implícito en la Declaración de Derechos. Sin embargo, al redactar la Constitución de los Estados Unidos, los Padres Fundadores no vieron la necesidad de explicitar el derecho a la privacidad en las conversaciones. Habría sido absurdo. Hace doscientos años, todas las conversaciones eran privadas. Si alguien estaba cerca, uno podía simplemente salir al granero y conversar allí. Nadie podía escuchar sin que uno lo supiera. El derecho a la privacidad en las conversaciones era un derecho natural, no solo en un sentido filosófico, sino también desde el punto de vista de las leyes de la física, dada la tecnología de la época.

Aquí es donde empieza a mencionarse el tema principal: la privacidad, para ello menciona parte de la historia de los Estados Unidos. Los Padres Fundadores fueron los que firmaron la Declaración de Independencia y establecieron la Constitución.

Pero con la llegada de la era de la información, comenzando con la invención del teléfono, todo cambió. Ahora, la mayoría de nuestras conversaciones se realizan electrónicamente. Esto permite que nuestras conversaciones más íntimas queden expuestas sin nuestro conocimiento. Cualquiera con una radio puede interceptar las llamadas de telefonía móvil. El correo electrónico, enviado a través de internet, no es más seguro que las llamadas de telefonía móvil. El correo electrónico está reemplazando rápidamente al correo postal, convirtiéndose en la norma para todos, no en la novedad que fue en el pasado.

Hay que tener en cuenta que cuando Zimmermann escribió esto, 1991 e incluso cuando lo actualizó en 1996, no existían los teléfonos tipo smartphone, el correo electrónico se usaba solo desde ordenadores.

Hasta hace poco, si el gobierno quería vulnerar la privacidad de los ciudadanos, tenía que invertir una cantidad considerable de recursos y mano de obra para interceptar, abrir y leer el correo postal. O bien, tenía que escuchar y, posiblemente, transcribir las conversaciones telefónicas, al menos antes de que existiera la tecnología de reconocimiento de voz automático. Este tipo de vigilancia, que requería mucha mano de obra, no era práctica a gran escala. Solo se realizaba en casos importantes, cuando parecía justificado. Es como pescar un pez a la vez, con anzuelo y sedal. Hoy en día, el correo electrónico se puede analizar de forma rutinaria y automática en busca de palabras clave interesantes, a gran escala, sin ser detectado. Es como pescar con redes de deriva. Y el crecimiento exponencial de la potencia informática está haciendo posible lo mismo con el tráfico de voz.

Muchos años después, cuando Edward Snowden tiró de la manta, declaró que el espionaje era realmente masivo, porque técnicamente se podía hacer.

Tal vez pienses que tu correo electrónico es lo suficientemente legítimo como para que el cifrado sea innecesario. Si de verdad eres un ciudadano respetuoso de la ley que no tiene nada que ocultar, ¿por qué no envías siempre tu correo postal en tarjetas postales? ¿Por qué no te sometes a pruebas de detección de drogas cuando te lo solicitan? ¿Por qué necesitas una orden judicial para que la policía registre tu casa? ¿Acaso intentas ocultar algo? Si escondes tu correo en sobres, ¿significa eso que eres un subversivo, un narcotraficante o quizás un paranoico? ¿De verdad los ciudadanos respetuosos de la ley necesitan cifrar su correo electrónico?

Ya antes del año 2000 funcionaba el argumento ese de «si no tienes nada que ocultar..., déjanos mirar todo.»

¿Qué pasaría si todos creyeran que los ciudadanos respetuosos de la ley deberían usar postales para su correo? Si alguien que no se ajusta a las normas intentara proteger su privacidad usando un sobre, levantaría sospechas. Quizás las autoridades abrirían su correo para ver qué oculta. Por suerte, no vivimos en un mundo así, porque casi todos protegemos nuestra correspondencia con sobres. Así que nadie levanta sospechas al proteger su privacidad con un sobre. La unión hace la fuerza. De forma similar, sería bueno que todos usaran habitualmente el cifrado para todos sus correos electrónicos, sean inocentes o no, para que nadie levantara sospechas al proteger su privacidad con cifrado. Piénsenlo como una forma de solidaridad.

Aquí se plantea la posibilidad de llamar la atención si haces algo no habitual para la mayoría (por desconocimiento), aunque estés ejerciendo tus derechos. Esto puede ser arriesgado en ciertos contextos, como en regímenes represivos.

El Proyecto de Ley del Senado 266, una ley integral contra el crimen de 1991, contenía una inquietante medida oculta. Si esta resolución no vinculante se hubiera convertido en ley, habría obligado a los fabricantes de equipos de comunicaciones seguras a insertar “puertas traseras” especiales en sus productos, permitiendo así que el gobierno leyera los mensajes cifrados de cualquier persona. El texto decía: “El Congreso considera que los proveedores de servicios de comunicaciones electrónicas y los fabricantes de equipos para dichos servicios deben garantizar que los sistemas de comunicaciones permitan al gobierno obtener el contenido en texto plano de las comunicaciones de voz, datos y otras comunicaciones cuando la ley lo autorice debidamente”. Fue este proyecto de ley el que me impulsó a publicar PGP electrónicamente y de forma gratuita ese mismo año, poco antes de que la medida fuera rechazada tras una enérgica protesta de defensores de las libertades civiles y grupos industriales.

La ley 266 planteaba la inclusión de puertas traseras para utilizarlas cuando se autorice debidamente, la cuestión es que una vez que hay puerta trasera, pues ahí está para abrir a discreción. Era parecido a la propuesta en Europa del Chatcontrol, con la diferencia de que aquí se propone el mismo escaneo pero incondicional. Allí hubieran llegado a lo mismo, pero ahora, aquí, es el punto de partida.

La Ley de Asistencia para las Comunicaciones en la Aplicación de la Ley (CALEA) de 1994 obligó a las compañías telefónicas a instalar puertos de escucha remota en sus centrales digitales, creando una nueva infraestructura tecnológica para la escucha telefónica mediante un simple clic. De esta manera, los agentes federales ya no tienen que desplazarse y conectar pinzas de cocodrilo a las líneas telefónicas. Ahora pueden escuchar las llamadas telefónicas desde sus oficinas centrales en Washington. Por supuesto, la ley aún exige una orden judicial para realizar una escucha. Pero si bien las infraestructuras tecnológicas pueden perdurar durante generaciones, las leyes y las políticas pueden cambiar de la noche a la mañana. Una vez que una infraestructura de comunicaciones optimizada para la vigilancia se consolida, un cambio en las condiciones políticas puede dar lugar al abuso de este nuevo poder. Las condiciones políticas pueden cambiar con la elección de un nuevo gobierno, o quizás de forma más abrupta tras el atentado con bomba contra un edificio federal.

CALEA son las siglas de Communications Assistance for Law Enforcement Act que es el nombre en inglés de dicha ley. Este párrafo forma parte de la actualización del original y ya avisa de sistemas que pueden ser utilizados bajo cierto control legal, también se pueden usar de forma discrecional e indiscriminadamente.

Un año después de la aprobación de la CALEA, el FBI reveló planes para exigir a las compañías telefónicas que incorporaran a su infraestructura la capacidad de intervenir simultáneamente el 1% de todas las llamadas telefónicas en las principales ciudades de Estados Unidos. Esto representaría un aumento de más de mil veces con respecto a los niveles anteriores en la cantidad de teléfonos que podían ser intervenidos. En años anteriores, solo se realizaban alrededor de mil intervenciones telefónicas ordenadas por un tribunal al año en Estados Unidos, sumando los niveles federal, estatal y local. Es difícil imaginar cómo el gobierno podría siquiera contratar suficientes jueces para firmar las órdenes de intervención necesarias para intervenir el 1% de todas nuestras llamadas telefónicas, y mucho menos contratar suficientes agentes federales para escuchar todo ese tráfico en tiempo real. La única forma plausible de procesar tal cantidad de tráfico sería una aplicación masiva, al estilo orwelliano, de tecnología de reconocimiento de voz automatizado para analizarlo todo, buscando palabras clave interesantes o la voz de un hablante en particular. Si el gobierno no encuentra al objetivo en la primera muestra del 1%, las escuchas telefónicas pueden trasladarse a otro 1% hasta dar con el objetivo o hasta que se hayan revisado todas las líneas telefónicas en busca de tráfico subversivo. El FBI afirmó que necesita esta capacidad para planificar el futuro. Este plan provocó tal indignación que fue rechazado en el Congreso. Pero el mero hecho de que el FBI solicitara estos amplios poderes revela sus verdaderas intenciones.

Fue tan escandaloso lo que pedía el FBI que incluso el congreso lo rechazó, ahora (finales de 2025) estamos en una situación un poco más avanzada: algo todavía peor, sin porcentajes, no lo pide un organismo policial, sino el propio Consejo Europeo.

Los avances tecnológicos no permitirán mantener el statu quo en lo que respecta a la privacidad. El statu quo es inestable. Si no hacemos nada, las nuevas tecnologías otorgarán al gobierno capacidades de vigilancia automática inimaginables para Stalin. La única manera de proteger la privacidad en la era de la información es mediante una criptografía robusta.

No es necesario desconfiar del gobierno para querer usar criptografía. Su empresa puede ser objeto de escuchas telefónicas por parte de competidores, el crimen organizado o gobiernos extranjeros. Varios gobiernos extranjeros, por ejemplo, admiten usar su inteligencia de señales contra empresas de otros países para dar a sus propias corporaciones una ventaja competitiva. Irónicamente, las restricciones impuestas por el gobierno de Estados Unidos a la criptografía en la década de 1990 han debilitado las defensas de las empresas estadounidenses contra la inteligencia extranjera y el crimen organizado.

Ya expliqué como, interceptando correos sin cifrar, se habían producido robos por el medio de modificar dichos correos para que contuvieran datos de cuentas bancarias ajenas a los interlocutores.

El gobierno es consciente del papel fundamental que la criptografía está destinada a desempeñar en la relación de poder con la ciudadanía. En abril de 1993, la administración Clinton presentó una ambiciosa iniciativa de cifrado, que la Agencia de Seguridad Nacional (NSA) había estado desarrollando desde el inicio de la administración Bush. La pieza central de esta iniciativa era un dispositivo de cifrado gubernamental, el chip Clipper, que contenía un nuevo algoritmo de cifrado clasificado de la NSA. El gobierno intentó incentivar a la industria privada a integrarlo en todos sus productos de comunicación segura, como teléfonos y faxes seguros. AT&T incorporó el Clipper a sus productos de voz segura. El inconveniente: al fabricarse, cada chip Clipper se carga con su propia clave única, y el gobierno conserva una copia en depósito. Sin embargo, no hay de qué preocuparse: el gobierno promete que solo utilizará estas claves para leer el tráfico de datos «cuando esté debidamente autorizado por ley». Por supuesto, para que el Clipper sea completamente efectivo, el siguiente paso lógico sería prohibir otras formas de criptografía.

EL gobierno USA estaba fabricando chips, el Consejo de Europa quiere que el escaneo de mensajes lo lleven a cabo las plataformas, externalizar que se dice. Y lo de prohibir el cifrado, pues eso es lo que le gustaría a nuestro actual gobierno.

Inicialmente, el gobierno afirmó que el uso de Clipper sería voluntario y que nadie estaría obligado a usarlo en lugar de otros tipos de criptografía. Sin embargo, la reacción pública contra el chip Clipper fue contundente, más de lo previsto. La industria informática manifestó unánimemente su oposición al uso de Clipper. En una rueda de prensa en 1994, el director del FBI, Louis Freeh, respondió a una pregunta afirmando que si Clipper no lograba el apoyo público y las escuchas telefónicas del FBI se veían obstaculizadas por la criptografía no controlada por el gobierno, su oficina no tendría más remedio que solicitar medidas legislativas. Posteriormente, tras la tragedia de Oklahoma City, Freeh testificó ante el Comité Judicial del Senado que el gobierno debía restringir la disponibilidad pública de criptografía robusta (aunque nadie había sugerido que los terroristas hubieran utilizado criptografía).

Aprovechando que el Pisuerga pasa por Valladolid, pues tratan de aplicar medidas que de otra manera sería difícil de justificar. Esto fue en 1995, pero actualmente también se hace y no solo en Estados Unidos.

El historial del gobierno no inspira confianza en que jamás abusará de nuestras libertades civiles. El programa COINTELPRO del FBI tuvo como objetivo a grupos que se oponían a las políticas gubernamentales. Espiaron el movimiento contra la guerra y el movimiento por los derechos civiles. Intervinieron el teléfono de Martin Luther King. Nixon tenía su lista de enemigos. Luego vino el escándalo Watergate. Más recientemente, el Congreso ha intentado, o incluso logrado, aprobar leyes que restringen nuestras libertades civiles en internet. Algunos miembros de la Casa Blanca de Clinton recopilaron archivos confidenciales del FBI sobre funcionarios republicanos, posiblemente con fines de explotación política. Y algunos fiscales demasiado celosos han demostrado estar dispuestos a llegar hasta el fin del mundo con tal de exponer las indiscreciones sexuales de sus adversarios políticos. En ningún otro momento del último siglo la desconfianza pública hacia el gobierno había estado tan extendida por todo el espectro político como lo está hoy.

Durante la década de 1990, pensé que si queríamos resistir esta inquietante tendencia del gobierno a prohibir la criptografía, una medida que podíamos aplicar era usarla tanto como fuera posible mientras aún fuera legal. Cuando el uso de criptografía robusta se populariza, al gobierno le resulta más difícil criminalizarla. Por lo tanto, usar PGP es beneficioso para preservar la democracia. Si se prohíbe la privacidad, solo los delincuentes tendrán privacidad.

Yo creo que actualmente tenemos que hacer lo mismo: aprender que es, como se hace, comprenderlo, en correo electrónico, en mensajería, enseñarlo y sobre todo usarlo, ejercer nuestros derechos.

Parece que la implementación de PGP, junto con años de constante protesta pública y presión de la industria para flexibilizar los controles de exportación, dio resultado. A finales de 1999, la administración Clinton anunció un cambio radical en la política de exportación de criptografía. Básicamente, eliminaron todo el régimen de control de exportaciones. Ahora, por fin podemos exportar criptografía robusta, sin límites de seguridad. Ha sido una larga lucha, pero finalmente hemos ganado, al menos en lo que respecta al control de exportaciones en Estados Unidos. Ahora debemos continuar nuestros esfuerzos para implementar criptografía robusta y contrarrestar los efectos del creciente espionaje en internet por parte de diversos gobiernos. Y aún necesitamos consolidar nuestro derecho a usarla en nuestro país, a pesar de las objeciones del FBI.

PGP empodera a las personas para que tomen el control de su privacidad. Ha habido una creciente necesidad social de ello. Por eso lo escribí.

Actualmente disponemos de más herramientas tecnológicas para esto, tomar el control de nuestra privacidad, además del PGP/OpenPGP. También existen otras herramientas con las que hay que tener cuidado porque sus patrocinadores prometen que con ellas también tomas el control de tu privacidad pero realmente son una trampa.

Philip R. Zimmermann Boulder, Colorado Junio ​​de 1991 (actualizado en 1999)

Durante esta presidencia parece que no va a ser, así que regalos de Navidad normales.

Patrick Breyer, exparlamentario europeo por el Partido Pirata, declaró que es un triunfo para el movimiento por la libertad digital y por la defensa del derecho por la confidencialidad de nuestras comunicaciones, pero que aún ve problemas, entre ellos la vigilancia masiva: aún cuando se implemente como escaneo voluntario, este es indiscriminado y da lugar a una vigilancia total y una transferencia de nuestra información a todas esas plataformas (Meta, Google...).

Así que, hay que ir pensando en abandonar todas esas plataformas y en aprender a cifrar nuestra información y comunicaciones y hacerlo.