Failed to derive attestation for a specific test in FIDO conformance tool

[abhijaikp99]

Hi,

I have implemented an mds3 FIDO server using Yubico webauthn library for passkey web authentication in my project.

After implementation, I've started testing the server with the FIDO conformance tool.
But for MakeCredential Response server test, Some tests are failing.

It throws an error : Registration verification failed: java.lang.IllegalArgumentException: Failed to derive trust for attestation key.

I've downloaded, extracted, and put into the folder example/fido-conformance-mds by clicking the button "Download Test Metadata" in the tool.
I have imported all the metadata files to the server (com.yubico.fido.metadata.MetadataBLOBPayload)
Created trustsource from (com.yubico.fido.metadata.FidoMetadataService)
allowUntrustedAttestation is set to false.

Test : P-5 Send a valid ServerAuthenticatorAttestationResponse with SELF "packed" attestation, for "ALG_SIGN_RSASSA_PKCSV15_SHA256_RAW" aka "RS256" algorithm, and check that server succeeds

What is the issue here? am I missing something?

Need the solution ASAP.

[emlun]

I'm not familiar with what exact behaviour the test suite expects, but at a glance this looks like the issue may be that you've set allowUntrustedAttestation(false) option on your RelyingParty instance.

A "self" attestation can never be a trusted attestation, because on its own it proves nothing. It has the same security characteristics as a self-signed certificate. The default RelyingParty settings do not require the attestation to be trusted, in order for "Self" and "None" attestation to work, but the trust evaluation is always returned via RegistrationResult.isAttestationTrusted() regardless of the allowUntrustedAttestation setting. allowUntrustedAttestation(false) essentially causes the registration to fail instead whenever isAttestationTrusted() would return false, which it always does for "Self" and "None" attestation since there is no way to establish trust in them.

Does that help?

[emlun]

Ah yes, I saw now that you explicitly mentioned:

allowUntrustedAttestation is set to false

so yeah, that's what's causing the test to fail. You'll have to run that test case with allowUntrustedAttestation(true) if you want it to pass.

[emlun]

Actually, there is one exception, in theory: if the self-attested key is itself one of the trust roots. See this test for an example:

java-webauthn-server/webauthn-server-core/src/test/scala/com/yubico/webauthn/RelyingPartyRegistrationSpec.scala

Lines 3563 to 3574 in 9933e58

	it("is accepted if untrusted attestation is not allowed, but the self attestation key is a trust anchor.") {
	val testData = RegistrationTestData.FidoU2f.SelfAttestation
	val selfAttestationCert = CertificateParser.parseDer(
	new AttestationObject(
	testData.attestationObject
	).getAttestationStatement.get("x5c").get(0).binaryValue()
	)
	val steps = finishRegistration(
	testData = testData,
	attestationTrustSource = Some(
	trustSourceWith(
	selfAttestationCert,

but note that this test uses a fido-u2f attestation, where the attestation statement still contains an x5c attribute but the attestation certificate has the same public key as the credential public key. This won't work for a packed "self" attestation, since those do not have the x5c attribute at all, but it should in theory work for a packed "basic" attestation with the credential public key identical to the attestation cert public key.

And as mentioned at the beginning, this is mostly theoretical: it'll only work in practice if the credential public key is static or otherwise known in advance, so that the RP can add it to its trust store. A freshly generated credential public key of course cannot be present in the RP trust store since it didn't yet exist before the registration ceremony.

[abhijaikp99]

Thanks for the quick reply.

So, the best solution that we can do to fix this is that we need to make allowUntrustedAttestation(true) for the packed self attestation requests?

The tool that I'm using for testing is FIDO official conformance tool.

Thanks again.

[emlun]

Yes.

[abhijaikp99]

Thanks @emlun

F-10 Send ServerAuthenticatorAttestationResponse with FULL "packed" attestation, with attStmt.x5c containing full chain, and check that server returns an error

F-2 Send ServerAuthenticatorAttestationResponse with SELF "packed" attestation, that contains full attestation, and check that server returns an error

The above test fails even when allowUntrustedAttestation is false/true. While registration it doesn't throw an error.

Every time the library accepts the request by default.