El resultado forense depende del estado real del dispositivo y las claves, no solo del nombre de una base de datos o algoritmo.
El cifrado de extremo a extremo y la protección de datos locales son cuestiones relacionadas, pero distintas. Un mensaje protegido durante su tránsito por la red debe hacerse legible para mostrarse en un dispositivo. El resultado de un análisis forense depende del estado del dispositivo, el tipo de acceso, las versiones del sistema y la aplicación y la ubicación de las claves; ningún nombre de algoritmo determina por sí solo el resultado.
Por tanto, tanto afirmar que «con acceso físico se lee todo de inmediato» como prometer que «la extracción nunca es posible» exige cautela.
Examina por separado cuatro capas de protección
| Capa | Función principal | Limitación importante |
|---|---|---|
| E2EE de mensajes | Proteger el contenido entre los dispositivos de los participantes | No garantiza la integridad del dispositivo ni la protección de las copias locales |
| Aislamiento de aplicaciones | Limitar el acceso de aplicaciones normales a los datos de otras | Un acceso elevado o una vulnerabilidad pueden cambiar el modelo |
| Cifrado de archivos o disco | Proteger los datos almacenados bajo condiciones específicas | Importan el estado de bloqueo y la disponibilidad de las claves |
| Cifrado de la base de datos en la aplicación | Añadir un límite de protección al archivo de la base de datos | Es decisivo cómo se guarda y utiliza la clave |
La documentación FBE de Android distingue el almacenamiento dependiente de las credenciales del usuario del disponible durante Direct Boot. «El teléfono está bloqueado» no revela por sí solo el estado de todas las claves; también puede importar si ya se produjo el primer desbloqueo tras el arranque.
¿Qué demuestra un archivo SQLite?
SQLite es un formato y motor de almacenamiento, no una etiqueta que indique por sí sola la presencia o ausencia de todas las protecciones. El archivo puede encontrarse en un espacio cifrado por el sistema operativo o estar protegido mediante otra solución.
Eliminar una fila tampoco borra necesariamente todos sus rastros de todos los archivos. La documentación de SQLite explica los ajustes de borrado seguro y las limitaciones de las tablas virtuales. Los archivos auxiliares y las copias de seguridad también deben incluirse al examinar el ciclo de vida de los datos. Esto no garantiza que se pueda recuperar todo mensaje eliminado en cualquier teléfono.
No ejecutes órdenes de mantenimiento de bases de datos sobre datos reales sin conocer la aplicación; modificar directamente sus archivos puede dañar los datos o alterar las pruebas.
SQLCipher y Keystore son soluciones, no certificados de inmunidad
SQLCipher está diseñado para el cifrado transparente de bases de datos, pero sus especificaciones deben leerse según la versión. La página de diseño de SQLCipher describe una estructura AES-CBC con autenticación; la presentación de la versión 5 beta en septiembre de 2026 describe el cambio a AES-GCM. Atribuir un único modo de cifrado a todas las versiones es, por tanto, inexacto.
Android Keystore también puede proteger las claves y controlar su uso, pero es necesario determinar qué funciones y nivel de seguridad del hardware utiliza realmente la aplicación. Mencionar StrongBox en un artículo no demuestra que un producto lo use. Consulta la guía de Keystore.
Incluso una clave no extraíble puede, en ciertas condiciones, utilizarse mediante operaciones autorizadas. «No se puede copiar la clave» no equivale a «el atacante no puede descifrar ningún dato».
¿Qué papel tienen la RAM y el ratchet?
Limitar la duración de las claves y del texto sensible reduce las oportunidades de exposición. Pero limpiar un búfer no demuestra que no quede otra copia en una biblioteca, una vista previa o el proceso de visualización.
El alcance del ratchet también varía según el tipo de clave comprometida y la continuidad del acceso del atacante. «Una clave distinta para cada mensaje» no implica que una captura de memoria exponga como máximo un mensaje. Guardar un historial legible en el dispositivo es una cuestión distinta de las claves de transporte.
¿Qué no se ha verificado sobre Livara?
El modelo de amenazas de Livara no garantiza protección en un dispositivo infectado o desbloqueado. Este artículo no verifica de forma independiente que una versión concreta de Livara use SQLCipher o StrongBox, limpie toda la RAM o no almacene datos locales de llamadas. No deben atribuirse estas propiedades al producto sin informes de pruebas y evidencias de implementación.
Asimismo, el paquete de recuperación de identidad de la documentación de seguridad no es una copia del historial. Comprobar el hash de un APK en Proof Lab puede demostrar que el archivo coincide con un hash de confianza; ese resultado no es una auditoría del almacenamiento ni una prueba antiforense.
¿Qué información necesita una afirmación forense creíble?
Pide el modelo del dispositivo, las versiones del sistema y la aplicación, el estado de bloqueo, el método y nivel de acceso, el tipo de datos obtenidos y las limitaciones de la prueba. El fallo de una herramienta en un experimento no demuestra que todos los métodos sean imposibles; un éxito limitado tampoco permite generalizar a todos los usuarios.
Para el usuario habitual, las prioridades son actualizar, usar un bloqueo robusto, reducir copias adicionales de archivos multimedia y proteger los métodos de recuperación. Ante un incidente grave, busca ayuda de un especialista autorizado antes de realizar acciones que cambien datos o pruebas.
