Usamos IA para escribir más rápido, no para decidir qué es verdad. Alguien de Digital Samba ha leído cada línea de este artículo antes que tú.
Respuesta corta: un cifrado de extremo a extremo (E2EE) bien implementado no se rompe atacando el cifrado en sí. Los riesgos reales están en los extremos, en el intercambio de claves y en la implementación, no en el algoritmo. Cuando una videollamada protegida con E2EE se ve comprometida, casi con total seguridad el atacante no ha reventado el algoritmo de cifrado. Lo ha esquivado por completo, apuntando a algo mucho más cercano al usuario.
Esto importa porque la pregunta «¿se puede hackear el cifrado de extremo a extremo?» suele responderse con falsa tranquilidad o con alarmismo exagerado. Ninguna de las dos cosas ayuda a quien tiene que tomar decisiones de seguridad de verdad. Este artículo explica qué protege el E2EE realmente, dónde está la superficie de ataque real y qué hace un sistema bien diseñado para defenderse de cada vía, usando la implementación de Digital Samba como ejemplo concreto.
Índice de contenidos
El cifrado de extremo a extremo (también llamado encriptación de extremo a extremo) significa que el contenido se cifra en el dispositivo del emisor y solo se descifra en el del receptor. Cada servidor o repetidor por el que pasa, incluida la propia infraestructura del proveedor del servicio, maneja texto cifrado que no puede leer. Las claves solo existen en los extremos. El servidor nunca las ve.
En una videollamada, el E2EE puede cubrir los flujos de vídeo, el uso compartido de pantalla, los mensajes de chat, los nombres de los participantes y el contenido de la pizarra, todo lo cual queda dentro de la frontera cifrada. Lo que queda fuera de esa frontera son los metadatos: el hecho de que hubo una llamada, cuándo empezó y terminó y qué cuentas participaron. Los metadatos no son la carga útil. Son información de enrutamiento y de sesión que la infraestructura necesita para funcionar, y el E2EE no los protege.
Las funciones del lado del servidor que necesitan acceder al contenido, como la grabación, la transcripción en directo y la toma de notas automática, no pueden funcionar dentro de una sesión E2EE de verdad, porque el servidor no puede descifrar lo que necesitaría procesar. Ese compromiso es real, y lo tratamos con más detalle más abajo.
Para ver con más profundidad cómo funciona el E2EE en WebRTC en concreto, el artículo de Digital Samba sobre el poder del E2EE en WebRTC cubre la mecánica interna al completo.
De forma realista, no. El cifrado de extremo a extremo moderno se apoya en AES, el cifrado simétrico en el que se confía para proteger desde la banca en línea hasta datos clasificados. En WebRTC, los medios se cifran fotograma a fotograma con SFrame, un estándar del IETF, y AES-128 es la longitud de clave establecida para ello: es lo que especifica el estándar y lo que han usado las implementaciones WebRTC de producción desde el primer despliegue del esquema. Digital Samba sigue ese estándar, con AES-128 en modo contador (CTR) y autenticación HMAC-SHA256 para los medios, y AES-256-GCM para los datos de vida más larga, como el chat y el propio intercambio de claves. Reventar por fuerza bruta una clave AES, sea de 128 o de 256 bits, es inviable en cómputo con la informática clásica actual. No es cuestión de que sea lento. En cualquier escala de tiempo realista, sencillamente no se puede hacer, y no se ha demostrado ningún ataque práctico contra AES.
La salvedad honesta es la computación cuántica. El algoritmo de Grover, si algún día se ejecutara en un ordenador cuántico tolerante a fallos lo bastante grande, daría una aceleración cuadrática para buscar claves, lo que en la práctica reduce a la mitad la fuerza en bits de una clave simétrica. Ese es uno de los motivos por los que las claves de medios son efímeras, se generan por sesión y se rotan, en lugar de ser de larga duración, y por los que se usan claves más largas para los datos que persisten. El NIST publicó sus primeros estándares de criptografía poscuántica en 2024; lo que sigue en marcha es la migración. Nada de esto hace que el E2EE actual sea vulnerable de forma inminente. La amenaza cuántica es un horizonte de planificación: algo para lo que prepararse en los próximos años, mucho antes de que pudiera afectar a una llamada hecha hoy.
La pregunta no es si el E2EE se puede romper. Es cómo se salta alguien la protección que da. En la práctica, los atacantes van una y otra vez a por las fronteras del canal cifrado.
Las vías de ataque de arriba no son insalvables. Una implementación E2EE bien diseñada aborda cada una desde la arquitectura. Esto es lo que hay que buscar en cualquier producto con E2EE, usando la implementación de Digital Samba como ejemplo trabajado.
Antes de entrar en la arquitectura, importa una distinción: el E2EE es un modo que activas para una sesión, no el estado por defecto de toda llamada. Todas las llamadas de Digital Samba están cifradas en tránsito, porque WebRTC lo exige. Ese cifrado de transporte (TLS y DTLS-SRTP) funciona salto a salto, eso sí, y termina en el servidor de medios a medida que se enruta cada flujo, que es lo que permite que funcionen las funciones del lado del servidor como la grabación en la configuración estándar. El E2EE añade una capa más encima, que cifra los propios medios de extremo a extremo, de modo que, una vez activado, los servidores de medios solo reenvían texto cifrado que no pueden leer. Esa capa de extremo a extremo es la parte que activas para una sesión dada, y de ella dependen las garantías de abajo.
Las claves se generan en el dispositivo con la Web Crypto API. Una vez activado el E2EE, las claves privadas nunca se transmiten a los servidores de Digital Samba ni se almacenan en ellos: solo existen en el dispositivo del participante mientras dura esa sesión. Es una restricción de arquitectura, no una simple promesa de política, y se mantiene durante todo el tiempo que corre la sesión E2EE.
Para defenderse de los ataques MITM al intercambio de claves, Digital Samba genera un código de verificación de seguridad que los participantes pueden comparar fuera de banda, por ejemplo por un mensaje de chat, una llamada de teléfono u otro canal independiente de la sesión de vídeo. Si los códigos coinciden, el intercambio de claves no ha sido manipulado. Si no coinciden, es una señal de que la sesión puede haber sido interceptada. Este mecanismo es sencillo, no requiere conocimientos especializados para usarlo y aborda directamente el ataque activo más realista contra el intercambio de claves E2EE.
Ese código de verificación descansa, eso sí, sobre una suposición: que el propio código que hace el cifrado es de fiar. El E2EE basado en navegador, el de Digital Samba incluido, corre como JavaScript que el navegador descarga de nuevo en cada sesión, en lugar de una app nativa fija y firmada que instalas una vez, como funcionan Signal o WhatsApp. Es un modelo de confianza genuinamente distinto. El mismo código que ejecuta el cifrado produce también el código de verificación, así que ese código no puede usarse para comprobarse a sí mismo. Es una propiedad inherente de hacer criptografía en el navegador, no algo específico de un proveedor concreto, y por eso las auditorías de seguridad independientes, las revisiones criptográficas publicadas y un código de cliente transparente tienen un peso especial en el E2EE de navegador. Es en lo que te apoyas en vez de dar el código por bueno sin más.
El secreto hacia delante y hacia atrás viene de la rotación de claves en los eventos de entrada y salida. Cuando un participante entra, se generan claves nuevas; cuando sale, las claves vuelven a rotar. Una clave que se vea comprometida más tarde no expone el contenido anterior a su generación ni el posterior a su rotación. Esto limita la exposición a la ventana entre rotaciones, en vez de a toda la sesión.
Con el E2EE activado, el SFU (Unidad de Reenvío Selectivo), que enruta los medios entre participantes, maneja solo texto cifrado. No puede descifrar los flujos que reenvía. Va integrado en el diseño: no hay ningún ajuste que pueda anularlo mientras el E2EE siga activo.
Esa misma garantía, que el servidor nunca tiene claves utilizables una vez activado el E2EE, es también lo que hace que el E2EE sea incompatible con cualquier función que necesite que el servidor lea el contenido. Es un compromiso que merece decirse con claridad en vez de enterrarse en la documentación.
La grabación y la transcripción, tal como se implementan normalmente, necesitan que el servidor acceda al audio o al vídeo en claro. En una sesión E2EE, donde el servidor no tiene claves, eso no es posible. Elegir E2EE para una sesión significa aceptar que la llamada no se puede grabar en el servidor, que no habrá transcripción automática y que el archivado para cumplimiento que dependa de la captura en el servidor no funcionará.
Para muchos casos de uso, como consultas jurídicas, citas sanitarias o conversaciones de negocio sensibles, es un compromiso aceptable y a menudo deseable. Para otros, como grabaciones de formación, control de calidad de atención al cliente o archivado en sectores regulados, puede que no. Lo importante es tomar esta decisión a propósito, con una idea exacta de lo que el E2EE impide en el lado del servidor, en lugar de descubrir la incompatibilidad después de desplegarlo.
Esto es lo que parece la protección de verdad en la práctica, y dónde quedan las responsabilidades residuales:
La respuesta corta, otra vez: el cifrado no va a ser el punto débil. Lo serán tu dispositivo, tus hábitos de verificación de claves y la calidad de la implementación. Un sistema E2EE bien diseñado mantiene las claves en el dispositivo, ofrece verificación fuera de banda, impone el secreto hacia delante y hacia atrás mediante la rotación de claves y asegura que el servidor maneje solo texto cifrado una vez activado. Esa combinación aborda de frente la superficie de ataque realista. Lo que no puede hacer es proteger un extremo comprometido, asegurar la privacidad de los metadatos, responder por el código que lo entrega en un navegador ni habilitar funciones del lado del servidor que necesiten acceso al contenido en claro.
Elige plataformas que sean honestas sobre estos límites. Las que nombran los compromisos con exactitud, incluido dónde hay que activar el E2EE y qué te cuesta cuando lo haces, suelen ser también las que han implementado bien el resto.
Para los detalles técnicos del enfoque de Digital Samba, el informe de seguridad cubre la implementación al completo. Para la mecánica del E2EE específica de WebRTC, el poder del E2EE en WebRTC es el artículo complementario a este.
Sí, cuando está bien implementado y activado para la sesión. El E2EE protege el contenido en tránsito al asegurar que solo los dispositivos de los extremos tienen las claves de descifrado. No protege frente a un dispositivo comprometido, no oculta los metadatos y su fuerza depende de la calidad de la implementación.
Las vías más realistas son un malware en el dispositivo de un participante que lee el contenido tras el descifrado, un ataque de intermediario (MITM) al intercambio de claves que sustituye las claves legítimas por las del atacante, fallos de implementación como una generación de claves débil o una reserva hacia modos de cifrado más flojos, y la ingeniería social que engaña a un usuario legítimo para dar acceso a la sesión a un atacante. El algoritmo de cifrado en sí no es un objetivo realista.
No con la informática clásica actual. Reventar por fuerza bruta una clave AES, sean las de 128 bits usadas para los medios en tiempo real o las de 256 bits para los datos de vida más larga, es inviable en cómputo en cualquier escala de tiempo práctica. La computación cuántica puede acabar reduciendo la fuerza efectiva de los cifrados simétricos, y por eso el NIST publicó sus primeros estándares de criptografía poscuántica en 2024 y las organizaciones están ahora con la migración. Eso sigue siendo un horizonte de planificación, no una amenaza presente. AES, en ambas longitudes de clave, sigue siendo el estándar del cifrado simétrico fuerte.
No. El E2EE protege el contenido entre dispositivos. Una vez descifrado el contenido en un dispositivo, queda accesible para cualquier cosa que corra en él, incluido el malware. La seguridad del extremo, como mantener los dispositivos parcheados o usar software de seguridad de confianza, es un requisito previo para que el E2EE dé una protección real.
El método más fiable es la verificación fuera de banda del código de seguridad que genera un sistema E2EE bien diseñado a partir de las claves compartidas. Si los dos participantes ven el mismo código, el intercambio de claves no ha sido manipulado. Si los códigos difieren, la sesión puede haber sido interceptada. Este paso debería formar parte de la práctica habitual en las llamadas sensibles. Más allá de eso, busca plataformas con auditorías criptográficas publicadas y prácticas de gestión de claves documentadas.
Al activar el E2EE, los medios se cifran de extremo a extremo y el servidor deja de tener claves utilizables, así que solo reenvía texto cifrado. A cambio, pierdes las funciones que necesitan que el servidor lea el contenido: la grabación en el servidor, la transcripción automática y el archivado para cumplimiento que dependa de la captura en el servidor dejan de estar disponibles. Por eso conviene decidir por política, y no por accidente, en qué sesiones activarlo.
No. Los metadatos, la información sobre quién llamó a quién, cuándo, cuánto tiempo y desde qué cuentas, suelen ser visibles para el proveedor del servicio y pueden aparecer en un análisis del tráfico a nivel de red, aun cuando el contenido de la llamada esté cifrado. El E2EE protege la carga útil; no protege la información de enrutamiento y de sesión que la infraestructura necesita para funcionar. Los casos de alta sensibilidad pueden necesitar controles adicionales para la exposición de metadatos.