Recovery Process Details
In this example, we'll explore a key recovery process using fictional users—Steve, Amy, Jamie, and Paul. This process outlines how an inheritor can regain access to a key in the event that Steve is no longer available. We use a method based on **Commutative ElGamal (CEG)** encryption, which allows for secure and verifiable key recovery.
​
This process ensures that even in Steve's absence, the recovery of his key is handled securely, transparently, and with proper authorization. The use of commutative encryption techniques like Commutative ElGamal provides a robust and verifiable method for key recovery.
Initiating the Recovery
The recovery process begins when someone other than Steve, such as Amy, Jamie, or Paul, initiates the key recovery. The process requires coordination with our platform to ensure security and proper validation.
Verification and Communication
Once the recovery request is initiated, we notify Steve (if possible) and begin the verification process. This includes requesting a death certificate or other necessary documentation to confirm the need for recovery.
- **Step 2.1:** A mandatory 1-month delay is enforced to ensure due diligence and allow time for any potential disputes or additional verification.
Inheritor Verification and Key Generation
After verifying the inheritor's identity, their client software generates a **Commutative ElGamal (CEG) key**, referred to as `InheritorCEG`. This key will be crucial in the decryption process.
Notifying Participants
We then notify all participants in the recovery set (e.g., Amy, Jamie, Paul) and prompt them to log into the platform.
Decryption and Re-Encryption by Participants
Each participant is provided with the `InheritorCEG` key. They follow these steps to decrypt and re-encrypt their share:
​- **Step 5.1:** The participant uses their AES password-protected private ECDH key to decrypt their share. Initially, this share was encrypted with both LockboxCEG and their own public key, but now it’s only encrypted with LockboxCEG, resulting in `LockboxCEG[share]`.
- **Step 5.2:** The participant then re-encrypts this `LockboxCEG[share]` using the inheritor's `InheritorCEG` key, creating a new encrypted share: `InheritorCEG[LockboxCEG[share]]`.
- **Step 5.3:** The participant sends this newly encrypted share back to our server.
- **Step 5.4:** On the server side, we use our CEG key to remove our layer of encryption from the share, leaving only the inheritor’s encryption: `InheritorCEG[share]`.
- **Step 5.5:** We then send this decrypted and re-encrypted share directly to the inheritor.
Inheritor Decrypts and Combines Shares
Once the inheritor receives `t` (the threshold number) of encrypted shares, they can use their `InheritorCEG` key to decrypt each share. After decrypting, they combine the shares to reveal the original seed phrase.
The inheritor now has full control of the seed phrase, granting them access to the associated funds or data.