In this second part of a two part series on how the open Decentralized Recovery (DeRec) Protocol supports the protection and recovery of secrets, we’re going to do a step-by-step walkthrough of a DeRec Protocol-driven recovery workflow. In other words, we’re going to demonstrate how the owner of a secret (see our FAQ What is a DeRec Owner?) would go about recovering that secret with the assistance of some DeRec Helpers (see our FAQ What is a DeRec Helper?). This example workflow assumes that a DeRec Owner named Alex has already used a DeRec-compliant application to protect the private key to his Ethereum account and that you’ve reviewed Part 1 of the series which offers a step-by-step review of how he put that protection into place. 

Both walkthroughs are based on screenshots that were taken from a video demonstration of the protection and recovery workflows. The full video is embedded at the end of this article. The video portrays four participants in the protection and recovery workflows; Alex, Bob, Carol, and Dave. As was suggested earlier, Alex is the Owner of the secret; someone who would rather take a safe, decentralized approach to protecting his secrets rather than risk their catastrophic loss (see Why Not To Trust a Lone Entity – Even Yourself – To Best Protect Your Secrets).

Meanwhile, Bob, Carol, and Dave are Alex’s Helpers. In Part 1 of this series, Alex used his copy of a DeRec-compliant mobile app to divide, encrypt, and distribute three different fragments of his secret to Bob, Carol, and Dave; the three Helpers all of whom are running the same DeRec-compliant mobile app as Alex. However, this needn’t be the case. As long as the Helper-capable applications they’re using are compliant with the Decentralized Recovery Protocol specification, they should be able to interoperate with whatever DeRec-compliant application Alex is running.

As we begin Part 2 of this series, Alex’s secret is in a DeRec-protected state. If Alex loses his secret (which can happen in a variety of ways including the loss of this smartphone), he should be able to recover that secret by following the standard recovery workflow described in this article. 

As an additional reminder, the DeRec Protocol is like other protocols in that it leaves most user interface (UI) design decisions to the developers of DeRec-compliant applications. Like many standard workflows, there is a sequence of events that cannot be circumvented. For example, before a secret can be recovered with a DeRec-compliant app, it first must be protected with a DeRec-compliant app (see our FAQ: I’ve lost access to a blockchain account. Can I use the DeRec Protocol to regain access?). Additionally, a DeRec Owner must be connected to a minimum of three DeRec Helpers before a secret can be protected with the DeRec Protocol. 

To start-off our walkthrough of the DeRec recovery workflow, let’s assume that Alex has lost his phone. Whereas Bob, Carol, and Dave still have their phones, each of which is running the same DeRec-compliant app that was originally used to protect Alex’s secret, Alex had to buy a new phone and install a DeRec-compliant application that offers DeRec Owner capabilities (Please bear in mind that we’re pretending that Alex lost his phone and that we’ve reinistalled the app. In reality, we didn’t reinstall it. But we’re going to re-initialize it to a fresh state). Also, even though our sample application can serve in both capacities (as a DeRec Owner and/or a DeRec Helper), it is possible for an application to only support one of the two functions (see our FAQ: Can a DeRec Owner also be a DeRec Helper?). 

The screenshot in Figure 1 below reflects the current states of Alex, Bob, Carol, and Dave’s apps. Whereas Alex has just installed the app and it is waiting to see if he wants to start in the Normal or Recovery Mode (we explored the Normal Mode in Part 1 of this series), Bob, Carol, and Dave’s apps are simply showing that Alex is listed as one of their DeRec Helpers. When Alex selected Bob, Carol, and Dave to be Helpers, our sample application automatically added Alex has a Helper to each of them. The automatic addition of a reciprocal Helper relationship is not a requirement of the DeRec Protocol. 

Figure 1: Alex lost his cell phone and has reinstalled a DeRec-compliant application. The way the sample app is designed, it checks with Alex to see if he wants to start in Normal Mode or Recovery Mode. The three helpers have had no change in status to the operation of their apps since they didn’t lose their smartphones.

Importantly, Bob is not aware that Carol and Dave are DeRec Helpers to Alex. The same goes for Carol with respect to Bob and Dave and likewise for Dave with respect to Bob and Carol. When Alex selected each of them to be his DeRec Helpers, he was careful not to tell them who his other DeRec Helpers were. If the DeRec Helpers were aware of each other, it could pave the way for a threat actor to discover the identities of all of Alex’s Helpers, steal their phones, and maliciously recover Alex’s secrets. It is therefore critical for Alex to keep the identities of his DeRec Helpers confidential. 

Moving forward, in contrast to Part 1 of this series where Alex took the path to start the application in the Normal Mode, Alex is currently locked out of his blockchain accounts because he lost his phone, and, along with the loss of that phone, he also lost the secret keys to those accounts. In order to restore that access, he needs to start the application in its Recovery Mode. However, it’s important to keep in mind that the two buttons – “Start in Normal Mode” and “Start in Recovery Mode” – are simply UI choices that were made on behalf of the designer of our demo app. Most cryptocurrency wallet applications already have a provision for importing secret recovery phrases and private keys. The feature that is labeled as a “Recovery Mode” in our demo app could just as easily be built into the import feature that’s already a part of most wallet apps. The DeRec Alliance is agnostic to such design choices. 

As shown in the screenshot in Figure 2 below, Alex has elected to begin the recovery workflow by starting the app in Recovery Mode. In our sample app, the app’s designer refers to the software container that contains Alex’s secrets as a “vault.” But again, this is a design choice. For example, some Password Managers refer to their software containers as vaults while others do not. “Vault” is just a term that is frequently used across a variety of apps to indicate a secure container of some sort. 

Figure 2: Alex has elected to start his newly installed DeRec-compliant application in its Recovery Mode.

In our demo application, Alex is presented with the option to continue with the irreversible action of recovering his secrets from his DeRec Helpers. It’s irreversible because, the way our sample app is designed, the Recovery Mode will restore the app to a freshly installed state and wipe out any pre-existing vaults. However, this is also a design choice on behalf of the developer of the DeRec-compliant app. For example, there’s no requirement that states that an app can only manage a single container of secrets. Or a single secret for that matter. Whereas some DeRec-compliant apps might allow you to keep track of multiple containers, some may only allow one. And so on. But for the purposes of this demo, Alex will tap the button to recover his one-and-only vault. 

Once Alex moves forward with the recovery workflow, his app needs to go through the pairing process with at least half of his pre-existing Helpers (the ones he paired with in Part 1 of this series). As shown in the screenshot in Figure 3 below, Alex’s app is indicating that it is in a recovery mode but is also notifying Alex that he has yet to associate his newly installed app with any DeRec Helpers. As also can be seen from the screenshot below, Alex is listed on Bob, Carol, and Dave’s apps as an “Inactive Helper.” This is because, at the moment that Alex indicated he wanted to restart the application in Recovery Mode, it returned his app to a fresh state where it is incapable of being a Helper to any Owners. Once he re-establishes his connections to Bob, Carol, and Dave, he will also be re-listed as an active Helper within their apps. 

Figure 3: Alex’s app has entered the recovery mode but is indicating that he hasn’t yet connected to any Helpers.

In other words, since Alex is starting over from scratch, neither Bob, Carol, nor Dave are paired with him anymore. Their copies of the app have lost their ability to communicate with Alex. Once Alex re-pairs with them, that connection will be restored. 

The moments at which Alex goes to re-pair with at least half of his DeRec Helpers is a very important and sensitive moment in a DeRec recovery workflow. Outside of the app, Alex must first start the process by contacting one of his pre-existing helpers (we’ll start with Bob) to let him know that he has lost is phone and would like to start a recovery workflow. At that moment, Alex must assert his identity to Bob and Bob must authenticate that assertion. For example, if Alex physically goes to meet Bob, then Bob can look at Alex and verify for himself that the person who is claiming to be Alex is, in fact, Alex. Theoretically, Alex could also assert his identity to Bob with a Zoom call. However, with such a virtual assertion, the risk that a threat actor could be impersonating Bob – especially in this day and age of AI-driven deep-fake audio and video – is greatly increased and highly discouraged.  

For these reasons, the DeRec Recovery workflow should not be automated to the point that manual intervention isn’t required from the DeRec Helpers. For example, there shouldn’t be any unattended recovery options where Alex’s DeRec-compliant app can automatically connect (via the Internet) to Bob, Carol, or Dave to start the recovery process without giving Bob, Carol, or Dave some way to verifiably authenticate Alex’s assertion of his identity. Otherwise, a threat actor could initiate the process and steal Alex’s secret. For these reasons, as DeRec Helpers, Bob, David and Carol must take great care to avoid the possibility of pairing with a malicious actor. In cases where there is no other option other than to virtually authenticate an Owner, a two-day waiting period before that authentication is completed is highly recommended to ensure that nothing malicious is afoot.

In our demo scenario, once Alex physically asserts his identity to Bob, Bob prepares his QR code to be scanned by Alex in the same exact way that he did in Part 1 of this series (as shown in Figure 4 below).

Figure 4: Bob prepares his QR code to be scanned by Alex in order to restore the Owner-Helper connection between the two of them.

The choice to use QR codes as a pairing mechanism is a choice that was made by the developer of our demo app. It is not a requirement. There are other ways to uniquely identify one DeRec node to another and most of us have seen how Bluetooth devices can pair with each without the need for a QR code (just as an example of an alternative pairing scheme). 

Next, similar to how the pairing process went in Part 1 of this series, Alex must tap the “+” button on his screen and scan Bob’s QR code. As shown by the redboxed portion of the screenshot in Figure 5 below, Alex aims the viewfinder of his smartphone’s camera at Bob’s QR code (see Part 1 of this series for a more detailed explanation of this process).

Figure 5: In order to restore the Owner-Helper connection between Alex and Bob, Alex scans Bob’s QR code

Bob’s QR code contains the information that Alex’s app needs to contact Bob’s app over the Internet. In the course of making that connection, Alex’s app basically says “Hi, it’s me Alex.. the same Alex that you paired with, but this time from a different phone. And now I’d like to begin the process of recovering my secret. At the moment Bob’s app receives this message, it gives Bob an opportunity to approve or deny the request as shown in Figure 6 below.

Figure 6: Bob is given the opportunity to confirm or deny Alex’s attempt to restore their original Owner-Helper connection

This is that all-important moment where Bob must manually make a choice based on the way that Alex asserted his identity. Since Alex is physically standing in front of Bob, Bob taps “Proceed with recovery”.

Now, as shown in the screenshot in Figure 7 below, Alex is once again listed as one of Bob’s connections. However, from Carol and Dave’s point of view, Alex is still inactive. The screenshot below also shows a message at the bottom of Alex’s screen that Bob was added as a DeRec Helper but that Alex needs to pair with more Helpers (at least half of them) in order for the recovery workflow to proceed.

Figure 7: Alex has restored his connection with Bob. However he isn’t finished yet. In order to restore his secret, he must restore the connections with at least half of his helpers

The way the DeRec Protocol works, Alex needs to pair with at  least half of his pre-existing Helpers in order to complete the recovery workflow. In Alex’s case, since he originally paired with three Helpers, he only needs to pair with two of them in order to recover his secrets. Alex picks Dave as the second of his three existing Helpers and the two of them repeat the exact same process (assertion, authentication, etc.) that took place with Bob. Once Dave approves the continuation of the recovery process and his app is successfully paired with Alex’s app, the recovery workflow is complete (as indicated in Figure 8 below). 

Figure 8: Once Alex re-pairs himself with Bob and Dave, he will have paired hims with at least half of his helpers. As indicated by the messages on the bottom of Alex’s screen, once Alex paired with at least half of his Helpers, his vault was automatically recovered. The decision to automate the recovery (once the pairings were complete) is a developer design decision.

As the messages on Alex’s copy of the app show, not only was Dave re-added as a Helper, the recovery process was successful. 

Additionally as shown on Figure 9 below, even though Alex never deliberately restored his connection to Carol, his app is listing Carol as one of his active Helpers. This is because of the way the DeRec Protocol works. When a user like Alex reconnects with half of his Helpers as a part of a DeRec recovery workflow, that workflow results in the restoration of all of his Helper connections as well as his lost secrets. 

Figure 9: When Alex completed the recovery of his secrets, it also recovered the remaining half of his Helper connections (essentially, the connection to Carol)

Once the DeRec recovery workflow is complete, Alex’s DeRec-compliant application is restored to the same state as though he never lost his smartphone in the first place. This includes access to all of his secrets as well as connections to all of his Helpers.  

The video version of the recovery workflow, beginning with the reloading of the app, appears below.  

https://derecalliance.org/wp-content/uploads/2024/02/DeRec-Video-v3-DeRec-1.mp4#t=464