1.White Paper
Bitverse Whitepaper
Bitverse MPC Wallet Key Management System Whitepaper
(1) Abstract
Bitverse is a safe, secure and decentralized Multi-Party Computation (MPC) digital wallet that does not require users’ personal, manual storage of corresponding private keys. Due to the overarching distributed key share architecture behind MPC wallets, common risks that are associated with insecure storage of private keys and a single signature verification point can be eliminated. Users will have absolute and full ownership over their wallet and funds with 100% privacy guarantees; trades can only be initiated by the users as Bitverse does not hold custody of a user’s funds.
This is all made possible due to the design of the Bitverse Key Management System (KMS), that is rooted in:
Cryptographic security
The use of a Trusted Execution Environment (TEE)
Multi-pronged security verification via distributed key shares and encryption safeguards
Reliable backups that will enable the safe and convenient management of a user’s wallet without the need for manual storing of their private keys
Users will find an independent wallet backup and recovery mechanism on the Bitverse platform that promises safe access and protection over their funds even in the case of any Bitverse service disruptions.
(2) Background
Existing digital wallets on the market, while already an innovation on traditional bank accounts or other fund storage systems, rely solely on users actively remembering and manually storing their private keys or recovery phrases in a safe manner. Similarly, the loss of private keys and recovery phrases in any of the following ways exposes a user’s funds to risks:
Writing down the wrong recovery phrase words
The fading of ink with a written recovery phrase note
Losing the document or note that the phrase is written on
If the screenshot or online storage falls into the hands of malicious third party actors
These are undoubtedly stressful scenarios for most, if not all crypto wallet users. These fears are hardly unfounded. Digital wallets governed by centralized entities that hold custody of the funds deposited often provide ways to help their users remember and store their recovery phrases, but theft of recovery phrases to gain unauthorized access to a user’s wallets are not uncommon. At the same time, there is also the possibility of already existing security risks with the centralized wallet service in use.
Bitverse’s goal is to be a decentralized cut above the rest, its design underpinned by an MPC foundational layer [Threshold Signature Scheme (TSS)], all to eliminate the risks that come with single private key and signature verifications. Bolstered by cryptographic security and safe storage mechanisms, Bitverse is the key to solving all existing private key challenges that a user faces — all with a unique private key share backup and recovery model.
(3) MPC & TEE Private Keys Secure Storage
3.1 Generation of Distributed Key Shares
The Bitverse Wallet is built on the MPC (2-of-2 multi signature) TSS, where the Bitverse MPC client and server nodes generate parts of their respective private keys via distributed key shares. Both private key shares are stored separately on the client and server node ends.
3.2 Distributed Signatures
When a transaction happens, the client node will trigger the signature request. In the process, both the MPC client and server nodes will generate the transaction signature via homomorphic encryption and decryption, before the client node publishes the transaction onto the blockchain.
At any point in time, the client and server nodes will only own their respective share of the MPC private key. No single node is able to complete the signature verification process for the transaction to be approved. Even if the private key details are leaked from either node, the assets in the wallet remain safe and inaccessible by third parties.
3.3 Secure Private Key Storage
Bitverse’s aim is to remove the burden of manual private key and recovery phrase storage in typical forms — with the Bitverse MPC wallet, users will no longer need to write down, screenshot or physically store and manage the keys to their digital wallet. Users can save their share of private keys in an isolated environment. Their complete private keys will never appear online (or offline) at any time.
Instead, users who have paired their MPC private keys with their email address can effectively restore their wallets with a backup through the same email. The necessary details required for the backup wallet are stored in the user’s personal online cloud storage — Bitverse’s MPC server node does not have any access to the user’s cloud storage. It is critical to highlight the full control that a user has in retrieving their wallet; and when the user switches out their old devices for new ones, all they need to do is verify their ownership over the wallet via email and cloud storage to instantly recover it.
The generation of the MPC server node private key share, multiple signature scheme and encryption are executed in a TEE via the AWS Nitro Enclaves (see section 7.1 below). The Nitro Enclave utilizes Nitro Hypervisor technology under EC2 instances to isolate the CPU from its internal memory and in turn, create an isolated data environment, also known as an independent “enclave”.
It is a hardened and highly constrained virtual machine based on the Nitro Hypervisor, which ensures that the parent instance has no way to access the virtual CPUs (vCPUs) and memory within an enclave. Correspondingly, it is impossible for the enclave to permanently store, interact with or visit external sites. Its only function is to support connections between a parent instance and a safe socket.
Users are able to access neither the enclave via Secure Shell (SSH), nor any processes, applications or users (root or admin) of the parent instance within the enclave’s environment.
(4) MPC Client Node Private Key Management
4.1 Client Node Private Key Share Storage
The Bitverse MPC wallet was designed with the Lindell et al. MPC (2-of-2) algorithm. As mentioned earlier in this whitepaper, the Bitverse MPC client and server nodes separately generate their individual private key shares via the distributed key share algorithm. A full private key will not be generated, and the client node private key share is stored on the App via a user’s encrypted password.
The client node utilizes a Key Derivative Function (KDF) algorithm, Scrypt, to turn a user’s password into a corresponding AES-128-CTR algorithmically-encrypted salt. This places an added layer of Advanced Encryption Standard (AES) encryption on the client node’s private key share, also known as Secret Share Key 1. After this, the key share is once again encrypted and stored through the operating system’s inbuilt security encryption and storage architecture. For Android devices, the private key share will be stored in the Keystore, and for iOS, on the Keychain.
A cryptographic salt is generated after a user enters their password for data hashing; the password will neither be locally stored, nor transmitted online. For example, in the event a hacker attempts to access the private key shares stored on the App, they are unlikely to decrypt them. Even if the key(s) are decrypted, hackers will only be able to obtain a partial share of the full private key. Bitverse guarantees that no single party or entity will be able to get access to a complete private key, and so, the safeguards on Bitverse’s MPC wallet are perpetually unbreakable.
4.2 Client Node Private Share Key Backup
When the MPC client node on Bitverse randomly generates a Rivest-Shamir-Adleman (RSA) key pair, this private key pair is then stored in the user’s cloud storage. The Bitverse App will only be authorized for access after user approval and verification via their cloud storage.
After the RSA public key encrypts the client node private key share, it will be sent to the Bitverse KMS server node as a ciphertext. This transmission of data too, is protected via Zero-Knowledge (ZK) range proof technology — all to prevent unauthorized changes by malicious actors during the process. This helps the server node to receive verified and unchanged encrypted data, without exposing client nodes to vulnerabilities.
Upon receiving the verified and encrypted data from the client node end, the Bitverse KMS server node will encrypt and store the data within a TEE, based on the AWS Nitro Enclaves (see sections 3.3 and 7.1). Data that is held within the TEE is isolated from the rest of the network and no one, including Bitverse’s creator, is able to decrypt and access it.
The only data that remains on the Bitverse server node is restricted to the encrypted client node private key share. The key for decryption continues to be stored only within the user’s personal cloud storage, eliminating any possibility of exposure from Bitverse’s end.
(5) MPC Server Node Private Key Management
5.1 MPC Server Node Key Share Generation
The MPC server node private key share is generated within a TEE is served by AWS (see sections 3.3 and 7.1) . The generated Secret Share Key 2 goes through an added layer of encryption in the TEE and is then stored in the database; this key is not visible to or accessible by any individual or entity — not even the creators and developers of Bitverse. This fortifies and guarantees absolute security of this server node private key share from external attacks.
5.2 Server Node Key Share Signature
The Secret Share Key 2 is stored within the Bitverse MPC server node as a ciphertext in an enclave. When the client node triggers a signature request, the server node then sends the Secret Share Key 2 ciphertext to the enclave environment. Only within the enclave does decryption occur for the complete processing of the signature verification request, before the transaction is sent back to the client node.
The Bitverse server node can execute multi-signature verifications within the TEE; during this process, the Secret Share Key 2 will only be fully visible within the isolated enclave, thus ensuring maximum underlying security of the environment in which signatures are processed.
5.3 Secret Share Key 2 Backup
Each moving part within the Bitverse system reiterates a user’s full control and ownership over their wallet and funds. In the unlikely event of Bitverse service disruption or temporary suspension of Bitverse services, users retain the complete freedom to manage their assets. The backup to the MPC server node private key share, i.e. Secret Share Key 2, is stored on the user’s cloud storage and protected under double-layered encryption.
The server node within the TEE uses the Public Share Key 1 to proceed with Elliptic-Curve Cryptography (ECC) encryption on the private key share, Secret Share Key 1 (see section 7.2 below). Thereafter, the encrypted data is sent back to the client node, where the user will further encrypt the received ciphertext using their password before saving it on their cloud storage. Only with the user’s password and verification through the cloud storage account will it be unlocked.
Similar to section 5.2, ZK range proof (see section 7.3) is utilized to erase any possibility of backup data being transmitted online. Therefore, the client node is able to verify the authenticity of the data sent from the server node end without any sensitive data and information being revealed at any point of this process.
(6) Wallet Recovery
6.1 Switching Devices
With the Bitverse MPC wallet, the need for manual storage and memorizing of private keys and recovery phrases respectively is removed. This is particularly useful when users switch from old to new devices, as they are able to safely recover and restore their wallet via their Bitverse-linked email account.
After users verify their identity via their emails, the Bitverse MPC server node will then decrypt the double-encrypted Secret Share Key 1 within the TEE. A ciphertext is produced, in this case named e(sk1), a random RSA key pair after encryption on the client node end. e(sk1) is then returned to the client node. With ZK range proof, the client node is able to verify the accuracy and reliability of the received data.
For the Bitverse client node to decrypt e(sk1), it will have to retrieve the RSA key pair within the user’s cloud storage. The cloud storage access permission is held solely by the user and requires them to personally log into their personal cloud storage account to manually approve any accessing party; Bitverse will not be able to access a user’s cloud storage at any point other than when its request has been approved.
After the successful decryption of e(sk1) on the client node end, users will need to enter their password (see section 4.1) to ensure the safe storage of the client node private key share. The key share is encrypted via AES, then saved in the device’s Keychain on Android or Keystore on iOS.
6.1.1 3FA Verification
Within the Bitverse MPC wallet system, Three-Factor Authentication (3FA) is utilized and includes:
The user’s cloud storage verification, stored on the user’s personal cloud storage service
A user’s verification code sent to their email address
The Bitverse server node’s TEE
This is to aid in a user’s recovery of their wallet and funds in the event they forget their password, or switch devices. Each 3FA component is independent from each other in the unlocking and recovering of the Bitverse MPC wallet. If verification for any of the three requirements above fails, recovery of the wallet will be unsuccessful. Therefore, in the event any of the components to the 3FA is leaked, capital losses for the user can be avoided.
6.2 Forgot Password
The Bitverse MPC client node private key share is encrypted via AES and safely stored on the App. A corresponding encrypted salt is generated via the KDF algorithm, Scrypt, with the user’s password. The password is the only thing that users will have to remember and is only used on the client node. It will not be transmitted online in any form.
Once a user forgets their password, they can reset it on the decentralized Bitverse MPC wallet. User passwords will only be effective on the App and will require users to remove all App-related data or delete and re-download the Bitverse App after a password change. Thereafter, the user will have to verify their identity and approve permissions via their email account and personal cloud storage respectively to restore the client node private key share (see section 6.1). All the user needs to do as a final step is to encrypt their new password and store it locally on the App.
6.2.1 3FA Verification
Refer to 6.1.1.
6.3 Bitverse Server Disruption
In the unlikely event that Bitverse experiences server disruption and has to temporarily suspend its services, Bitverse offers a safe recovery model that guarantees protection over a user’s assets. A single private key can be exported with the user’s encrypted cloud storage private key share, Secret Share Key 2, and the Bitverse MPC client node’s private key share, Secret Share Key 1. This process will require the user’s password for decryption.
Users can use the exported private key as they would with a typical non-MPC wallet. After importing the private key into other digital wallet applications, users can proceed with the recovery of their funds.
6.3.1 3FA Verification
To export the complete private key to the Bitverse MPC wallet, 3FA is required, and this includes:
The user’s cloud storage verification, stored on the user’s personal cloud storage service
The user’s password verification
The private key share stored on the App
Each 3FA component is independent from each other in the unlocking and recovering of the Bitverse MPC wallet. If verification for any of the three requirements above fails, recovery of the wallet will also be unsuccessful. Therefore, in the event any of the components to the 3FA is leaked, capital losses can be avoided.
(7) Security & Cryptography
7.1 AWS Nitro Enclaves
The following section is a copy of official AWS documentation (see references) on its Nitro Enclaves.
AWS Nitro Enclaves is an Amazon EC2 feature that allows you to create isolated execution environments, called enclaves, from Amazon EC2 instances. Enclaves are separate, hardened, and highly constrained virtual machines. They provide only secure local socket connectivity with their parent instance. They have no persistent storage, interactive access, or external networking. Users cannot SSH into an enclave, and the data and applications inside the enclave cannot be accessed by the processes, applications, or users (root or admin) of the parent instance. Using Nitro Enclaves, you can secure your most sensitive data, such as personally identifiable information (PII), and your data processing applications.
Nitro Enclaves also supports an attestation feature, which allows you to verify an enclave's identity and ensure that only authorized code is running inside it. Nitro Enclaves is integrated with the AWS Key Management Service, which provides built-in support for attestation and enables you to prepare and protect your sensitive data for processing inside enclaves. Nitro Enclaves can also be used with other key management services.
Nitro Enclaves use the same Nitro Hypervisor technology that provides CPU and memory isolation for Amazon EC2 instances in order to isolate the vCPUs and memory for an enclave from a parent instance. The Nitro Hypervisor ensures that the parent instance has no access to the isolated vCPUs and memory of the enclave.
7.2 ECC Encryption and Decryption
ECC is a technique used to fortify the security of encrypted data, and is based on calculations over elliptic curves in finite fields on a graph. A similar concept in the field of cryptography is RSA key pairs, but compared to RSA key pairs, the advantage of ECC lies in the effective encryption of shorter private keys, which match or surpass the security standards provided by RSA.
Let’s refer to private keys and public keys as d and Q respectively. In a formula where Q = d * G and G as the base point for the elliptic curve, it is a laborious endeavor to solve the equation for d even with known factors G and Q. To put it plainly, it is impossible to solve for the private key with only the public key and elliptic curve base point.
Public Key Encryption
Firstly, let’s look at the random value r. Through r and public key Q, if we generate a ciphertext based on a message, denoted as M, then:
C = {C1, C2}, where C1 = M + (r * Q) and C2 = (r * G)
Private Key Decryption
D(C) = C1 - (d * C2) = M + r * Q - (d * r * G) = M + (r * d * G) - (d * r * G) = M
7.3 Zero-Knowledge Proofs
ZK proofs are typically used on blockchains for data verification so that validators, without clear knowledge of what that data comprises, are able to validate its accuracy and authenticity. On Bitverse, ZK range proofs have been integrated in the private key share backup and recovery process. The Bitverse MPC client and server nodes can therefore validate the private key shares without exposing any critical portions of the data.
(8) References
https://help.apple.com/pdf/security/en_US/apple-platform-security-guide.pdf
https://source.android.google.cn/security/trusty
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57Pt3r1.pdf
https://docs.aws.amazon.com/enclaves/latest/user/enclaves-user.pdf
https://eprint.iacr.org/2017/1066.pdf
Bünz B, Bootle J, Boneh D, et al. Bulletproofs: Short proofs for confidential transactions and more[C]//2018 IEEE Symposium on Security and Privacy (SP). IEEE, 2018: 315-334.
Li L, Abd El-Latif A A, Niu X. Elliptic curve ElGamal based homomorphic image encryption scheme for sharing secret images[J]. Signal Processing, 2012, 92(4): 1069-1078.
Last updated
