Private Key Generation (Keygen)
The above figure demonstrates the Private Key generation process of our 2-3 default scheme, which requires 3 participants: User Device, Hot Server, and Cold Server. The entire Keygen cycle carries a unique Session ID to identify a single round of information. The messages are passed through the message queue (MQ). Using end-to-end encryption and token authentication ensures 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:
The client initiates a keygen request to the server to obtain the Session ID.
The server responds to the request, generates a Session ID, and returns it to the client.
The client broadcasts the Keygen initiation message with Session ID to the MQ. Meanwhile, the Keygen process is started asynchronously locally.
The MQ receives the request, analyzes the user token, and checks whether it is legal in the user center.
If the authentication passes, proving it is a client-side routine request; otherwise, it directly refuses to return.
The MQ broadcasts the Keygen initiation message to the channels subscribed by Hot Server and Cold Server. When they receive the message, they also start the Keygen process asynchronously one after another.
The MQ returns a successful broadcast response and the client starts the MPC protocol interaction process. Otherwise, a Keygen exception would occur.
User, Hot Server, and Cold Server exchanged MPC information several times by MQ. Finally, the Hot Server encrypts the generated Private Key fragments in TEE and stores them in the DB. For Cold Server, the Private Key fragments after TEE encryption are transferred to a trusted third party for cold data storage. Next, the Hot Server and Cold Server broadcast the Keygen end signal respectively.
The client needs to ensure that the end signals of the Hot Server and Cold Server are received, and the local Private Key is also generated.
The client uses AES-256 to encrypt and store the Private Key fragments locally.
The client informs the server user center of the Private Key generation result and Private Key version information.
The server records the Private Key version of the corresponding device, sets the account to be active, returns a successful response, and the entire Keygen process ends.