Re: Recovering from Device Loss in WebAuthn

I should also note that these ideas have been published in the public
domain and aren't protected by IP.

On Tue, Apr 3, 2018 at 12:06 PM, Alex Takakuwa <alextaka@uw.edu> wrote:

>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *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.*
>