Esta página contiene información sobre las funciones de criptografía de Keystore en Android 6.0 y versiones posteriores.
Primitivas criptográficas
El almacén de claves proporciona las siguientes categorías de operaciones:
- Generación de claves
- Importación y exportación de claves asimétricas (sin unión de claves)
- Importación de claves simétricas sin procesar (sin unión de claves)
- Encriptación y desencriptación asimétricas con los modos de relleno adecuados
- Firma y verificación asimétricas con resumen y modos de padding adecuados
- Encriptación y desencriptación simétricas en los modos adecuados, incluido un modo AEAD
- Generación y verificación de códigos de autenticación de mensajes simétricos
Los elementos del protocolo, como el propósito, el modo y el padding, así como las restricciones de control de acceso, se especifican cuando se generan o importan claves y se vinculan de forma permanente a la clave, lo que garantiza que no se pueda usar de ninguna otra manera.
Además de la lista anterior, hay un servicio más que proporcionan las implementaciones de Keymaster, pero que no se expone como una API: la generación de números aleatorios. Se usa de forma interna para generar claves, vectores de inicialización (IV), relleno aleatorio y otros elementos de protocolos seguros que requieren aleatoriedad.
Primitivos necesarios
Todas las implementaciones de Keymaster proporcionan lo siguiente:
- RSA
- Compatibilidad con claves de 2048, 3072 y 4096 bits
- Compatibilidad con el exponente público F4 (2^16+1)
- Modos de padding para la firma RSA:
- RSASSA-PSS (
PaddingMode::RSA_PSS
) - RSASSA-PKCS1-v1_5 (
PaddingMode::RSA_PKCS1_1_5_SIGN
)
- RSASSA-PSS (
- Modos de resumen para la firma RSA:
- SHA-256
- Modos de padding para la encriptación o desencriptación de RSA:
- Sin relleno
- RSAES-OAEP (
PaddingMode::RSA_OAEP
) - RSAES-PKCS1-v1_5 (
PaddingMode::RSA_PKCS1_1_5_ENCRYPT
)
- ECDSA
- Se admite la compatibilidad con claves de 224, 256, 384 y 521 bits, con las curvas P-224, P-256, P-384 y P-521 de NIST, respectivamente.
- Modos de resumen para ECDSA:
- Sin resumen (obsoleto, se quitará en el futuro)
- SHA-256
- AES
- Se admiten claves de 128 y 256 bits
- CBC, CTR, ECB y GCM. La implementación de GCM no permite el uso de etiquetas menores que 96 bits ni longitudes de nonce distintas de 96 bits.
- Los modos de padding
PaddingMode::NONE
yPaddingMode::PKCS7
son compatibles con los modos CBC y ECB. Sin relleno, la encriptación en modo CBC o ECB falla si la entrada no es un múltiplo del tamaño del bloque.
- HMAC SHA-256, con cualquier tamaño de clave de hasta 32 bytes como mínimo
Se recomienda usar SHA1 y los otros miembros de la familia SHA2 (SHA-224, SHA384 y SHA512) para las implementaciones de Keymaster. Keystore los proporciona en software si la implementación de Keymaster de hardware no los proporciona.
También se recomiendan algunas primitivas para la interoperabilidad con otros sistemas:
- Tamaños de clave más pequeños para RSA
- Exponentes públicos arbitrarios para RSA
Control de acceso a las claves
Las claves basadas en hardware que nunca se pueden extraer del dispositivo no proporcionan mucha seguridad si un atacante puede usarlas a voluntad (aunque son más seguras que las claves que se pueden extraer). Por lo tanto, es fundamental que el almacén de claves aplique controles de acceso.
Los controles de acceso se definen como una "lista de autorización" de pares etiqueta/valor. Las etiquetas de autorización son números enteros de 32 bits y los valores son de varios tipos. Algunas etiquetas se pueden repetir para especificar varios valores. Se especifica si se puede repetir una etiqueta en la interfaz de HAL de KeyMint (anteriormente Keymaster). Cuando se crea una clave, el llamador especifica una lista de autorización. La implementación de Keymaster subyacente al almacén de claves modifica la lista para especificar información adicional, como si la clave tiene protección de reversión, y muestra una lista de autorización "final", codificada en el BLOB de claves que se muestra. Cualquier intento de usar la clave para cualquier operación criptográfica fallará si se modifica la lista de autorización final.
En Keymaster 2 y versiones anteriores, el conjunto de etiquetas posibles se define en la enumeración keymaster_authorization_tag_t
y se fija de forma permanente (aunque se puede extender).
Los nombres tenían el prefijo KM_TAG
. Los cuatro primeros bits de los IDs de etiqueta se usan para indicar el tipo.
Keymaster 3 cambió el prefijo KM_TAG
a Tag::
.
Entre los tipos posibles, se incluyen los siguientes:
ENUM
: Muchos valores de etiquetas se definen en enumeraciones. Por ejemplo, los valores posibles de TAG::PURPOSE
se definen en la enum keymaster_purpose_t
.
ENUM_REP
: Es igual que ENUM
, excepto que la etiqueta se puede repetir en una lista de autorización. La repetición indica varios valores autorizados. Por ejemplo, es probable que una clave de encriptación tenga KeyPurpose::ENCRYPT
y KeyPurpose::DECRYPT
.
UINT
: Números enteros de 32 bits sin firma. Ejemplo:
TAG::KEY_SIZE
UINT_REP
: Es igual que UINT
, excepto que la etiqueta se puede repetir en una lista de autorización. La repetición indica varios valores autorizados.
ULONG
: Números enteros de 64 bits sin firma. Ejemplo:
TAG::RSA_PUBLIC_EXPONENT
ULONG_REP
: Es igual que ULONG
, excepto que la etiqueta se puede repetir en una lista de autorización. La repetición indica varios valores autorizados.
DATE
: Valores de fecha y hora, expresados en milisegundos desde el 1 de enero de 1970.
Ejemplo: TAG::PRIVKEY_EXPIRE_DATETIME
BOOL
: Es verdadero o falso. Se supone que una etiqueta de tipo BOOL
es "false" si no está presente y "true" si lo está. Ejemplo: TAG::ROLLBACK_RESISTANT
BIGNUM
: Números enteros de longitud arbitraria, expresados como un array de bytes en orden de big-endian. Ejemplo:
TAG::RSA_PUBLIC_EXPONENT
BYTES
: Es una secuencia de bytes. Ejemplo:
TAG::ROOT_OF_TRUST
Aplicación forzosa de hardware en comparación con la de software
No todas las implementaciones de hardware seguro contienen las mismas funciones. Para admitir una variedad de enfoques, Keymaster distingue entre la aplicación forzosa de control de acceso mundial segura y no segura, o la aplicación forzosa de hardware y software, respectivamente.
Todas las implementaciones:
- Aplica la coincidencia exacta (no la aplicación forzosa) de todas las autorizaciones. Las listas de autorizaciones en los blobs de claves coinciden exactamente con las autorizaciones que se muestran durante la generación de claves, incluido el orden. Cualquier discrepancia genera un diagnóstico de error.
- Declara las autorizaciones cuyos valores semánticos se aplican de forma forzosa.
El mecanismo de la API para declarar autorizaciones aplicadas por hardware se encuentra en la estructura keymaster_key_characteristics_t
. Divide la lista de autorizaciones en dos sublistas, hw_enforced
y sw_enforced
. El hardware seguro es responsable de colocar los valores adecuados en cada uno, según lo que pueda aplicar.
Además, Keystore implementa la aplicación forzosa basada en software de todas las autorizaciones, ya sea que el hardware seguro las aplique o no.
Por ejemplo, considera una implementación basada en TrustZone que no admite el vencimiento de claves. Es posible que se cree una clave con una fecha de vencimiento. La lista de autorizaciones de esa clave incluye la etiqueta TAG::ORIGINATION_EXPIRE_DATETIME
con la fecha de vencimiento. Una solicitud al almacén de claves para las características de clave encuentra esta etiqueta en la lista sw_enforced
, y el hardware seguro no aplica el requisito de vencimiento. Sin embargo, Keystore rechaza los intentos de usar la clave después del vencimiento.
Si, luego, el dispositivo se actualiza con hardware seguro que admite el vencimiento, una solicitud de características de clave encuentra TAG::ORIGINATION_EXPIRE_DATETIME
en la lista hw_enforced
y los intentos de usar la clave después del vencimiento fallan, incluso si se subvierte o se omite el almacén de claves.
Para obtener más información sobre cómo determinar si las claves tienen copia de seguridad en hardware, consulta Certificación de claves.
Autorizaciones de construcción de mensajes criptográficos
Las siguientes etiquetas se usan para definir las características criptográficas de las operaciones con la clave asociada: TAG::ALGORITHM
, TAG::KEY_SIZE
, TAG::BLOCK_MODE
, TAG::PADDING
, TAG::CALLER_NONCE
y TAG::DIGEST
.
TAG::PADDING
, TAG::DIGEST
y PaddingMode::BLOCK_MODE
se pueden repetir, lo que significa que se pueden asociar varios valores con una sola clave, y el valor que se usará se especifica en el momento de la operación.
Propósito
Las claves tienen un conjunto asociado de propósitos, expresados como una o más entradas de autorización con la etiqueta TAG::PURPOSE
, que define cómo se pueden usar. Los fines son los siguientes:
KeyPurpose::ENCRYPT
KeyPurpose::DECRYPT
KeyPurpose::SIGN
KeyPurpose::VERIFY
Cualquier clave puede tener cualquier subconjunto de estos fines. Ten en cuenta que algunas combinaciones pueden crear problemas de seguridad. Por ejemplo, una clave RSA que se puede usar para encriptar y firmar permite que un atacante que pueda convencer al sistema de desencriptar datos arbitrarios genere firmas.
Importación y exportación
Keymaster admite solo la exportación de claves públicas, en formato X.509, y la importación de lo siguiente:
- Pares de claves públicas y privadas en formato PKCS#8 con codificación DER, sin encriptación basada en contraseñas
- Claves simétricas como bytes sin procesar
Para garantizar que las claves importadas se puedan distinguir de las claves generadas de forma segura, TAG::ORIGIN
se incluye en la lista de autorizaciones de claves adecuada. Por ejemplo, si una clave se generó en hardware seguro, TAG::ORIGIN
con el valor KeyOrigin::GENERATED
se encuentra en la lista hw_enforced
de las características clave, mientras que una clave que se importó a hardware seguro tiene el valor KeyOrigin::IMPORTED
.
Autenticación de usuarios
Las implementaciones de Secure Keymaster no implementan la autenticación del usuario, pero dependen de otras apps de confianza que sí lo hacen. Para ver la interfaz que implementan estas apps, consulta la página de Gatekeeper.
Los requisitos de autenticación del usuario se especifican mediante dos conjuntos de etiquetas. El primer conjunto indica qué usuario puede usar la clave:
TAG::ALL_USERS
indica que todos los usuarios pueden usar la clave. Si está presente,TAG::USER_ID
yTAG::USER_SECURE_ID
no están presentes.TAG::USER_ID
tiene un valor numérico que especifica el ID del usuario autorizado. Ten en cuenta que este es el ID de usuario de Android (para varios usuarios), no el UID de la app, y solo se aplica con software no seguro. Si está presente,TAG::ALL_USERS
no lo está.TAG::USER_SECURE_ID
tiene un valor numérico de 64 bits que especifica el ID de usuario seguro que se proporciona en un token de autenticación seguro para desbloquear el uso de la clave. Si se repite, la clave se puede usar si alguno de los valores se proporciona en un token de autenticación seguro.
El segundo conjunto indica si se debe autenticar al usuario y cuándo.
Si no hay ninguna de estas etiquetas, pero sí TAG::USER_SECURE_ID
, se requiere la autenticación para cada uso de la clave.
NO_AUTHENTICATION_REQUIRED
indica que no se requiere autenticación del usuario, aunque solo las apps que se ejecutan como los usuarios especificados porTAG::USER_ID
pueden usar la clave.TAG::AUTH_TIMEOUT
es un valor numérico que especifica, en segundos, qué tan reciente debe ser la autenticación del usuario para autorizar el uso de la clave. Esto solo se aplica a las operaciones de claves privadas o secretas. Las operaciones de clave pública no requieren autenticación. Los tiempos de espera no se transfieren entre reinicios. Después de un reinicio, nunca se autentican todas las claves. El tiempo de espera se puede establecer en un valor alto para indicar que se requiere la autenticación una vez por inicio (2^32 segundos son aproximadamente 136 años; se supone que los dispositivos Android se reinician con más frecuencia).
Cómo solicitar que se desbloquee el dispositivo
Las claves con TAG::UNLOCKED_DEVICE_REQUIRED
solo se pueden usar mientras el dispositivo está desbloqueado. Para obtener la semántica detallada, consulta
KeyProtection.Builder#setUnlockedDeviceRequired(boolean)
.
Keystore aplica UNLOCKED_DEVICE_REQUIRED
, no Keymaster. Sin embargo, en Android 12 y versiones posteriores, el almacén de claves protege de forma criptográfica las claves UNLOCKED_DEVICE_REQUIRED
mientras el dispositivo está bloqueado para garantizar que, en la mayoría de los casos, no se puedan usar, incluso si el almacén de claves está comprometido mientras el dispositivo está bloqueado.
Para lograrlo, el almacén de claves "superencripta" todas las claves UNLOCKED_DEVICE_REQUIRED
antes de almacenarlas en su base de datos y, cuando es posible, protege las claves de superencriptación (superclaves) mientras el dispositivo está bloqueado de manera tal que solo se puedan recuperar si se desbloquea correctamente. (Se usa el término "superencriptación" porque esta capa de encriptación se aplica además de la capa de encriptación que Keymaster ya aplica a todas las claves).
Cada usuario (incluidos los perfiles) tiene dos superclaves asociadas con UNLOCKED_DEVICE_REQUIRED
:
- La superclave simétrica UnlockedDeviceRequired. Esta es una clave AES-256-GCM. Encripta las claves
UNLOCKED_DEVICE_REQUIRED
que se importan o generan mientras el dispositivo está desbloqueado para el usuario. - La superclave asimétrica UnlockedDeviceRequired. Este es un par de claves ECDH P-521. Encripta las claves
UNLOCKED_DEVICE_REQUIRED
que se importan o generan mientras el dispositivo está bloqueado para el usuario. Las claves encriptadas con esta clave asimétrica se vuelven a encriptar con la clave simétrica en el primer uso (lo que solo puede ocurrir mientras el dispositivo está desbloqueado).
El almacén de claves genera estas superclaves en el momento de la creación del usuario y las almacena en su base de datos, encriptadas con la contraseña sintética del usuario. Esto permite que se recuperen con un PIN, un patrón o una contraseña equivalentes.
El almacén de claves también almacena en caché estas superclaves en la memoria, lo que le permite operar en claves UNLOCKED_DEVICE_REQUIRED
. Sin embargo, intenta almacenar en caché las partes secretas de estas claves solo mientras el dispositivo está desbloqueado para el usuario. Cuando el dispositivo está bloqueado para el usuario, Keystore pone a cero su copia almacenada en caché de las partes secretas de estas superclaves, si es posible. Específicamente, cuando el dispositivo está bloqueado para el usuario, Keystore selecciona y aplica uno de los tres niveles de protección para las superclaves UnlockedDeviceRequired del usuario:
- Si el usuario solo tiene habilitado el PIN, el patrón o la contraseña, Keystore anula las partes secretas de sus superclaves almacenadas en caché. Esto hace que las superclaves solo se puedan recuperar a través de la copia encriptada en la base de datos, que solo se puede desencriptar con un PIN, un patrón o una contraseña equivalentes.
- Si el usuario solo tiene datos biométricos de clase 3 (“fuertes”) y tiene habilitado el PIN, el patrón o la contraseña, Keystore organiza las superclaves para que cualquiera de los datos biométricos de clase 3 inscritos del usuario (por lo general, la huella dactilar) pueda recuperarlas, como alternativa al PIN, el patrón o la contraseña equivalentes. Para ello, genera una nueva clave AES-256-GCM, encripta las partes secretas de las superclaves con ella, importa la clave AES-256-GCM a Keymaster como una clave vinculada a la biometría que requiere que la autenticación biométrica se haya realizado correctamente en los últimos 15 segundos y pone a cero las copias de texto simple de todas estas claves.
- Si el usuario tiene habilitada una biométrica de clase 1 ("práctica"), de clase 2 ("débil") o un agente de confianza de desbloqueo activo, el almacén de claves mantiene las superclaves almacenadas en caché en texto simple. En este caso, no se proporciona seguridad criptográfica para las claves
UNLOCKED_DEVICE_REQUIRED
. Los usuarios pueden evitar este resguardo menos seguro si no habilitan estos métodos de desbloqueo. Los métodos de desbloqueo más comunes que se incluyen en estas categorías son el desbloqueo facial en muchos dispositivos y el desbloqueo con un reloj inteligente vinculado.
Cuando el dispositivo se desbloquea para el usuario, Keystore recupera las superclaves de UnlockedDeviceRequired del usuario si es posible. Para el desbloqueo equivalente con PIN, patrón o contraseña, desencripta la copia de estas claves que se almacena en la base de datos. De lo contrario, verifica si se guardó una copia de estas claves encriptadas con una clave vinculada a la biometría y, de ser así, intenta desencriptarla. Esto tiene éxito solo si el usuario se autenticó correctamente con una biométrica de clase 3 en los últimos 15 segundos, que se aplica mediante Keymaster (no Keystore).
Vinculación de clientes
La vinculación de clientes, la asociación de una clave con una app de cliente particular, se realiza a través de un ID de cliente opcional y algunos datos de cliente opcionales (TAG::APPLICATION_ID
y TAG::APPLICATION_DATA
, respectivamente). Keystore trata estos valores como objetos blob opacos y solo se asegura de que los mismos objetos blob que se presentan durante la generación o importación de claves se presenten para cada uso y sean idénticos byte por byte. Keymaster no muestra los datos de vinculación del cliente. El llamador debe conocerla para usar la clave.
Esta función no está expuesta a las apps.
Vencimiento
El almacén de claves admite la restricción del uso de claves por fecha. El inicio de validez y el vencimiento de las claves se pueden asociar con una clave, y Keymaster se niega a realizar operaciones de clave si la fecha y hora actuales están fuera del rango válido. El rango de validez de la clave se especifica con las etiquetas TAG::ACTIVE_DATETIME
, TAG::ORIGINATION_EXPIRE_DATETIME
y TAG::USAGE_EXPIRE_DATETIME
. La distinción entre "origenación" y "uso" se basa en si la clave se usa para "originar" un texto cifrado, una firma, etcétera, nuevos, o para "usar" un texto cifrado, una firma, etcétera, existente. Ten en cuenta que esta distinción no se expone a las apps.
Las etiquetas TAG::ACTIVE_DATETIME
, TAG::ORIGINATION_EXPIRE_DATETIME
y TAG::USAGE_EXPIRE_DATETIME
son opcionales. Si no hay etiquetas, se supone que la clave en cuestión siempre se puede usar para desencriptar o verificar mensajes.
Debido a que el mundo no seguro proporciona la hora del reloj, es poco probable que las etiquetas relacionadas con el vencimiento estén en la lista aplicada por hardware. La aplicación forzosa del vencimiento de hardware requeriría que el mundo seguro obtuviera de alguna manera datos y tiempo de confianza, por ejemplo, a través de un protocolo de respuesta de desafío con un servidor de tiempo remoto de confianza.
Vinculación de la raíz de confianza
El almacén de claves requiere que las claves estén vinculadas a una raíz de confianza, que es una cadena de bits que se proporciona al hardware seguro de Keymaster durante el inicio, preferiblemente por el bootloader. Esta cadena de bits está vinculada criptográficamente a cada clave que administra Keymaster.
La raíz de confianza consiste en la clave pública que se usa para verificar la firma en la imagen de inicio y el estado de bloqueo del dispositivo. Si se cambia la clave pública para permitir que se use una imagen del sistema diferente o si se cambia el estado de bloqueo, ninguna de las claves protegidas por Keymaster que creó el sistema anterior se puede usar, a menos que se restablezca la raíz de confianza anterior y se inicie un sistema firmado con esa clave. El objetivo es aumentar el valor de los controles de acceso a claves que aplica el software, ya que hace imposible que un sistema operativo instalado por un atacante use las claves de Keymaster.
Claves independientes
Algunos hardware seguro de Keymaster pueden optar por almacenar el material de claves de forma interna y mostrar controladores en lugar de material de claves encriptado. O bien puede haber otros
casos en los que las claves no se puedan usar hasta que haya disponible algún otro componente del sistema mundial
no seguro o seguro. El HAL de Keymaster permite que el llamador solicite que una clave sea "independiente" a través de la etiqueta TAG::STANDALONE
, lo que significa que no se requieren recursos distintos del BLOB y el sistema Keymaster en ejecución. Se pueden inspeccionar las etiquetas asociadas con una clave para ver si es independiente. Actualmente, solo se definen dos valores:
KeyBlobUsageRequirements::STANDALONE
KeyBlobUsageRequirements::REQUIRES_FILE_SYSTEM
Esta función no está expuesta a las apps.
Velocidad
Cuando se crea, se puede especificar la velocidad máxima de uso con TAG::MIN_SECONDS_BETWEEN_OPS
.
Las implementaciones de TrustZone se niegan a realizar operaciones criptográficas con esa clave si se realizó una operación menos de TAG::MIN_SECONDS_BETWEEN_OPS
segundos antes.
El enfoque simple para implementar límites de velocidad es una tabla de IDs de claves y marcas de tiempo de último uso. Esta tabla tiene un tamaño limitado, pero puede admitir al menos 16 entradas. En caso de que la tabla esté llena y no se puedan actualizar ni descartar entradas, las implementaciones de hardware seguras “fallan de forma segura” y prefieren rechazar todas las operaciones de claves limitadas por velocidad hasta que venza una de las entradas. Se acepta que todas las entradas venzan al reiniciarse el dispositivo.
Las claves también se pueden limitar a n usos por inicio con TAG::MAX_USES_PER_BOOT
. Esto también requiere una tabla de seguimiento,
que acepte al menos cuatro claves y también tenga un sistema de resguardo. Ten en cuenta que las apps no pueden crear claves limitadas por inicio. Esta función
no se expone a través de Keystore y está reservada para las operaciones del sistema.
Esta función no está expuesta a las apps.
Regeneración del valor inicial del generador de números aleatorios
Debido a que el hardware seguro genera números aleatorios para el material de claves y los vectores de inicialización (IV), y debido a que los generadores de números aleatorios de hardware no siempre son completamente confiables, el HAL de Keymaster proporciona una interfaz para permitir que el cliente proporcione entropía adicional, que se mezcla con los números aleatorios generados.
Usa un generador de números aleatorios de hardware como fuente de valor inicial principal. Los datos iniciales proporcionados a través de la API externa no pueden ser la única fuente de aleatoriedad que se usa para la generación de números. Además, la operación de combinación que se usa debe garantizar que el resultado aleatorio sea impredecible si alguna de las fuentes de origen es impredecible.
Esta función no está expuesta a las apps, pero el framework la usa, lo que proporciona enentropía adicional, recuperada de una instancia de Java SecureRandom, al hardware seguro.