¿WhatsApp es realmente seguro? El problema de los extremos que no controlas
Serie sobre WhatsApp, 2/2. En el primer artículo conté cómo estuve a punto de perder once años de mensajes por una copia de seguridad que WhatsApp no sabía restaurar. Cuando pedí la clave de mi propio fichero, el soporte me contestó con la publicidad del cifrado de extremo a extremo: «nadie más, ni siquiera WhatsApp» puede leer tus mensajes. De esa frase trata este artículo.
TL;DR — No tengo tiempo para leer un texto tan largo en este momento
WhatsApp repite que nuestras conversaciones están protegidas mediante "cifrado de extremo a extremo" y que, por tanto, "ni siquiera WhatsApp" puede leerlas.
El cifrado de extremo a extremo es real y es una protección muy importante. Pero esa afirmación esconde una condición fundamental:
el cifrado protege la comunicación entre los extremos, pero no garantiza que los extremos mismos sean fiables.
Y "el extremo" no eres exactamente tú. Es el programa que se ejecuta en tu teléfono o en tu ordenador.
Si el proveedor controla ese programa, puede actualizarlo, puede decidir qué versiones siguen funcionando con su servicio y tú no puedes auditar independientemente el binario que ejecutas, entonces sigues necesitando confiar en el proveedor.
La tesis de este artículo es, por tanto:
Ningún sistema E2EE puede proporcionar una garantía fuerte contra el propio proveedor si el usuario no puede saber exactamente qué código ejecutan los extremos, verificarlo y, en el modelo más exigente, compilarlo y controlar cuándo lo actualiza.
Esto no demuestra que WhatsApp espíe nuestros mensajes ni que exista una puerta trasera para gobiernos o servicios de inteligencia.
Demuestra algo más modesto pero importante:
No podemos convertir la afirmación "WhatsApp dice que no puede leerlos" en la propiedad técnica "WhatsApp no podría hacer que nuestro endpoint los entregara".
La diferencia es entre confianza y verificación.
"Ni siquiera WhatsApp puede leer tus mensajes"
Una de las principales promesas de privacidad de WhatsApp es el cifrado de extremo a extremo, habitualmente abreviado E2EE, del inglés "end-to-end encryption".
El principio es excelente.
Cuando Alicia envía un mensaje a Bernardo, el mensaje debería cifrarse en el dispositivo de Alicia y no descifrarse hasta que llega a un dispositivo autorizado de Bernardo.
Simplificando:
Figura 1
Esto protege contra amenazas muy importantes.
Una persona que intercepte el tráfico no debería poder leerlo. Una intrusión en determinados servidores tampoco debería proporcionar directamente el contenido de todas las conversaciones. Y el servidor que transporta los mensajes no necesita conocer el plaintext.
WhatsApp afirma, además, en su política de privacidad que los mensajes entregados se borran de sus servidores y que los pendientes de entrega se mantienen, cifrados, durante un máximo de 30 días.
Todo esto es una mejora de seguridad enorme.
El problema empieza cuando transformamos esta afirmación:
"Los servidores de WhatsApp no disponen normalmente del contenido ni de las claves necesarias para descifrarlo."
en esta otra:
"WhatsApp no podría obtener mis conversaciones."
No es exactamente la misma afirmación.
¿Qué es realmente "el extremo"?
En nuestra imaginación, E2EE significa:
yo <====================> tú
E2EEPero, técnicamente, se parece más a:
Figura 2
El cifrado no empieza directamente en mi cerebro ni acaba directamente en el tuyo.
Empieza y acaba en programas.
Por tanto, después de preguntar:
"¿Está cifrada la comunicación?"
deberíamos preguntar inmediatamente:
"¿Quién controla el programa que constituye cada extremo?"
Esa segunda pregunta es la que desaparece casi siempre de la publicidad sobre E2EE.
En algún momento el mensaje tiene que estar en claro
Hay una limitación inevitable.
Si yo puedo leer un mensaje en la pantalla, mi dispositivo ha tenido que descifrarlo.
Por tanto, en algún momento tenemos:
Figura 3
La criptografía ha terminado su trabajo.
A partir de ese momento la seguridad depende del endpoint.
Y eso significa que una aplicación hipotéticamente maliciosa no necesitaría romper el protocolo criptográfico.
No necesitaría descubrir una clave mediante fuerza bruta.
No necesitaría atacar matemáticamente el Signal Protocol.
Conceptualmente, bastaría con que hiciera:
decrypt(message)
display(message)y, además:
send_copy(message)Es decir:
Figura 4
El protocolo E2EE podría seguir siendo impecable.
El servidor podría seguir sin saber descifrar el ciphertext.
Las claves podrían incluso seguir sin abandonar formalmente el dispositivo.
Pero el plaintext ya ha sido obtenido por la aplicación.
No se ha atacado el cifrado. Se ha atacado el extremo.
¿Y si el propio proveedor controla el extremo?
Aquí aparece el conflicto conceptual interesante de WhatsApp.
WhatsApp nos dice:
"Nuestro servidor no puede descifrar tus mensajes."
Pero es el mismo proveedor quien distribuye el programa que:
- genera o gestiona las claves;
- recibe los mensajes;
- los descifra;
- accede a su contenido;
- consulta la base de datos local;
- muestra las conversaciones;
- y se comunica con sus servidores.
Por tanto:
Figura 5
El E2EE impide que el servidor ataque directamente el canal criptográfico.
Pero no garantiza por sí mismo qué hará mañana el software que llega a uno de los extremos.
"Pero la aplicación está firmada"
Sí.
Y eso es muy importante contra un adversario distinto.
La firma criptográfica de una aplicación ayuda a impedir que un desconocido cree un APK modificado y lo haga pasar fácilmente por una actualización legítima de WhatsApp.
Pero la firma responde aproximadamente a:
"¿Proviene este software de la cadena autorizada?"
No responde a:
"¿Hace este software exactamente lo mismo que hacía la versión anterior?"
Si es el mismo desarrollador autorizado quien publica una nueva versión, el nuevo programa seguirá estando perfectamente firmado.
Figura 6
Firma y confianza funcional son conceptos diferentes.
"Pues no actualizo WhatsApp"
A primera vista podría parecer una solución.
Si confío en la versión 2.X y no quiero que nadie me la cambie, desactivo las actualizaciones.
El problema es que eso solo te da un control parcial.
Puedes impedir temporalmente que Google Play instale automáticamente una versión nueva, pero no controlas el servidor ni el protocolo de WhatsApp.
El proveedor puede modificar:
- los protocolos aceptados;
- las versiones mínimas compatibles;
- los requisitos de registro;
- las funcionalidades que necesitan soporte del servidor.
Por tanto, no tienes garantizada la posibilidad de utilizar indefinidamente una versión antigua que tú has decidido congelar.
Esa diferencia es esencial:
"Puedo desactivar las actualizaciones automáticas" no equivale a "controlo qué versión del cliente seguirá siendo funcional".
En un sistema realmente bajo tu control podrías decidir:
Figura 7
En un servicio centralizado, el servidor mantiene siempre la última palabra sobre qué sigue siendo interoperable.
¿Podrían enviar una versión especial solo a una persona?
Es una posibilidad que requiere matices.
Google Play dispone de "staged rollouts", es decir, despliegues graduales donde una versión nueva llega inicialmente solo a un porcentaje de los usuarios.
Pero según la documentación de Google, en los despliegues graduales ordinarios los usuarios se eligen al azar dentro del porcentaje correspondiente. No sería correcto, por tanto, decir que el sistema normal de Play permite simplemente ordenar:
"Instala este APK especial exactamente en el número de teléfono X."
Pero eso no resuelve el problema general.
Un programa puede contener funcionalidades cuyo comportamiento cambie según información proporcionada por el servidor:
- "feature flags";
- configuración remota;
- experimentos A/B;
- activaciones graduales;
- parámetros asociados a la cuenta.
Figura 8
Naturalmente, una configuración remota solo puede activar funcionalidad que el programa ya sea capaz de ejecutar.
Y no tenemos evidencia de que WhatsApp contenga un mecanismo destinado a exfiltrar secretamente conversaciones.
No es eso lo que estoy afirmando.
El punto es otro:
Auditar el protocolo E2EE no nos dice automáticamente todo lo que puede hacer el cliente.
Tampoco haría falta robar la clave de la base de datos
A veces imaginamos un ataque complicadísimo:
- robar la base de datos local;
- extraer su clave;
- enviarla al servidor;
- descifrar allí las conversaciones.
Pero una hipotética versión maliciosa del cliente probablemente tendría una opción mucho más sencilla.
La aplicación legítima ya necesita leer sus propios datos.
Si WhatsApp puede mostrarte una conversación de hace seis meses, alguna parte del cliente tiene acceso a esa información en una forma utilizable.
Por tanto:
Figura 9
El cifrado "en reposo" es muy útil contra otros programas, contra determinados accesos físicos o contra la copia directa de los ficheros.
Pero no protege los datos contra el propio programa que legítimamente necesita descifrarlos.
Y, en el caso de WhatsApp, la clave de la copia de seguridad normal ni siquiera es solo del móvil: como cuento en el primer artículo, la guarda WhatsApp en sus servidores y la entrega a cualquier móvil que verifique el número. A la aplicación, sí. Al usuario, no.
Y ni siquiera haría falta enviarlo todo
Un hipotético ataque dirigido tampoco necesitaría transferir 30 GB de fotografías, vídeos y audios.
El texto es muy barato.
Se podría seleccionar, en abstracto:
- los últimos mensajes;
- una conversación concreta;
- solo texto;
- mensajes a partir de una fecha;
- datos de un determinado interlocutor;
- determinados metadatos.
Esto importa porque un hipotético ataque de endpoint bien delimitado podría generar muy poco tráfico respecto del tráfico ordinario de una aplicación de mensajería.
WhatsApp Web multiplica los extremos
La situación es todavía más interesante desde que WhatsApp dispone de una arquitectura multidispositivo real.
WhatsApp Web ya no es simplemente una pantalla que depende permanentemente del teléfono principal.
En la arquitectura multidispositivo, cada dispositivo vinculado tiene su propia clave de identidad y mantiene sesiones E2EE independientes. Cuando se vincula un dispositivo, el móvil principal le envía cifrada una parte del historial reciente, y después el dispositivo mantiene su propia base de datos local.
Por tanto:
Figura 10
Esto es muy cómodo.
Pero desde el punto de vista del modelo de amenaza significa que ya no tenemos necesariamente un único endpoint.
Tenemos varios dispositivos con:
- claves o estado criptográfico propio;
- datos locales;
- credenciales;
- capacidad de recibir y descifrar mensajes.
Por eso WhatsApp permite consultar los dispositivos vinculados y eliminar sesiones.
La lección general es:
El E2EE reduce mucho la confianza necesaria en el servidor, pero cada dispositivo autorizado se convierte en un nuevo lugar donde el contenido existe en claro.
"Pero WhatsApp dice que no puede dar los mensajes ni a la policía"
Y efectivamente WhatsApp presenta públicamente esa posición.
Pero tiene una puerta reservada a las autoridades. Literalmente: el Law Enforcement Online Request System de WhatsApp es un portal donde solo pueden entrar agentes de las fuerzas del orden para pedir datos en el marco de una investigación oficial o de una emergencia. Meta tiene otro equivalente para Facebook e Instagram.
Tiene su gracia: hay una ventanilla exclusiva para pedir información a una empresa que dice que no tiene la información. No es una contradicción, porque lo que entrega son datos de la cuenta y metadatos, no las conversaciones. Pero ilustra bien que «no tenemos tus mensajes» no quiere decir «no tenemos nada».
El funcionamiento lo explican ellas mismas:
- La página de WhatsApp para las fuerzas del orden: dentro de una investigación penal oficial, WhatsApp preserva los datos de una cuenta durante 90 días mientras llega el requerimiento judicial formal.
- Las pautas de Meta distinguen tres tipos de petición: de preservación (90 días), de emergencia (daño inminente a un menor o riesgo de muerte o de lesiones graves, por el mismo portal) y de registros, que exigen el procedimiento legal correspondiente.
Y el volumen no es anecdótico. En noviembre de 2024, en el caso Shabana v. Govt of NCT of Delhi, el Tribunal Superior de Delhi recogió lo que la propia Meta le explicó. Su sistema de peticiones (LEORS) recibió más de cien mil solicitudes de datos en un año (2023), y las de emergencia las responde en cuestión de minutos: 18 o 30, en casos de menores desaparecidos. WhatsApp también recibe «un número sustancial» de peticiones ordinarias y de emergencia. Incluso ha llegado a entregar información sobre actividad terrorista 12 minutos después de recibir la petición. Lo que entregan, según el tribunal, es la información básica del suscriptor: nombre, correo, teléfono y fecha de registro.
En Europa, el informe SIRIUS de 2024 de Eurojust y Europol cuenta a WhatsApp, aparte de Meta, entre los proveedores que tienen portal propio para las peticiones policiales.
Esto no tiene nada de extraordinario: las grandes empresas tecnológicas disponen habitualmente de procedimientos para responder a requerimientos legales.
Según el modelo público de WhatsApp, lo que pueden proporcionar depende de los datos que efectivamente poseen.
La cuestión interesante para este artículo es otra.
Podemos distinguir:
A) "WhatsApp afirma que sus servidores no pueden
desxifrar las conversaciones E2EE."
B) "Podemos verificar independientemente que ningún
cliente controlado por WhatsApp podría obtener el plaintext."A no implica automáticamente B.
¿Nos lo tenemos que creer?
Aquí es importante no confundir escepticismo con acusación.
No tengo evidencia de que WhatsApp distribuya versiones especiales destinadas a permitir que una agencia de inteligencia lea conversaciones.
Por tanto, sería irresponsable afirmar que lo hace.
Pero tampoco es razonable convertir:
"No tenemos pruebas de que lo haga"
en:
"Está técnicamente demostrado que no podría hacerlo."
Son tres grados epistemológicos distintos:
Figura 11
Una buena arquitectura de seguridad intenta avanzar tanto como sea posible de la confianza hacia la garantía verificable.
No porque cualquier empresa sea necesariamente maliciosa.
Sino porque un sistema seguro intenta minimizar las cosas que tenemos que creer por pura confianza.
Aquí aparece la diferencia entre "seguro" y "verificable"
WhatsApp puede ser extraordinariamente seguro contra muchos adversarios.
Por ejemplo:
- alguien que escucha una red Wi-Fi;
- un operador de telecomunicaciones;
- un atacante que captura tráfico;
- una intrusión determinada en infraestructura de servidor;
- determinados administradores internos.
El problema de este artículo es mucho más específico:
¿Qué garantía tenemos contra el propio proveedor que controla nuestro endpoint?
Y aquí la situación es diferente.
Podemos resumirlo:
| Propiedad | E2EE | Cliente auditable y verificable |
|---|---|---|
| Protege el tráfico contra intercepción | Sí | No es su función principal |
| Evita que el servidor descifre directamente | Sí | No es su función principal |
| Demuestra qué hace el cliente con el plaintext | No | Puede hacerlo |
| Permite comprobar el código ejecutado | No necesariamente | Sí, con compilaciones reproducibles |
| Permite compilar personalmente el endpoint | No necesariamente | Sí |
| Reduce la confianza necesaria en el proveedor | Parcialmente | Mucho más |
Signal: código público y compilaciones reproducibles
Signal ofrece un buen ejemplo de un modelo más verificable.
El cliente Android tiene el código público y soporta compilaciones reproducibles.
Las instrucciones oficiales explican cómo:
- obtener exactamente el código correspondiente a una versión;
- reproducir el entorno de compilación;
- compilarlo;
- extraer los APK instalados en el dispositivo;
- compararlos.
El objetivo declarado es precisamente verificar que la versión descargada de Google Play corresponde al código fuente publicado.
Esto es una diferencia enorme.
No hace falta que cada usuario de Signal sea programador.
El hecho de que cualquier investigador independiente pueda comprobarlo ya hace mucho más difícil distribuir masivamente un binario que no corresponda a las fuentes públicas.
Ahora bien, incluso eso tiene un límite importante.
Si tu modelo de amenaza incluye un ataque extraordinariamente selectivo solo contra ti, lo más fuerte sería verificar tu propio APK instalado.
La escala sería:
Figura 12
Cada paso elimina una parte de la confianza ciega.
Delta Chat: todavía otra manera de separar confianza
Delta Chat es software libre.
En Android hay, además, un caso interesante cuando se instala desde F-Droid: la ficha de F-Droid indica que cada versión es compilada y firmada por el propio F-Droid y que está garantizado que corresponde al paquete de fuentes publicado.
Eso introduce una separación:
Figura 13
No elimina toda confianza.
Tienes que confiar también en F-Droid, en su infraestructura, en Android, etc.
Pero evita al menos el modelo más simple de:
"La misma empresa escribe el código, compila un binario opaco y me entrega exactamente aquello que ella quiere."
Telegram: una comparación especialmente interesante
Telegram necesita una distinción importante.
Sus chats en la nube no son E2EE. Según las preguntas frecuentes de Telegram, usan cifrado cliente-servidor y se guardan cifrados en la nube de Telegram para que estén disponibles en todos los dispositivos.
Los chats secretos, en cambio, sí que utilizan cifrado de extremo a extremo.
Por tanto, Telegram no es "más privado" que WhatsApp por defecto.
Pero es interesante para la cuestión que nos ocupa porque sus clientes son de código público y Telegram publica instrucciones para verificar que las versiones de la App Store y de Google Play corresponden al código publicado.
Además, TDLib permite construir clientes propios, y también soporta los chats secretos.
Eso posibilita un modelo como:
Figura 14
Telegram podría cambiar el protocolo.
Podría acabar rechazando tu cliente.
Podría dejar de darte servicio.
Pero si tú controlas el ejecutable que estás ejecutando, el servidor no puede simplemente reescribirlo remotamente para que haga otra cosa.
Es una diferencia importante.
El E2EE también es muy conveniente para WhatsApp
Hay otro aspecto que raramente se comenta.
La narrativa habitual presenta el E2EE como si fuera una concesión que la empresa hace exclusivamente en beneficio del usuario.
Pero una arquitectura en la que el proveedor no conserva normalmente una copia legible de todas las conversaciones también es extraordinariamente beneficiosa para el proveedor.
Como hemos visto, WhatsApp dice que los mensajes entregados se eliminan de sus servidores y que los pendientes se conservan temporalmente en forma cifrada.
Eso tiene consecuencias empresariales muy favorables:
Figura 15
Esto no demuestra que WhatsApp adoptara el E2EE por esos motivos.
No podemos atribuirle esa intención.
Pero las ventajas objetivas existen.
"Esa información no la tenemos" es una posición muy cómoda
Imaginemos que una editorial descubre que determinados usuarios se envían libros pirateados por WhatsApp.
O que una autoridad quiere conocer el contenido de una conversación antigua.
Si WhatsApp realmente no conserva ese contenido y la arquitectura normal impide al servidor descifrarlo, puede responder:
"Esa información no la tenemos."
Es una buena noticia para la privacidad.
Pero es también una situación muy conveniente para el proveedor.
No necesita:
- decidir sistemáticamente qué es legal dentro de cada conversación privada;
- mantener sistemas que inspeccionen todos los ficheros;
- conservar durante años el contenido;
- responder a cada petición entregando datos que ya no posee;
- custodiar una base de datos central extraordinariamente comprometedora.
No utilizaría aquí la palabra "denegabilidad", porque tiene significados técnicos específicos en criptografía y podría confundir.
Hablaría más bien de no-custodia del contenido.
La misma característica que dice:
"WhatsApp no puede verlo"
también dice:
"WhatsApp no tiene que custodiarlo."
Y, como comprobé en mis propias carnes, también permite decir: «no podemos ayudarte a restaurar tus chats».
Pero WhatsApp no es ciego
Tampoco deberíamos ir al otro extremo.
Que el contenido de una conversación sea E2EE no significa que WhatsApp no disponga de información relacionada con el uso del servicio.
Su política de privacidad describe, entre otras cosas:
- información de la cuenta;
- información del dispositivo y la conexión;
- registros y diagnóstico;
- información necesaria para operar el servicio.
También dice que conserva información relacionada con la transmisión, como el número, la fecha y la hora de un mensaje o la duración de una llamada, mientras haga falta para transmitir la comunicación, operar el servicio o cumplir obligaciones legales.
Por tanto:
Figura 16
"E2EE" no significa "WhatsApp no sabe nada sobre mí".
Significa una propiedad específica sobre el contenido.
El proveedor puede entregar los datos que efectivamente posee. Lo que no debería poder entregar, según la arquitectura publicada, es el plaintext de una conversación E2EE que no conserva.
La pregunta de este artículo sigue siendo, sin embargo:
¿Es esa incapacidad una propiedad que nosotros podemos verificar independientemente en el endpoint, o una propiedad que depende también de confiar en el cliente que WhatsApp nos proporciona?
Y ahí volvemos al principio.
No es lo mismo "no lo hacen" que "no pueden hacerlo"
Esta es probablemente la distinción más importante de todo el artículo.
Podemos tener tres situaciones:
1. El proveedor dice que no lo hace
Es una afirmación.
2. No tenemos evidencia de que lo haga
Es una observación sobre lo que sabemos.
3. El sistema está construido de manera que nosotros mismos podemos verificar que no puede hacerlo silenciosamente
Eso es una garantía técnica mucho más fuerte.
Figura 17
El software libre no es mágicamente seguro.
Una compilación propia tampoco es mágicamente segura.
Pero cada capa de verificabilidad reduce el número de afirmaciones que necesitamos aceptar porque sí.
Ni siquiera compilarlo personalmente elimina toda confianza
Podríamos seguir bajando indefinidamente.
Si compilo la aplicación yo mismo, sigo confiando en:
- las fuentes;
- el compilador;
- las dependencias;
- el sistema operativo;
- el kernel;
- el firmware;
- el hardware.
Figura 18
No existe la confianza cero.
La pregunta útil es:
¿Cuánta confianza puedo sustituir por verificación?
Y en ese sentido no todos los sistemas son equivalentes.
¿Entonces WhatsApp es inseguro?
Esta pregunta está mal formulada.
Hay que preguntar:
¿Inseguro contra quién?
WhatsApp con E2EE puede ser muy seguro contra una persona que capture el tráfico de la red.
Puede ser muy seguro contra un operador de telecomunicaciones curioso.
Puede proteger extraordinariamente bien contra una intrusión determinada en un servidor.
Pero si tu modelo de amenaza incluye:
"No quiero tener que confiar en el propio proveedor del servicio"
entonces el control del cliente pasa a ser fundamental.
Y el E2EE, por sí solo, ya no es suficiente.
¿Y por qué sigo utilizando Telegram para cosas poco sensibles?
Precisamente porque la seguridad no existe en el vacío.
Depende de lo que intentes proteger.
Telegram me permite:
- tener todo el historial sincronizado;
- utilizar muchos dispositivos con facilidad;
- recuperar inmediatamente las conversaciones;
- almacenar una enorme cantidad de datos en la nube;
- acceder a ellos independientemente del dispositivo concreto.
Los chats en la nube de Telegram no son E2EE, y Telegram lo explica abiertamente: los guarda en su nube para que sean accesibles desde cualquier dispositivo.
Pero para hablar de:
- gramática;
- esperanto;
- clases;
- una afición;
- una reunión;
- una actividad social ordinaria;
puedo llegar perfectamente a la conclusión de que esas propiedades son más valiosas para mí que eliminar un riesgo que, para esa información concreta, considero poco relevante.
Eso no significa que Telegram sea más seguro.
Significa aplicar un modelo de amenaza proporcional.
Para una conversación altamente sensible, elegiría unas garantías diferentes.
Para discutir si el acusativo en esperanto toca o no toca después de una determinada construcción, probablemente no.
¿Qué debería exigir un sistema con garantías muy fuertes?
Si realmente quisiéramos reducir al máximo la confianza en el proveedor, buscaríamos al menos:
- un protocolo criptográfico público y auditable;
- código completo del cliente público;
- compilaciones reproducibles;
- posibilidad de comparar nuestro binario con las fuentes;
- posibilidad de compilar el cliente nosotros mismos;
- capacidad de controlar cuándo actualizamos;
- posibilidad de utilizar implementaciones alternativas;
- mecanismos de transparencia contra tratamientos selectivos;
- minimización de metadatos;
- un sistema operativo y una cadena de compilación también razonablemente verificables.
No todos los sistemas populares cumplen todo eso.
Pero hay una diferencia cualitativa entre:
"El fabricante me asegura que no puede hacerlo."
y:
"La construcción del sistema me permite comprobar independientemente que no puede hacerlo de la manera que estamos considerando."
La pregunta correcta: ¿de quién son los extremos?
Cuando aparece el conocido candado de WhatsApp, la pregunta habitual es:
"¿Está cifrada la conversación?"
Sí.
Es una pregunta importante.
Pero inmediatamente deberíamos hacer otra:
"¿De quién son los extremos?"
Porque la representación correcta no es:
yo <============= E2EE =============> túsino:
Figura 19
El E2EE protege magníficamente el tramo entre B y C.
Pero no certifica ni B ni C.
Y si B y C son programas que el mismo proveedor puede desarrollar, distribuir y modificar, la confianza en ese proveedor no ha desaparecido.
Simplemente se ha trasladado.
Conclusión
El cifrado de extremo a extremo de WhatsApp no es falso ni inútil.
Al contrario: es una medida de seguridad importantísima.
El problema es convertir una propiedad concreta:
"nuestros servidores no necesitan poder descifrar los mensajes"
en una afirmación absoluta:
"nosotros no podríamos obtener nunca los mensajes".
Eso exigiría confiar también en el comportamiento de los endpoints.
Y los endpoints son software.
Software que alguien escribe.
Software que alguien compila.
Software que alguien distribuye.
Software que alguien actualiza.
Software que, finalmente, tiene el plaintext delante.
Por eso, ante cualquier aplicación que presuma de E2EE, yo ya no me conformaría con preguntar:
"¿Está cifrado de extremo a extremo?"
Preguntaría también:
"¿Puedo leer el código de los extremos?"
"¿Puedo demostrar que el binario instalado corresponde a ese código?"
"¿Puedo compilarlo yo mismo?"
"¿Puedo decidir cuándo cambio de versión?"
"¿Puedo seguir utilizando esa versión sin que el proveedor me obligue a sustituirla?"
"¿Puede el servidor modificar selectivamente el comportamiento de mi endpoint?"
Y sobre todo:
"¿El extremo es realmente mío, o sigue estando bajo el control del proveedor?"
El candado del E2EE nos dice que el trayecto entre los extremos está protegido.
No nos dice, por sí solo, en quién tenemos que confiar cuando llegamos a los extremos.