El almacén de claves de Android (Keystore)

Según la documentación de Android, el material de una clave del Keystore nunca entra en el proceso de la aplicación: las operaciones criptográficas ocurren en un proceso del sistema, así que, si la aplicación se compromete, el atacante puede pedir que se use la clave mientras dure el compromiso, pero no puede copiarla. Además, la clave puede quedar atada a hardware seguro (un entorno de ejecución de confianza o un elemento seguro dedicado), de modo que ni siquiera un sistema comprometido o el contenido del almacenamiento la entregan.

Lo que no garantiza: que una aplicación comprometida no pueda usar la clave en el momento. Por eso se combina con exigir la autenticación del usuario en cada operación importante.

El volcado de propiedades de una clave incluye su nivel de seguridad: entorno de ejecución de confianza, elemento seguro dedicado (StrongBox) o software. Una clave a nivel de software vive en el sistema operativo y pierde la parte «atada al hardware» de la garantía. A veces es inevitable (dispositivos antiguos, emuladores); lo que se reporta es que una clave que protege datos importantes quedó en software y que nadie lo supo hasta mirar.

Abre el laboratorio y lee el inventario del Keystore.

Una clave puede exigir que el usuario se autentique (biometría fuerte o credencial del dispositivo) antes de cada uso. Con esa exigencia, aunque una aplicación comprometida pida firmar, la firma no sale sin que la persona confirme en el dispositivo. Para operaciones que mueven dinero o autorizan cambios, es la configuración esperada; para una clave que solo cifra una caché no hace falta, y exigirla estorbaría. El criterio es el valor de lo que la clave autoriza.

Una clave generada en el almacén nunca estuvo fuera de él. Una clave importada pasó por algún sitio antes: por la memoria de la aplicación y, muy probablemente, por una constante del código, un archivo o una respuesta del servidor. El almacén custodia la copia, pero la clave ya pudo haberse visto. En el informe se anota el alias y se busca de dónde salió el material importado.

Lee el inventario y localiza la clave cuyo origen no es el propio almacén.

Un almacén seguro con un plan B inseguro es un almacén inseguro: si el cifrado falla y el código escribe el token en claro «para no perder la sesión», quien provoque el fallo (o simplemente un dispositivo con el almacén dañado) consigue el token sin cifrar. El principio es fallar cerrado: ante un error del almacén, no se guarda el dato, se pide iniciar sesión de nuevo y se registra el fallo sin el dato.

Lee el extracto del código que guarda el token en el laboratorio antes de responder.