Características

Esta página contiene información sobre las características criptográficas de Keystore en Android 6.0 y superior.

Nota: 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 envoltura de claves)
• Importación de claves simétricas sin procesar (sin envoltura de claves)
• Cifrado y descifrado asimétrico con modos de relleno apropiados
• Firma asimétrica y verificación con digestión y modos de relleno apropiados
• Cifrado y descifrado simétrico en los 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 las claves se generan o importan y se vinculan permanentemente a la clave, lo que garantiza que la clave no se pueda usar 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 una API: la generación de números aleatorios. Esto se usa internamente para la generación de 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:

• RSA
  • Compatibilidad con claves de 2048, 3072 y 4096 bits
  • Compatibilidad con el exponente público F4 (2^16+1)
  • Modos de relleno para la firma RSA:
    • RSASSA-PSS (Modo de PaddingMode::RSA_PSS )
    • RSASSA-PKCS1-v1_5 (modo de PaddingMode::RSA_PKCS1_1_5_SIGN )
  • Modos de resumen para la firma RSA:
    • SHA-256
  • Modos de relleno para el cifrado/descifrado RSA:
    • sin relleno
    • RSAES-OAEP (Modo de PaddingMode::RSA_OAEP )
    • RSAES-PKCS1-v1_5 (Modo de PaddingMode::RSA_PKCS1_1_5_ENCRYPT )
• ECDSA
  • Se admiten 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 (en desuso, 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 de nonce que no sean de 96 bits.
  • Los 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 hasta al menos 32 bytes.

SHA1 y los demás miembros de la familia SHA2 (SHA-224, SHA384 y SHA512) son muy recomendables para las implementaciones de Keymaster. Keystore los proporciona en software si la implementación de hardware Keymaster 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 exfiltrar). 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 etiqueta/valor. Las etiquetas de autorización son números enteros de 32 bits y los valores son de varios tipos. Algunas etiquetas pueden repetirse para especificar varios valores. Si una etiqueta se puede repetir 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 Keystore modifica la lista para especificar información adicional, como si la clave tiene protección de reversión, y devuelve una lista de autorización "final", codificada en el blob de clave devuelto. Cualquier intento de usar la clave para cualquier operación criptográfica falla si se modifica la lista final de autorizaciones.

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

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

Los posibles tipos incluyen:

ENUM : los valores de muchas etiquetas se definen en enumeraciones. Por ejemplo, los valores posibles de TAG::PURPOSE PURPOSE se definen en la enumeración 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, es probable que una clave de cifrado 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 autorizaciones. 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 autorizaciones. 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

Cumplimiento de hardware frente a software

No todas las implementaciones de hardware seguro contienen las mismas características. Para admitir una variedad de enfoques, Keymaster distingue entre la aplicación de control de acceso mundial segura y no segura, o la 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 los 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.
• Declarar las autorizaciones cuyos valores semánticos se aplican.

El mecanismo de la API para declarar autorizaciones forzadas 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 apropiados en cada uno, en función de lo que puede hacer cumplir.

Además, Keystore implementa la aplicación basada en software de todas las autorizaciones, ya sea que el hardware seguro las haga cumplir o no.

Por ejemplo, considere una implementación basada en TrustZone que no admita la caducidad de la clave. Aún se puede crear una clave con fecha de caducidad. La lista de autorizaciones 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 impondrá el requisito de caducidad. Sin embargo, Keystore rechazará los intentos de usar la clave después de su vencimiento.

Si el dispositivo se actualiza con hardware seguro que admita la caducidad, 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 clave .

Autorizaciones de construcción de mensajes criptográficos

Las siguientes etiquetas se utilizan para definir las características criptográficas de las operaciones que utilizan la clave asociada: TAG::ALGORITHM ::ALGORITHM , TAG::KEY_SIZE , TAG::BLOCK_MODE , TAG::PADDING , TAG::CALLER_NONCE y TAG::DIGEST

TAG::PADDING , TAG::DIGEST 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 de propósitos asociados, expresados ​​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 que un atacante convenza al sistema de descifrar datos arbitrarios para generar firmas.

Importar y exportar

Keymaster solo admite 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 con codificación DER, sin encriptación basada 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 un hardware seguro, TAG::ORIGIN con el valor KeyOrigin::GENERATED se encontrará en la lista hw_enforced de las características de la clave, mientras que una clave que se importó en un hardware seguro tendrá el valor KeyOrigin::IMPORTED .

Autenticacion de usuario

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

Los requisitos de autenticación del usuario se especifican a través de 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 usuarios múltiples), no el UID de la aplicación, y solo lo aplica el 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 usar si alguno de los valores se proporciona en un token de autenticación seguro.

El segundo conjunto indica si el usuario debe autenticarse y cuándo. Si ninguna de estas etiquetas está presente, pero TAG::USER_SECURE_ID lo está, 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 por TAG::USER_ID .
• 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 se aplica solo a las 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 un reinicio, todas las claves "nunca se autentican". El tiempo de espera se puede establecer en un valor alto para indicar que se requiere autenticación una vez por arranque (2^32 segundos son ~136 años; presumiblemente, los dispositivos Android se reinician con más frecuencia).

Vinculación del cliente

El enlace del cliente, la asociación de una clave con una aplicación de cliente en particular, se realiza a través de una ID de cliente opcional y algunos datos de cliente opcionales ( TAG::APPLICATION_ID y TAG::APPLICATION_DATA , respectivamente). El almacén de claves trata estos valores como blobs opacos y solo se asegura de 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 vinculación del cliente. La persona que llama tiene que saberlo para usar la clave.

Esta función no está expuesta a las aplicaciones.

Vencimiento

Keystore admite la restricción del uso de claves por fecha. El inicio de la validez de la clave y la caducidad de la clave se pueden asociar con una clave y Keymaster se niega a realizar operaciones 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 ORIGINATION_EXPIRE_DATETIME y TAG::USAGE_EXPIRE_DATETIME . La distinción entre "origen" y "uso" se basa en si la clave se utiliza para "originar" un nuevo texto cifrado/firma/etc., o para "utilizar" un texto cifrado/firma/etc. existente. Tenga en cuenta que esta distinción no está expuesta a las aplicaciones.

Las TAG::ACTIVE_DATETIME , TAG::ORIGINATION_EXPIRE_DATETIME 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 usar para descifrar/verificar mensajes.

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

Enlace de 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 proporcionada al hardware seguro de Keymaster durante el inicio, preferiblemente por 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 arranque 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 se podrá utilizar, a menos que se restaure la raíz de confianza anterior y se restablezca un sistema. que está firmado por esa clave se inicia. El objetivo es aumentar el valor de los controles de acceso de clave aplicados por software haciendo imposible que un sistema operativo instalado por un atacante use claves Keymaster.

Teclas independientes

Algunos hardware seguros de Keymaster pueden optar por almacenar el material de la clave internamente y devolver los identificadores en lugar del material de la clave cifrada. O puede haber otros casos en los que las claves no se puedan usar 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 más recursos que el blob y el sistema Keymaster en ejecución. Las etiquetas asociadas con una clave pueden inspeccionarse para ver si una clave es independiente. En la actualidad, sólo se definen dos valores:

• KeyBlobUsageRequirements::STANDALONE
• KeyBlobUsageRequirements::REQUIRES_FILE_SYSTEM

Esta función 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 clave y marcas de tiempo de último uso. Es probable que esta tabla tenga un tamaño limitado, pero admite al menos 16 entradas. En el caso de que la tabla esté llena y no se pueda actualizar ni descartar ninguna entrada, las implementaciones de hardware seguras son "a prueba de fallas", y prefieren rechazar todas las operaciones clave de velocidad limitada hasta que caduque una de las entradas. 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 también a prueba de fallas. Tenga en cuenta que las aplicaciones no podrán crear claves limitadas por arranque. Esta característica no está expuesta a través de Keystore y está reservada para operaciones del sistema.

Esta función no está expuesta a las aplicaciones.

Resembrado del generador de números aleatorios

Debido a que el hardware seguro genera números aleatorios para el material clave y los vectores de inicialización (IV), y debido a que los generadores de números aleatorios de hardware no siempre son totalmente confiables, Keymaster HAL proporciona una interfaz para permitir que el cliente proporcione entropía adicional que se mezclará con el aleatorio. 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 función no está expuesta a las aplicaciones, pero la utiliza el marco, que regularmente proporciona entropía adicional, recuperada de una instancia de Java SecureRandom, al hardware seguro.