Protección de datos y llavero: cuándo queda cifrado lo que la app guarda

Cada archivo del contenedor de una app tiene una clase de protección. Hay cuatro. La más estricta hace que el archivo solo se pueda abrir con el teléfono desbloqueado. Otra permite seguir escribiendo un archivo que ya estaba abierto cuando el teléfono se bloqueó. La tercera lo abre desde el primer desbloqueo tras encender el aparato, aunque después se vuelva a bloquear. La cuarta no protege el archivo con la clave de acceso del usuario.

Si la app no elige otra, los archivos reciben la tercera, que es el valor intermedio. Eso significa que, tras un primer desbloqueo, un archivo con la clase por defecto queda disponible aunque la pantalla esté bloqueada. Para un dato que debe estar protegido en cuanto el teléfono se bloquea, la clase por defecto no basta y la app debe pedir la más estricta.

La clase sin protección no es un problema por sí misma: una imagen pública de una campaña o un catálogo de talleres no pierden nada porque se lean. El hallazgo aparece cuando esa clase coincide con un dato personal o de negocio. La revisión cruza dos columnas: qué protección tiene el archivo y qué contiene.

El listado del contenedor de Quetzal trae seis archivos con su clase y una nota sobre el contenido. Dos llevan la clase sin protección. Cruza la columna de clase con la de contenido y quédate con el que guarda datos de personas.

El llavero guarda secretos pequeños (tokens, claves, contraseñas) con una clase de accesibilidad por elemento. Las habituales son: solo con el teléfono desbloqueado, tras el primer desbloqueo, y variantes que además atan el elemento a este aparato o exigen que haya un código de acceso puesto. La clase por defecto, si la app no elige, es la de solo con el teléfono desbloqueado.

Hay una clase que permite leer el elemento siempre, incluso con el teléfono recién encendido y sin desbloquear, y que Apple marcó como obsoleta. Quitar la protección del bloqueo de un secreto es justo lo que el llavero existe para evitar. Revisa el listado del llavero de Quetzal y localiza el elemento con esa clase.

En el dispositivo de pruebas, el token de sesión de la cuenta de prueba está en el llavero, donde corresponde, y además en un archivo de preferencias de la app, que no tiene el cifrado reforzado de un elemento de llavero y suele entrar en las copias de seguridad del dispositivo. Esa segunda copia es el hallazgo: el secreto está protegido en un sitio y desprotegido en otro, y vale lo que valga el eslabón más débil.

El arreglo no es proteger mejor la copia, es no tenerla. Y como el valor ya estuvo guardado en un sitio débil, se recomienda también invalidar los tokens emitidos, porque no se puede dar por perdido el secreto sin rotarlo.