Add basic ACME device-attest-01 support
#712
Conversation
The `--permanent-identifier` flag can be used when requesting a certificate from `step-ca`. The ACME `device-attest-01` challenge method will be used to authorize the certificate request.
github-actions
bot
added
the
needs triage
hslatman
force-pushed
the
acme-attestation
branch
2 times, most recently
from
ab42da5 to
0026346
Compare
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
When performing Device Attestation with a specific `identifier`, the CLI will now first check if an `AK` is available with a certificate that contains a `PermanentIdentifier` SAN. If there's no chain, or the certificate doesn't contain the SAN, the CLI will perform an attestation flow.
Additionally, make the logic for selecting which TPM EK to use deterministic by always selecting the first RSA EK returned by the TPM, falling back to the first EC EK if it exists.
|
@maraino: There are still things to be improved w.r.t. using the |
utils/cautils/tpm.go
Outdated
|
|
||
| tpmAttestationCABaseURL := clictx.String("attestation-ca-url") | ||
| if tpmAttestationCABaseURL == "" { | ||
| return fmt.Errorf("flag %q cannot be empty", "--attestation-ca-url") |
There was a problem hiding this comment.
We should be consistent with these types of errors and use:
| return fmt.Errorf("flag %q cannot be empty", "--attestation-ca-url") | |
| return errs.RequiredFlag(ctx, "attestation-ca-url") |
| cli.StringFlag{ | ||
| Name: "attestation-ca-url", | ||
| Usage: "The base url of the Attestation CA to use", | ||
| }, | ||
| cli.StringFlag{ | ||
| Name: "attestation-ca-root", | ||
| Usage: "The path to the PEM <file> with trusted roots when connecting to the Attestation CA", | ||
| }, |
There was a problem hiding this comment.
In the future, we might want to add some defaults for this, ok for now.
There was a problem hiding this comment.
Although this does not require CGO support, having some of this logic out of the CLI would be nice. I think right now is ok to have it here, but we should think about other options.
Right now, with a YubiKey, the attestation statement is on step kms attest, but in that case is because it requires CGO. We will need to integrate this there too.
Other options are to create an ACMEAttester interface or perhaps just an extension to the Attester interface in the crypto KMS package. So we can use it in step-kms-plugin as well as here.
There was a problem hiding this comment.
Yes, I agree that it would be nice to have it all behind a single interface. The thing that made it less simple, at least for me, is the online Attestation CA involved: there are more parameters that the step kms attest with a TPM has to know about. And it probably also needs to keep track of some state, independent of the CLI. The TPMStore seems like a good candidate for that, but it somewhat muddies its responsibility, so I'm not entirely sure about it yet.
The
--attestation-uriand--attestation-ca-urlflags can be used when requesting acertificate from
step-ca. The ACMEdevice-attest-01challenge method will beused to authorize the certificate request when
--attestation-uriindicates usageof the TPM KMS (
tpmkms).The example below will perform the ACME
device-attest-01challenge verificationby including an AK certificate in the response to the ACME server, configured with
an ACME provisioner called
attestation.step ca certificate my-unique-id id.crt --attestation-uri tpmkms:name=first-key --provisioner attestation --attestation-ca-url https://attca:portIf no valid AK certificate is available, the client will try to enroll with the Attestation CA
at
https://attca:portfirst. If an AK is already available, the existing certificate and privatekey will be used. The AK private key to be used will be derived from the EK public key.
The private key for the certificate issued by the ACME server will be attested by the AK and
persisted in a
step contextaware directory, so that it can be reloaded when required.The ACME provisioner must be configured with the trusted root of the Attestation CA, so
that the AK certificate can be verified.
Two additional flags are present to help connecting to the Attestation CA:
--attestation-ca-rootcan be used to provide the path to a file with trusted root CAs touse when a TLS connection is made to the Attestation CA.
--attestation-ca-insecurecan be used to disable TLS validation when connectingto the Attestation CA.