6

I'd like to be able to inject my own key material in the FIDO2 authenticator; at the very least it will remove the need to trust the vendor (because we have no guarantee whether the vendor keeps copies of the keys to themselves, because of government request or for any other reason).

So I believe that for customers it'd be very valuable to be able to set their own key material.

However, Yubico argues that if they allow that, it would:

"undermine device attestation, which would likely disqualify those authenticators from high-security applications like financial institutions"

I'm not quite aware of the regulations in this area, and so, my main question is, whether that is true. I'm struggling to understand why by setting my own key material (and thus by improving my personal security), I would disqualify the authenticator being used.

Also, it looks a bit ironic since these days financial institutions tend to trust SMS and not U2F, even though SMS is anything but secure. I do hope that this is going to change someday though.

For reference, the discussion is happening here: WebAuthn recovery credentials extension

xxx
  • 167
  • 8
Dmitry Frank
  • 195
  • 11

2 Answers2

3

The argument is that, if you supply your own key material, the key manufacturer has no way to verify that the key material is sufficiently random, not stored elsewhere, etc. Imagine if you are the victim of a sophisticated targeted attack, and you generate the key material on a computer that has malware on it which exfiltrates it to the attacker. Or perhaps a supply chain attack, Alice sets the key material then hands the authenticator to Eve to deliver it to Bob, but by the time Bob receives it Eve has changed the key material to a value she knows. This would be fixed by Bob setting his own key material, but then Alice has to trust Bob to do that correctly.

It sounds like Yubico wants to be able to say "if an attestation is verified up to our root cert, we guarantee that the associated keypair comes from a Yubikey, and the key material used to create the keypair was generated securely by us and is stored only on the authenticator." If they allowed you to set your own key material they would no longer be able to make that guarantee.

Now this doesn't really matter for public websites, and most (or all) public websites that allow U2F or WebAuthn for 2nd factor don't bother checking attestation at all. But for something like a high security intranet, there could be value in auditing a small number of authenticator manufacturers and using attestation to only allow authenticators from those manufacturers. In that scenario not being able to modify the key material could be seen as an advantage.

Also, it looks a bit ironic since these days financial institutions tend to trust SMS and not U2F, even though SMS is anything but secure.

I imagine he's talking about employees of a financial institution rather than clients.

AndrolGenhald
  • 15,436
  • 5
  • 45
  • 50
  • Thanks for this useful answer! The part I'm stuck on is how the Yubikeys generate attestation certs which can be `verified up to our root cert` [thus guaranteeing] `that the associated keypair comes from a Yubikey, and the key material used to create the keypair was generated securely by us and is stored only on the authenticator`. How can the Yubikey generate an attestation cert which is (a) uniquely associated with the keying material and (b) signed by their root cert? My recent question on this: https://security.stackexchange.com/questions/224692 – Dan Lenski Jan 23 '20 at 21:59
0

They could allow you to change your own key but it would eliminate the point in trusting them as an authentication authority. TLDR;

The whole purpose of using a FIDO2 authenticator is 'trusting the vendor'. That is what you are paying for when you buy it. They are selling a product saying we have a trusted server technology. Just like a browser operates using signed trust certificates, root certificates, ssh has key finger prints.

Technically speaking. If they allowed you to replace the material then that would be fine as long as they used a public key private key infrastructure you would just need to say I'm changing my key to this so when we do the handshake I'm going to be using this key from now on.

They are the signing authority, in this type of authentication technology so it would make their job a lot harder if they had to track who has every key and have they changed said key.

The public key finger print you send ends up being similar to a tracking cookie in the web application that is authenticating you so it would also cause issues with said systems if they made the key editable.

Protocol Link I believe this document for FIDO2 describes a public key private key infrastructure.