Cifrado con XMPP

Una característica importante del protocolo XMPP es la posibilidad de cifrar las conversaciones con un interlocutor o participando en un grupo. El cifrado es extremo a extremo, es decir, el servidor no participa en la operación de cifrado ni en la de descifrado.

Hace algún tiempo se usaba un sistema que se llama OTR (Off-The-Record) y se aplicaba a XMPP. Hay varios programas cliente que están tratando de incorporar de nuevo la funcionalidad para usarlo de forma experimental, pero su uso está desaconsejado porque hace tiempo que no se desarrolla ni actualiza (aunque hubo un momento que parecía que resurgía), por lo que los problemas de uso en grupos y alguna otra cosa, no encontrarán solución.

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: