support for attestation extension

[Anti-Myon]

I would like to extend x509.py to support the X509v3 Extension «AttestationExtension» (OID «1.3.6.1.4.1.11129.2.1.17»).

The definition is outlined under https://developer.android.com/training/articles/security-key-attestation.html.

Most added classes are straight forward. However, there are 2 classes which are hacky and need to be improved (they might be even at the wrong place): • class AttestationApplicationIdWrapper(ParsableOctetString) • class UnixTimestamp(Integer)

Please advise.

[MatthiasValvekens]

Just for my information: this OID is in a private arc owned by Google, and the documentation you cite is Android-specific. Is this attestation extension format also used by other vendors? Is it standardised somewhere?

I can't check right now, but IIRC YubiKeys use a slightly different mechanism. Not that that's a problem, but if it's really something specific to Google, then maybe the generic x509 module isn't the right place. :)

[Anti-Myon]

It's an Android standard, shared by all OEM, i.e. all manufacturer / vendors of Android powered devices.

Attestation will become important for all HW generated / based keys. FIDO2 defines also attestation extensions.

Attestation extensions will always belong to the x509v3 certificate extensions.

Where would be the right place?

[bparmentier]

How should the different versions of the attestation structure be handled? E.g. I have a certificate with attestation_version=2 (Keymaster version 3.0) and attestation_security_level=1 (TrustedEnvironment) and it fails to parse completely because _Field "verified_boothash" is missing from structure while parsing asn1crypto.x509.RootOfTrust.

[APCDemo]

Just for my information: this OID is in a private arc owned by Google, and the documentation you cite is Android-specific. Is this attestation extension format also used by other vendors? Is it standardised somewhere?

I can't check right now, but IIRC YubiKeys use a slightly different mechanism. Not that that's a problem, but if it's really something specific to Google, then maybe the generic x509 module isn't the right place. :)

It is an Android standard. As such, all OEM producing Android powered phones comply to it. There is a good description on the android dev website: https://developer.android.com/privacy-and-security/security-key-attestation

Android Key Attestation holds significant relevance within the mobile device landscape, particularly for approximately 85% of devices, reflecting the dominant market share occupied by Android-powered smartphones and tablets.

[APCDemo]

How should the different versions of the attestation structure be handled? E.g. I have a certificate with attestation_version=2 (Keymaster version 3.0) and attestation_security_level=1 (TrustedEnvironment) and it fails to parse completely because _Field "verified_boothash" is missing from structure while parsing asn1crypto.x509.RootOfTrust.

Ideally, all 6 versions of the key attestation extension has OID 1.3.6.1.4.1.11129.2.1.17 would be implemented:

• Version 200
• Version 100
• Version 4
• Version 3
• Version 2
• Version 1

All schemas corresponding to the attestation version are given on the android dev web site: https://developer.android.com/privacy-and-security/security-key-attestation#attestation-v1