Recovering from Device Loss in WebAuthn

*During the FIDO Plenary in Vancouver, we presented a potential solution
and implementation that allows users to replace/upgrade devices in the
FIDO/WebAuthn ecosystem. We called this Transfer Access
https://www.cs.washington.edu/tr/2017/06/UW-CSE-17-06-01.pdf
<https://www.cs.washington.edu/tr/2017/06/UW-CSE-17-06-01.pdf>. Following
that presentation, FIDO members asked us to include solutions for account
recovery to solve issues related to Device Loss in addition to Device
Upgrade.Currently in the WebAuthn ecosystem, if a user loses a device the
recovery process is quite onerous as the user must manually update settings
at each relying party. Because solutions relying on passwords make
passwords the weakest link, we present three potential solutions to enable
recovery from Device Loss that do not rely on passwords and that vastly
reduce user burden. They are: 1. Copy Private Key Material
(https://homes.cs.washington.edu/~alextaka/overview-copy.pdf
<https://homes.cs.washington.edu/~alextaka/overview-copy.pdf>)2. Online
Recovery Storage
(https://homes.cs.washington.edu/~alextaka/overview-ors.pdf
<https://homes.cs.washington.edu/~alextaka/overview-ors.pdf>)3. Pre-emptive
Syncing (https://homes.cs.washington.edu/~alextaka/overview-psk.pdf
<https://homes.cs.washington.edu/~alextaka/overview-psk.pdf>)We have linked
to slides with quick overviews of each approach, but we discuss the
proposals in more detail below. We have also aggregated information about
our proposals in this doc:
https://docs.google.com/document/d/1tRLbXYLb9Z65QqhOX7v9D-aq_RUODyn5oALpCXj46K8/edit?usp=sharing
<https://docs.google.com/document/d/1tRLbXYLb9Z65QqhOX7v9D-aq_RUODyn5oALpCXj46K8/edit?usp=sharing>For
each of our proposals, our goals were as follows:1. Preserve ALL of the
security and privacy benefits afforded by FIDO/WebAuthn.2. Have minimal
impact on the user experience. (User burden not dependent on the number of
registrations)3. Allow users to choose what kinds of recovery "devices"
they would like to use, and allow the Relying Parties to vet these
solutions via attestations. Possible recovery "devices" should include
hardware keys, traditional authenticators, key-sharding solutions, third
parties, hardware/software.4. Enable Device Replacement/Upgrade for both
primary authenticators and backup "devices".5. Allow for multiple backup
"devices".6. Allow a single backup "device" to back up multiple primary
authenticators.Thanks for reading! We would love to hear your feedback on
these proposals.- Alex Takakuwa In collaboration with Alexei Czeskis
(Google), Arnar Birgisson (Google), Hideo Nishimura (NTT Labs), and
Tadayoshi Kohno (University of Washington)------------------------------*






















*More Detail on Key Copy(overview:
https://homes.cs.washington.edu/~alextaka/overview-copy.pdf
<https://homes.cs.washington.edu/~alextaka/overview-copy.pdf>)This approach
encompassess methods for copying necessary private key material in order to
duplicate private keys on new devices. This could mean copying a wrapping
key or a private seed. A key copy approach benefits from simplicity, as it
does not require any changes from the relying party, though the RP will
likely lose any benefits provided by hardware attestations. Further, users
can use any active key to “activate” a new key.Although copying private key
material violates some of the existing FIDO/WebAuthn guarantees, it may be
possible to implement it securely (see:
http://ieeexplore.ieee.org/document/8311436/
<http://ieeexplore.ieee.org/document/8311436/>). However, it does come with
tradeoffs: - Revocation is potentially unsolved. We have some potential
workarounds that rely on trusitng the authenticators to update counters,
but revoking access from a single device which may be compromised in the
future is difficult.- Relying Party can’t validate new hardwareMore Detail
on Online Recovery Storage and Pre-emptive Syncing:Each of these two
solutions require a user to manage a backup "device", which the user will
sync with a primary authenticator upon setup of the primary authenticator.
However, note that as opposed to the current protocols, where the user
would have to register a second authenticator manually at each relying
party, in the proposed schemes the user only uses the backup authenticator
once -- to pair it with the primary authenticator. After the initial
syncronization, the user can store the backup "device" (or in the case of a
third party, log out) and will not need that device until the user loses
the primary authenticator and needs to recover. The primary authenticator
will work as a standard FIDO authenticator for future registrations and
authentications. Both solutions require Relying Parties to implement the
Transfer Access Protocol
<https://www.cs.washington.edu/tr/2017/06/UW-CSE-17-06-01.pdf>, which also
allows for Device Replacement/Upgrade.Solution 1 - Utilizing Online
Recovery Storage(overview:
https://homes.cs.washington.edu/~alextaka/overview-ors.pdf
<https://homes.cs.washington.edu/~alextaka/overview-ors.pdf>)Power Point
Slides explaining this solution in more detail:
https://homes.cs.washington.edu/~alextaka/ORS.pdf
<https://homes.cs.washington.edu/~alextaka/ORS.pdf>Summary: This solution
uses some online entity (can be a privately run server or an actual third
party) to store information about registrations and that will help the user
recover. We do NOT need to trust the Online Recovery Storage provider for
any security or privacy properties and the Online Recovery Storage provider
cannot affect the security of FIDO protocols. Further, Relying Parties do
not need to know about the Online Recovery Storage at any point.This
solution has the following caveats: - The Online Recovery Storage must be
available during registrations and recoveries- The Online Recovery Storage
is not necessary for authentications.- Requires authenticators that can
access the internet in some way- Relying Party must implement something
like the Transfer Access Protocol
<https://www.cs.washington.edu/tr/2017/06/UW-CSE-17-06-01.pdf> for chains
of signatures.Solution 2 - Pre-emptively syncing keys:(overview:
https://homes.cs.washington.edu/~alextaka/overview-psk.pdf
<https://homes.cs.washington.edu/~alextaka/overview-psk.pdf>)Power Point
Slides explaining this solution in more detail:
https://homes.cs.washington.edu/~alextaka/PSK.pdf
<https://homes.cs.washington.edu/~alextaka/PSK.pdf>In-depth summary:
https://docs.google.com/document/d/1VtmqeciSGRjRXcrkSq-WjCDz44KdQM-Xt9VR1OU9AsM/edit?usp=sharing
<https://docs.google.com/document/d/1VtmqeciSGRjRXcrkSq-WjCDz44KdQM-Xt9VR1OU9AsM/edit?usp=sharing>Summary:
In the event that we do not want to trust an online recovery storage
provider to be available during registrations and recoveries, we can use a
solution that does not depend on any third party. In this solution, the
backup "device" pre-generates key pairs, stores them, and pre-loads the
public keys onto the primary authenticator. During registration, the
primary authenticator registers as normal, but also automatically registers
one of the recovery public keys as a recovery key. This solution has the
following caveats: - Storage and computation overhead.- Backup Devices and
Primary Authenticators store extra keys. During recovery, the backup device
does not know which of the previously generated keys have been used, so it
needs to perform recoveries for all of them. - Revocation is tricky- The
Backup Device has no information about the usage of its keys. It cannot,
without the Primary Authenticator, revoke access from lost devices for all
accounts. If a user keeps record of all RPs separately, then the Backup
Device can revoke access for all accounts.- Servers must allow for the
registrations of backup keys, which can be done via an optional extension.-
Relying Party must implement something like the Transfer Access Protocol
<https://www.cs.washington.edu/tr/2017/06/UW-CSE-17-06-01.pdf> for chains
of signatures.*