Certificates

[ucola]

Hi all

Thank you for this example!

Question, did I need the certificates? If yes, did I need to create this self? If yes, did you have any instructions how to do this?

[lbuchs]

You can't create own certificates, except you're a hardware manufacturer.
Certificates are issued by hardware manufacturer, e.g. by yubico, to verify that the authenticator is original. If you e.g. use webauthn for a company login, and you know that every employee has it's yubico usb stick, you can verify the login against the yubico root certificate to be sure that it's a yubico hardware.

If you want to protect logins for anyone with 2FA, it's probably nonsense to validate against a root ca, because you'll never have all root ca's of all hardware manufacturer, so you would unnecessary limit the hardware which is working with your app.

[ucola]

all right, thank you lbuchs.

If I select all certificats in your test application and then verify with apple macbook (fingerprint) we became "invalid root certificate". If I deselect all it works. Did you have any idea why? Is there an issue with the "apple" certificate?

[7tobias]

I have similar issues with TrustKey Solutions sticks. So even the TrustKeys certificates are registered with the MDS servers at the Fido Alliance it seems like the library does not query the MDS servers. Or does the library quere the MDS servers and you can then allow just a subset of the CAs with the checkboxes?!

https://fidoalliance.org/metadata/

[lbuchs]

this library does not query the metadata service, this library does not contain any certificate in its source. The certificates you can select at the demo page are just some examples located at it's _test folder.

[7tobias]

Thanks for clarification. That helps already. Anyway wouldn't it make sense to query MDS to avoid the need for every library user to manually takeing care of the ca certificates?

[lbuchs]

FIDO Alliance Metadata Service is not a live api, its designed for periodically downloading metadata. So a library querying the mds and save the certificates in some folder would be another project and has basically nothing to do with the authentication process itself (what this library is for).

[ucola]

@lbuchs we try again your certs on _test folder but without success. In your test application you have checked all certs as default

• Accept keys signed by apple root ca
• Accept keys signed by yubico root ca
• Accept keys signed by solokeys root ca
• Accept keys signed by hypersecu root ca
• Accept keys signed by google root ca
• Accept keys signed by Microsofts collection of trusted TPM root ca
• (Nothing checked = accept all)

In this case it is now working for us "invalid root certificate". If we deselect all it is working... Did you have an idea or what we do wrong? I.e. we want to use Finterprint / FaceID from Apple and Android.

[lbuchs]

as if I have written before, the certificate is not matching with the one in the demo app.

As this seems to be a issue confusing many, I've updated my demo page. Now you can see what's stored on the server side. Try again and check whats in the "certificate" saved on the server. Probably apple has a second one than the one in the _test directory, or is using none attestation format.

[ucola]

@lbuchs i was testing it on my own server with the _test and the certificates inside. I test right now with MacBook and I became this message "registration ok, but certificate does not match any of the selected root ca.". Did you see any security issues, if we use NO certificates?

[My1]

when you dont wanna care about certs and all you can also just turn off attestation as a whole by only selecting none in the format, that way you wouldnt need to worry about the certs at all.

also several clients (some browsers and windows 10) throw an extra warning when attestation is asked for so it's one less warning.

[lbuchs]

@My1 thats maybe the wrong way. Just add no root certificate but select all format, because browser will not switch to "none" for sure. e.g. Android always use android-safetynet format, never "none". If you provide no root certificate, library sets attestation to indirect, I think that's the better way Update: I'm wrong, you're right, if you use only "none", its working :-)

@ucola thats absolutely no problem if you just want to protect logins, there is no security issue. You only need a root certificate if you want to verify the device of the user - but in most cases all you need is to make sure a login is from the same device as the registered device, for this you don't need any certificate. Most services using webauthn like facebook, github, etc. don't verify root certificates.

[My1]

@lbuchs yeah if you set none the FIDO request it will also set the attestation parameter to none as the webauthn parameter is none or direct on this lib.

also in case of future devices with yet unknown attestations there's #25 open, so you can grab attestation at least for the devices you can.

@ucola I fully agree with lbuchs regarding the certs. in most cases you dont need to check against roots and in even more cases you dont even need any attestation at all.

[SeanHerbert]

Hey everyone,

I was curious how much security you lose without attestation. Without it, there is no way to be certain that the private key has a hardware cryptographic root of trust (never left the hardware). I assume it's possible to generate a credential where the private key may not be secret if attestation is not used. Does anyone know to what degree of confidence an RP can assume the private key is secret without using attestation?

[My1]

@SeanHerbert i would say it's the user's problem.

Fun fact there are already attested and certified fido devices where that's already the case (any u2f/fido2 device that doubles as cryptocoin hardware wallet, as these have a backup/restore function).

I'd maybe inform the user but not outright block anything unless it's for example q company service where the type of security keys are known.