BOX (Enterprise Digital Asset Safe) is a set of enterprise-level digital asset security solutions based on block technology. It relies on axiomatic technologies in the fields of blockchain, cryptography, communication security, etc. to achieve seamless connection between technologies, fundamentally solving the industry's pain of private keys being stolen and instructions being tampered with. At this stage, BOX mainly serves digital asset exchanges, digital asset investment institutions and related entrepreneurial teams.

Project Introduction

BOX (EnterpriseTokenSafeBox) is an enterprise-level digital asset safe application. It uses axiomatic technologies in the fields of blockchain, cryptography, communication security, etc. to protect the private keys and operation instructions of various digital assets, and solves the problems of private keys and instructions in principle.

Project Highlights

Design Thoughts
BOX is a digital asset banking system owned by enterprises. Through the BOX system, the various digital asset wallets owned by the enterprise are managed centrally, and the private keys are encrypted and run in memory will never be exposed. Through the private blockchain network owned by the enterprise, the enterprise's customized asset management business flow is constructed through sequential private key signatures, and the communication channel is guaranteed to be absolutely safe through SSL/TLS encryption. BOX has been able to prevent vulnerabilities that are common in personal wallets such as external hackers, internal hackers, and single-person misoperation. At the same time, BOX has security mechanisms such as intrusion locking and system resetting to ensure the high security of corporate digital assets.

Private Key Security Mechanism
The private key is stored in the memory of the signing machine and will not be persisted. After the signing machine is invaded in extreme cases, it is difficult for the intruder to find the private key in a short period of time, greatly reducing the risk of private key exposure.

In order to prevent the generation of private keys from being simulated, we adopt the deformation form of RFC6979 protocol: k=SHA256(d+SHA256(m1)+SHA256(m2)+SHA256(m3)+…), d is the server random number, and m is the key sentence input by the private key APP. The generation of a private key is generated by inputting key sentences by three private key APPs respectively. The key sentences are strings composed of arbitrary letters and numbers. After the three or more private key APPs enter the key sentences in turn, the private key generated by the three key sentences will be stored in the memory of the signing machine. At the same time, the public key address generated by the private key will be registered on the public chain, that is, a public chain hot wallet will be generated. The private key APP will not store this key sentence, and the source code of the private key APP will also be open source synchronously.

As soon as the signature machine is shut down, the private key in memory will disappear immediately, when the signature machine needs to restart, all private key APPs need to re-enter the correct key sentence. If a private key APP holder cannot enter the correct key sentence, you need to enable cold backup of the private key sentence. Since this process belongs to the actual enterprise management process, this article only provides a suggestion for cold backup

Private Chain

Private chains play an evidence-keeping and authenticity role in the entire BOX system. Taking advantage of the immutable characteristics of blockchain, the approval process and transfer approval process are put on the chain to save, providing a reliable basis for the program to realize transfer automation. The first release version of the BOX system uses Ethereum to build a private chain, and plans to support more private chain construction solutions in the future.

The companion program is Ethereum DAPP. Each private chain node is equipped with the same companion program, which is used to handle traditional CS (client-server) application requests, process data upload private chains, execute smart contracts, listen for smart contract events, send status notifications, coordinate interactions between upper-level applications and authorized services, etc.

The data stored on the chain is stored in the smart contract. Smart contracts use voting to confirm a data on the chain of evidence storage. Each data must be voted by 51% of the private chain nodes, and the content of each vote is consistent before it is confirmed to be valid evidence storage. Each node corresponds to an account that operates the same contract. Unless more than 50% of the nodes are captured, the data stored on the chain can be guaranteed to be valid.

Access Layer

The access layer adopts a discrete power architecture.

The power of the entire system is discrete in each APP end. Although the access layer server undertakes the transfer and merger of various services, the rights exercised on the information cannot be modified and executed. The implementation of power discrete relies on the basic algorithm ECDSA (Elliptic Curve Digital Signature Algorithm). In the algorithm, ECC (Ellipticcurvecryptography) uses the Bitcoin classic curve secp256K1.

The transfer process is: the employee APP and the management APP generate the signature, then the transfer is completed in the access layer, and the confirmation is obtained at the private chain layer, and finally the signature machine is implemented on the public chain.

The access layer service is divided into two parts: 1. Construction and modification of approval flow. 2. Implementation of approval flow.

Approval flow security mechanism
There are two important parts of the security of automated transfers. One is the security of the private key itself (already explained in the Private Key Security Chapter), and the other is the security of the right to use (approval flow).

Communication Security Mechanism
The signing machine is the server where the service in the authorization layer resides. Communication between the signing machine and the private chain is the communication between the services of the authorization layer and the services of the private chain layer. Communication between services is authenticated using gRPC+SSL/TLS two-way certificates. gRPC is a high-performance RPC framework designed based on the HTTP/2 protocol standard and developed based on the ProtoBuf (ProtocolBuffers) serialization protocol. The HTTP/2 protocol standard itself requires encrypted transmission of data (SSL/TLS). The BOX system will develop authorized service modules for all public chains. Due to the existence of SSL/TLS two-way authentication certificates, information security will be guaranteed to a great extent. Once there is an abnormal connection between the servers, the request will be immediately rejected, which can prevent the risk of man-in-the-middle attacks.

All APPs that communicate with the access layer adopt HTTPS. The private key used for employee signatures is issued through the management app.

The access layer and the private link are internal communication and are connected by TCP/IP protocol. At this time, the data transmitted to the private link by the access layer has been signed and authorized, and an information digest has been generated. The private link only needs to use the signature verification program to verify it. If the verification fails, service will be refused. The access layer sends requests to all private chain nodes. Each private chain node corresponds to an account. Each account will verified request data and store evidence through a voting mechanism. After the smart contract on the private chain is confirmed by more than 50% of the accounts, the data will be successfully uploaded. The access layer provides signatures and digests for private chain confirmation, and the private chain provides voting results to the access layer through voting. The above process can be summarized into two formulas:

signature=sign(hash)
publickey==recover(hash,signature)

Cold backup of private keys

In order to prevent unexpected situations of a private key APP holder from resetting the private key, it is recommended to physically back up all keywords. For example, after each private key APP holder enters a keyword, the mobile phone running on the private key APP can be connected to a non-networked mini printer. The keyword is automatically printed on the note in a QR code, and two copies will be printed. All keyword notes will be divided into two copies and sealed in two envelopes. It is recommended that the company store this mini printer and two keyword backup copies in two bank safes respectively. One of the keys in the safe can be entrusted to the corporate lawyer to hold, and it is agreed that this backup can only be opened with the consent of the company's board of directors' resolution.

Related links:
https://www.qukuaiwang.com.cn/news/12143.html