Basically:
* Attestation keys are not unique per authenticator; they're shared among batches of authenticators.
* If you extract the batch's attestation key, you can imitate authenticators from that batch. That doesn't mean you can authenticate as a registered authenticator, of course; it just means you can pretend to be a "Yubico XYZ" device.
* Yes, I think Cloudflare is assuming it's hard to extract the attestation key. I think this is basically a safe assumption, but if it isn't, they can always choose to distrust batches known to be compromised.
- Does this mean if I buy 2 of these devices at the same time, it's possible for me to get the same attestation keys on both devices? I guess depends on how many batches at a time a company is producing.
- Doesn't this mean that attestation keys will get more unique over time as devices from the pool fall out of circulation and become rarer? Are keys rotated to prevent that (ie, would a manufacturer ever re-release a new pool with the same keys as an old one)?
- To my (limited) knowledge, yes, you are right that keys will get more unique over time. That's a very good point. Keys are not rotated nor (generally) are they rotatable; they are usually read-only. If you are using a very old FIDO device and worried it has too much entropy now--like, if it's a "rare" or "vintage" device!--then you should buy a new one, I guess?
(I honestly have not thought about your second point before, but I am not really deep in the FIDO stuff. So take my answer with a grain of salt.)
Such behavior would require some way of revoking old keys from newer devices to prevent a situation where a compromised and blacklisted old key is selected and causes the CAPTCHA to fail, seemingly at random.
But of course, despite this, still a unique key is generated for each identity upon sign up [0]. I am not sure (as in 'have no knowledge of') the entropy for these devices.
[0] https://fidoalliance.org/fido-technotes-the-truth-about-atte...
Which effectively means bricking the devices of 9999 innocent users each time.
Why are we creating a world where users will be told they can't visit a website or access their account any more because they didn't spend enough money on a hardware DRM device which tries to hide a key from them?
Vanguard restricts (or used to) trusted keys to those made by Yubico. This annoys me, given they let me use any phone number. So this suggests (as you seem to be arguing) that attestation is an attractive nuisance—when you can't tell whether a phone number is with a trustworthy or untrustworthy exchange, teleco, or VOIP service, you just have no choice but to trust it. But when you can enforce attestation, some Vanguard employee with a Yubico Certified Security Engineer certificate (I made that up) decides to restrict us to Yubico's keys.
On the other hand, FIDO aims to also support enterprise usage, and I think it'd be a nonstarter to say that enterprises shouldn't be able to restrict you to officially issued authenticators—and without remote attestation, they'd have to do more cumbersome steps like handling enrollment centrally (and then shipping enrolled authenticators to users), which, in a distributed workforce, sucks.
So attestation fills a need, and I think we just have to hope it's not widely used or abused.
Is Cloudflare's usage an abuse? Eh, I don't know. It's an interesting experiment.
It seems to me that this use case is completely at odds with the general use cases we expect when people browse the web.
In the enterprise, society accepts the idea that someone's employer knows their name, their address, their bank details, and even everything they browse on their company-issued computer. Whether that's good or bad, it's not a model that FIDO should be trying to support.
This reminds me of the controversy around TLS 1.3 allowing forward secrecy.[0] If companies want to make their own alternative to FIDO which has DRM and user tracking, to control access to their intranets, that's fine, but we shouldn't have allowed FIDO to become a Trojan Horse (or Trojan Dog?) to sneak this anti-feature into the general web.
[0] https://www.eff.org/deeplinks/2019/02/ets-isnt-tls-and-you-s...
Let's imagine I'm a consumer bank. I want the following features:
* I ship users a FIDO key when they sign up for an account.
* Users can register additional keys they bought or already have, and can use my key elsewhere.
* I consider malware on the user's computer to be in the scope of my threat model, and so I want all risky transactions (like transferring money) to come with a secure test of user presence.
I believe that the above three constraints are sufficient to motivate the current design. Why?
Well, let's say we do the obvious and just eliminate attestation. If the design otherwise remains unchanged, there's nothing to prevent clever malware from piggybacking a legitimate user presence tap to add a malicious, software-only authenticator to the user's account, which can then approve future transactions.[1]
Currently, however, I can simply require that authenticators all be non-self-signed, restricting to those that come with real hardware-backed security.
So now I have a few options. I can:
a) Disallow enrolling new authenticators. I think this is the worst option, because it means that the FIDO ecosystem would basically revert to (at worst) "an authenticator per relying party", which is expressly something it aims to avoid. (Think, keyrings full of USB fobs!)
b) Declare malware out of scope. I find this unsatisfying, since it suggests we might as well just replace FIDO with USB keys with X509 client certs, but see my footnote [1]--maybe at the limit these are equivalent?
c) Do what the FIDO Alliance seem to have done: create batch attestation, but discourage RPs from using it spuriously.
I think (c) is fairly reasonable, but as I said, I do find the entire malware argument sort of unsatisfying in a way, so, shrug.
[1] Arguably, if this is an attack you are concerned about, malware can also just piggyback presence to directly trigger transfers and other abuse, of course, so maybe this argument is a weak one? But I think an RP might reasonably want to say that "malware can do anything malicious within 10 seconds of a tap on your key, but if you think someone might have hacked your account, just remove your key and call customer support." If malware can add new software-only authenticators, it violates this functionality.
And presumably RPs in practice achieve this by subscribing to a list of key updates managed by the FIDO Alliance themselves. That seems like it puts a lot of control over the web into the hands of a group whose incentives may not be the same as those of the average web user.
As a point of comparison, my impression is that it's been quite difficult to get all Certificate Authorities to correctly follow the CA/Browser Forum rules, and to tighten those rules. That forum at least tries to balance the wishes of User Agents against those of the entities selling (access to) the keys, which I'm not sure if FIDO will achieve.
> malware can do anything malicious within 10 seconds of a tap on your key
If this is the security situation that FIDO aims to create, then I'm not sure if requiring a whitelisted hardware device adds anything, relative to allowing self-signed software-only authenticators, other than security theatre and a single point of failure (namely the whitelist itself).
I'm not aware of the FIDO Alliance doing this today. I guess anyone could create such a list, but while I think your concern is valid, it has not (yet) played out that way, so I don't think you can claim it's inevitable.
Anyway, I laid out what I believe are the reasonable alternatives. I think you're taking the position that local malware is already sufficiently powerful that it's not meaningful to restrict adding new authenticators?
I entertained this as well, and I think there's validity to it--but I do think it's reasonable for an RP to say, "If you unplug your FIDO key, the attacker is thwarted", which is not something that remains true if you allow self-signed authenticators.
Nope, it's just "expensive" to extract keys from secure hardware like this. The problem with an approach like this is that when the secret keys are identical for a large number of devices then the cost of revoking a compromised key goes up significantly which, for a spammer, would increase the value of obtaining said key because of the likelyhood that the key would be usable for a much longer time than if the key was unique to each device (and could be very easily blacklisted).
Techniques to extract data from these sorts of secure devices include various forms of side-channel analysis, decapping and microprobing the IC, using SEM, etc. to physically damage parts of the circuit to try to force it to disclose the key and various forms of power and clock glitching.
Most decent hardware-based cryptosystems are designed to ensure that each device has a unique key so that the cost of extracting one key (lets say around $100k) is too high for a potential attacker if the key can just be blacklisted, but if the key is expensive/impossible to blacklist then that cost might be worthwhile to an attacker.
Whilst Fast Identity Online (FIDO) is much more than WebAuthn, Cloudflare's proposal here is to use WebAuthn to get rid of CAPTCHAs. The official WebAuthn doc is surprisingly accessible with neat illustrations for key topics: https://w3c.github.io/webauthn/ (ref registration and authentication ceremonies, in particular)
If the key being shared is embedded in the device, even in a secure enclave or something, then my understanding was that would open the door for key extraction. If the key is unique per-device, then that's not a problem. But if the key is unique per-10,000 and stored statically on the device, then hacking one device means that key can be released to anyone and the entire pool can be imitated.
So if the above is correct, it can't be that a single private key shared across the entire company is stored on the device because that key would be getting constantly extracted and leaked by some determined hacker somewhere. But if it's a unique key per-device, then... I just can't figure out how validating that key wouldn't require transmitting unique information to somebody, whether it's Cloudflare or the device manufacturer.
Where am I going wrong? I feel like I'm misunderstanding something fundamental about how signing works on these devices, but I can't figure out what it is. If I buy a Yubikey, is it connecting to the manufacturer's servers and getting a new key each time it's used? I thought they worked offline.
Or are secure enclaves just much more secure than I think they are? Are we assuming that it's impossible to extract a private key from one of these devices?