Skip to main content

Private Key Reset



resetKey


The above figure demonstrates the Private Key reset process of our 2-3 default scheme, which requires 3 participants: User Device, Hot Server, and Cold Server. The entire reset life cycle carries a unique Session ID to identify a single round of information. The message is passed through the message queue (MQ) using end-to-end encryption. It uses token authentication to ensure that each party can only obtain the messages of its own Channel. Hot Server and Cold Server are permanent services that can receive information anytime through message subscription.



The specific steps of Keygen are as follows:

  1. The user initiates a reset request to the server.
  2. The server sets the user account to the "resetting" state, freezes the Private Key operations of all devices, and returns a successful response.
  3. Users must wait seven days to prevent malicious Private Key Reset. If the users do not do it, they can cancel the reset and change the account password
  4. After the seven-day waiting period, the user center will bring the user's Login Email and Secure Email information to apply to the third-party cold data storage to retrieve the Private Key through a unique secured channel.
  5. After the third party verifies the validity of the request, it returns a response and starts the process of retrieving the Private Key asynchronously. After decryption in TEE, the Private Key is split into two parts. Then, after encrypting and compressing the information, it will be sent to the user's Login Email and Secure Email, respectively.
  6. After the user acquires two Private Key fragments from the Login Email and Secure Email, they will upload them on the reset page. Then the reset process officially started.
  7. The client initiates a reset request to the server and obtains the Session ID.
  8. The server responds to the request, generates a Session ID, and returns it to the client.
  9. The client broadcasts a message to MQ with Session ID to initiate the reset process. At the same time, the reset process is started asynchronously locally.
  10. The MQ receives the request, analyzes the user token, and checks whether it is legal or not in the user center.
  11. If the authentication is passed, proving it is a routine request from the client. Otherwise, it directly refuses to return.
  12. The MQ broadcasts the initiation message to the channels subscribed by Hot Server and Cold Server. When they receive the message, the reset process starts asynchronously, one after another.
  13. The MQ returns a successful broadcast response, and the client starts the MPC protocol interaction process. On the contrary, a reset exception would occur.
  14. User, Hot Server, and Cold Server exchanged MPC information several times by MQ. Finally, the Hot Server encrypts the generated Private Key in TEE, stores it in DB, and marks the previous Private Key as invalid. The Private Key is transferred to a trusted third party for cold storage for Cold Server. Next, Hot Server and Cold Server broadcast reset end signals, respectively.
  15. The client needs to ensure that the Hot Server and Cold Server's end signals are received, and the local Private Key is reset and generated.
  16. The client uses AES-256 to encrypt the Private Key fragments and store them locally.
  17. The client informs the server of the Private Key reset result and the new Private Key version information.
  18. The server records the new Private Key version of the corresponding device, sets the account to be active, returns a successful response, and the entire reset process ends.