Add android-key attestation format support

[jbpin]

Add a new attestationFormat for ACME device-attest-01 challenge to support Android attestation (android-key) as defined by WebAuthn and modify by RFC (sig use key authorization).

The implementation involve adding a CRL. ACME provider support a new configuration key called RootCRLs (rootCRLs in json). When 'android-key' is specified in attestationFormat and the list is not provided by the configuration, the list will be populated and updated
automatically based on the validation implementation procedure. Other ACME challenge could use IsRootRevoked and RootCRLs in the future independantly to android-key or device-attest-01 challenge.

Name of feature:

android-key attestation support for device-attest-01 challenge

Pain or issue this feature alleviates:

All to use device identifier certificate issuing on Android devices

Why is this important to the project (if not answered above):

The project already support Apple, so supporting Android is a plus.

Is there documentation on how to use this feature? If so, where?

This PR only provide a new attestationFormat called android-key

In what environments or workflows is this feature supported?

ACME provisionner with device_attest_01 and attestationFormat android-key. The device need to be managed by a MDM and an ACME client for android should be deployed

In what environments or workflows is this feature explicitly NOT supported (if any)?

Supporting links/other PRs/issues:

💔Thank you!

[jbpin]

Hi,
This PR can be test with a provisioner config like this :

{
            "attestationFormats": [
              "android-key"
            ],
            "challenges": [
              "device-attest-01"
            ],
            "claims": {
              "defaultTLSCertDuration": "2h",
              "maxTLSCertDuration": "8h"
            },
            "name": "android-acme",
            "type": "ACME"
          },

However, this PR will require an update to linkedca for two reason:

• android-key is not supported on attestionFormat [in the proto].(https://github.com/smallstep/linkedca/blob/339b487a925e0cf176a55133a755a1a40e602c35/spec/linkedca/provisioners.proto#L149).
• the new RootCRLs can't be included in ether ca.json nor step cli, so we can't override the default behavior that consist of loading the Android CRL Json

The CRL List is cached for 24h and refreshed when android-key attestation validation occurred passed this delay.

I will be happy to reply to any comments or suggestions.

[hslatman]

Hey @jbpin,

Looking quite good overall. Many suggestions are stylistic; feel free to combine them into your own commit(s).

I'd like to test this myself with a device too to inspect the full X5C that's provided. Or, alternatively, it would be nice to get a chain from your testing. There's some surprising thing in the code and the Google docs, so I just want to make sure things are correct.

Functionally, and kind of expected, the biggest thing that needs some attention/changes is fetching and refreshing the revoked attestation certificate serials. Eventually that logic needs to become "more pluggable" because of the way we integrate changes into our hosted version. Concretely, it would not be necessary to refetch the revocation list for each hosted authority, as it would simply be retrieving the same list for each. I think it'll come down to going with a basic version for now, and then we may do some changes to make it compatible with our platform ourselves, but we'll have to see how things roll.

[jbpin]

Hi @hslatman,
I'm back from vacation, I will implement the suggestion and change a bit the code. It looks like there are some changes since this implementation on Google side : https://developer.android.com/privacy-and-security/security-key-attestation

We will be able to implement the attestationRoots instead of key and support ECDSA as well.

[jbpin]

This line ensure that the hardware identifier match the permanent-identifier. I've updated the comment.
There are actually severals others checks that can be done, like verified boot, but seems interested to leave that to a webhook validation. What do you think ?

[CLAassistant]

All committers have signed the CLA.

[hslatman]

Closing this, as its functionality has been merged via #2749.