Certificación de ID y claves

El almacén de claves brinda un lugar más seguro para crear, almacenar y usar de forma controlada. Cuando haya almacenamiento de claves con copia de seguridad en hardware cuando se usa, el material de claves es más seguro contra la extracción del dispositivo Keymaster aplica restricciones difíciles de subvertir.

Esto solo sucede, sin embargo, si se sabe que las claves del almacén de claves están en respaldado por hardware. En Keymaster 1, no había forma de que las apps o servidores remotos para verificar de forma confiable si este fue el caso. Daemon del almacén de claves cargó la HAL de keymaster disponible y creyó que lo que decía la HAL con con respecto a la copia de seguridad del hardware de las claves.

Para solucionar este problema, Keymaster introdujo la certificación de claves en Android 7.0 (Keymaster 2) y el ID. en Android 8.0 (Keymaster 3).

El objetivo de la certificación de claves es proporcionar una forma determinar 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 ID permite que el dispositivo proporcione pruebas de sus identificadores de hardware, como el número de serie o IMEI.

Certificación de claves

Para admitir la atestación de claves, Android 7.0 introdujo un conjunto de etiquetas, tipo y al HAL.

Etiquetas

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

Tipo

Keymaster 2 y versiones anteriores

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

Método AttestKey

Keymaster 3

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

Keymaster 2 y versiones anteriores

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 de keymaster.
• keyToAttest es el BLOB de claves que se muestra desde generateKey para la que se creará la certificación.
• attestParams es una lista de cualquier parámetro necesario para certificación. Esto incluye Tag::ATTESTATION_CHALLENGE y posiblemente Tag::RESET_SINCE_ID_ROTATION, así como Tag::APPLICATION_ID y Tag::APPLICATION_DATA. El los dos últimos son necesarios para desencriptar el BLOB de la clave si se especificaron durante la generación de la clave.
• certChain es el parámetro del resultado, que muestra un array de certificados. La entrada 0 es la certificación, lo que significa que certifica la clave de keyToAttest y contiene el de certificación de Google Cloud.

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

Certificado de certificación

La certificación es un certificado estándar X.509, con un de certificación que contiene una descripción de la clave certificada. El El certificado se firma con una clave de certificación certificada. La clave de certificación es posible que use un algoritmo diferente al de la clave que se está certificando.

La certificación contiene los campos de la siguiente tabla y no puede que contengan campos adicionales. Algunos campos especifican un valor de campo fijo. CTS las pruebas validan que el contenido del certificado sea exactamente como se definió.

Certificado SEQUENCE

TBSCertificate SEQUENCE

Extensión de certificación

La extensión attestation contiene una descripción completa del keymaster. autorizaciones asociadas con la clave, en una estructura que se corresponde a las listas de autorización, tal como se usan en Android y en la HAL de keymaster. Cada etiqueta en una lista de autorizaciones se representa con un ASN.1 SEQUENCE. de forma explícita con el número de etiqueta de keymaster, pero con el descriptor de tipo (cuatro valores de bits de orden) enmascarados.

Por ejemplo, en Keymaster 3, Tag::PURPOSE se define en types.hal como ENUM_REP | 1 Para la extensión de certificación, Se quita el valor ENUM_REP y se deja la etiqueta 1. (Para Keymaster 2 y las versiones anteriores, KM_TAG_PURPOSE se define en keymaster_defs.h).

Los valores se traducen de una manera directa a tipos ASN.1, según esta tabla:

Esquema

El contenido de la extensión de la certificación se describe en el siguiente esquema de 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,
  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 KeyDescription

keymasterVersion y attestationChallenge los campos correspondientes posicionalmente, en lugar de hacerlo por etiqueta, por lo que las etiquetas en la forma codificada solo especifican . Los campos restantes se etiquetan de forma implícita como se especifica en el .

Campos de AuthorizationList

AuthorizationList campos son opcionales y están identificados por el valor de la etiqueta keymaster, con los bits de tipo enmascarados. Se usa etiquetado explícito para que los campos también contengan una etiqueta que indique su tipo ASN.1 para un análisis más fácil.

Si deseas obtener detalles sobre los valores de cada campo, consulta types.hal para Keymaster 3 y keymaster_defs.h para Keymaster 2 y versiones anteriores. Nombres de etiquetas de Keymaster se transformaron en nombres de campo omitiendo KM_TAG. el prefijo y cambiar resto a mayúsculas mediales, de manera que Tag::KEY_SIZE se convirtió keySize

Campos RootOfTrust

Los campos RootOfTrust se identifican posicionalmente.

Valores VerifiedBootState

Los valores de verifiedBootState tienen los siguientes significados:

Valores SecurityLevel

Los valores de securityLevel tienen los siguientes significados:

ID único

El ID único es un valor de 128 bits que identifica al dispositivo, pero solo para período limitado. El valor se calcula de la siguiente manera:

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

donde:

• T es el "valor de contador temporal", que se calcula dividiendo el valor valor de Tag::CREATION_DATETIME por 25,200,000, lo que reduce cualquiera resto. T cambia cada 30 días (2592000000 = 30 * 24 * 60 * 60 × 1,000).
• C es el valor de Tag::APPLICATION_ID.
• R es 1 si Tag::RESET_SINCE_ID_ROTATION es presente en el parámetro attest_params a la llamada attest_key, o 0 si la la etiqueta no está presente.
• HBK es un secreto único vinculado al hardware que conoce el Trusted de ejecución y nunca es revelado por este. El secreto contiene al menos tiene 128 bits de entropía y es única para cada dispositivo (probabilístico la exclusividad es aceptable dada la entropía de 128 bits). La HBK debe ser derivadas del material de claves fusionadas a través de HMAC o AES_CMAC.

Truncar la salida de HMAC_SHA256 a 128 bits

Las claves de certificación y certificados

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

Android 12 presenta el aprovisionamiento de claves remotas, y Android 13 requiere dispositivos implementarlo. Remote Key Provisioning proporciona a los dispositivos en el campo y certificación ECDSA P256 por aplicación. Estos certificados son de corta duración que los certificados de fábrica.

Varios IMEI

En Android 14, se agrega compatibilidad con varios IMEI en el Registro de Certificación de claves de Android. Los OEMs pueden implementar esta función agregando una etiqueta KeyMint para un segundo IMEI. Cada vez es más común que los dispositivos tengan varias radios y los OEM ahora pueden admitir dispositivos con dos IMEI.

Los OEMs deben tener un IMEI secundario, si está presente en sus dispositivos, para poder aprovisionar a las implementaciones de KeyMint para que esas implementaciones puedan lo certifican de la misma manera que lo hacen en el primer IMEI

Certificación de ID

Android 8.0 incluye compatibilidad opcional con la certificación de ID para dispositivos con Keymaster 3. La certificación de ID permite que el dispositivo proporcione pruebas de su hardware identificadores, como el número de serie o IMEI. Si bien es una función opcional, se se recomienda que todas las implementaciones de Keymaster 3 lo admitan ya que poder demostrar la identidad del dispositivo habilita casos de uso como configuración remota de inscripción automática para que sea más segura (porque el lado remoto puede asegúrate de que se comunique con el dispositivo correcto y no de que falsifique su identidad. identidad).

La certificación de ID crea copias de los identificadores de hardware del dispositivo al que solo puede acceder el entorno de ejecución confiable (TEE) antes que el dispositivo sale de la fábrica. Un usuario puede desbloquear el bootloader del dispositivo y cambiar el el software del sistema y los identificadores informados por los frameworks de Android. El no se pueden manipular de esta manera las copias de los identificadores que conserva el TEE lo que garantiza que la certificación del ID del dispositivo solo certifique identificadores de hardware originales y así frustrar los intentos de falsificación de identidad.

La plataforma principal de la API para la certificación de ID se compila sobre la clave existente. el mecanismo de certificación introducido con Keymaster 2. Al solicitar un para una clave mantenida por el keymaster, el llamador puede solicitar que los identificadores de hardware del dispositivo se incluyan en la certificación en los metadatos del certificado. Si la clave se conserva en el TEE, el certificado a una raíz de confianza conocida. El destinatario de un certificado de este tipo puede que el certificado y su contenido, incluido el hardware identificadores, los escribió el TEE. Cuando se te solicite que incluyas hardware identificadores en la certificación, el TEE certifica únicamente el identificadores conservados en su almacenamiento, tal como se propagan en la planta.

Propiedades de almacenamiento

El almacenamiento que contiene los identificadores del dispositivo debe tener las siguientes 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. Destrucción permanente se refiere los datos se eliminan por completo, por lo que ni un restablecimiento de la configuración de fábrica ni ninguna otra realizado en el dispositivo puede restablecerlo. Esto es especialmente importante para dispositivos en los que un usuario desbloqueó el bootloader y cambió el software del sistema y modificamos los identificadores que muestra Android de seguridad en la nube.
• Las instalaciones de ADP deben tener la capacidad de generar copias nuevas de los datos derivados del identificador de hardware. De esta manera, el dispositivo que pasa por la ADP puede volver a realizar la certificación de ID. El mecanismo de control utilizado por las instalaciones de ADP deben protegerse para que los usuarios no puedan invocarlo ellos mismos, ya que eso les permitiría obtener certificaciones de para identificar IDs falsificados.
• Ningún código, excepto la app de confianza de Keymaster, en el TEE puede leer el los datos derivados de identificadores que se mantienen en el almacenamiento.
• El almacenamiento es a prueba de manipulaciones: si el contenido del almacenamiento modificado, el TEE lo trata de la misma manera que si las copias del contenido tuvieran se destruyó y rechaza todos los intentos de certificación de ID. Esto se implementa Firmando o creando un MAC en el almacenamiento como se describe abajo.
• El almacenamiento no contiene los identificadores originales. Porque la certificación de ID implica un desafío, la persona que llama siempre proporciona los identificadores certificado. El TEE solo necesita verificar que estos coincidan con los valores que que tenía originalmente. Almacenar hashes seguros de los valores originales en lugar del de salida habilita esta verificación.

Construcción

Para crear una implementación que tenga las propiedades mencionadas anteriormente, almacena el Valores derivados de ID en la siguiente construcción S. No almacenes otras copias de los valores de ID, excepto los lugares normales en el sistema, donde el propietario de un dispositivo puede modificarse con permisos de administrador:

S = D || HMAC(HBK, D)

donde:

• D = HMAC(HBK, ID1) || HMAC(HBK, ID2) || ... || HMAC(HBK, IDn)
• HMAC es la construcción de HMAC con un hash seguro adecuado. (se recomienda SHA-256)
• HBK es una clave vinculada al hardware que no se usa para ningún otro propósito
• ID1...IDn son los valores de ID originales. asociación de un para un índice en particular depende de la implementación, ya que Cada dispositivo tendrá un número diferente de identificadores
• || representa la concatenación.

Debido a que las salidas HMAC son de tamaño fijo, no se deben incluir encabezados ni ninguna otra estructura necesarios para poder encontrar hashes de ID individuales, o el HMAC de D. Además, para verificar los valores proporcionados para realizar la certificación, validar S mediante la extracción de D de S, el cálculo de HMAC(HBK, D) y la comparación con el valor en S para verificar que no se haya modificado ni dañado ningún ID individual. Además, implementaciones deben usar comparaciones de tiempo constante para todos los ID y la validación de S. El tiempo de comparación debe ser constante, independientemente de la cantidad de IDs proporcionados y la coincidencia correcta de cualquier parte de la prueba.

Identificadores de hardware

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

1. Nombre de la marca, como lo muestra Build.BRAND en Android
2. Nombre del dispositivo, como lo muestra Build.DEVICE en Android
3. Nombre del producto, como lo muestra Build.PRODUCT en Android
4. Nombre del fabricante, como lo muestra Build.MANUFACTURER en Android
5. Nombre del modelo, como lo muestra 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. Todo Los dispositivos con Android tienen los seis primeros pasos, que son necesarios para que funcione. Si el dispositivo tiene radios móviles integradas, también debe admitir la certificación de los IMEI o MEID de las radios.

para solicitar la certificación de ID se debe realizar una certificación de claves que incluya identificadores de dispositivos certificarlos en la solicitud. Los identificadores se etiquetan de la siguiente manera:

• 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 que se debe certificar es una cadena de bytes con codificación UTF-8. Este formato se aplica a también los identificadores numéricos. Cada identificador que se certificará se expresa como un Es una cadena con codificación UTF-8.

Si el dispositivo no admite certificación de ID (o Se llamó a destroyAttestationIds() anteriormente, y el dispositivo no puede certifican sus IDs por más tiempo), cualquier solicitud de certificación de claves que incluya uno o más de estas etiquetas fallan con ErrorCode::CANNOT_ATTEST_IDS.

Si el dispositivo admite certificación de ID y una o más de las etiquetas anteriores tienen en una solicitud de certificación de claves, el TEE verifica el identificador proporcionada con cada una de las etiquetas coincide 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 varias veces. Esto puede ser útil, por ejemplo, para certificar IMEI: Un dispositivo puede tener varias radios con diferentes IMEI. Una solicitud de certificación es válido si el valor proporcionado con cada ATTESTATION_ID_IMEI coincide una de las radios del dispositivo. Lo mismo se aplica a todas las demás etiquetas.

Si la certificación es correcta, los IDs certificados se agregan al extensión de certificación (OID 1.3.6.1.4.1.11129.2.1.17) de la certificación emitida, con el esquema anterior. Cambios de Keymaster 2 esquema de certificación están en negrita, con comentarios.

API de Java

Esta sección es solo informativa. Implementadores de Keymaster: implementar ni usar la API de Java. Se proporciona para ayudar a los implementadores a comprender cómo las aplicaciones usan la función. Es posible que los componentes del sistema lo usen de forma 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].