Skip to main content

Overview

When we consider building an OnChain wallet, we first need to understand our users and their most significant painpoint to solve. Although blockchain has been popular recently, it still needs time for the general public to recognize the technology. The fundamental reason is the lack of a safe and easy-to-use wallet, which is convenient for everyone to enter the web 3.0 world anytime and anywhere. So, to answer the questions above:

Q: Who are our users?

A: Our target users are the general public who lack professional skills to adopt blockchain technologies and applications.

Q: What problem are we trying to solve?

A: To answer this question, we must be clear about the most significant pain point of the OnChain wallet: Private Key and recovery phrase management. In the blockchain world, the Private Key controls everything. Once lost or stolen, it means permanent loss of assets, which is unbearable for the general public. We hope to make a product that does not need to worry about Private Key security, decentralized, intuitive, and easy to use like web2.0 applications. Users only need to log in to the website to experience the blockchain.

Based on the considerations above, we chose to use MPC (Secure Multi-Party Computation) technology to implement Threshold Signature Scheme (TSS), which can accomplish distributed Private Key generation and transaction signature. There are several benefits:

  1. The Private Key has no single point of failure: each participant only owns partial Private Key fragments. From account signup to signing a transaction, the complete Private Key never exists during the entire life cycle, which can eliminate the risk of Private Key theft.

  2. Better anonymity: Traditional OnChain multi-signature compromises privacy because information about the signer must also be transmitted on the blockchain. In TSS, signer information is included in general transactions, reducing costs while maintaining confidentiality.

  3. Lower complexity: Traditional OnChain multi-signatures are blockchain-specific, which means that they must be reimplemented for each blockchain yet in some cases, they are not supported at all. However, TSS relies on pure encryption technology, which completely avoids the heterogeneous designs of different blockchains.

  4. Higher security: TSS supports Private Key rotation. The Private Key fragment holders can initiate a process to change the fragment implementation without changing the corresponding public key and address on the blockchain. This structure adds a temporary layer of security. When a Private Key is lost or leaked, the design allows the users to reset and retrieve the key. The attacker must simultaneously break through multiple Private Key devices before the Private Key is rotated.

Next is to determine the TSS architecture, which means how many fragments are split from the Private Key and who is in charge of each fragment. Generally speaking, the more fragments split from the Private Key means higher security and more significant performance loss. For example: in a 5-8 structure, each signature requires 5 participants to interact online simultaneously, significantly reducing the performance and the ease of use. However, fewer splits mean a lower level of security. For example, in a 2-2 structure, both parties must make sufficient backups. Once lost, a single party cannot do the reset. We have created a trade-off regarding security and ease of use by adopting a 2-3 architecture for our product. The Private Key is split into three fragments, and the signature only requires two of the participants to interact online. And to determine who keeps the Private Key, we provide two options:

  1. Default scheme: Users, OpenBlock, and trusted third party. Holding one fragment alone and working with the 24-hour online OpenBlock service, the general public can complete the signature anytime and anywhere. The third shard is stored in a trusted third-party cold data storage, and we will try our best to select credible institutions. The institutions are only responsible for storage, and they cannot decrypt the fragments. Users can apply to retrieve the third fragment at any time, such as when their Private Key is lost and needs a reset. The following illustration is a simple demonstration of the default scheme signing process for reference only.

  2. Upgraded scheme: user device 1, OpenBlock, and user equipment 2. For professional users, it is necessary to maintain zero trust in third parties but still have specific security backup capabilities. Therefore, it is better to hold two fragments on multiple devices. This strategy has not been launched yet, so stay tuned

Security is the foundation for a smooth user experience. Without a strong layer of security, everything is impossible. The above describes the form of our Private Key security. The following introduces some security considerations in engineering implementation.

  • Infrastructure Security

  1. We choose AWS to deploy our services. Their security and data privacy controls have been regularly attested and validated with compliances. It is widely known that they have been continuously innovating in world-class security infrastructure establishment. In addition, reliability and availability are also our primary considerations. From container services to Private Key management services, AWS provides more than 99.9% uptime, which is the basis for us to provide stable services to our customers.

  2. Isolated network environment: OpenBlock deploys services in virtual private clouds (VPC). Each environment (dev, uat, and prod) has a dedicated VPC, and no communication is allowed between VPCs except with the VPN's VPC. Within a VPC, we divide our network into public subnets and private subnets. Services deployed in public subnets are accessible to the world, whereas those in private ones aren't. This allows us to deploy core business logic in the private network and protect those services from being influenced by the internet.

  3. Real-time intrusion detection: OpenBlock deploys intrusion detection systems in its cloud environment. We analyze all of our VPC logs, DNS logs, and service logs to detect threats and any unauthorized access. We continuously monitor the traffic and will take action when it's needed.

  • Communication Security

The request parameters and response data can be obtained by capturing packets in the traditional Internet API interaction. Parameter manipulation, SQL injection, and replay attacks are prevalent attacks unacceptable in financial products. Communication security is critical, especially with the information related to user privacy and Private Keys. Corrupted parties can steal this information if users are not careful. In our engineering practice, we have done the following:

  1. Communication using HTTPS

  2. Signature request to prevent parameters from being tampered with

  3. Identity confirmation mechanism. Each request must be verified for the legality

  4. Use SSL pinning in APP to prevent packet capture

  5. Encrypting all requests and responses.

  • Data Security

  1. Encrypt and store users' local data with the AES-256 encryption algorithm.

  2. Encrypt and DB store server-side data with AWS KMS adjustment in Trusted Execution Environment (TEE).

  • Execution Environment Security

To further enhance the security level and prevent possible internal malicious activity, our Private Key generation, signature, reset, encryption, decryption, and other sensitive operations are all executed in Trusted Execution Environment (TEE). TEE is an isolated space separated at the chip level to establish an isolated execution environment that runs in parallel with the local operating system to ensure that the code and data loaded into the interior are protected in terms of confidentiality and integrity. Also, sensitive code and data are protected from privileged attacks and potential vulnerability in the native operating system. See the "Trusted Execution Environment" chapter for more details.