Questions from "State of Portability of Passkeys"

[Daniel Shumway]

I attended the March 20th virtual summit for passkeys, but unfortunately at that point Rew and Nick weren't available for questions, and it was mentioned during the QA that since they were more specific I should email technical questions to the FIDO Alliance to get them answered. I'm hoping I have the correct email address for this, sorry if not.

First off, great talk, thanks for sharing so much information :) I'm excited to see what the full standard looks like!

I do have a couple of questions that might just be me not understanding.

1. Rew talked about moving away from encrypted export and some of the downsides of securing exports with another key/password. At about 18 minutes, Nick was talking about a pre-shared key flow for authorization. My question is, would that flow inherit the same problems as an encrypted export? It seems (naively) to me that any attack on encrypted exports would also be executable against pre-shared keys. Is there a difference in the implementation or flow that makes it harder for those attacks to be carried out?

2. A big point of the exchange protocol was this idea key negotiation from both parties. At around 15 minutes Nick mentioned that a benefit of this kind of approach was that the actual payload could sit safely on disk for things like backup.

But I'm not sure I understand how that would work in practice: First, it seems this would only work for backup within a single provider, the exported backup couldn't be used with any other provider unless it was installed and able to enter into this bi-directional communication at the time of export. Second, even for local backup within the same program, where are the keys to decrypt the backup actually stored? Because if I enter into this process and export the payload and put that on a drive somewhere and then my computer melts, when I reinstall the client it won't have the keys to decrypt the backup I made unless the keys are either persistent or are stored in the backup itself, which seems to defeat the point. So I'm not sure I understand what the situations are where I could ever use this for long term storage.

3. This again could just be my ignorance of how this all works, but where this bi-directional auth-flow is concerned, am I correct in understanding that (absent using the pre-shared key authorization flow) both programs would need to be installed simultaneously?

4. The talk mentioned the OS negotiating some of this communication -- I think I understand that but I want to make sure; does that cover discoverability and programs presenting as migration targets? In other words, is the list of providers I can import from and export from something that has to be coded into each client, or is this a generic interface where Provider A goes to the OS and says, "the user wants to migrate, what can they migrate to" and the OS says "here's the list". My concern is whether a smaller or independently compiled provider will show up in that list if a larger provider like 1Password or Dashlane isn't aware that it exists. There's a concern (if this is working through pre-negotiated lists of providers) that this could end up being portability *only* for the largest providers and not for anybody else.

Certainly for any Open Source implementation, it would imply that users could never import keys into a self-compiled application, which would be a large limitation in the spec if that was the case. Again, I might be completely misunderstanding how this is intended to work.

While my preference is that export targets be a fully independent list that the OS just populates based on software categories or something, I do have a question/concern in the opposite direction as well -- if the OS is negotiating which providers are available to export to, what prevents an attacker from tricking a user into exporting keys into another fake provider that they control? Especially if (correct me if I'm wrong, I could be misunderstanding) this communication is intended to be able to happen across computers or across a network -- I'm not sure I understand the mitigations there for potential phishing attacks.

----

Thanks again for the talk. Let me know if I'm being unclear or if I'm asking something that doesn't make sense, or if I'm just emailing the wrong group :D

Best wishes,

Daniel Shumway

[Nicholas Steele]

Hello Daniel,

Firstly, thanks so much for attending our talk. I'll try to answer your questions to the best of my ability, and feel free to email me directly for further explanation. 

> At about 18 minutes, Nick was talking about a pre-shared key flow for authorization. My question is, would that flow inherit the same problems as an encrypted export?

In the pre-shared key flow I mention, the modality of the key would be through a public/private key pair negotiated by the authorizing party, rather than a shared password. So, in a potential authorizing party flow, a key pair would be shared with both the importer and exporter that they could use to either encrypt the payload and/or prove that the authorizing party has authorized the exchange of the credentials.

>First, it seems this would only work for backup within a single provider, the exported backup couldn't be used with any other provider unless it was installed and able to enter into this bi-directional communication at the time of export. 

First, not necessarily. One could potentially use a password or, more ideally, PKI, and then provide that decryption secret to the importing party, in the case that the importer and exporter are different providers. In the singular case, the provider could potentially hold the authorizing party export key.

> Second, even for local backup within the same program, where are the keys to decrypt the backup actually stored?

This is out of scope for the protocol and data format. Neither -and to use the working names here- CREEP (CREdential Exchange Protocol) nor CEF (Credential Exchange Format) should make any determinations about how the importer, exporter, or platform should store their keys, but we'll say that it should be secure.

>This again could just be my ignorance of how this all works, but where this bi-directional auth-flow is concerned, am I correct in understanding that (absent using the pre-shared key authorization flow) both programs would need to be installed simultaneously?

Not necessarily but I imagine that will be the most common scenario. One could imagine a case where an exporter, running in a browser extension, is capable of performing CREEP with an importer running via a web application. 

>The talk mentioned the OS negotiating some of this communication -- I think I understand that but I want to make sure; does that cover discoverability and programs presenting as migration targets?

Yes. 

> In other words, is the list of providers I can import from and export from something that has to be coded into each client, or is this a generic interface where Provider A goes to the OS and says, "the user wants to migrate, what can they migrate to" and the OS says "here's the list".

The latter

>My concern is whether a smaller or independently compiled provider will show up in that list if a larger provider like 1Password or Dashlane isn't aware that it exists. There's a concern (if this is working through pre-negotiated lists of providers) that this could end up being portability *only* for the largest providers and not for anybody else.

That is indeed a concern, but ideally when we look for valid importers on, for example, Android, we'll be filtering apps by interfaces rather than hard-coded IDs.

To your concerns around phishing and avoiding allow/block listing from occurring, you'll be glad to know I share them. I have some thoughts on how we can do this, and we'll have firmer updates later this year, but in the mean time I invite you to reach out if you want, and we should have a v1 draft of the two standards published shortly for public viewing.

Thanks,

NS

[Daniel Shumway]

Replying back to the main group since I carelessly forgot to reply-all, I apologize about that.

On Tue, Mar 26, 2024, at 1:18 AM, Daniel Shumway wrote:

Hi Nick, thanks so much for replying, this does clarify a lot. I appreciate you taking the time for this.

> the modality of the key would be through a public/private key pair negotiated by the authorizing party [...] a key pair wuld be shared [...] that they could use to either encrypt the payload and/or prove that the authorizing party has authorized the exchange of the credentials.

I think I understand, but I'm not certain. Just making sure that I've got it, is this saying that authorizing party's key is being used more as proof of authorization rather than as encryption/decryption of the payload itself? That makes sense to me, in that case it's more the authorizing party saying "here's a key you can use as proof that you are actually authorized to do this."

For encryption of the payload itself, I guess I do see some advantages there, but it also seems like -- if the authorizing party is distributing the keys to use for encryption/decryption then it knows those key pairs, right? In that scenario ti seems like it would still have the ability to decrypt the payload and would be vulnerable to many of the same kinds of phishing attacks -- ie, a fake authenticator or convincing the user to extract and share the keys. I apologize if that's a naive question, it's possible that when the spec comes out it'll be more obvious to me where I'm going wrong on that.

> One could potentially use a password or, more ideally, PKI, and then provide that decryption secret to the importing party, in the case that the importer and exporter are different providers.

So that's reasonable, and it's a great answer, and it makes me feel a lot better about portability. I was worried that a generic export/backup wouldn't be possible. So I was thinking through a future scenario where I might have passkeys stored in an account from 10-20 years ago and the software is all deprecated but I have a backup of an export sitting on a hard-drive, and I was worried in that case the keys would be gone forever if they weren't being managed through an online ecosystem or if I couldn't get their provider running again. But it sounds like that won't be a concern!

So I hesitate to question this because I'm happy that the spec supports that use-case, but... let's say I'm not even using a password, I'm using a PKI to encrypt that payload and storing it on a disk for backup: I still have access to the PKI though, it seems, so would I still be vulnerable to phishing attacks or having an attacker get access to my keys?

I mean, this came up in various talks a few times as well -- even if that's the case, it still seems better than passwords, users are still probably less likely to share a key pair being managed through some standard format than they are to share a passphrase that they came up with on their own. But I'm just trying to get a frame of reference for where the line on phishing-resistant ends up being.

> This is out of scope for the protocol and data format. Neither -and to use the working names here- CREEP (CREdential Exchange Protocol) nor CEF (Credential Exchange Format) should make any determinations about how the importer, exporter, or platform should store their keys, but we'll say that it should be secure.

Seems reasonable.

> Not necessarily but I imagine that will be the most common scenario. One could imagine a case where an exporter, running in a browser extension, is capable of performing CREEP with an importer running via a web application. 

This makes a lot of sense. I think my concern was more about migration across time rather than about needing to have the two programs installed on the exact same computer -- but it also seems like your comments above address that use-case already, so if it's possible to do export using a separate decryption secret, that easily covers a use-case where both the exporter and importer aren't running at the same time to communicate with each other.

> That is indeed a concern, but ideally when we look for valid importers on, for example, Android, we'll be filtering apps by interfaces rather than hard-coded IDs.

Yep, I think this handles my concerns there. If it's not a hard-coded list of providers and it's being managed through an interface, that gets rid of pretty much all of my worries about migration support with smaller or self-compiled clients, and it seems like that should make support for migration even broader than is currently the case with password vaults, so that's very welcome news. :)

> but in the mean time I invite you to reach out if you want, and we should have a v1 draft of the two standards published shortly for public viewing.

Looking forward to learning more once the the v1 draft is ready to share :)

--

You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.

To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/43f68326-1453-48ba-a83c-ec5642961787n%40fidoalliance.org.

Best wishes,

Daniel Shumway

Best wishes,

Daniel Shumway