A Deep Dive into ZenGo Guaranteed Access Solution

TL;DR: ZenGo guarantees access to your funds even if ZenGo, the company, ceases to operate.

At ZenGo, our mission is to provide a superior user experience that enables our users to simply and securely manage their crypto assets without the typical risks associated with private key management and account recovery. These risks include the theft or loss of personal wallet (hardware/software/mobile) private keys, damaging hacks, and/or brutal failures of custodial service such as exchanges.

On a previous post we had described our “Guaranteed Access” solution, that allows users to access their funds even if ZenGo, the company, is unable to operate.

In this blog post, we would take a deeper look into the technical and operational details of the solution.

Guaranteed access: A high-level reminder

The “secret share” stored on the ZenGo server (“Server Share”) is far less susceptible to loss compared to the Client Share. We use best-in-class cloud-based safeguards and backups to ensure that we never lose the Server Shares.

However, what happens if the company itself becomes unable to operate? How will transactions ever be signed without the server? Even if we believe the probability of that event to be very low, we had to be prepared for that unlikely scenario. We have invested a substantial amount of time, energy, and resources into addressing this concern.

In response to this scenario, we designed a solution relatively similar in concept to Client Recovery, but without the need for ZenGo’s server to be operational. To the best of our knowledge, this is the first such solution in our industry. We call it “Guaranteed Access.”

During normal operations:

  1. We instituted this guaranteed access process by creating both a master encryption and a master decryption key. Next, we deposited this master decryption key in a known escrow (EscrowTech) and appointed a law office (JRG) as trustee. The trustee’s role is to check and report on ZenGo “proof of life,” composed of both legal and technical criteria. The master encryption key is maintained on our servers and continuously encrypts the server share, every time a new one is created;
  2. Every client then gets an encrypted version of that server share (encrypted with the master encryption key).

During recovery mode:

  1. If the Trustee discovers that ZenGo is not operational, they can request the decryption key from the escrow provider;
  2. The trustee will then post the decryption key to a dedicated GitHub account. This process is run by humans with multiple safeguards and checks to avoid wrong signals;
  3. ZenGo, the mobile app installed by our customers, constantly monitors this repository and if a valid key is released, it enters recovery mode;
  4. Upon entering recovery mode, the app is able to decrypt the Server Key and recreate the private keys for all the associated coins and addresses. These private keys can then be loaded to other wallets. That way, users are free to move their funds without relying upon ZenGo servers.

It should be noted that the sole purpose of this encryption and decryption keys is to recover the shares in case of need and they cannot be used for any other purpose, such as spending funds.

Guaranteed access: deep dive

Creating the master key

We had mentioned that ZenGo created both a master encryption and a master decryption key.

The master encryption key is maintained on our servers and continuously encrypts the server share, every time a new one is created; every client then gets an encrypted version of that server share (encrypted with the master encryption key).

Naturally, the master decryption must be created and kept in a secure manner. To do so, we created the keys on a fresh computer (in fact, a Raspberry Pi), that was never connected to the internet. Then we encrypted the master decryption key with a unique PGP key supplied to us by the escrow and sent the encrypted key to the escrow over an encrypted protocol.

To make sure the key could not be stolen from the Raspberry Pi, we had deleted the files and physically destroyed the device and its memory card.

Validating the keys deposit

To make sure that the Escrow received the correct decryption key that matches the public key, the escrow performed a signing operation that takes a string created on the date (we included BTC’s price on the date) and cryptographically signs with the decryption key. This allows anyone that holds the public key to verify that indeed the Escrow holds the appropriate decryption key (all without revealing the decryption key itself.)

In fact, you can validate it too!

The signing file was uploaded by our Trustee to GitHub

Anyone can input the public key, string, and signature to a crypto tool, such as the open source openSSL library, and verify the correctness of the signature.

The Trustee role

During normal operation of ZenGo the trustee monitors its “liveliness” through legal and technical proof or signs of life and proper operation.

If everything goes well, then on each new calendar quarter a letter is published by the Trustee on GitHub. The first report is already live.  

If the Trustee discovers and verifies that ZenGo is not operational, then they will request the decryption key from the escrow provider; the trustee will then post the decryption key to a dedicated GitHub account.

Validating the solution end-to-end

Before we launched ZenGo publicly, we had to test and verify the above solution to guarantee that it actually works.

For that purpose, we simulated the key release with our trustee.

The trustee has uploaded a report to GitHub to attest to that.

Here are the various steps a ZenGo customer would go through should the recovery process be triggered by the trustee and escrow company.

1. Below, you can see a ZenGo account with some funds. Note – naturally, you must have an installed ZenGo app before the recovery can take place;

2. The trustee releases the Decryption key to GitHub;

3. Upon launch, the ZenGo app checks the Github URL. If it detects the release of the Decryption key, it activates the “Account Recovery” mode. Now we are able to export the associated private keys from the ZenGo wallet to any new wallet;

4. When we clicked “Export Keys,” we were provided with a list of public addresses and their corresponding private key;

5. Finally, we were able to load those keys to another wallet and access the funds.

You can check out the transaction on the Bitcoin blockchain: https://www.blockchain.com/btc/address/3MiCZmZomvhwTov3gazmwmgLe8KVPk4W5w

The above would work simultaneously for every single ZenGo customer with a valid account, no matter the amount of funds they own.

Conclusions

It is critical to ZenGo’s own mission to be able to guarantee customers access to their funds no matter what. Because of the unique approach we have taken with our security design and the role of both the client and the server, we had to create recovery solutions for both sides that are highly reliable, secure, and verifiable –before we have even launched.

To make sure that your funds are safe even if one of the shares is lost, we created innovative backup solutions for all scenarios. We plan to keep investing in this area as we grow.

To our knowledge, this is the first time a wallet solution provides such a guarantee operated in such a way. In a way, think of it as a decentralized version of ZenGo for the purpose of systemic recovery.

We have more ideas on how to improve this area. But as of today, our system guarantees you peace of mind.