Add android-key attestation format support
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!
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-keyis 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.
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.
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.
:white_check_mark: jbpin
:x: Jean-Baptiste Pin
Jean-Baptiste Pin seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
You have signed the CLA already but the status is still pending? Let us recheck it.