Recovering from Device Loss in WebAuthn/FIDO2

[Alex Takakuwa]

As you all know, currently in the FIDO2/WebAuthn ecosystem, if a user loses a device or upgrades to a new one the recovery process can be quite onerous. During the FIDO Plenary in Vancouver, we presented a potential solution and implementation that allows users to replace/upgrade devices and were asked to extend that solution to solve recovery from device loss as well.

We presented three potential solutions to enable recovery from device loss (in addition to allowing transferring access during upgrades to new devices) that do not rely on passwords and that vastly reduce user burden, all while retaining the security guarantees of the existing FIDO2/WebAuthn specifications and without changing the API. These initial proposals are outlined here:

https://docs.google.com/document/d/1tRLbXYLb9Z65QqhOX7v9D-aq_RUODyn5oALpCXj46K8/edit?usp=sharing

I look forward to your feedback!

[Jan]

Hi!

As far as I understand your proposal, the Transfer Access Protocol is primarily designed for phones but not for USB keys for example. Also for a full solution (reliable, easy to use, lost or broken devices) it has the following requirements:

a) The new device is registered at all RPs before disposing the old device or

b) all keys are known by the device (to generate transfer requests for the new device upfront).

Assuming that the “problem” of passwords (which FIDO aims to solve) is so dominant because people use so many websites/RPs these days I think a) can’t be assumed to be practical. Assuming USB keys usually implement a form of key derivation I don’t think requirement b) can be fulfilled either.

IMHO a sufficient solution should be generic enough to cover both phones and USB keys.

Talking about security: A mechanism for a backup device generally reduces the security one way or the other. Hence, I think users should have the choice to use a backup mechanism (with potentially reduced security) or use only one device. In the later case the security must not be reduced. In other words: The solution shouldn’t establish a backdoor in the very FIDO protocol but be an option only.

This brings me to the following variations of the solutions described in your paper, with USB keys in mind:

c) Copy keys during device initialization: Assuming a key derivation approach, the master/device key would be cloned during device initialization and be imported into other FIDO devices. Key cloning wouldn’t be possible after device initialization, because it would be a backdoor (independent of user’s choice).

d) Pre-emptively syncing keys: n devices sync among each other, sharing their public keys. During device registration not just one but all (synced) public keys are sent to the RP. Backup devices would only work for RP which are registered after syncing the backup device to the main device. The FIDO protocol would only require a minor modification which is that multiple public keys can be registered.

Both approaches could be assumed practical for inexpensive USB keys but wouldn’t work well for phones, which is why you came up with the more complex Transfer Access Protocol. So I don’t have a desired solution practical for phones and USB keys.

Both approaches share one problem: How to prevent that cloned devices are sold/given to unaware users, so that the attacker has a backup key? Perhaps the device signalizes it cloned status so that the browser provides a warning to users? In scenario d) the browser would naturally see that a backup device is synchronized, by looking at the public keys.

I'm wondering if the FIDO Alliance has a solution or position on this topic.

Best regards,

Jan

[Alex Takakuwa]

Hey Jan!

Thanks for your feedback! Sorry I’m just seeing this. I’ve marked the thread so I should see responses more promptly from now on.

I agree with you that a solution should work for phones and USB keys and that such a solution should be optional for users.

Storing all the keys would be prohibitive for USB keys that currently just use key wrapping/derivation. However, I believe the “Online Recovery Storage” option we mention should be feasible with key wrapping and allow for cheap scalable storage of many credentials online both privately and confidentially.

As for a key copy solution, as we mention in the documents this solution has the caveat of violating the security assumption that keys won’t be usable on any other devices, which in turn negates the purpose of hardware attestations as currently constructed (I believe). However, this still may be a viable solution.

If you’d like to discuss this more (even in person!) we are also offering to hold a summit to discuss these solutions and problems related to recovering from device loss in WebAuthn at the University of Washington. The available dates right now are July 10 and August 3. We’d love for you to come to the University or tune in via conference call if you are available so that you can raise these concerns to other interested parties.

There’s a doodle here:
https://doodle.com/poll/yb5rqiadhaksk5um


-Alex

--
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+unsubscribe@fidoalliance.org.
To post to this group, send email to fido...@fidoalliance.org.
Visit this group at https://groups.google.com/a/fidoalliance.org/group/fido-dev/.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/5655569b-edd4-4264-970a-0d7947757a2c%40fidoalliance.org.

[Nitrokey]

Hi Alex!

> just use key wrapping/derivation. However, I believe the “Online
> Recovery Storage” option we mention should be feasible with key wrapping
> and allow for cheap scalable storage of many credentials online both
> privately and confidentially.

In theory you are right but in practice I see the following challenges:

I personally have several hundred accounts. This would implicate to
generate - say - 500 keys in advance which could take long (especially
for simple USB dongles). Also users may run into situations where they
need to add more pre-generated keys with their backup device to the
Online Recovery Service. This would further complicate the process and
protocol.

At the same time simple USB dongles wouldn't be capable to process large
blobs. Take in mind that these can be 8 bit systems with a few KB or RAM
which can't handle large blobs.

Hence, did you consider using individual keys instead of a large blob? I
assume the blob was chosen for privacy reasons, right?

Best regards
jan

[Alex Takakuwa]

Hence, did you consider using individual keys instead of a large blob? I
assume the blob was chosen for privacy reasons, right?

Yes, in fact the blob can be stored un-encrypted at the online recovery storage and managed via a website if the user wishes it in order to reduce computation and interaction on the device. However, they would reveal the public keys to the online recovery storage provider and need to trust that provider to preserve non-linkability.

One aspect that I think is desirable is the property that the protocol at the RP side doesn't really depend on the decisions the user makes, so that the user can choose the experience that suits their security and usability preferences. Those choices may potentially be communicated via hardware attestations. However, for users that want the full security and privacy benefits of FIDO authentications, it would be nice to have a great user experience during recoveries, even if that is potentially at the cost of more capable devices.

With that in mind, even though syncing hundreds of keys could take a long time, this should only happen rarely (when the user sets up a new device), and should be possible in the background.

Also users may run into situations where they
need to add more pre-generated keys with their backup device to the
Online Recovery Service. This would further complicate the process and
protocol.

I agree. Though the technical solution is straightforward, convincing the user to get their backup device and upload more keys could be troublesome and would have to be mitigated in some way.

Thanks!

- Alex

--
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+unsubscribe@fidoalliance.org.
To post to this group, send email to fido...@fidoalliance.org.
Visit this group at https://groups.google.com/a/fidoalliance.org/group/fido-dev/.

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/bf603c28-0014-59de-0cc4-18f3a05c6b43%40nitrokey.com.