Características

Esta página contiene información sobre las funciones criptográficas de Keystore en Android 6.0 y versiones posteriores.

Nota: Las etiquetas y funciones están escritas en estilo Keymaster 3. Para obtener más información, consulte la descripción general de HIDL .

Primitivas criptográficas

Keystore proporciona las siguientes categorías de operaciones:

• Generación de claves
• Importación y exportación de claves asimétricas (sin ajuste de claves)
• Importación de claves simétricas sin procesar (sin ajuste de claves)
• Cifrado y descifrado asimétrico con modos de relleno adecuados
• Firma y verificación asimétricas con modos de digestión y relleno apropiados
• Cifrado y descifrado simétrico en modos apropiados, 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 relleno, así como las restricciones de control de acceso , se especifican cuando se generan o importan claves y están vinculados permanentemente a la clave, lo que garantiza que la clave no se pueda utilizar de ninguna otra manera.

Además de la lista anterior, hay un servicio más que brindan las implementaciones de Keymaster, pero que no está expuesto como API: la generación de números aleatorios. Esto se utiliza internamente para la generación de claves, vectores de inicialización (IV), relleno aleatorio y otros elementos de protocolos seguros que requieren aleatoriedad.

Primitivas necesarias

Todas las implementaciones de Keymaster proporcionan:

• RSA
  • Compatibilidad con claves de 2048, 3072 y 4096 bits
  • Soporte para exponente público F4 (2^16+1)
  • Modos de relleno para la firma RSA:
    • RSASSA-PSS ( PaddingMode::RSA_PSS )
    • RSASSA-PKCS1-v1_5 ( PaddingMode::RSA_PKCS1_1_5_SIGN )
  • Modos de resumen para la firma RSA:
    • SHA-256
  • Modos de relleno para cifrado/descifrado RSA:
    • Sin acolchado
    • RSAES-OAEP ( PaddingMode::RSA_OAEP )
    • RSAES-PKCS1-v1_5 ( PaddingMode::RSA_PKCS1_1_5_ENCRYPT )
• ECDSA
  • Se admite compatibilidad con claves de 224, 256, 384 y 521 bits, utilizando las curvas NIST P-224, P-256, P-384 y P-521, respectivamente.
  • Modos de resumen para ECDSA:
    • Sin resumen (obsoleto, se eliminará en el futuro)
    • SHA-256
• AES
  • Se admiten claves de 128 y 256 bits
  • CBC , CTR, BCE y GCM. La implementación de GCM no permite el uso de etiquetas de menos de 96 bits o longitudes nonce distintas de 96 bits.
  • Modos de relleno PaddingMode::NONE y PaddingMode::PKCS7 son compatibles con los modos CBC y ECB. Sin relleno, el cifrado 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 al menos 32 bytes.

Se recomienda encarecidamente SHA1 y los demás miembros de la familia SHA2 (SHA-224, SHA384 y SHA512) para implementaciones de Keymaster. Keystore los proporciona en software si la implementación de Keymaster en 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 clave

Las claves basadas en hardware que nunca se pueden extraer del dispositivo no brindan 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 crucial que Keystore aplique controles de acceso.

Los controles de acceso se definen como una "lista de autorización" de pares de etiqueta/valor. Las etiquetas de autorización son números enteros de 32 bits y los valores son de diversos tipos. Algunas etiquetas pueden repetirse para especificar varios valores. Si una etiqueta puede repetirse se especifica en la documentación de la etiqueta . Cuando se crea una clave, la persona que llama especifica una lista de autorización. La implementación de Keymaster subyacente a Keystore modifica la lista para especificar información adicional, como si la clave tiene protección de reversión y devolver una lista de autorización "final", codificada en el blob de clave devuelto. Cualquier intento de utilizar la clave para cualquier operación criptográfica falla si se modifica la lista de autorización final.

Para Keymaster 2 y versiones anteriores, el conjunto de etiquetas posibles se define en la enumeración keymaster_authorization_tag_t y está permanentemente fijo (aunque se puede ampliar). Los nombres tenían el prefijo KM_TAG . Los cuatro bits superiores de los ID de etiqueta se utilizan para indicar el tipo.

Keymaster 3 cambió el prefijo KM_TAG a Tag:: .

Los tipos posibles incluyen:

ENUM : los valores de muchas etiquetas se definen en enumeraciones. Por ejemplo, los posibles valores de TAG::PURPOSE se definen en enum keymaster_purpose_t .

ENUM_REP : Igual que ENUM , excepto que la etiqueta puede repetirse en una lista de autorización. La repetición indica múltiples valores autorizados. Por ejemplo, una clave de cifrado probablemente tenga KeyPurpose::ENCRYPT y KeyPurpose::DECRYPT .

UINT : enteros sin signo de 32 bits. Ejemplo: TAG::KEY_SIZE

UINT_REP : Igual que UINT , excepto que la etiqueta puede repetirse en una lista de autorización. La repetición indica múltiples valores autorizados.

ULONG : enteros sin signo de 64 bits. Ejemplo: TAG::RSA_PUBLIC_EXPONENT

ULONG_REP : Igual que ULONG , excepto que la etiqueta puede repetirse en una lista de autorización. La repetición indica múltiples valores autorizados.

DATE : Valores de fecha/hora, expresados ​​en milisegundos desde el 1 de enero de 1970. Ejemplo: TAG::PRIVKEY_EXPIRE_DATETIME

BOOL : Verdadero o falso. Se supone que una etiqueta de tipo BOOL es "falsa" si la etiqueta no está presente y "verdadera" si está presente. Ejemplo: TAG::ROLLBACK_RESISTANT

BIGNUM : enteros de longitud arbitraria, expresados ​​como una matriz de bytes en orden big-endian. Ejemplo: TAG::RSA_PUBLIC_EXPONENT

BYTES : una secuencia de bytes. Ejemplo: TAG::ROOT_OF_TRUST

Aplicación de hardware versus software

No todas las implementaciones de hardware seguro contienen las mismas funciones. Para respaldar una variedad de enfoques, Keymaster distingue entre aplicación de control de acceso mundial seguro y no seguro, o aplicación de hardware y software, respectivamente.

Todas las implementaciones:

• Hacer cumplir la coincidencia exacta (no la aplicación) de todas las autorizaciones. Las listas de autorizaciones en blobs de claves coinciden exactamente con las autorizaciones devueltas durante la generación de claves, incluido el pedido. Cualquier discrepancia provoca un diagnóstico de error.
• Declare las autorizaciones cuyos valores semánticos se aplican.

El mecanismo API para declarar autorizaciones aplicadas por hardware se encuentra en la estructura keymaster_key_characteristics_t . Divide la lista de autorización en dos sublistas, hw_enforced y sw_enforced . El hardware seguro es responsable de colocar los valores adecuados en cada uno, en función de lo que puede hacer cumplir.

Además, Keystore implementa el cumplimiento de todas las autorizaciones mediante software, ya sea que se apliquen mediante hardware seguro o no.

Por ejemplo, considere una implementación basada en TrustZone que no admita la caducidad de claves. Es posible que aún se cree una clave con fecha de vencimiento. La lista de autorización de esa clave incluirá la etiqueta TAG::ORIGINATION_EXPIRE_DATETIME con la fecha de vencimiento. Una solicitud a Keystore para las características clave encontrará esta etiqueta en la lista sw_enforced y el hardware seguro no exigirá el requisito de caducidad. Sin embargo, Keystore rechazará los intentos de utilizar la clave después de su vencimiento.

Si luego el dispositivo se actualiza con hardware seguro que admita la caducidad, entonces una solicitud de características clave encontrará TAG::ORIGINATION_EXPIRE_DATETIME en la lista hw_enforced , y los intentos de usar la clave después de la caducidad fallarán incluso si el almacén de claves se subvierte o se omite de alguna manera. .

Para obtener más información sobre cómo determinar si las claves están respaldadas por hardware, consulte Atestación de claves .

Autorizaciones de construcción de mensajes criptográficos

Las siguientes etiquetas se utilizan para definir las características criptográficas de las operaciones utilizando 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 son repetibles, lo que significa que se pueden asociar varios valores con una sola clave y el valor que se utilizará se especifica en el momento de la operación.

Objetivo

Las claves tienen un conjunto asociado de propósitos, expresado como una o más entradas de autorización con la etiqueta TAG::PURPOSE , que define cómo se pueden usar. Los propósitos son:

• KeyPurpose::ENCRYPT
• KeyPurpose::DECRYPT
• KeyPurpose::SIGN
• KeyPurpose::VERIFY

Cualquier clave puede tener cualquier subconjunto de estos propósitos. Tenga en cuenta que algunas combinaciones crean problemas de seguridad. Por ejemplo, una clave RSA que se puede utilizar tanto para cifrar como para firmar permite a un atacante convencer al sistema de descifrar datos arbitrarios para generar firmas.

Importar y exportar

Keymaster admite únicamente la exportación de claves públicas, en formato X.509, y la importación de:

• Pares de claves públicas y privadas en formato PKCS#8 codificado en DER, sin cifrado basado en contraseña
• Claves simétricas como bytes sin formato

Para garantizar que las claves importadas se puedan distinguir de las claves generadas de forma segura, TAG::ORIGIN se incluye en la lista de autorización de claves adecuada. Por ejemplo, si una clave se generó en hardware seguro, TAG::ORIGIN con el valor KeyOrigin::GENERATED se encontrará en la lista hw_enforced de características clave, mientras que una clave que se importó en hardware seguro tendrá el valor KeyOrigin::IMPORTED .

Autenticacion de usuario

Las implementaciones seguras de Keymaster no implementan la autenticación de usuario, sino que dependen de otras aplicaciones confiables que sí lo hacen. Para conocer la interfaz que implementan estas aplicaciones, consulte la página Gatekeeper .

Los requisitos de autenticación de 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 utilizar la clave. Si está presente, TAG::USER_ID y TAG::USER_SECURE_ID no están presentes.
• TAG::USER_ID tiene un valor numérico que especifica el ID del usuario autorizado. Tenga en cuenta que este es el ID de usuario de Android (para multiusuario), no el UID de la aplicación, y solo lo aplica software no seguro. Si está presente, TAG::ALL_USERS no está presente.
• 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 utilizar si alguno de los valores se proporciona en un token de autenticación seguro.

El segundo conjunto indica si el usuario necesita ser autenticado y cuándo. Si ninguna de estas etiquetas está presente, pero TAG::USER_SECURE_ID sí, se requiere autenticación para cada uso de la clave.

• NO_AUTHENTICATION_REQUIRED indica que no se requiere autenticación de usuario, aunque la clave solo puede ser utilizada por aplicaciones que se ejecutan como los usuarios especificados en TAG::USER_ID .
• TAG::AUTH_TIMEOUT es un valor numérico que especifica, en segundos, qué tan actualizada debe ser la autenticación del usuario para autorizar el uso de la clave. Esto se aplica sólo a operaciones de clave privada/secreta. Las operaciones de clave pública no requieren autenticación. Los tiempos de espera no se cruzan con los reinicios; después de reiniciar, todas las claves "nunca se autentican". El tiempo de espera se puede establecer en un valor grande para indicar que se requiere autenticación una vez por inicio (2^32 segundos son ~136 años; presumiblemente los dispositivos Android se reinician con más frecuencia).

Enlace de cliente

El enlace del cliente, la asociación de una clave con una aplicación cliente particular, se realiza mediante un ID de cliente opcional y algunos datos de cliente opcionales ( TAG::APPLICATION_ID y TAG::APPLICATION_DATA , respectivamente). Keystore trata estos valores como blobs opacos y solo garantiza que los mismos blobs presentados durante la generación/importación de claves se presenten para cada uso y sean idénticos byte por byte. Keymaster no devuelve los datos de enlace del cliente. La persona que llama debe saberlo para poder utilizar la clave.

Esta característica no está expuesta a las aplicaciones.

Vencimiento

Keystore admite restringir el uso de claves por fecha. El inicio de la validez de la clave y los vencimientos de la clave se pueden asociar con una clave y Keymaster se niega a realizar operaciones de clave si la fecha/hora actual está 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 "origen" y "uso" se basa en si la clave se utiliza para "generar" un nuevo texto cifrado/firma/etc., o para "usar" un texto cifrado/firma/etc. Tenga en cuenta que esta distinción no está expuesta a aplicaciones.

Las TAG::ACTIVE_DATETIME , TAG::ORIGINATION_EXPIRE_DATETIME y TAG::USAGE_EXPIRE_DATETIME son opcionales. Si las etiquetas están ausentes, se supone que la clave en cuestión siempre se puede utilizar para descifrar/verificar mensajes.

Debido a que el mundo no seguro proporciona la hora del reloj de pared, es poco probable que las etiquetas relacionadas con la caducidad estén en la lista impuesta por hardware. La aplicación de la caducidad por hardware requeriría que el mundo seguro obtuviera de alguna manera tiempo y datos confiables, por ejemplo a través de un protocolo de respuesta a desafío con un servidor de tiempo remoto confiable.

Enlace de raíz de confianza

Keystore requiere que las claves estén vinculadas a una raíz de confianza, que es una cadena de bits proporcionada al hardware seguro de Keymaster durante el inicio, preferiblemente mediante el gestor de arranque. Esta cadena de bits está vinculada criptográficamente a cada clave administrada por Keymaster.

La raíz de confianza consta de la clave pública utilizada 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 el uso de una imagen de sistema diferente o si se cambia el estado de bloqueo, ninguna de las claves protegidas por Keymaster creadas por el sistema anterior será utilizable, a menos que se restaure la raíz de confianza anterior y se establezca un sistema. que está firmado por esa clave se inicia. El objetivo es aumentar el valor de los controles de acceso a claves aplicados por software haciendo imposible que un sistema operativo instalado por un atacante utilice claves Keymaster.

Teclas independientes

Algunos hardware seguros de Keymaster pueden optar por almacenar el material de claves internamente y devolver identificadores en lugar de material de claves cifrado. O puede haber otros casos en los que las claves no se puedan utilizar hasta que esté disponible algún otro componente del sistema mundial seguro o no seguro. Keymaster HAL permite a la persona que llama solicitar 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. Las etiquetas asociadas con una clave se pueden inspeccionar para ver si una clave es independiente. Actualmente, sólo se definen dos valores:

• KeyBlobUsageRequirements::STANDALONE
• KeyBlobUsageRequirements::REQUIRES_FILE_SYSTEM

Esta característica no está expuesta a las aplicaciones.

Velocidad

Cuando se crea, la velocidad máxima de uso se puede especificar con TAG::MIN_SECONDS_BETWEEN_OPS . Las implementaciones de TrustZone se niegan a realizar operaciones criptográficas con esa clave si una operación se realizó menos de TAG::MIN_SECONDS_BETWEEN_OPS segundos antes.

El enfoque simple para implementar límites de velocidad es una tabla de ID de claves y marcas de tiempo de último uso. Es probable que esta tabla sea de tamaño limitado, pero tiene capacidad para al menos 16 entradas. En el caso de que la tabla esté llena y no se puedan actualizar o descartar entradas, las implementaciones de hardware seguras son "a prueba de fallos", prefiriendo rechazar todas las operaciones de clave con velocidad limitada hasta que una de las entradas caduque. Es aceptable que todas las entradas caduquen al reiniciar.

Las claves también se pueden limitar a n usos por arranque con TAG::MAX_USES_PER_BOOT . Esto también requiere una mesa de seguimiento, que acomode al menos cuatro llaves y que también sea a prueba de fallos. Tenga en cuenta que las aplicaciones no podrán crear claves limitadas por inicio. Esta característica no está expuesta a través de Keystore y está reservada para las operaciones del sistema.

Esta característica no está expuesta a las aplicaciones.

Resiembra 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 del hardware pueden no siempre ser completamente confiables, Keymaster HAL proporciona una interfaz que permite al cliente proporcionar entropía adicional que se mezclará con la información aleatoria. números generados.

Utilice un generador de números aleatorios de hardware como fuente principal de semillas. Los datos iniciales proporcionados a través de la API externa no pueden ser la única fuente de aleatoriedad utilizada para la generación de números. Además, la operación de mezcla utilizada debe garantizar que la salida aleatoria sea impredecible si alguna de las fuentes de semillas es impredecible.

Esta característica no está expuesta a las aplicaciones, pero la utiliza el marco, que proporciona periódicamente entropía adicional, recuperada de una instancia de Java SecureRandom, al hardware seguro.