Una copia del disco, el control activo del servidor y el acceso al teléfono son tres escenarios distintos; una garantía general no basta para los tres.
Si se toma el control de un servidor de mensajería, la respuesta precisa a «¿qué queda expuesto?» depende de los datos almacenados, de dónde estén las claves y del tipo de acceso del atacante. Obtener una copia del disco no equivale a controlar en vivo el servicio y la vía de distribución de la aplicación.
Este artículo examina un escenario hipotético a partir de la documentación pública de Livara. No afirma dónde están sus centros de datos, que se haya producido una incautación ni que el servicio tenga garantizado su funcionamiento durante un corte de internet. El cifrado del contenido, la disponibilidad de la red y la seguridad de la infraestructura son cuestiones distintas.
Primero, identifiquemos el tipo de acceso
Una copia almacenada del servidor: El atacante accede a los archivos, bases de datos o copias de seguridad presentes en esa copia. Si el contenido privado se ha cifrado correctamente en el dispositivo y el servidor no dispone de la clave para descifrarlo, tener esa copia por sí sola no revela el texto de la conversación.
Control activo del servicio: Además de leer los datos existentes, el atacante puede bloquear algunas solicitudes, devolver datos antiguos o modificar el comportamiento de los componentes que controla. La verificación de la identidad del contacto, el control de versiones y la integridad del cliente cobran más importancia en este escenario.
Acceso simultáneo al dispositivo: Un teléfono desbloqueado, malware o una copia legible en manos de un miembro de la conversación pueden exponer el contenido por una vía completamente diferente. El modelo de amenazas de Livara tampoco garantiza la protección de un dispositivo desbloqueado o infectado.
¿Qué datos son visibles en el servidor según la documentación de Livara?
La página de seguridad de Livara, identificada como versión 0.1.68, separa el contenido de los chats directos bajo LVR1 y de los grupos privados compatibles bajo LGS1 de la información operativa. Esa misma página indica que un grupo antiguo incompatible queda explícitamente fuera del E2EE; por tanto, hay que comprobar el estado de la conversación concreta.
| Categoría de datos | Límite documentado y posible consecuencia |
|---|---|
| Texto y archivos adjuntos de una conversación protegida | El servidor conserva una copia cifrada; leerla exige la clave adecuada |
| Metadatos de comunicación | El servicio dispone de información como participantes, hora, tamaño y estado de entrega |
| Pertenencia a grupos | Forma parte de la información y la autoridad operativas del servidor |
| Canal público | El contenido es público y legible por el servidor |
| Paquete de recuperación de identidad v7 | Se cifra antes de subirlo y requiere un secreto de recuperación independiente |
| Modo opcional de grabación en el servidor | El indicador REC lo distingue del modo E2EE; no debe suponerse privacidad de extremo a extremo para él |
La documentación menciona código LSS1 para proteger los metadatos, pero no está conectado al envío normal de mensajes. Que el nombre de un protocolo figure en un proyecto no demuestra que esté activo en todas las comunicaciones.
Esta tabla describe afirmaciones del producto, no los resultados de una prueba de incautación real ni de una auditoría independiente de todas las versiones de la base de datos.
¿Qué importancia pueden tener los metadatos?
La información sobre las comunicaciones entre personas, los horarios y la pertenencia a grupos puede ser sensible incluso sin el texto de los mensajes. Sin embargo, decir «todo el grafo de comunicaciones queda expuesto para siempre» no es preciso sin conocer los plazos de conservación, la cobertura de los registros y la versión de los datos obtenidos.
Una evaluación real debe preguntar qué campos se recopilaron, cuánto tiempo se conservaron y qué copias de seguridad están disponibles. El cifrado del contenido no define por sí solo la política de conservación de datos. Tampoco puede deducirse de la arquitectura de un servicio de mensajería que todos conserven necesariamente los mismos metadatos.
¿Qué riesgo supone controlar el servidor para los mensajes futuros?
Una evaluación de seguridad debe probar por separado la manipulación de la lista de miembros, la entrega de una clave de identidad diferente, el bloqueo de actualizaciones y la distribución de un cliente malicioso. El efecto de cada caso depende de la validación en el cliente, de cómo se muestran los cambios y de la verificación de identidad.
Sin probar la implementación, no puede afirmarse que cualquier servidor comprometido pueda necesariamente añadir un miembro oculto; del mismo modo, tampoco puede afirmarse que el control activo del servidor no tenga efecto alguno. En conversaciones sensibles deben investigarse los cambios inesperados de identidad o de miembros. Comparar las huellas de las claves con el contacto por una vía independiente y de confianza aporta más información que fiarse únicamente de un nombre visible.
Si el atacante cambia el código que se ejecuta en el dispositivo, podría ver el texto antes de cifrarse. Por eso la seguridad de la distribución y las actualizaciones de la aplicación forma parte de este escenario, en lugar de ser una cuestión ajena al cifrado.
¿Qué aporta el carácter poscuántico?
El estándar NIST FIPS 203 para ML-KEM ayuda a establecer un secreto compartido. Su uso correcto en una construcción híbrida puede reducir el riesgo de ciertos ataques futuros contra el intercambio de claves. Esto no sustituye la seguridad del dispositivo, la conservación limitada de metadatos ni los controles de acceso al servidor.
Proof Lab también muestra únicamente determinadas operaciones locales de P-256, HKDF y AES-GCM, y deja fuera de esa prueba la composición completa LVR1/LGS1. Un resultado satisfactorio no garantiza la resistencia de todo el producto ante una toma de la infraestructura.
¿Qué hacer en una evaluación o un incidente reales?
- Registre el tipo de acceso y la información confirmada; no equipare los rumores de interrupciones a un incidente de seguridad confirmado.
- Compruebe la versión de la aplicación y el estado de cifrado de esa conversación concreta.
- Investigue por canales oficiales los cambios de identidad, los miembros del grupo y las sesiones desconocidas.
- No entregue secretos de recuperación, contraseñas ni contenido privado a desconocidos para una «revisión de seguridad».
- Ante un riesgo grave o una cuestión jurídica, recurra al especialista adecuado y no tome medidas irreversibles basándose en un artículo.
Una conclusión fiable debe indicar qué datos están protegidos, en qué versión y frente a qué tipo de acceso. «Aunque se incaute el servidor, no pasa nada» no sustituye esa respuesta.
