Please let me know If not the correct place, it wasn’t clear where a Webauthn topic is most appropriate.
As the topic suggests, I’m implementing Webauthn, which allows devices that support u2f to authenticate. OnlyKey should work, but most Webauthn implementations do not have a critical piece of information needed to enable supporting the OnlyKey.
If you take a quick look at the Duo labs demo, they have support for Yubico and Solokeys.
This is not because there is some special relationship, business deal, or anything like that.
It is simply because it was easy to find the ‘device attestation certificate’ publicly for the trusted attestation roots that a server will accept authentication requests for;
If I can locate the OnlyKey ‘device attestation certificate’ I can contribute to Duo labs so that Onlykey gets wider adoption by any one who follows Duo labs when they are implementing Webauthn too (like I am). There are a few more locations that can achieve the same via demos like this.
The problem I am facing is OnlyKey do not seem to publicly provide their device attestation certificate, and I am not educated in webauthn enough myself to correctly ‘derive’ the proper device attestation certificate to utilise myself.
Can someone either;
provide a public link to the device attestation certificate for OnlyKey
let me know where to request the device attestation certificate from Onlykey if it is not public (strange it isn’t public)
educate me on why I don’t need a device attestation certificate for OnlyKey (maybe it is not following u2f specification the same as other compliant devices, and can work with webauthn some other way I am not aware of)
the onlykey already has a device attestation cert on it, you are likely referring to the issuer cert as there generally is no single attestation cert but rather one per batch, and all those issued/signed by the certificate above.
I think most people dont need to care about the device attestation in general. the only thing attestation does is providing the server with something to make sure it is a real device which can be helpful in settings where you have to make really sure the users cannot go with other device types for example.
no idea how your service goes but if it’s public facing it’s the users’ responsibility to care about their creds anyway, and just blocking all “unknown” fido devices likely wont be fun. also browsers can and sometimes do anonymize the U2F cert so that would screw you over too.
an unknown attestation should in most cases in my opinin not go much beyond a warning
However unfortunately you may not realise you’re completely off topic here.
You’re making statements in context to a user ‘most people’.
I have specifically phrased the post in the context of an implementer of webauthn i.e. establishing server and device trust through verification of an attestation. Which is security jargon for enabling a server to gain assurance a device is as it claims to be, and was not modified before the browser interaction, or after user interaction on the user computer if it was compromised, or in transit to the server from the user computer.
Specifically, quote ‘the onlykey already has a device attestation cert on it’ this is not what you think it is. There is no ‘device attestation cert’ exactly, it is just a “device certificate” as is the device cert that is unique to a device and is a private and never given to a server or external use of any kind.
An ‘attestation’ cert is public, it represents the device manufacturer not the device. I linked in my post to the webauthn repository that identifies this exact mechanism with yubico and solokey as the supported devices using such an attestation cert that I am looking for to enable support of onlykey.
with most people I meant most people running a service. (specifically public facing services).
I have implemented Webauthn and FIDO2 myself in some hobby things and have used FIDO stuff for about 4 and a half years by now.
because if you enforce attestation you get the annoying issue that unless you get really thorough you might lock out newer or smaller devices out, and users should be able to choose their FIDO devices. if it is a solo Hacker which does not have a typical attestation cert (in the sense that it either runs a custom one from the user or the default which is public knowledge incl private key) because it runs firmware the user has then so be it.
Obviously if you run something e.g. for your employees the situation is different.
also the cert stored on a device is decidedly not unique to the device in many if not most cases to prevent tracking users.
doesnt really help against modification by someone who has a FIDO device with its own attestation on registration tho because an attacker could if they really wanted replace the entire response with one from a different genuine FIDO device.
if you really need the root certs tho, FIDO has a metadata service where you can download a big jwt and you should be able to get most FIDO device data.
thank you again for providing your thoughts. However again you’re going off track talking about FIDO when this is specifically a U2F / webauthn discussion.
And I acknowledge your points about user lockout, however if you do not do verification you are trusting without verifying (so no assurance whatsoever) which offers little security and the hardware device factor is semantic and pointless security through obscurity.
In webauthn you can apply token binding verification to prevent tampering, so i acknowledge your point about attackers but you’re probably not doing token binding verification or use a library like Duo that documents they do token binding verification but do not functionally perform the verification in code I have found.
Hope this helps you better understand the importance of assurances for the security characteristics you assume are in place to actually apply
okay. have you tried looking at the metadata service (linked above) yet, a ton of stuff iirc including the attestation CAs are in there for basically anything in the FIDO space.
If I go to Yubico demo website and register with OnlyKey, I was able to get a attestation certificate although the website can’t decode it correctly. But if I copy the PEM certificate and save it as a .crt file, I was able to open it with Microsoft Windows.