What a nice guy… Basically saying do what we say or we will make the treacherous part of your device do it against your will.
I’ve already posted at length on HN about the risks of treating attestation as evil and refusing to discuss its benefits at all, and how that manner of engagement will lead to it being widely adopted over the objections of an uncoordinated minority. The sky is falling, yet no one discusses how freedom and attestation might coexist, and so the majority use case (end users) is winning.
I still expect the big wake up call is going to be in a couple years when Steam enables attestation in their Linux product and VAC begins requiring it, but at least the ripples of LXC’s approach are being seen at all.
I've seen lots of discussion about the benefits on HN.
But attestation really is fundamentally opposed to freedom. It allows someone else to dictate how you use your own machines. So, the debate necessarily revolves around whether or not it's worth it to give some freedom up for this.
Some people will say it is, others will say it's not.
> yet no one discusses how freedom and attestation might coexist
How could they coexist? I honestly don't see it, but that's likely a result of my own lack of imagination.
> Being able to zero-effort cleartext a passkey strips it of the HSM-lite properties that make it safer than passwords.
You might have an argument if we were talking about device-bound keys. But the second we start talking about roaming keys, this just becomes a bad excuse. iCloud accounts can be phished, Google accounts can be phished. Roaming keys are vulnerable to phishing. The ability to export a key (encrypted or not) does not change that.
Device-level attestation and platform control over keys is out-of-scope and inappropriate for a credential that is fundamentally designed to live on multiple devices. We aren't talking about Yubikeys or device-bound keys, we're talking about roaming keys that are designed to get synchronized to the cloud and moved between devices at the direction of the user. Necessarily, there is going to be some level of phishing risk. We've accepted that because device-bound keys are unacceptable for most average users even if they're more secure.
Notably, this does not mean that passkeys are useless or that they are not phishing resistant. There are a large number of security benefits from passkeys even though they are not completely phishing proof. Those benefits do not go away if attestation is not supported for roaming keys, nor do they go away if users are able to decrypt their own keys. And given that companies like Apple led on zeroing out attestation requests for roaming keys, there clearly is not consensus in the FIDO Alliance about whether attestation is desirable or necessary for roaming keys.
Passkeys in a world where users can inspect and access their own keys are still a meaningful security improvement over passwords. And importantly, the lack of attestation makes it more feasible that they will actually be used. The goal is not to make something perfectly secure, the goal is to replace passwords with something better. I am continually surprised to see how little people understand about the myriads of use-cases that passkeys will need to support if they are going to actually replace passwords, and how little they seem to care about the ability of an attestation-encumbered system to handle those niche cases.
I've been in this space for a while. First, advocates told me that roaming keys were never going to happen because the whole point was for keys to be device-bound. Then it turned out, well, that's a dealbreaker, so we can compromise on that. Then I was told that sharing passkeys was never going to happen because it would destroy the security benefits. Well... okay, now we support sharing. Then I was told that migration was out-of-scope and the FIDO Alliance was not going to get involved. Now the FIDO Alliance is involved. Then I was told that export was fundamentally insecure, and any migration between providers would need to happen via a secure channel online or without ever putting the passkey on disk. And now I'm told that, okay, we can put the passkey on disk, but the problem is that it's zero-effort to get a cleartext. And at every step of that process, I'm told that these are non-negotiable security properties of WebAuthn.
Well, after a while these all start to feel less like security principles and more like excuses for why export isn't happening. It's weird how these security principles only get brought up in regards to user freedom, and not in regards to Apple supporting passkey sharing over Airdrop. I'm sorry, that doesn't open up phishing risks?
Tim suggests in this issue encrypting the passkey with some kind of additional key on export. How does that mean that HSM properties are preserved? The horse is out the barn, we are not doing HSM security on roaming passkeys, we are just pretending to. HSM gets brought up as this important feature but passkeys are already ignoring it. So let us export the keys; enough with this bullcrap double-standard about what does and doesn't count as a phishing risk.
----
> The sky is falling, yet no one discusses how freedom and attestation might coexist, and so the majority use case (end users) is winning.
Sure, I'll start the ball on that conversation. There's a straightforward indication now that attestation and certification can be used to punish and block spec deviations (https://github.com/keepassxreboot/keepassxc/issues/10406#iss...). This comment could not possibly be more clear, FIDO Alliance is looking for ways to force providers to implement in specific ways.
And that's interesting because in the past I have been told that interoperability and universal import/export cannot be required by the spec because the FIDO alliance has no way to force providers to interoperate, and because interoperability is out-of-scope. The only thing we can do (I'm told) is hope that companies support export/import out of the goodness of their hearts.
Well, now we know that those arguments are wrong. FIDO members are willing to get involved in discussions about how projects do or don't handle migration so this is very clearly "in-scope", and FIDO members are willing to get forcefully involved, and are actively working on mechanisms to require independent projects that are not members of the FIDO alliance to seek certification. FIDO is going to have a level of control over how providers act.
So if we must have attestation, is anyone involved in the spec process for WebAuthn willing to publicly commit right now that export/import for roaming keys will be a required part of the spec and that failure to implement export/import will result in blocking certification? Why is it that attestation is being used to shut down user agency, but for corporations we have to just trust that they'll do the right thing?
We've apparently got this amazing tool for forcing compliance. That implies to me that user freedom can be part of the spec and those compliance tools can be used to safeguard it. If we're talking about using attestation to enhance user freedom, then using attestation to require universal export/import controls with every single certified provider would be a pretty big selling point for attestation, and would go a long ways towards avoiding the mistakes that were made with 2FA, where many apps straight up never provided a way to export keys. I wouldn't be thrilled with it, attestation would still be dangerous, but at least it could be used to ensure that the ecosystem guarantees user rights as well as restricts them.
But I'm not holding my breath that the FIDO Alliance is going to require that kind of thing.
It is not for lack of conversation that attestation is primarily used today to curb user freedom and agency. It is that the technology is naturally prone to abuse if it isn't coupled with adequate safeguards. Early on during TPP debates, proposals were made for ways to make TPPs that coexisted with user freedoms and enhanced user freedoms. It is not that Linux communities aren't involved, it's that we correctly recognize at this point that practically every single real-world implementation of attestation has been used to shut down user freedom because it is fundamentally prone to abuse. So what safeguards is FIDO going to put in place? How is FIDO going to use attestation this time to actually help user freedom?
Because I can think of ways: mandate interoperability, require implementations to be open and documented, require cross-platform support for most providers, require fall-back methods of authentication for users who do not own hardware that can handle attestation requests, publicly commit to making attestation available to De-Googled phones and to "authorized" 3rd-party ROMs.
While we're at it, require clients to support multiple keys per-domain which by extension would effectively force domains to accept multiple keys. Today, there are domains that only allow registering one passkey, which is wildly irresponsible given that registering multiple keys is the only way right now to simulate portability. If we're going to use attestation to threaten non-compliant implementations, then at the very least we could also use attestation to threaten implementations that deny user freedom and agency.
Will FIDO commit to any of that? Or do I have to simultaneously watch Open Source provider implementations get threatened by attestation while also listening to advocates tell me that there's nothing the FIDO alliance can do to require an Open ecosystem with universal data-portability?
I have a feeling this is coming down the line too. But I also don't see the coexistence part in any of this. There is no compromise, it's do what we say or else. You can call this coexistence, but Stockholm syndrome is more apt I think.
This is a spec issue. There are (as far as I can tell) no penalties or mechanisms to guard against businesses using attestation punitively to punish actors that deviate from the spec even when that deviation is in the interest of users. We are relying on corporate good will, and corporate good will is not something that ought to be relied on. Now, what that comment reveals is that there are multiple actors pushing to extend attestation to roaming keys and to have even fewer safeguards against excluding clients from the ecosystem.
That's scary, and that's a much bigger problem than one person.
When Apple zeroed out attestation requests for its roaming keys, I was told by multiple advocates that this meant that attestation would not be coming for roaming keys, and that attestation would never be used this way. After all, attestation was primarily intended (they told me) for regulatory compliance in industries that were primarily worried about device-bound keys. "What is Apple changes its mind" was dismissed as fearmongering.
But here we see the danger of setting expectations about an ecosystem based on Apple deciding randomly not to do something. There was no public commitment from FIDO not to pursue additional attestation for roaming keys, and behind the scenes it looks like players calling for that attestation have more sway than advocates let on.
So we end up with essentially a threat against implementations that deviate from the standard even when they are deviating in the clear interest of users. I don't think Tim meant it as a threat, if anything he was probably trying to be helpful. But it is still a threat regardless of the intention. And it's a threat because the ecosystem explicitly exposes tools to enable this kind of behavior. It's not a threat because of Tim, it's a threat because it's plausible. And it shouldn't be plausible.
This is why attestation is dangerous without safeguards; and the FIDO alliance has completely ignored the need for safeguards. Maybe there are conversations that I'm not privy to -- there probably are. But from the outside, it looks like a lot of people hoping that Google and Apple and Netflix and your bank will all magically care about not locking users to hardware and will completely voluntarily choose not abuse attestation. And I'm sorry, that's just not in their nature to do. If the spec directly gives these companies tools to be abusive, then they're going to be abusive.
Exactly. And these safeguards would need be legal. Seeing that the EU can't even force Apple to let me install a .ipa file on iOS without jailbreaking, I think it's safe to say we are fucked.