Cifrado de extremo a extremo sin compromisos

Nota: Este artículo describe la arquitectura y diseño de Mandraki. Algunas características discutidas se están implementando progresivamente y pueden no estar aún disponibles en todos los planes.

El cifrado de extremo a extremo es una de esas características que es fácil de prometer y difícil de entregar correctamente. Muchas plataformas de colaboración afirman ofrecer E2EE, pero los detalles de sus implementaciones varían enormemente — y los detalles son donde vive o muere la seguridad.

Este artículo explica cómo Mandraki implementa cifrado de extremo a extremo, las opciones de protocolo que hicimos, y los intercambios sobre los que somos transparentes.

Qué cifrado de extremo a extremo realmente significa

En un sistema con cifrado de extremo a extremo, los mensajes y medios se cifran en el dispositivo del remitente y solo pueden descifrarse en los dispositivos de los destinatarios. El servidor que retransmite los datos ve solo cifrado. No puede leer el contenido, incluso si es obligado a hacerlo por una orden judicial, un empleado malvado, o una violación de seguridad.

Esto es fundamentalmente diferente del cifrado de transporte (TLS), que protege datos en tránsito entre un cliente y un servidor pero deja al servidor con acceso al texto plano. También es diferente del cifrado en reposo, que protege datos en disco pero deja la capa de aplicación con acceso al texto plano durante el procesamiento.

El E2EE verdadero significa que el servidor no es de confianza por diseño. Es un retransmisor, no un lector.

El protocolo MLS para mensajería

Para mensajería cifrada, usamos el protocolo Messaging Layer Security (MLS), estandarizado como RFC 9420 por el IETF. MLS fue diseñado específicamente para escenarios de mensajería grupal y ofrece varias ventajas sobre enfoques más antiguos.

MLS usa una estructura de acuerdo de clave basada en árbol llamada TreeKEM, que permite que un grupo de participantes establezca un secreto compartido eficientemente. Cuando un miembro se une o sale de un grupo, el material de clave se actualiza a través de un mensaje de Commit que avanza la época del grupo. Esto proporciona secreto hacia adelante — comprometer las claves de un miembro en un punto en el tiempo no revela mensajes de épocas anteriores — y seguridad post-compromiso — el grupo recupera seguridad después de un compromiso tan pronto como el material de clave del miembro afectado es rotado.

Cada dispositivo de usuario sube paquetes de clave MLS al servidor. Estos son haces criptográficos de uso único que permiten a otros dispositivos agregarlos a un grupo sin requerir que el dispositivo esté en línea en ese momento. Cuando un paquete de clave es consumido, el dispositivo debe subir nuevos. El servidor almacena y distribuye estos paquetes pero nunca tiene acceso al material de clave privada que contienen.

Los grupos de MLS en Mandraki se mapean a canales e hilos de mensaje directo. Cuando envías un mensaje en un canal cifrado, tu cliente lo cifra usando la clave de época actual del grupo. El servidor recibe cifrado, lo almacena, y lo distribuye a miembros del grupo. Sus clientes lo descifran localmente.

SFrame para cifrado de medios

Cifrar medios en tiempo real — audio y vídeo en una llamada grupal — presenta desafíos diferentes de la mensajería. La tolerancia de latencia se mide en milisegundos, no segundos. Las tasas de datos son órdenes de magnitud más altas. Y los medios pasan a través de una Unidad de Reenvío Selectivo (SFU), que necesita enrutar paquetes a los participantes correctos sin poder ver el contenido.

Usamos SFrame (RFC 9605) para cifrado de medios, aplicado vía la WebRTC Encoded Transform API. Esta API permite que código JavaScript intercepte fotogramas de medios codificados después de la codificación pero antes de la empaquetización, los cifre, y pase el cifrado a la capa de transporte. En el extremo receptor, los fotogramas se descifran después de la reensamblaje pero antes de la decodificación.

La ventaja clave de SFrame en una arquitectura de SFU es que el SFU aún puede realizar su función de enrutamiento — reenviando paquetes de un participante a otros, tomando decisiones adaptativas de ancho de banda sobre qué capas reenviar — sin jamás tener acceso a los medios de texto plano. El SFU ve fotogramas cifrados y los reenvía como blobs opacos.

Los intercambios sobre los que somos honestos

El cifrado de extremo a extremo no es gratis. Introduce restricciones reales que creemos valen la pena reconocer.

La búsqueda del lado del servidor no es posible en contenido E2EE. Si los mensajes se cifran con claves que el servidor no sostiene, el servidor no puede indexarlos para búsqueda. Mandraki aborda esto manteniendo un índice de búsqueda cifrado local en el cliente usando IndexedDB. Esto proporciona búsqueda por-dispositivo pero no soporta búsqueda de historial entre dispositivos para mensajes recibidos antes de que un dispositivo fuera agregado al grupo.

Las características de IA del lado del servidor son mutuamente exclusivas con E2EE. Nuestras características de transcripción de IA y resumen requieren acceso del lado del servidor a audio de texto plano. Una llamada o canal no puede tener tanto E2EE como características de IA habilitadas simultáneamente. Esto se hace cumplir arquitectónicamente, no solo por política. Las organizaciones eligen a nivel de llamada o canal qué modelo prefieren.

Los nuevos dispositivos ven mensajes solo desde el punto de unión en adelante. Cuando agregas un nuevo dispositivo a tu cuenta, puede descifrar mensajes desde el momento en que se une al grupo de MLS en adelante. Los mensajes históricos cifrados bajo épocas anteriores no son accesibles en el nuevo dispositivo. Esta es una propiedad fundamental del secreto hacia adelante. Estamos explorando mecanismos de respaldo seguro que permitirían a los usuarios exportar historial de mensajes cifrados a un nuevo dispositivo, pero esto permanece en progreso.

La gestión de claves añade complejidad. Cada dispositivo debe mantener material de clave, subir paquetes de clave frescos, y procesar actualizaciones de estado de grupo. Invertimos esfuerzo de ingeniería significativo en hacer esto invisible para los usuarios. El objetivo es que el cifrado no sea algo que configures o pienses — simplemente sucede.

E2EE y cifrado del lado del servidor coexisten

Vale la pena notar que la capa E2EE de Mandraki y nuestro cifrado del lado del servidor (la jerarquía de claves de tres capas descrita en nuestra arquitectura de seguridad) sirven propósitos complementarios. El cifrado del lado del servidor protege datos en reposo en nuestra infraestructura — si un disco es robado o una copia de seguridad de base de datos es comprometida, los datos son ilegibles sin las claves de cifrado. E2EE va más allá asegurando que el servidor nunca vea texto plano en primer lugar.

Para organizaciones que habilitan E2EE, ambas capas están activas simultáneamente. Los datos se cifran de extremo a extremo por los clientes y también se cifran en reposo en el servidor. Cinturón y tirantes.

Creemos que el cifrado de extremo a extremo debería ser el predeterminado para comunicaciones sensibles, no un add-on premium o una casilla que la mayoría de usuarios nunca encuentren. Mandraki lo hace directo de habilitar, transparente en sus limitaciones, y robusto en su implementación.