Atestación de clave e identificación

Keystore proporciona un lugar más seguro para crear, almacenar y utilizar claves criptográficas de forma controlada. Cuando el almacenamiento de claves respaldado por hardware está disponible y se utiliza, el material de claves es más seguro contra la extracción del dispositivo y Keymaster impone restricciones que son difíciles de subvertir.

Sin embargo, esto sólo es cierto si se sabe que las claves del almacén de claves están en un almacenamiento respaldado por hardware. En Keymaster 1, no había forma de que las aplicaciones o los servidores remotos verificaran de manera confiable si este era el caso. El demonio del almacén de claves cargó el HAL maestro de claves disponible y creyó todo lo que decía el HAL con respecto al respaldo de hardware de las claves.

Para remediar esto, Keymaster introdujo la atestación de clave en Android 7.0 (Keymaster 2) y la atestación de ID en Android 8.0 (Keymaster 3).

La atestación de claves tiene como objetivo proporcionar una manera de determinar con precisión si un par de claves asimétricas está respaldado por hardware, cuáles son las propiedades de la clave y qué restricciones se aplican a su uso.

La certificación de identificación permite que el dispositivo proporcione pruebas de sus identificadores de hardware, como el número de serie o IMEI.

atestación clave

Para admitir la atestación de claves, Android 7.1 introdujo un conjunto de etiquetas, tipos y métodos en HAL.

Etiquetas

• Tag::ATTESTATION_CHALLENGE
• Tag::INCLUDE_UNIQUE_ID
• Tag::RESET_SINCE_ID_ROTATION

Tipo

Keymaster 2 y inferiores

typedef struct {
    keymaster_blob_t* entries;
    size_t entry_count;
} keymaster_cert_chain_t;

Método AttestKey

Maestro de llaves 3

    attestKey(vec<uint8_t> keyToAttest, vec<KeyParameter> attestParams)
        generates(ErrorCode error, vec<vec<uint8_t>> certChain);

Keymaster 2 y inferiores

keymaster_error_t (*attest_key)(const struct keymaster2_device* dev,
        const keymaster_key_blob_t* key_to_attest,
        const keymaster_key_param_set_t* attest_params,
        keymaster_cert_chain_t* cert_chain);

• dev es la estructura del dispositivo keymaster.
• keyToAttest es el blob de claves devuelto por generateKey para el cual se creará la atestación.
• attestParams es una lista de los parámetros necesarios para la certificación. Esto incluye Tag::ATTESTATION_CHALLENGE y posiblemente Tag::RESET_SINCE_ID_ROTATION , así como Tag::APPLICATION_ID y Tag::APPLICATION_DATA . Los dos últimos son necesarios para descifrar el blob de claves si se especificaron durante la generación de claves.
• certChain es el parámetro de salida, que devuelve una serie de certificados. La entrada 0 es el certificado de atestación, lo que significa que certifica la clave de keyToAttest y contiene la extensión de atestación.

El método attestKey se considera una operación de clave pública en la clave certificada, porque se puede llamar en cualquier momento y no necesita cumplir restricciones de autorización. Por ejemplo, si la clave certificada necesita autenticación de usuario para su uso, se puede generar una certificación sin autenticación de usuario.

Certificado de atestación

El certificado de atestación es un certificado X.509 estándar, con una extensión de atestación opcional que contiene una descripción de la clave atestada. El certificado está firmado con una clave de atestación certificada. La clave de certificación puede utilizar un algoritmo diferente al de la clave que se está certificando.

El certificado de atestación contiene los campos de la siguiente tabla y no puede contener ningún campo adicional. Algunos campos especifican un valor de campo fijo. Las pruebas CTS validan que el contenido del certificado sea exactamente como se define.

Certificado SECUENCIA

TBSCertificado SECUENCIA

Extensión de atestación

La extensión attestation contiene una descripción completa de las autorizaciones de Keymaster asociadas con la clave, en una estructura que corresponde directamente a las listas de autorización utilizadas en Android y Keymaster HAL. Cada etiqueta en una lista de autorización está representada por una entrada SEQUENCE ASN.1, etiquetada explícitamente con el número de etiqueta maestra de clave, pero con el descriptor de tipo (cuatro bits de orden superior) enmascarado.

Por ejemplo, en Keymaster 3, Tag::PURPOSE se define en tipos.hal como ENUM_REP | 1 . Para la extensión de atestación, el valor ENUM_REP se elimina, dejando la etiqueta 1 . (Para Keymaster 2 y versiones anteriores, KM_TAG_PURPOSE se define en keymaster_defs.h.)

Los valores se traducen de forma sencilla a tipos ASN.1, según esta tabla:

Esquema

El contenido de la extensión de certificación se describe en el siguiente esquema ASN.1.

KeyDescription ::= SEQUENCE {
  attestationVersion         INTEGER, # KM2 value is 1. KM3 value is 2. KM4 value is 3.
  attestationSecurityLevel   SecurityLevel,
  keymasterVersion           INTEGER,
  keymasterSecurityLevel     SecurityLevel,
  attestationChallenge       OCTET_STRING,
  uniqueId                   OCTET_STRING,
  softwareEnforced           AuthorizationList,
  teeEnforced                AuthorizationList,
}

SecurityLevel ::= ENUMERATED {
  Software                   (0),
  TrustedEnvironment         (1),
  StrongBox                  (2),
}

AuthorizationList ::= SEQUENCE {
  purpose                     [1] EXPLICIT SET OF INTEGER OPTIONAL,
  algorithm                   [2] EXPLICIT INTEGER OPTIONAL,
  keySize                     [3] EXPLICIT INTEGER OPTIONAL.
  digest                      [5] EXPLICIT SET OF INTEGER OPTIONAL,
  padding                     [6] EXPLICIT SET OF INTEGER OPTIONAL,
  ecCurve                     [10] EXPLICIT INTEGER OPTIONAL,
  rsaPublicExponent           [200] EXPLICIT INTEGER OPTIONAL,
  rollbackResistance          [303] EXPLICIT NULL OPTIONAL, # KM4
  activeDateTime              [400] EXPLICIT INTEGER OPTIONAL
  originationExpireDateTime   [401] EXPLICIT INTEGER OPTIONAL
  usageExpireDateTime         [402] EXPLICIT INTEGER OPTIONAL
  noAuthRequired              [503] EXPLICIT NULL OPTIONAL,
  userAuthType                [504] EXPLICIT INTEGER OPTIONAL,
  authTimeout                 [505] EXPLICIT INTEGER OPTIONAL,
  allowWhileOnBody            [506] EXPLICIT NULL OPTIONAL,
  trustedUserPresenceRequired [507] EXPLICIT NULL OPTIONAL, # KM4
  trustedConfirmationRequired [508] EXPLICIT NULL OPTIONAL, # KM4
  unlockedDeviceRequired      [509] EXPLICIT NULL OPTIONAL, # KM4
  allApplications             [600] EXPLICIT NULL OPTIONAL,
  applicationId               [601] EXPLICIT OCTET_STRING OPTIONAL,
  creationDateTime            [701] EXPLICIT INTEGER OPTIONAL,
  origin                      [702] EXPLICIT INTEGER OPTIONAL,
  rollbackResistant           [703] EXPLICIT NULL OPTIONAL, # KM2 and KM3 only.
  rootOfTrust                 [704] EXPLICIT RootOfTrust OPTIONAL,
  osVersion                   [705] EXPLICIT INTEGER OPTIONAL,
  osPatchLevel                [706] EXPLICIT INTEGER OPTIONAL,
  attestationApplicationId    [709] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdBrand          [710] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdDevice         [711] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdProduct        [712] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdSerial         [713] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdImei           [714] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdMeid           [715] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdManufacturer   [716] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdModel          [717] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  vendorPatchLevel            [718] EXPLICIT INTEGER OPTIONAL, # KM4
  bootPatchLevel              [719] EXPLICIT INTEGER OPTIONAL, # KM4
}

RootOfTrust ::= SEQUENCE {
  verifiedBootKey            OCTET_STRING,
  deviceLocked               BOOLEAN,
  verifiedBootState          VerifiedBootState,
  verifiedBootHash           OCTET_STRING, # KM4
}

VerifiedBootState ::= ENUMERATED {
  Verified                   (0),
  SelfSigned                 (1),
  Unverified                 (2),
  Failed                     (3),
}

Campos de descripción clave

Los campos keymasterVersion y attestationChallenge se identifican posicionalmente, en lugar de por etiqueta, por lo que las etiquetas en el formulario codificado solo especifican el tipo de campo. Los campos restantes están etiquetados implícitamente como se especifica en el esquema.

Campos de la lista de autorización

Los campos AuthorizationList son todos opcionales y se identifican mediante el valor de la etiqueta Keymaster, con los bits de tipo enmascarados. Se utiliza etiquetado explícito para que los campos también contengan una etiqueta que indique su tipo ASN.1, para facilitar el análisis.

Para obtener detalles sobre los valores de cada campo, consulte types.hal para Keymaster 3 y keymaster_defs.h para Keymaster 2 y siguientes. Los nombres de las etiquetas Keymaster se transformaron en nombres de campos omitiendo el prefijo KM_TAG y cambiando el resto a mayúsculas y minúsculas, por lo que Tag::KEY_SIZE se convirtió en keySize .

Campos RootOfTrust

Los campos RootOfTrust se identifican posicionalmente.

Valores de VerifiedBootState

Los valores de verifiedBootState tienen los siguientes significados:

Valores de nivel de seguridad

Los valores de securityLevel tienen los siguientes significados:

Identificación única

El ID único es un valor de 128 bits que identifica el dispositivo, pero sólo por un período de tiempo limitado. El valor se calcula con:

HMAC_SHA256(T || C || R, HBK)

Dónde:

• T es el "valor del contador temporal", calculado dividiendo el valor de Tag::CREATION_DATETIME por 2592000000, eliminando el resto. T cambia cada 30 días (2592000000 = 30 * 24 * 60 * 60 * 1000).
• C es el valor de Tag::APPLICATION_ID
• R es 1 si Tag::RESET_SINCE_ID_ROTATION está presente en el parámetro attest_params de la llamada attest_key, o 0 si la etiqueta no está presente.
• HBK es un secreto exclusivo vinculado al hardware conocido por Trusted Execution Environment y que nunca revela. El secreto contiene al menos 128 bits de entropía y es exclusivo de cada dispositivo individual (la unicidad probabilística es aceptable dados los 128 bits de entropía). HBK debe derivarse del material de clave fusionada mediante HMAC o AES_CMAC.

Trunca la salida HMAC_SHA256 a 128 bits.

Claves de atestación y certificados

Se proporcionan de forma segura en el dispositivo dos claves, una RSA y una ECDSA, y las cadenas de certificados correspondientes.

Android 12 introduce el aprovisionamiento remoto de claves y Android 13 requiere que los dispositivos lo implementen. Remote Key Provisioning proporciona a los dispositivos en el campo certificados de atestación ECDSA P256 por aplicación. Estos certificados tienen una vida más corta que los certificados proporcionados por la fábrica.

Múltiples IMEI

Android 14 agrega soporte para múltiples IMEI en el registro de atestación de clave de Android. Los OEM pueden implementar esta función agregando una etiqueta KeyMint para un segundo IMEI. Cada vez es más común que los dispositivos tengan múltiples radios celulares y los OEM ahora pueden admitir dispositivos con dos IMEI.

Los OEM deben tener un IMEI secundario, si está presente en sus dispositivos, para ser aprovisionado en las implementaciones de KeyMint para que esas implementaciones puedan dar fe de él de la misma manera que dan fe del primer IMEI.

atestación de identidad

Android 8.0 incluye soporte opcional para la certificación de identificación para dispositivos con Keymaster 3. La certificación de identificación permite que el dispositivo proporcione pruebas de sus identificadores de hardware, como el número de serie o IMEI. Aunque es una característica opcional, se recomienda encarecidamente que todas las implementaciones de Keymaster 3 brinden soporte para ella porque poder probar la identidad del dispositivo permite que casos de uso como la verdadera configuración remota sin intervención sean más seguros (porque el lado remoto puede estar seguro de que está hablando con el dispositivo correcto, no con un dispositivo que suplanta su identidad).

La certificación de identificación funciona mediante la creación de copias de los identificadores de hardware del dispositivo a las que solo el entorno de ejecución confiable (TEE) puede acceder antes de que el dispositivo salga de fábrica. Un usuario puede desbloquear el gestor de arranque del dispositivo y cambiar el software del sistema y los identificadores informados por los marcos de Android. Las copias de los identificadores en poder del TEE no se pueden manipular de esta manera, lo que garantiza que la certificación de ID del dispositivo solo dará fe de los identificadores de hardware originales del dispositivo, frustrando así los intentos de suplantación de identidad.

La superficie API principal para la atestación de ID se basa en el mecanismo de atestación de claves existente introducido con Keymaster 2. Al solicitar un certificado de atestación para una clave en poder de Keymaster, la persona que llama puede solicitar que los identificadores de hardware del dispositivo se incluyan en los metadatos del certificado de atestación. Si la clave se encuentra en el TEE, el certificado se encadenará a una raíz de confianza conocida. El destinatario de dicho certificado puede verificar que el certificado y su contenido, incluidos los identificadores de hardware, fueron escritos por el TEE. Cuando se le solicita que incluya identificadores de hardware en el certificado de certificación, el TEE certifica solo los identificadores que se encuentran en su almacenamiento, tal como se encuentran en la fábrica.

Propiedades de almacenamiento

El almacenamiento que contiene los identificadores del dispositivo debe tener estas propiedades:

• Los valores derivados de los identificadores originales del dispositivo se copian en el almacenamiento antes de que el dispositivo salga de fábrica.
• El método destroyAttestationIds() puede destruir permanentemente esta copia de los datos derivados del identificador. La destrucción permanente significa que los datos se eliminan por completo, por lo que ni un restablecimiento de fábrica ni ningún otro procedimiento realizado en el dispositivo pueden restaurarlos. Esto es especialmente importante para dispositivos en los que un usuario desbloqueó el gestor de arranque, cambió el software del sistema y modificó los identificadores devueltos por los marcos de Android.
• Las instalaciones de RMA deben tener la capacidad de generar copias nuevas de los datos derivados del identificador de hardware. De esta manera, un dispositivo que pasa por RMA puede volver a realizar la certificación de identidad. El mecanismo utilizado por las instalaciones de RMA debe protegerse para que los usuarios no puedan invocarlo ellos mismos, ya que eso les permitiría obtener certificaciones de identificaciones falsificadas.
• Ningún otro código que no sea la aplicación confiable de Keymaster en el TEE puede leer los datos derivados del identificador guardados en el almacenamiento.
• El almacenamiento es a prueba de manipulaciones: si el contenido del almacenamiento ha sido modificado, el TEE lo trata igual que si las copias del contenido hubieran sido destruidas y rechaza todos los intentos de certificación de identidad. Esto se implementa firmando o asignando MAC al almacenamiento como se describe a continuación .
• El almacenamiento no contiene los identificadores originales. Dado que la certificación de identidad implica un desafío, la persona que llama siempre proporciona los identificadores que se deben certificar. El TEE sólo necesita verificar que estos coincidan con los valores que tenían originalmente. Almacenar hashes seguros de los valores originales en lugar de los valores permite esta verificación.

Construcción

Para crear una implementación que tenga las propiedades enumeradas anteriormente, almacene los valores derivados de ID en la siguiente construcción S. No almacene otras copias de los valores de ID, excepto los lugares normales en el sistema, que el propietario de un dispositivo puede modificar mediante rooteo:

S = D || HMAC(HBK, D)

dónde:

• D = HMAC(HBK, ID 1 ) || HMAC(HBK, ID 2 ) || ... || HMAC(HBK, ID n )
• HMAC es la construcción HMAC con un hash seguro apropiado (se recomienda SHA-256)
• HBK es una clave vinculada al hardware que no se utiliza para ningún otro propósito.
• ID 1 ...ID n son los valores de ID originales; La asociación de un valor particular a un índice particular depende de la implementación, ya que diferentes dispositivos tendrán diferentes números de identificadores.
• || representa concatenación

Debido a que las salidas HMAC tienen un tamaño fijo, no se requieren encabezados ni ninguna otra estructura para poder encontrar hashes de ID individuales o el HMAC de D. Además de verificar los valores proporcionados para realizar la certificación, las implementaciones deben validar S extrayendo D de S. , calculando HMAC(HBK, D) y comparándolo con el valor en S para verificar que no se modificaron/corrompieron ID individuales. Además, las implementaciones deben utilizar comparaciones de tiempo constante para todos los elementos de ID individuales y la validación de S. El tiempo de comparación debe ser constante independientemente de la cantidad de ID proporcionadas y de la coincidencia correcta de cualquier parte de la prueba.

Identificadores de hardware

La atestación de ID admite los siguientes identificadores de hardware:

1. Nombre de la marca, según lo devuelto por Build.BRAND en Android
2. Nombre del dispositivo, según lo devuelto por Build.DEVICE en Android
3. Nombre del producto, según lo devuelto por Build.PRODUCT en Android
4. Nombre del fabricante, según lo devuelto por Build.MANUFACTURER en Android
5. Nombre del modelo, según lo devuelto por Build.MODEL en Android
6. Número de serie
7. IMEI de todas las radios
8. MEID de todas las radios

Para admitir la certificación de ID de dispositivo, un dispositivo certifica estos identificadores. Todos los dispositivos con Android tienen los primeros seis y son necesarios para que esta función funcione. Si el dispositivo tiene radios celulares integradas, el dispositivo también debe admitir la certificación de los IMEI y/o MEID de las radios.

La certificación de identificación se solicita realizando una certificación de clave e incluyendo los identificadores del dispositivo para certificar en la solicitud. Los identificadores están etiquetados como:

• ATTESTATION_ID_BRAND
• ATTESTATION_ID_DEVICE
• ATTESTATION_ID_PRODUCT
• ATTESTATION_ID_MANUFACTURER
• ATTESTATION_ID_MODEL
• ATTESTATION_ID_SERIAL
• ATTESTATION_ID_IMEI
• ATTESTATION_ID_MEID

El identificador a dar fe es una cadena de bytes codificada en UTF-8. Este formato también se aplica a los identificadores numéricos. Cada identificador a certificar se expresa como una cadena codificada en UTF-8.

Si el dispositivo no admite la certificación de ID (o anteriormente se llamó a destroyAttestationIds() y el dispositivo ya no puede certificar sus ID), cualquier solicitud de certificación de clave que incluya una o más de estas etiquetas falla con ErrorCode::CANNOT_ATTEST_IDS .

Si el dispositivo admite la certificación de identificación y una o más de las etiquetas anteriores se han incluido en una solicitud de certificación de clave, el TEE verifica que el identificador suministrado con cada una de las etiquetas coincida con su copia de los identificadores de hardware. Si uno o más identificadores no coinciden, toda la certificación falla con ErrorCode::CANNOT_ATTEST_IDS . Es válido que la misma etiqueta se proporcione varias veces. Esto puede resultar útil, por ejemplo, al comprobar IMEI: un dispositivo puede tener varias radios con varios IMEI. Una solicitud de certificación es válida si el valor proporcionado con cada ATTESTATION_ID_IMEI coincide con una de las radios del dispositivo. Lo mismo se aplica a todas las demás etiquetas.

Si la atestación se realiza correctamente, los ID atestiguados se agregan a la extensión de atestación (OID 1.3.6.1.4.1.11129.2.1.17) del certificado de atestación emitido, utilizando el esquema anterior . Los cambios del esquema de certificación de Keymaster 2 están en negrita y con comentarios.

API de Java

Esta sección es sólo informativa. Los implementadores de Keymaster no implementan ni utilizan la API de Java. Esto se proporciona para ayudar a los implementadores a comprender cómo las aplicaciones utilizan la característica. Los componentes del sistema pueden usarlo de manera diferente, por lo que es fundamental que esta sección no se trate como normativa.

// Create KeyPairGenerator and set generation parameters for an ECDSA key pair
// using the NIST P-256 curve.  "Key1" is the key alias.
KeyPairGenerator keyPairGenerator = KeyPairGenerator.getInstance(
    KeyProperties.KEY_ALGORITHM_EC, "AndroidKeyStore");
keyPairGenerator.initialize(
    new KeyGenParameterSpec.Builder("Key1", KeyProperties.PURPOSE_SIGN)
         .setAlgorithmParameterSpec(new ECGenParameterSpec("secp256r1"))
         .setDigests(KeyProperties.DIGEST_SHA256,
                     KeyProperties.DIGEST_SHA384,
                     KeyProperties.DIGEST_SHA512)
         // Only permit the private key to be used if the user
         // authenticated within the last five minutes.
         .setUserAuthenticationRequired(true)
         .setUserAuthenticationValidityDurationSeconds(5 * 60)
         // Request an attestation with challenge "hello world".
         .setAttestationChallenge("hello world".getBytes("UTF-8"))
         .build());
// Generate the key pair. This will result in calls to both generate_key() and
// attest_key() at the keymaster2 HAL.
KeyPair keyPair = keyPairGenerator.generateKeyPair();
// Get the certificate chain
KeyStore keyStore = KeyStore.getInstance("AndroidKeyStore");
keyStore.load(null);
Certificate[] certs = keyStore.getCertificateChain("Key1");
// certs[0] is the attestation certificate. certs[1] signs certs[0], etc.,
// up to certs[certs.length - 1].