Por qué elegimos el cifrado de sobre en lugar de SQLCipher para una app bancaria
SQLCipher es la respuesta habitual para cifrar datos locales en Android. Explicamos por qué elegimos el cifrado de sobre para una app bancaria y qué implica.
Cuando una app móvil almacena datos sensibles en local, el consejo por defecto en Android es casi automático: use SQLCipher. Es una solución madura, conocida y que cifra toda la base de datos.
Durante una auditoría de seguridad y su posterior remediación para la app Android de un banco minorista, optamos por otro enfoque: el cifrado de sobre de los propios valores sensibles, con las claves guardadas en el Android Keystore. En este artículo explicamos ambas opciones, por qué el cifrado de sobre encajaba con esta app y a qué renunciamos para lograrlo.
El problema: datos sensibles en reposo
Las apps bancarias guardan datos en caché para ser rápidas y poder usarse sin conexión: datos de cuentas, movimientos recientes, información del perfil. Si esos datos quedan en el dispositivo sin cifrar, un teléfono rooteado, una copia de seguridad o una copia forense pueden exponerlos. En el OWASP Mobile Top 10 (2024), esto corresponde a M9: Insecure Data Storage y M10: Insufficient Cryptography.
Opción 1: SQLCipher
SQLCipher es un fork de SQLite que cifra el archivo completo de la base de datos.
-
Ventaja: todo queda cifrado, incluidos los índices y los metadatos.
-
Ventaja: los datos cifrados siguen pudiéndose consultar por completo.
-
Coste: bibliotecas nativas para cada arquitectura de CPU, que aumentan el tamaño de la app.
-
Coste: la clave de la base de datos sigue teniendo que protegerse, normalmente también con el Keystore.
Opción 2: cifrado de sobre
El cifrado de sobre funciona con dos niveles de claves:
-
Una clave de cifrado de datos (DEK) cifra los valores sensibles con un cifrado autenticado como AES-GCM.
-
Una clave de cifrado de claves (KEK) en el Android Keystore envuelve la DEK. El código de la app nunca ve la KEK y, en los dispositivos compatibles, está respaldada por hardware.
📌 Idea clave:
En ambos enfoques, la protección real proviene del Keystore. La decisión está en qué se cifra con él: el archivo completo o solo los valores que importan.
Por qué el cifrado de sobre encajaba con esta app
1. La mayoría de los datos almacenados no eran sensibles
Buena parte de la base de datos local contenía configuración de la interfaz y otros datos no sensibles. Cifrar los valores sensibles concretos protegía lo importante sin cambiar el funcionamiento del resto de la base de datos.
2. El tamaño de la app importaba
Prescindir de SQLCipher ahorró unos 6,5 MB de código nativo. En una app bancaria que muchos usuarios instalan en teléfonos de gama media y con datos móviles, es una diferencia significativa.
3. El coste de rendimiento era medible y pequeño
Medimos la sobrecarga de descifrar los valores que muestra cada pantalla en alrededor de 1 ms por pantalla, muy por debajo de lo que un usuario podría notar.
4. Un único modelo de claves para todo
El mismo modelo de claves respaldado por el Keystore puede proteger valores en la base de datos, en las preferencias y en archivos, en lugar de tener un mecanismo distinto para cada caso.
Las contrapartidas que aceptamos
-
Sin consultas sobre campos cifrados. Los valores sensibles no se pueden buscar, ordenar ni indexar, así que las consultas tuvieron que diseñarse en torno a los campos no sensibles.
-
La clasificación pasa a ser una tarea de diseño. Alguien tiene que decidir, y documentar, qué valores son sensibles. Si se equivoca, los datos quedan sin cifrar.
-
Los metadatos no se cifran. La estructura de las tablas y las columnas no sensibles siguen siendo legibles.
Comparativa lado a lado
| Aspecto | SQLCipher | Cifrado de sobre |
| Qué se cifra | Todo el archivo de la base de datos | Valores sensibles seleccionados |
| Consultas sobre datos cifrados | Sí | No |
| Impacto en el tamaño de la app | Se añaden bibliotecas nativas | Unos 6,5 MB menos en esta app |
| Coste en tiempo de ejecución | Cifrado en cada página de la base de datos | Alrededor de 1 ms por pantalla, medido |
| Esfuerzo de diseño | Bajo | Requiere clasificar los datos |
| Ideal para | Datos mayoritariamente sensibles y consultables | Pocos valores sensibles en un conjunto de datos mayor |
Cómo aborda Mobian estas decisiones
En Mobian, cada cambio de seguridad de esa auditoría venía acompañado de un breve memorando de decisión por escrito: el riesgo, las opciones, lo que elegimos y lo que descartamos. Ese registro es lo que permite al equipo de seguridad de un banco, o a su auditor, entender por qué la app funciona como funciona. Elegiríamos SQLCipher con la misma naturalidad para una app en la que la mayoría de los datos locales fueran sensibles.
Conclusión
Tanto SQLCipher como el cifrado de sobre dependen del Android Keystore para ofrecer una protección real. En una app en la que solo una parte de los datos locales es sensible, cifrar directamente esos valores ahorró 6,5 MB y costó alrededor de 1 ms por pantalla, a cambio de una cuidadosa clasificación de los datos y de renunciar a las consultas sobre campos cifrados. La respuesta correcta depende de sus datos, y la decisión merece quedar por escrito.
Preguntas frecuentes
¿Qué es el cifrado de sobre?
El cifrado de sobre (envelope encryption) usa dos niveles de claves. Los datos se cifran con una clave de cifrado de datos (DEK), y la propia DEK se cifra, o envuelve, con una clave de cifrado de claves (KEK). En Android, la KEK puede residir en el Android Keystore, donde nunca queda expuesta al código de la app.
¿Es SQLCipher una mala elección?
No. SQLCipher es una solución madura que cifra todo el archivo de la base de datos, incluidos los índices y los metadatos. Encaja bien cuando la mayor parte de la base de datos es sensible o cuando los datos cifrados deben poder consultarse. Eso sí, añade bibliotecas nativas a la app y cambia el funcionamiento de la capa de base de datos.
¿Qué ahorró el cifrado de sobre en este proyecto?
Prescindir de SQLCipher ahorró unos 6,5 MB de código nativo en la app, con un coste medido de alrededor de 1 ms por pantalla para cifrar y descifrar los valores sensibles que muestra.
¿Cuál es el principal inconveniente del cifrado de sobre a nivel de campo?
La base de datos no puede buscar, ordenar ni indexar los campos cifrados. Hay que decidir con cuidado qué valores son sensibles y diseñar las consultas en torno a los campos no sensibles. El cifrado de toda la base de datos evita ese trabajo de diseño.
¿Cumple el cifrado de sobre los requisitos de OWASP?
Bien implementado, con claves respaldadas por hardware cuando están disponibles y un cifrado autenticado como AES-GCM, aborda las categorías de almacenamiento de datos inseguro y criptografía insuficiente del OWASP Mobile Top 10 (2024). Que satisfaga una auditoría concreta depende de los requisitos de esa auditoría.