Hoy en día, nuestros dispositivos móviles son prácticamente un diario donde guardamos todo: desde fotos íntimas hasta los datos de nuestra tarjeta de crédito. Por eso, no podemos dejar la seguridad al azar. Cuando hablamos de proteger datos sensibles en Android, el Android Keystore System se convierte en la herramienta estrella para evitar que cualquier malintencionado se lleve el botín de nuestras claves criptográficas, siendo un pilar fundamental de la seguridad en Android.
Básicamente, este sistema actúa como una caja fuerte digital. En lugar de guardar las claves como simples archivos de texto en el almacenamiento del teléfono (que sería un suicidio en términos de seguridad), las encierra en un contenedor blindado. Lo mejor de todo es que, una vez que la clave está ahí dentro, puedes usarla para cifrar o firmar cosas, pero jamás podrá ser extraída del dispositivo, ni siquiera si el sistema operativo ha sido comprometido.
¿Cómo funciona la seguridad en el corazón del sistema?
El Keystore no se anda con chiquitas y protege el material de las claves de dos formas muy claras. Primero, evita que alguien desde fuera del dispositivo pueda robar el material de las claves, ya que impide la extracción desde los procesos de la aplicación. Segundo, controla que, aunque alguien haya logrado entrar en el sistema, no pueda usar la clave para lo que quiera; las apps deben definir usos autorizados que el sistema aplica estrictamente.
Para que esto sea realmente robusto, Android se apoya en el hardware. El material de las claves no pasa por el proceso de la app; cuando necesitas hacer una operación, los datos se envían a un proceso del sistema especializado. Además, si el móvil es moderno, las claves se vinculan al Entorno de Ejecución Confiable (TEE) o al Elemento Seguro (SE). Si tienes un dispositivo con StrongBox, la seguridad sube de nivel, ya que este módulo tiene su propia CPU, almacenamiento seguro y un generador de números aleatorios real, resistiendo incluso ataques físicos.
Para saber si una clave está realmente protegida por hardware, los desarrolladores pueden usar getSecurityLevel() en Android 10 o versiones superiores. Si el resultado es TRUSTED_ENVIRONMENT o STRONGBOX, podemos respirar tranquilos porque la clave reside en una zona aislada del procesador principal.
Control de acceso y autorizaciones de uso
Una de las joyas de este sistema es que puedes ponerle «reglas» a cada clave al momento de crearla. Estas reglas son inmutables; una vez fijadas, no se pueden cambiar. Por ejemplo, puedes restringir que una clave solo sirva para algoritmos específicos, como AES o RSA, o definir un intervalo de tiempo exacto en el que la clave sea válida.
Pero lo más potente es la autenticación del usuario. Puedes configurar la clave para que solo funcione si el usuario se ha autenticado recientemente mediante su PIN, patrón o biometría (huella o rostro), considerando que el desbloqueo facial 2D vs 3D ofrece distintos niveles de protección. Existen dos modalidades: una que autoriza todas las claves durante un tiempo determinado tras la autenticación, y otra más estricta donde cada operación criptográfica debe ser autorizada individualmente mediante un BiometricPrompt.
KeyChain frente al Proveedor de Android Keystore
A veces surge la duda de cuál elegir. La API de KeyChain es la opción ideal cuando necesitas credenciales que sirvan para todo el sistema. Aquí, el usuario elige a través de una interfaz del sistema qué credencial quiere compartir con la app. Es muy útil para credenciales compartidas entre varias aplicaciones con el consentimiento explícito del dueño del móvil.
Por otro lado, el Proveedor de Android Keystore está pensado para que cada aplicación gestione sus propias llaves de forma privada. Es la opción preferida cuando quieres que solo tu app tenga acceso a sus secretos, sin necesidad de que el usuario intervenga seleccionando claves en una lista. Para implementarlo, se utilizan clases estándar de Java como KeyStore, KeyPairGenerator o KeyGenerator.
Implementación técnica: Cifrado y Firmas
Para cifrar datos de forma simétrica, lo más recomendable es usar AES-GCM. Este modo no solo mantiene el secreto, sino que garantiza la integridad de la información, detectando si alguien ha manipulado los bytes cifrados. Es fundamental recordar que cada operación genera un Vector de Inicialización (IV) único que debe almacenarse junto al dato cifrado para poder revertir la operación.
Si lo que necesitas es una firma digital, el camino es usar RSA. Se genera un par de claves (pública y privada) dentro del Keystore. La clave privada se queda encerrada en el hardware seguro para firmar la información, mientras que la clave pública puede distribuirse para verificar que el mensaje no ha sido alterado y que proviene de la fuente original.
Arquitectura interna y evolución del sistema
Bajo el capó, el sistema es una maquinaria compleja. El AndroidKeyStore es la cara visible para la app, pero este se comunica con el daemon del almacén de claves a través de Binder. Este daemon gestiona los keyblobs (claves cifradas) y se apoya en el HAL de KeyMint (antiguamente Keymaster) para realizar las operaciones pesadas en el mundo seguro.
El camino ha sido largo: desde Android 6.0, que introdujo el control de acceso y primitivas AES/HMAC, pasando por Android 7.0 con la certificación de claves y la vinculación de versiones (para evitar que un atacante degrade el SO a una versión vulnerable), hasta Android 12. En esta última versión, el daemon fue reescrito en Rust para ganar seguridad y se introdujo la HAL de KeyMint, que soporta acuerdos de claves ECDH y límites de uso de las claves.
Perspectiva forense y riesgos de extracción
Aunque el Keystore es muy robusto, en el mundo de la informática forense existen métodos para intentar sacar la información. Las claves se guardan cifradas en /misc/keystore/ (o en una base de datos SQLite desde Android 12). Para protegerlas, se usa una Clave de Cifrado de Clave (KEK) derivada de valores fijos del hardware seguro.
Algunos expertos en forense digital intentan realizar descifrados sin conexión extrayendo valores del hardware mediante vulnerabilidades específicas de procesadores (como MTK o Qualcomm). Si logran obtener la KEK, pueden descifrar las claves del almacén y, posteriormente, acceder a bases de datos cifradas de aplicaciones como Signal o Element, que suelen usar el Keystore para proteger la llave maestra de sus bases de datos Realm.
