Windows Hello - Attestation verification

[CyrilCadoux]

Hello,

I have implemented attestation verification + custom filtering for FIDO2 / U2F devices. Everything seems to work fine: the blob is correctly retrieved & parsed, and we are able to test different scenario which comply (or not) to our custom filters. We are basically only accepting FIDO_CERTIFIED* devices. There is no problem with FIDO2 or U2F Yubikeys.

I only have a problem with Windows Hello Hardware. There was no problem registering Windows Hello before attestation was verified, but now it seems impossible. It does not pass the result.isAttestationTrusted() call at the end of the registration ceremony.

I suspect that something with the attestation certificate on the mds side (or on my inner Windows Hello side) is wrong, but it is of course hard to check.

My question is, as developpers, have you already managed to pass this attestationVerification with Windows Hello ? I could not find any useful resource about this problem on other websites...

Any input appreciated, thanks in advance !

Cheers,

Cyril

[emlun]

Hi! It's likely that Windows is generating tpm attestation statements, which you can confirm by inspecting the "fmt" attribute in the attestationObject (for example using this tool).

tpm attestation is currently not supported by this library, but will be supported in the next release. The release is currently scheduled for October, but please let us know if you need it sooner. We can probably work something out.

[CyrilCadoux]

Ok, nice to know. There is no rush on my side, I can wait for October. It gives me time to understand a little bit how ATTESTATION_CA and ANONYMIZATION_CA attestation types work.

I am just trying to understand how we can support the most cases at the same time. Is it possible to configure the same RelyingParty object to support all of the attestation types ? Or do we have to guess which attestation type is needed prior to the RelyingParty instantiation (for example if we need to provide external CA)?

So if we want to use WindowsHello with tpm attestation, must we set the AttestationConveyancePreference to INDIRECT?

[emlun]

All attestation types are always supported, you don't need to guess anything up front.

But note the difference between attestation type and attestation statement format. Different attestation statement formats require different signature verification procedures, and thus different code paths to support, but the attestation type is a property determined during the verification procedure and is not directly represented in the attestation data structure.

ATTESTATION_CA and ANONYMIZATION_CA are essentially the same thing. I'm not sure why Apple wanted to add ANONYMIZATION_CA as a distinct case in the spec.

As of the next release, the library will support all attestation statement formats in the spec except for android-key (but we do support android-safetynet). We intend to add support for android-key eventually, but we don't currently have a concrete plan for when.

So if we want to use WindowsHello with tpm attestation, must we set the AttestationConveyancePreference to INDIRECT?

Short answer is no, you probably want DIRECT. I'm not sure how Windows behaves if you set INDIRECT, but it instructs the browser that it's fine with you if the browser anonymizes the attestation before passing it on. For example, Chrome has expressed some ideas about sending the authenticator's attestation off to some Google server that verifies it and then returns a new attestation from Google that just says "trustworthy" or "not trustworthy" without revealing the specific authenticator model. I don't know if they've actually implemented something like that, so it may be that INDIRECT and DIRECT happen to behave the same way right now. But if you want the browser to not insert an attestation proxy like that, you should use DIRECT to tell the browser that you want the original attestation statement from the authenticator.

[CyrilCadoux]

Ok, thanks a lot !
I'll go through the documentation to try to understand all these usecases a bit better.

Have a nice day !