Root Certificate explicitly trusted by the FIDO Alliance?
570 views
Skip to first unread message
Jay Kim
Jun 23, 2015, 4:08:20 AM6/23/15
to fido...@fidoalliance.org
Hi All.
In the glossary document, Attestation Root Certificate means "A root certificate explicitly trusted by the FIDO
Alliance, to which Attestation Certificates chain to."
I don't clearly understand that meaning of "explicitly trusted".
Could you please explain this?
Thanks
Fred Le Tamanoir (NEOWAVE.FR)
Jul 6, 2015, 4:05:38 AM7/6/15
to fido...@fidoalliance.org
Don't bother, this root certificate does not exist.
Anyway, noone seems to really care about Attestation Certificates in FIDO 1.0...
--
Fred
Arshad Noor
Jul 6, 2015, 2:18:42 PM7/6/15
to fido...@fidoalliance.org
Hi Fred,
I would disagree with your second statement. As a company that has been building and supporting PKIs for the last 14 years - and still doing so - and, as a manufacturer of a FIDO U2F server, we do care. But, until FIDO U2F Authenticator manufacturers start using Attestation certificates (that conform to established best-practices in the PKI industry), there is little a FIDO Server can do (other than reject the Key-Registration).
I believe there was some discussion in 2014 (n the TWG) that as the ecosystem was getting started, the servers had to be a little flexible to allow Authenticator manufacturers to get their protocol implementations down correctly and inter-operate before focusing on validating Attestation Certificates.
Now that there appear to be no less than a dozen U2F Authenticators that are FIDO Ready or FIDO Certified - which means that they interoperate at a protocol layer, but says little about the Attestation Certificate - perhaps the Technical Working Groups will start tightening that up this year.
Arshad Noor
StrongAuth, inc.
I would disagree with your second statement. As a company that has been building and supporting PKIs for the last 14 years - and still doing so - and, as a manufacturer of a FIDO U2F server, we do care. But, until FIDO U2F Authenticator manufacturers start using Attestation certificates (that conform to established best-practices in the PKI industry), there is little a FIDO Server can do (other than reject the Key-Registration).
I believe there was some discussion in 2014 (n the TWG) that as the ecosystem was getting started, the servers had to be a little flexible to allow Authenticator manufacturers to get their protocol implementations down correctly and inter-operate before focusing on validating Attestation Certificates.
Now that there appear to be no less than a dozen U2F Authenticators that are FIDO Ready or FIDO Certified - which means that they interoperate at a protocol layer, but says little about the Attestation Certificate - perhaps the Technical Working Groups will start tightening that up this year.
Arshad Noor
StrongAuth, inc.
--
Fred Le Tamanoir (NEOWAVE.FR)
Jul 6, 2015, 4:10:09 PM7/6/15
to fido...@fidoalliance.org
Even without having a hierarchically chained FIDO alliance root CA, it would be great if manufacturers (like us) were forced to give their own CA info and if FIDO Alliance was in charge of maintaining the listing in a centralized place... available to authentication servers...
...and by the way, yes, it seems FIDO 2.0 will have better security options about these Attestation information (because in U2F 1.0 you can simply copy/paste any manufacturer Attestation certificate to forge a "fake" device).
I am confident this will soon be improved and that FIDO 2.0 will be closer to standard smart card based PKI architectures we all learned to love (and hate regarding the missing link to to web/cloud :) ).
Regards,
--
Fred
Arshad Noor
Jul 6, 2015, 5:10:52 PM7/6/15
to fido...@fidoalliance.org
Hi Fred,
Where did you get that notion (highlighted in red)? It is incorrect, because you CANNOT paste any manufacturer's Attestation Certificate to pass-off as an authentic U2F device. One may be able to sell such a device if someone merely looks at the Attestation Certificate, but it will never work with any authentic FIDO Ready/Certified U2F server.
The U2F protocol requires that the U2F Authenticator MUST digitally sign a number of parameters in the RegistrationData (see attached) to attest that the user's key-pair were generated in the "device". While most elements of the RegistrationData can be faked by a spurious U2F authenticator, the one thing it cannot do is forge another manufacturer's Attestation Certificate. This is because the "fake" U2F authenticator will need the authentic private-key associated with the Attestation Certificate in the authenticator.
Unless the authentic manufacturer was so bad in their security/control of Attestation Certificates and their private-keys, copy-pasting another Attestation Certificate into a "fake" device will not work because the U2F server MUST reject the RegistrationData if the signature (created by the private-key corresponding to the public-key in the Attestation Certificate in RegistrationData) cannot be verified.
Arshad Noor
StrongAuth, Inc.
Where did you get that notion (highlighted in red)? It is incorrect, because you CANNOT paste any manufacturer's Attestation Certificate to pass-off as an authentic U2F device. One may be able to sell such a device if someone merely looks at the Attestation Certificate, but it will never work with any authentic FIDO Ready/Certified U2F server.
The U2F protocol requires that the U2F Authenticator MUST digitally sign a number of parameters in the RegistrationData (see attached) to attest that the user's key-pair were generated in the "device". While most elements of the RegistrationData can be faked by a spurious U2F authenticator, the one thing it cannot do is forge another manufacturer's Attestation Certificate. This is because the "fake" U2F authenticator will need the authentic private-key associated with the Attestation Certificate in the authenticator.
Unless the authentic manufacturer was so bad in their security/control of Attestation Certificates and their private-keys, copy-pasting another Attestation Certificate into a "fake" device will not work because the U2F server MUST reject the RegistrationData if the signature (created by the private-key corresponding to the public-key in the Attestation Certificate in RegistrationData) cannot be verified.
Arshad Noor
StrongAuth, Inc.
Oh, I did not say I was pleased by the present situation :)
Arshad Noor
Jul 6, 2015, 5:31:49 PM7/6/15
to fido...@fidoalliance.org
I should have added one more point.
If you meant that an "Acme U2F Tokens" could pass off as a Fortune 500 company's U2F token because they can make up a self-signed Attestation Certificate using the F500 company's name, then you would be correct. But, only until the FIDO Alliance's Metadata Services Operation is unavailable.
The UAF protocol specifies the use of a Metadata Service that would be used to provide Relying Parties information on authentic Attestation Certificates (amongst other things). There is no reason why a U2F server could not take advantage of that Metadata Service if they chose to implement the protocol and "validate" the U2F tokens' Attestation Certificate in this manner.
Until the MSO is available from the FIDO Alliance, a Relying Party can always import the Attestation Certificates/Chains of their trusted U2F authenticators into their U2F servers. The "import" process would not work for all use-cases, but it can definitely work for companies authenticating their employees/partners to walled-garden portals.
Arshad Noor
StrongAuth, Inc.
If you meant that an "Acme U2F Tokens" could pass off as a Fortune 500 company's U2F token because they can make up a self-signed Attestation Certificate using the F500 company's name, then you would be correct. But, only until the FIDO Alliance's Metadata Services Operation is unavailable.
The UAF protocol specifies the use of a Metadata Service that would be used to provide Relying Parties information on authentic Attestation Certificates (amongst other things). There is no reason why a U2F server could not take advantage of that Metadata Service if they chose to implement the protocol and "validate" the U2F tokens' Attestation Certificate in this manner.
Until the MSO is available from the FIDO Alliance, a Relying Party can always import the Attestation Certificates/Chains of their trusted U2F authenticators into their U2F servers. The "import" process would not work for all use-cases, but it can definitely work for companies authenticating their employees/partners to walled-garden portals.
Arshad Noor
StrongAuth, Inc.
Fred Le Tamanoir (NEOWAVE.FR)
Jul 6, 2015, 7:05:14 PM7/6/15
to fido...@fidoalliance.org
Yes that was exactly what I meant and so... I don't think MSO-like server or CA/Chain import can this "same public Attestation Certificate everywhere" problem.
The -quite hard- real world attack could be described like this :
In a big company when FIDO U2F devices from manufacturer XYZ are deployed and where users have to add/enroll their U2F devices to their existing user/password protected accounts, the attacker would have to replace legit U2F tokens from XYZ manufacturer with fake ones, with the same casing, the same copied XYZ Attestation certificate and a non-random private key generator. These fake keys can't be detected/rejected by authentication servers that will accept non-secure enrollment.
Sometimes, you can avoid that by deploying already enrolled tokens... but this option is simply not available like inside Google Apps for Work admin panel where admins can't enroll a token on the behalf of a user before giving a token .
There are other solutions that would require modification of the standard and this is probably outside the scope of generic open FIDO U2F devices and outside the scope of this forum.
--
Frederic MARTIN
NEOWAVE
Security & System Architect
Reply all
Reply to author
Forward
0 new messages