Key Attestation gives you more confidence that the keys you use in your app are stored in a device's hardware-backed keystore. The following sections describe how to verify the properties of hardware-backed keys and how to interpret the schema of the attestation certificate's extension data.
Note: Before you verify the properties of a device's
hardware-backed keys in a production-level environment, you should make sure
that the device supports hardware-level key attestation. To do so, you should
check that the attestation certificate chain contains a root certificate that
is signed with the Google attestation root key and that the
attestationSecurityLevel
element within the key description data structure
is set to the TrustedEnvironment security level.
In addition, it's important to verify the signatures in the certificate chain and to check that none of the keys in the chain have been revoked by checking the Certificate Revocation Status List. Unless all are valid and the root is the Google root key mentioned above, you shouldn't fully trust the attestation. Note, however, that devices containing revoked certificates are still at least as trustworthy as devices that only support software attestation. Having a fully-valid attestation is a strong positive indicator. Not having one is a neutral—not negative—indicator.
Retrieve and verify a hardware-backed key pair
During key attestation, you specify the alias of a key pair. The attestation tool, in return, provides a certificate chain, which you can use to verify the properties of that key pair.
If the device supports hardware-level key attestation, the root certificate within this chain is signed using an attestation root key, which the device manufacturer injects into the device's hardware-backed keystore at the factory.
Note: On devices that ship with hardware-level key attestation, Android 7.0 (API level 24) or higher, and Google Play services, the root certificate is signed with the Google attestation root key. You should verify that this root certificate is among those listed below.
To implement key attestation, complete the following steps:
-
Use a
KeyStore
object'sgetCertificateChain()
method to get a reference to the chain of X.509 certificates associated with the hardware-backed keystore. -
Check each certificate's validity using a
X509Certificate
object'scheckValidity()
method. Also verify that the root certificate is trustworthy.Caution: Although you can complete this process within your app directly, it's safer to check the certificates' revocation status on a separate server that you trust.
-
On a separate server that you trust, obtain a reference to the ASN.1 parser library that is most appropriate for your toolset. Use this parser to extract the attestation certificate extension data, which appears within the first element of the certificate chain.
The Key Attestation sample uses the ASN.1 parser from Bouncy Castle to extract an attestation certificate's extension data. You can use this sample as a reference for creating your own parser.
For more details about the schema of the extension data, see Certificate Extension Data Schema.
-
Compare the extension data that you've retrieved from your ASN.1 parser with the set of values that you expect the hardware-backed key to contain.
Caution: Although you can complete this process within your app directly, it's safer to check the certificate's extension data on a separate server that you trust.
Root certificates
The trustworthiness of the attestation depends on the root certificate of the chain. Android devices that have passed the testing required to have the Google suite of apps, including Google Play, and which launched with Android 7.0 (API level 24) or higher should use attestation keys signed by the Google Hardware Attestation Root certificate. This certificate is one of the following certificates:
-----BEGIN CERTIFICATE----- MIIFYDCCA0igAwIBAgIJAOj6GWMU0voYMA0GCSqGSIb3DQEBCwUAMBsxGTAXBgNV BAUTEGY5MjAwOWU4NTNiNmIwNDUwHhcNMTYwNTI2MTYyODUyWhcNMjYwNTI0MTYy ODUyWjAbMRkwFwYDVQQFExBmOTIwMDllODUzYjZiMDQ1MIICIjANBgkqhkiG9w0B AQEFAAOCAg8AMIICCgKCAgEAr7bHgiuxpwHsK7Qui8xUFmOr75gvMsd/dTEDDJdS Sxtf6An7xyqpRR90PL2abxM1dEqlXnf2tqw1Ne4Xwl5jlRfdnJLmN0pTy/4lj4/7 tv0Sk3iiKkypnEUtR6WfMgH0QZfKHM1+di+y9TFRtv6y//0rb+T+W8a9nsNL/ggj nar86461qO0rOs2cXjp3kOG1FEJ5MVmFmBGtnrKpa73XpXyTqRxB/M0n1n/W9nGq C4FSYa04T6N5RIZGBN2z2MT5IKGbFlbC8UrW0DxW7AYImQQcHtGl/m00QLVWutHQ oVJYnFPlXTcHYvASLu+RhhsbDmxMgJJ0mcDpvsC4PjvB+TxywElgS70vE0XmLD+O JtvsBslHZvPBKCOdT0MS+tgSOIfga+z1Z1g7+DVagf7quvmag8jfPioyKvxnK/Eg sTUVi2ghzq8wm27ud/mIM7AY2qEORR8Go3TVB4HzWQgpZrt3i5MIlCaY504LzSRi igHCzAPlHws+W0rB5N+er5/2pJKnfBSDiCiFAVtCLOZ7gLiMm0jhO2B6tUXHI/+M RPjy02i59lINMRRev56GKtcd9qO/0kUJWdZTdA2XoS82ixPvZtXQpUpuL12ab+9E aDK8Z4RHJYYfCT3Q5vNAXaiWQ+8PTWm2QgBR/bkwSWc+NpUFgNPN9PvQi8WEg5Um AGMCAwEAAaOBpjCBozAdBgNVHQ4EFgQUNmHhAHyIBQlRi0RsR/8aTMnqTxIwHwYD VR0jBBgwFoAUNmHhAHyIBQlRi0RsR/8aTMnqTxIwDwYDVR0TAQH/BAUwAwEB/zAO BgNVHQ8BAf8EBAMCAYYwQAYDVR0fBDkwNzA1oDOgMYYvaHR0cHM6Ly9hbmRyb2lk Lmdvb2dsZWFwaXMuY29tL2F0dGVzdGF0aW9uL2NybC8wDQYJKoZIhvcNAQELBQAD ggIBACDIw41L3KlXG0aMiS//cqrG+EShHUGo8HNsw30W1kJtjn6UBwRM6jnmiwfB Pb8VA91chb2vssAtX2zbTvqBJ9+LBPGCdw/E53Rbf86qhxKaiAHOjpvAy5Y3m00m qC0w/Zwvju1twb4vhLaJ5NkUJYsUS7rmJKHHBnETLi8GFqiEsqTWpG/6ibYCv7rY DBJDcR9W62BW9jfIoBQcxUCUJouMPH25lLNcDc1ssqvC2v7iUgI9LeoM1sNovqPm QUiG9rHli1vXxzCyaMTjwftkJLkf6724DFhuKug2jITV0QkXvaJWF4nUaHOTNA4u JU9WDvZLI1j83A+/xnAJUucIv/zGJ1AMH2boHqF8CY16LpsYgBt6tKxxWH00XcyD CdW2KlBCeqbQPcsFmWyWugxdcekhYsAWyoSf818NUsZdBWBaR/OukXrNLfkQ79Iy ZohZbvabO/X+MVT3rriAoKc8oE2Uws6DF+60PV7/WIPjNvXySdqspImSN78mflxD qwLqRBYkA3I75qppLGG9rp7UCdRjxMl8ZDBld+7yvHVgt1cVzJx9xnyGCC23Uaic MDSXYrB4I4WHXPGjxhZuCuPBLTdOLU8YRvMYdEvYebWHMpvwGCF6bAx3JBpIeOQ1 wDB5y0USicV3YgYGmi+NZfhA4URSh77Yd6uuJOJENRaNVTzk -----END CERTIFICATE-----
-----BEGIN CERTIFICATE----- MIIFHDCCAwSgAwIBAgIJANUP8luj8tazMA0GCSqGSIb3DQEBCwUAMBsxGTAXBgNV BAUTEGY5MjAwOWU4NTNiNmIwNDUwHhcNMTkxMTIyMjAzNzU4WhcNMzQxMTE4MjAz NzU4WjAbMRkwFwYDVQQFExBmOTIwMDllODUzYjZiMDQ1MIICIjANBgkqhkiG9w0B AQEFAAOCAg8AMIICCgKCAgEAr7bHgiuxpwHsK7Qui8xUFmOr75gvMsd/dTEDDJdS Sxtf6An7xyqpRR90PL2abxM1dEqlXnf2tqw1Ne4Xwl5jlRfdnJLmN0pTy/4lj4/7 tv0Sk3iiKkypnEUtR6WfMgH0QZfKHM1+di+y9TFRtv6y//0rb+T+W8a9nsNL/ggj nar86461qO0rOs2cXjp3kOG1FEJ5MVmFmBGtnrKpa73XpXyTqRxB/M0n1n/W9nGq C4FSYa04T6N5RIZGBN2z2MT5IKGbFlbC8UrW0DxW7AYImQQcHtGl/m00QLVWutHQ oVJYnFPlXTcHYvASLu+RhhsbDmxMgJJ0mcDpvsC4PjvB+TxywElgS70vE0XmLD+O JtvsBslHZvPBKCOdT0MS+tgSOIfga+z1Z1g7+DVagf7quvmag8jfPioyKvxnK/Eg sTUVi2ghzq8wm27ud/mIM7AY2qEORR8Go3TVB4HzWQgpZrt3i5MIlCaY504LzSRi igHCzAPlHws+W0rB5N+er5/2pJKnfBSDiCiFAVtCLOZ7gLiMm0jhO2B6tUXHI/+M RPjy02i59lINMRRev56GKtcd9qO/0kUJWdZTdA2XoS82ixPvZtXQpUpuL12ab+9E aDK8Z4RHJYYfCT3Q5vNAXaiWQ+8PTWm2QgBR/bkwSWc+NpUFgNPN9PvQi8WEg5Um AGMCAwEAAaNjMGEwHQYDVR0OBBYEFDZh4QB8iAUJUYtEbEf/GkzJ6k8SMB8GA1Ud IwQYMBaAFDZh4QB8iAUJUYtEbEf/GkzJ6k8SMA8GA1UdEwEB/wQFMAMBAf8wDgYD VR0PAQH/BAQDAgIEMA0GCSqGSIb3DQEBCwUAA4ICAQBOMaBc8oumXb2voc7XCWnu XKhBBK3e2KMGz39t7lA3XXRe2ZLLAkLM5y3J7tURkf5a1SutfdOyXAmeE6SRo83U h6WszodmMkxK5GM4JGrnt4pBisu5igXEydaW7qq2CdC6DOGjG+mEkN8/TA6p3cno L/sPyz6evdjLlSeJ8rFBH6xWyIZCbrcpYEJzXaUOEaxxXxgYz5/cTiVKN2M1G2ok QBUIYSY6bjEL4aUN5cfo7ogP3UvliEo3Eo0YgwuzR2v0KR6C1cZqZJSTnghIC/vA D32KdNQ+c3N+vl2OTsUVMC1GiWkngNx1OO1+kXW+YTnnTUOtOIswUP/Vqd5SYgAI mMAfY8U9/iIgkQj6T2W6FsScy94IN9fFhE1UtzmLoBIuUFsVXJMTz+Jucth+IqoW Fua9v1R93/k98p41pjtFX+H8DslVgfP097vju4KDlqN64xV1grw3ZLl4CiOe/A91 oeLm2UHOq6wn3esB4r2EIQKb6jTVGu5sYCcdWpXr0AUVqcABPdgL+H7qJguBw09o jm6xNIrw2OocrDKsudk/okr/AwqEyPKw9WnMlQgLIKw1rODG2NvU9oR3GVGdMkUB ZutL8VuFkERQGt6vQ2OCw0sV47VMkuYbacK/xyZFiRcrPJPb41zgbQj9XAEyLKCH ex0SdDrx+tWUDqG8At2JHA== -----END CERTIFICATE-----
If the root certificate in the attestation chain you receive is one of the above certificates and none of the certificates in the chain have been revoked, you know that:
- Your key is in hardware that Google believes to be secure; and
- It has the properties described in the attestation certificate.
If the attestation chain has any other root certificate, then Google does not make any claims about the security of the hardware. This does not mean that your key is compromised, just that the attestation does not prove that the key is in security hardware, and you should adjust your security assumptions accordingly.
If the root certificate is not in the above list, there are two likely reasons:
- Most likely, the device launched with an Android version less than 7.0 and it does not support hardware attestation. In this case, Android has a software implementation of attestation which produces the same sort of attestation certificate, but signed with a key hardcoded in Android source code. Because this signing key is not a secret, the attestation could have been created by an attacker pretending to provide secure hardware.
- The other likely reason is that the device is not a Google Play device. In that case, the device maker is free to create their own root and to make whatever claims they like about what the attestation means. Refer to the device maker's documentation. Note that as of this writing Google is not aware of any device makers who have done this.
Certificate Revocation Status List
Attestation keys can be revoked for a number of reasons, including mishandling or suspected extraction by an attacker. For this reason, it's critical that the status of each certificate in an attestation chain be checked against the official certificate revocation status list. This list is maintained by Google and published at: https://android.googleapis.com/attestation/status. This URL returns a JSON file containing the revocation status for any certificates that don't have a normal valid status. The format of the JSON file adheres to the following JSON Schema (draft 07) definition:
{ "$schema": "http://json-schema.org/draft-07/schema#", "type": "object", "properties": { "entries": { "description" : "Each entry represents the status of an attestation key. The dictionary-key is the certificate serial number in lowercase hex.", "type": "object", "propertyNames": { "pattern": "^[a-f0-9]*$" }, "additionalProperties": { "type": "object", "properties": { "status": { "description": "[REQUIRED] Current status of the key.", "type": "string", "enum": ["REVOKED", "SUSPENDED"] }, "expires": { "description": "[OPTIONAL] UTC date when certificate expires in ISO8601 format (YYYY-MM-DD). Can be used to clear expired certificates from the status list.", "type": "string", "format": "date" }, "reason": { "description": "[OPTIONAL] Reason for the current status.", "type": "string", "enum": ["UNSPECIFIED", "KEY_COMPROMISE", "CA_COMPROMISE", "SUPERSEDED", "SOFTWARE_FLAW"] }, "comment": { "description": "[OPTIONAL] Free form comment about the key status.", "type": "string", "maxLength": 140 } }, "required": ["status"], "additionalProperties": false } } }, "required": ["entries"], "additionalProperties": false }
Example certificate revocation status list:
{ "entries": { "2c8cdddfd5e03bfc": { "status": "REVOKED", "expires": "2020-11-13", "reason": "KEY_COMPROMISE", "comment": "Key stored on unsecure system" }, "c8966fcb2fbb0d7a": { "status": "SUSPENDED", "reason": "SOFTWARE_FLAW", "comment": "Bug in keystore causes this key malfunction b/555555" } } }
Legacy CRLs
The CRL urls embedded in legacy attestation certificates will continue to operate. New attestation certificates will no longer contain a CRL url extension. The status of legacy certificates will also be included in the attestation status list, so developers can safely switch to using the attestation status list for both new and legacy certificates. An example of how to correctly verify Android attestation keys is included in the Key Attestation sample.
Certificate extension data schema
Key attestation verifies the extension data that appears in the first certificate within the chain in a device's hardware-backed keystore. The certificate stores the information according to an ASN.1 schema. To view the schema corresponding to the attestation version that you're using, select the appropriate tab in the following schema listing:
Version 3
KeyDescription ::= SEQUENCE { attestationVersion 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, 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, trustedConfirmationRequired [508] EXPLICIT NULL OPTIONAL, unlockedDeviceRequired [509] EXPLICIT NULL OPTIONAL, allApplications [600] EXPLICIT NULL OPTIONAL, applicationId [601] EXPLICIT OCTET_STRING OPTIONAL, creationDateTime [701] EXPLICIT INTEGER OPTIONAL, origin [702] EXPLICIT INTEGER OPTIONAL, rootOfTrust [704] EXPLICIT RootOfTrust OPTIONAL, osVersion [705] EXPLICIT INTEGER OPTIONAL, osPatchLevel [706] EXPLICIT INTEGER OPTIONAL, attestationApplicationId [709] EXPLICIT OCTET_STRING OPTIONAL, attestationIdBrand [710] EXPLICIT OCTET_STRING OPTIONAL, attestationIdDevice [711] EXPLICIT OCTET_STRING OPTIONAL, attestationIdProduct [712] EXPLICIT OCTET_STRING OPTIONAL, attestationIdSerial [713] EXPLICIT OCTET_STRING OPTIONAL, attestationIdImei [714] EXPLICIT OCTET_STRING OPTIONAL, attestationIdMeid [715] EXPLICIT OCTET_STRING OPTIONAL, attestationIdManufacturer [716] EXPLICIT OCTET_STRING OPTIONAL, attestationIdModel [717] EXPLICIT OCTET_STRING OPTIONAL, vendorPatchLevel [718] EXPLICIT INTEGER OPTIONAL, bootPatchLevel [719] EXPLICIT INTEGER OPTIONAL, } RootOfTrust ::= SEQUENCE { verifiedBootKey OCTET_STRING, deviceLocked BOOLEAN, verifiedBootState VerifiedBootState, verifiedBootHash OCTET_STRING, } VerifiedBootState ::= ENUMERATED { Verified (0), SelfSigned (1), Unverified (2), Failed (3), }
Version 2
KeyDescription ::= SEQUENCE { attestationVersion 2, attestationSecurityLevel SecurityLevel, keymasterVersion INTEGER, keymasterSecurityLevel SecurityLevel, attestationChallenge OCTET_STRING, uniqueId OCTET_STRING, softwareEnforced AuthorizationList, teeEnforced AuthorizationList, } SecurityLevel ::= ENUMERATED { Software (0), TrustedEnvironment (1), } 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, 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, 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, rootOfTrust [704] EXPLICIT RootOfTrust OPTIONAL, osVersion [705] EXPLICIT INTEGER OPTIONAL, osPatchLevel [706] EXPLICIT INTEGER OPTIONAL, attestationApplicationId [709] EXPLICIT OCTET_STRING OPTIONAL, attestationIdBrand [710] EXPLICIT OCTET_STRING OPTIONAL, attestationIdDevice [711] EXPLICIT OCTET_STRING OPTIONAL, attestationIdProduct [712] EXPLICIT OCTET_STRING OPTIONAL, attestationIdSerial [713] EXPLICIT OCTET_STRING OPTIONAL, attestationIdImei [714] EXPLICIT OCTET_STRING OPTIONAL, attestationIdMeid [715] EXPLICIT OCTET_STRING OPTIONAL, attestationIdManufacturer [716] EXPLICIT OCTET_STRING OPTIONAL, attestationIdModel [717] EXPLICIT OCTET_STRING OPTIONAL, } RootOfTrust ::= SEQUENCE { verifiedBootKey OCTET_STRING, deviceLocked BOOLEAN, verifiedBootState VerifiedBootState, } VerifiedBootState ::= ENUMERATED { Verified (0), SelfSigned (1), Unverified (2), Failed (3), }
Version 1
KeyDescription ::= SEQUENCE { attestationVersion 1, attestationSecurityLevel SecurityLevel, keymasterVersion INTEGER, keymasterSecurityLevel SecurityLevel, attestationChallenge OCTET_STRING, uniqueId OCTET_STRING, softwareEnforced AuthorizationList, teeEnforced AuthorizationList, } SecurityLevel ::= ENUMERATED { Software (0), TrustedEnvironment (1), } 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, 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, 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, rootOfTrust [704] EXPLICIT RootOfTrust OPTIONAL, osVersion [705] EXPLICIT INTEGER OPTIONAL, osPatchLevel [706] EXPLICIT INTEGER OPTIONAL, } RootOfTrust ::= SEQUENCE { verifiedBootKey OCTET_STRING, deviceLocked BOOLEAN, verifiedBootState VerifiedBootState, } VerifiedBootState ::= ENUMERATED { Verified (0), SelfSigned (1), Unverified (2), Failed (3), }
The following list presents a description of each element within the schema:
KeyDescription
This sequence of values presents general information about the key pair being verified through key attestation and provides easy access to additional details.
-
attestationVersion
- The version of the key attestation feature.
-
attestationSecurityLevel
-
The security level of the attestation.
Warning: Although it is possible to attest keys that are stored in the Android system—that is, if the value of
attestationSecurityLevel
is set to Software—you cannot trust these attestations if the Android system becomes compromised. -
keymasterVersion
- The version of the Keymaster hardware abstraction layer (HAL). Use 0 to represent version 0.2 or 0.3, 1 to represent version 1.0, and 2 to represent version 2.0.
-
keymasterSecurityLevel
- The security level of the Keymaster implementation.
-
uniqueId
-
This value identifies the device—but only for a limited period of time. It is
computed and
is only used by system apps. In all other apps,
uniqueId
is empty. -
softwareEnforced
- Optional. The Keymaster authorization list that is enforced by the Android system, not by the device's TEE.
-
teeEnforced
- Optional. The Keymaster authorization list that is enforced by the device's TEE.
SecurityLevel
This data structure indicates the extent to which a software feature, such as a key pair, is protected based on its location within the device.
Because the data structure is an enumeration, it takes on exactly one of the following values:
- Software
- The logic for creating and managing the feature is implemented in the Android system. For the purposes of creating and storing key pairs, this location is less secure than the TEE but is more secure than your app's process space.
- TrustedEnvironment
- The logic for creating and managing the feature is implemented in secure hardware, such as a TEE. For the purposes of creating and storing key pairs, this location is more secure because secure hardware is highly resistant to remote compromise.
- StrongBox
- The logic for creating and managing the feature is implemented in a dedicated hardware security module. For the purposes of creating and storing key pairs, this location is more secure because it is highly resistant to remote compromise and hardware attacks against the module.
AuthorizationList
This data structure contains the key pair's properties themselves, as defined in the Keymaster hardware abstraction layer (HAL). You compare these values to the device's current state or to a set of expected values to verify that a key pair is still valid for use in your app.
Each field name corresponds to a similarly-named Keymaster authorization tag.
For example, the keySize
field in an authorization list
corresponds to the
Tag::KEY_SIZE
Keymaster authorization tag.
Each field in the following list is optional:
-
purpose
-
Corresponds to the
Tag::PURPOSE
Keymaster authorization tag, which uses a tag ID value of 1. -
algorithm
-
Corresponds to the
Tag::ALGORITHM
Keymaster authorization tag, which uses a tag ID value of 2.In an attestation
AuthorizationList
object, the algorithm value is alwaysRSA
orEC
. -
keySize
-
Corresponds to the
Tag::KEY_SIZE
Keymaster authorization tag, which uses a tag ID value of 3. -
digest
-
Corresponds to the
Tag::DIGEST
Keymaster authorization tag, which uses a tag ID value of 5. -
padding
-
Corresponds to the
Tag::PADDING
Keymaster authorization tag, which uses a tag ID value of 6. -
ecCurve
-
Corresponds to the
Tag::EC_CURVE
Keymaster authorization tag, which uses a tag ID value of 10.The set of parameters used to generate an elliptic curve (EC) key pair, which uses ECDSA for signing and verification, within the Android system keystore.
-
rsaPublicExponent
-
Corresponds to the
Tag::RSA_PUBLIC_EXPONENT
Keymaster authorization tag, which uses a tag ID value of 200. -
rollbackResistance
-
Present only in key attestation version 3.
Corresponds to the
Tag::ROLLBACK_RESISTANT
Keymaster authorization tag, which uses a tag ID value of 303. -
activeDateTime
-
Corresponds to the
Tag::ACTIVE_DATETIME
Keymaster authorization tag, which uses a tag ID value of 400. -
originationExpireDateTime
-
Corresponds to the
Tag::ORIGINATION_EXPIRE_DATETIME
Keymaster authorization tag, which uses a tag ID value of 401. -
usageExpireDateTime
-
Corresponds to the
Tag::USAGE_EXPIRE_DATETIME
Keymaster authorization tag, which uses a tag ID value of 402. -
noAuthRequired
-
Corresponds to the
Tag::NO_AUTH_REQUIRED
Keymaster authorization tag, which uses a tag ID value of 503. -
userAuthType
-
Corresponds to the
Tag::USER_AUTH_TYPE
Keymaster authorization tag, which uses a tag ID value of 504. -
authTimeout
-
Corresponds to the
Tag::AUTH_TIMEOUT
Keymaster authorization tag, which uses a tag ID value of 505. -
allowWhileOnBody
-
Corresponds to the
Tag::ALLOW_WHILE_ON_BODY
Keymaster authorization tag, which uses a tag ID value of 506.Allows the key to be used after its authentication timeout period if the user is still wearing the device on their body. Note that a secure on-body sensor determines whether the device is being worn on the user's body.
-
trustedUserPresenceRequired
-
Present only in key attestation version 3.
Corresponds to the
Tag::TRUSTED_USER_PRESENCE_REQUIRED
Keymaster authorization tag, which uses a tag ID value of 507.Specifies that this key is usable only if the user has provided proof of physical presence. Several examples include the following:
- For a StrongBox key, a hardware button hardwired to a pin on the StrongBox device.
- For a TEE key, fingerprint authentication provides proof of presence as long as the TEE has exclusive control of the scanner and performs the fingerprint matching process.
-
trustedConfirmationRequired
-
Present only in key attestation version 3.
Corresponds to the
Tag::TRUSTED_CONFIRMATION_REQUIRED
Keymaster authorization tag, which uses a tag ID value of 508.Specifies that the key is usable only if the user provides confirmation of the data to be signed using an approval token. For more information about how to obtain user confirmation, see Android Protected Confirmation.
Note: This tag is only applicable to keys that use the
SIGN
purpose. -
unlockedDeviceRequired
-
Present only in key attestation version 3.
Corresponds to the
Tag::UNLOCKED_DEVICE_REQUIRED
Keymaster authorization tag, which uses a tag ID value of 509. -
allApplications
-
Corresponds to the
Tag::ALL_APPLICATIONS
Keymaster authorization tag, which uses a tag ID value of 600.Indicates whether all apps on a device can access the key pair.
-
applicationId
-
Corresponds to the
Tag::APPLICATION_ID
Keymaster authorization tag, which uses a tag ID value of 601. -
creationDateTime
-
Corresponds to the
Tag::CREATION_DATETIME
Keymaster authorization tag, which uses a tag ID value of 701. -
origin
-
Corresponds to the
Tag::ORIGIN
Keymaster authorization tag, which uses a tag ID value of 702. -
rollbackResistant
-
Present only in key attestation versions 1 and 2.
Corresponds to the
Tag::ROLLBACK_RESISTANT
Keymaster authorization tag, which uses a tag ID value of 703. -
rootOfTrust
-
Corresponds to the
Tag::ROOT_OF_TRUST
Keymaster authorization tag, which uses a tag ID value of 704.For more details, see the section describing the RootOfTrust data structure.
-
osVersion
-
Corresponds to the
Tag::OS_VERSION
Keymaster authorization tag, which uses a tag ID value of 705.The version of the Android operating system associated with the Keymaster, specified as a six-digit integer. For example, version 8.1.0 is represented as 080100.
Only Keymaster version 1.0 or higher includes this value in the authorization list.
-
osPatchLevel
-
Corresponds to the
Tag::PATCHLEVEL
Keymaster authorization tag, which uses a tag ID value of 706.The month and year associated with the security patch that is being used within the Keymaster, specified as a six-digit integer. For example, the August 2018 patch is represented as 201808.
Only Keymaster version 1.0 or higher includes this value in the authorization list.
-
attestationApplicationId
-
Present only in key attestation versions 2 and 3.
Corresponds to the
Tag::ATTESTATION_APPLICATION_ID
Keymaster authorization tag, which uses a tag ID value of 709.For more details, see the section describing the AttestationApplicationId data structure.
-
attestationIdBrand
-
Present only in key attestation versions 2 and 3.
Corresponds to the
Tag::ATTESTATION_ID_BRAND
Keymaster tag, which uses a tag ID value of 710. -
attestationIdDevice
-
Present only in key attestation versions 2 and 3.
Corresponds to the
Tag::ATTESTATION_ID_DEVICE
Keymaster tag, which uses a tag ID value of 711. -
attestationIdProduct
-
Present only in key attestation versions 2 and 3.
Corresponds to the
Tag::ATTESTATION_ID_PRODUCT
Keymaster tag, which uses a tag ID value of 712. -
attestationIdSerial
-
Present only in key attestation versions 2 and 3.
Corresponds to the
Tag::ATTESTATION_ID_SERIAL
Keymaster tag, which uses a tag ID value of 713. -
attestationIdImei
-
Present only in key attestation versions 2 and 3.
Corresponds to the
Tag::ATTESTATION_ID_IMEI
Keymaster authorization tag, which uses a tag ID value of 714. -
attestationIdMeid
-
Present only in key attestation versions 2 and 3.
Corresponds to the
Tag::ATTESTATION_ID_MEID
Keymaster authorization tag, which uses a tag ID value of 715. -
attestationIdManufacturer
-
Present only in key attestation versions 2 and 3.
Corresponds to the
Tag::ATTESTATION_ID_MANUFACTURER
Keymaster authorization tag, which uses a tag ID value of 716. -
attestationIdModel
-
Present only in key attestation versions 2 and 3.
Corresponds to the
Tag::ATTESTATION_ID_MODEL
Keymaster tag, which uses a tag ID value of 717. -
vendorPatchLevel
-
Present only in key attestation version 3.
Corresponds to the
Tag::VENDOR_PATCHLEVEL
Keymaster authorization tag, which uses a tag ID value of 718.Specifies the vendor image security patch level that must be installed on the device for this key to be used. The value appears in the form YYYYMMDD, representing the date of the vendor security patch. For example, if a key were generated on an Android device with the vendor's August 1, 2018 security patch installed, this value would be 20180801.
-
bootPatchLevel
-
Present only in key attestation version 3.
Corresponds to the
Tag::BOOT_PATCHLEVEL
Keymaster authorization tag, which uses a tag ID value of 719.Specifies the kernel image security patch level that must be installed on the device for this key to be used. The value appears in the form YYYYMMDD, representing the date of the system security patch. For example, if a key were generated on an Android device with the system's August 5, 2018 security patch installed, this value would be 20180805.
RootOfTrust
This collection of values defines key information about the device's status.
Each field in the following list is required:
-
verifiedBootKey
-
A secure hash of the key that verifies the system image. It is recommended that you use the SHA-256 algorithm for this hash.
-
deviceLocked
- True if the device's bootloader is locked, which enables Verified Boot checking and prevents an unsigned device image from being flashed onto the device. For more information about this feature, see the Verifying Boot documentation.
-
verifiedBootState
- The boot state of the device, according to the Verified Boot feature.
-
verifiedBootHash
-
Present only in key attestation version 3.
A digest of all data protected by Verified Boot. For devices that use the Android Verified Boot implementation of Verified Boot, this value contains the digest of the VBMeta struct, or the Verified Boot metadata structure.
To learn more about how to calculate this value, see The VBMeta Digest.
VerifiedBootState
This data structure provides the device's current boot state, which represents the level of protection provided to the user and to apps after the device finishes booting. For more information about this feature, see the Boot State section within the Verifying Boot documentation.
This data structure is an enumeration, so it takes on exactly one of the following values:
- Verified
-
Indicates a full chain of trust, which includes the bootloader, the boot partition, and all verified partitions.
When the device is in this boot state, the
verifiedBootKey
is the hash of the device-embedded certificate, which the device manufacturer adds to the device's ROM at the factory. - SelfSigned
-
Indicates that the device-embedded certificate has verified the device's boot partition and that the signature is valid.
When the device is in this boot state, the
verifiedBootKey
is the hash of a user-installed certificate, which signs a boot partition that the user adds to the device in place of the original, manufacturer-provided boot partition. - Unverified
- Indicates that the user can modify the device freely. Therefore, the user is responsible for verifying the device's integrity.
- Failed
-
Indicates that the device has failed verification. The attestation
certificate should never use this value for
VerifiedBootState
.
AttestationApplicationId
This data structure reflects the Android platform's belief as to which apps are allowed to use the secret key material under attestation. The ID can comprise multiple packages if and only if multiple packages share the same UID. The octet string is itself formatted according to the following ASN.1 schema:
AttestationApplicationId ::= SEQUENCE { package_infos SET OF AttestationPackageInfo, signature_digests SET OF OCTET_STRING, } AttestationPackageInfo ::= SEQUENCE { package_name OCTET_STRING, version INTEGER, }
- package_infos
-
A set of
AttestationPackageInfo
objects, each providing a package's name and version number. - signature_digests
-
A set of SHA-256 digests of the app's signature blobs, as contained within the
signatures
field of thePackageInfo
that is returned upon a call togetPackageInfo()
. The following code snippet shows an example set:{SHA256(PackageInfo.signature[0]), SHA256(PackageInfo.signature[1]), ...}