BOX
BOX (Enterprise Token Safe Box) is an enterprise-level digital assets safe application that uses the axiomatic techniques in blockchain, cryptography and communications security to protect the private keys and instructions. BOX in principle prevents the theft and tamper of private keys and instructions.
Official Website
http://www.box.laWhitepaper: You can find the updated version on our official website.
Trading Platform:
已上架交易平台:www.hotbit.io
Social Media:
小管家官方QQ:1694348187
BOX官方微信公众号:SafeBox(box-la)
BOX官方微博:Box小管家
http://weibo.com/u/6443171368Twitter:SafeBox.la（@SafeboxL）
https://twitter.com/SafeboxLFacebook:BOX-Foundation
Beechat:BOX官方社区交流1群
Telegram: boxfoundation
Telegram (CN): Safeboxla
https://beechat.io/join?g=7a68910fa46b490b917a6c8f4a1874ae&lang=zhi. Background1. Digital Assets Rapid Growth
With the rapid growth of the digital asset market, more and more investment agencies, enterprises and start-up teams have entered this field, and the amount of various digital assets they hold is also rapidly increasing. However, the current digital asset management tools for enterprises are extremely limited. A large number of assets are kept in personal wallets, trading platforms or cold wallets, which is different from the traditional asset management processes. Enterprises have the concerns in terms of the digital assets management and investment as the matters such as the loss of private keys, the theft of trading platform wallets are disclosed by public media. These problems have restricted the investment and management of digital assets by enterprise users.
2. Shortage of Enterprise Digital Asset Mangement System
In the past few years, few teams have tried or are trying to use various technologies to enhance the security of their wallets, but for a variety of reasons, there has so far not been a generic, low cost and easy solution being deployed. Based on the belief and love of the blockchain, we created a high-security digital asset management system through a large number of theoretical discussions and scenario demonstrations for different application scenarios. BOX WAS BORN. In order to thank the communities who have same faith, we will make code open source immediately after its official release. Any organization or individual may deploy and use BOX NOT for commercial purposes.
3. Demand of Enterprise Digtial Assest Mangement
We learned the following requirements are urgently needed through many years of practical experience and a large number of visits:
a) One-stop management tools of digital assets;
b) The highest authority owned by multiple individuals or entities, making digital assets belong to the enterprise, rather than individuals;
c) Unified enterprise wallet address for public account;
d) Financial approval process and reduce the possibility of human error;
e) NO exposure of private key under any circumstances;
f) Unforgeable transaction instructions to steal assets;
g) Facilitate enterprises to record and audit digital assets;
h) Unaffected enterprise assets safety under any circumstances that the private key holder(s) will not or cannot exercise his or her authority.
ii. Design PhilosophyBOX is an independent digital assets bank system owned by the enterprise. BOX system unified manage all types of enterprises owned digital asset, by encrypting private key in memory in order to never being exposed; by recording and verifying instructions in enterprise owned private chain; by customized asset management business flow through orderly signature; by SSL/TLS to ensure absolute security of the communication.BOX in principle to prevent the ubiquitous wallet problems such as hacker, mole and misoperation. Meanwhile, BOX can ensure the high security of enterprise digital assets via intrusion lock, system reset and other mechanisms.
The number of private chain nodes is 2n + 1 (n≥1), the minimum number of private key APPs (PKApp) is 3, the specific number is customized independently by enterprise, the signature machine is an independent physical server. Access layer is cloud server and has no communication with the signature machine. Signature machine can only communicate with the private chain; and only the signature machine can issue the transaction instruction to public chain. The employee APP (EApp) initiates the transaction request and then management APP (MApp) to approval.
BOX system can access all digital assets that support offline signature. The first version will support Ethereum and ERC20 tokens. In future, more digital assets will be supported.
iii. Private Key Safe Protocol1. Private Key Storage
The private key is stored in the memory of signature machine and will not be stored permanently. In extreme condition that signature machine is hacked, and it is almost impossible to crack the private key in short time, and then the risk of exposure will be reduced greatly.
The signature machine should be an independent server. It is recommended to store in a very high security facility, for example, a financial computer center or a high security computer room owned by enterprise. The signature machine needs 24 hours of uninterrupted power, internet access and a fixed IP address. The signature machine should not be easily accessed to anyone, including the enterprise IT officer.
The enterprise digital assets are actually stored on each public chain (referred to herein as a "hot wallet"). If the official digital wallet supports offline signatures, the private key can be stored in the signature machine memory and be used for the transactions confirmation without exposing private key.
2. Private Key Generation
In order to prevent the private key generation being cracked, BOX use the variant of RFC6979 protocol: k = SHA256 (d + SHA256 (m1) + SHA256 (m2) + SHA256 (m3) + ...), d is the server random number; m is key sentence inputted by PKApp. It is generated by inputting three (minimum number) key sentences (KS), which are strings of any combination of letters and numbers. After the three or more PKApps sequentially input the KSs, the generated private key is stored in the signature machine memory, and the public key address generated by the private key will be registered in the public chain. The PKApp does not store the KS, and BOX code is open to community.
All transaction processes of the PKApp require mutual authentication. PKApp numbers are fixed during first setup. Server only distributes certain number (N) certificates, and the certificate is bound to device ID, other connection requests will be rejected.
If the PKApp is lost, there is no security risk because the APP does not record any KS and passwords. The owner of the KS can reinstall the PKApp and retrieve the server certificate using the original KS. Then, the signature machine rebinds the device ID of the new PKApp.
3. Private Key Recovery
Once the signature machine power off, the private key will disappear immediately. Therefore, after the signature machine restarts, all PKApps are required to re-enter the correct KS. If the owner of a PKApp cannot enter the correct one, you need to enable the cold backup of KS. Since this process belongs to the enterprise management process, this document only provides the recommended solution of cold backup; refer to “Private Key Cold Backup” section.
iv. Private Chain1. Private Chain Function and Advantage
Private chain in the BOX system is to record and verify the transaction flow. Transaction flow setup and transaction flow approval process are recorded on private chain, and it will be the reliable bases for the auto-transaction on public chain. BOX system (1.0) will build private chain based on Ethereum, the future plans are to support more chains.
The enterprise not only gets a set of systems of record and verification, but also independently controls all nodes via deploying private enterprise chain. Enterprise can control the maximum transactions number per block, the block time, and node numbers by defining the genesis block settings.
Gas consumption is negligible as it is on a private chain and gas consumption is transparent for access layer.
The private chain adopts the Proof of Authority (PoA) consensus mechanism to directly specify which private chain nodes have accounting rights and the other nodes will exist as backup nodes.
2. Companion Program
Companion program is same as Ethereum DAPP. Each private chain node is equipped with the same companion program that is used to handle traditional CS (client-server) application requests, process data to upload private chains, execute smart contracts, monitor smart contract events, send status notifications, coordinate interaction between access layer and signature machine.
Companion programs are parallel and communicate only with private chain nodes on the same server. There are no direct connections between companion programs. Each companion program links to one private chain account for smart contracts execution.
Companion programs coordinate the interaction between the access layer and signature machine. A transaction includes four steps: 1. Initiate the transaction request; 2. Approve the transaction request 3. Complete transaction on public chain; 4. Check the transaction status on chain. We divide these four processes into four sections, as shown in the following figure. Companion programs is in the private chain layer section, it is to record and verify transaction flow through private chain, and it returns the transaction flow results to signature machine. On chain transaction will be operated by the signature machine. Companion programs isolate the direct interaction between the transaction requester and the public account, and this process is automatically executed by the programs with the approved transaction flow.
3. Smart Contract Consensus Mechanism
Data is stored in a smart contract on private chain. Smart contracts use voting to confirm the data on a private chain. Each data must be confirmed with more than 50% nodes having same content.
Each node represents one account operating the same contract. The data on the private chain can be guaranteed to be valid unless more than 50% of the nodes are fully compromised.
The smart contract voting system needs to assign reasonable authority to the accounts. All private chain accounts are fixed after the private chain setup. When a new node is to be added, you must have all the private chain accounts to authorize the node, the system will automatically re-balance the 51% strategy without redeploying the new contract to adapt to the change.
The recorded data include approval process and transaction requests. As shown below: Prior to transaction, you need to set up an approval process which is to identify the departments and corresponding participants that need to be in for transaction request approval. The number of people needs to be confirmed. The transaction request needs to be approved by the highest level of enterprise management. Approved process is used to initiate the transaction.
v. Access LayerAccess layer using the separation of powers architecture.
The power of the entire system is dispersed in the Apps, access layer takes a variety of transactions coordination, but it does not have the right to execute and modify the transaction.
The separation of powers architecture depends on the ECDSA (Elliptic Curve Digital Signature Algorithm). ECC (Elliptic curve cryptography) uses the Bitcoin classic curve secp256K1.
The transaction process is as follows: signature is generated by the EApp & MApp; the transfer is coordinated in the access layer; and it is confirmed on the private chain. Finally, the signature machine issues the transaction on the public chain.
Access layer business includes: 1) transaction flow setup; 2) transaction flow approval
1. Transaction Flow Setup
Transaction flow is setup before executing the transaction. It is a multi-level approve model. The first level is the employee group; and there will be several approval levels with defined minimum approvals.
For example, the transaction flow is shown below:
When the enterprise finishes the transaction flow setup, a system-recognizable protocol format will be inputted via MApp. It is named boxflow in the BOX system.
Boxflow is unauthorized state. If authorization is needed, it is flowed into the access layer. The access layer checks the format, checksum, upload hash to the private chain. All nodes vote and record, then notify the signature machine. Signature machine authorized by PKApp upload hash to the public chain, the hash status is set into valid on private chain once the transaction is successful. Enterprise can make transactions via boxflow as it is authorized state now.
The boxflow modification needs the PKApps to cancel the current authorization and then re- establish.
2. Transaction Flow Approval
After the authorization of boxflow, employee accounts need to be created.
In the BOX system, employee accounts are assigned public and private keys by the employee management group. The EApp obtains the current authorized boxflow, the employee selects the employee group to apply the private key, and the employee management group derives the sub- private key and assigns to employee.
EApp can initiate a transaction request with private key, the application format is as follows: { balance: 100E18,
timestamp: 1512719484736,
destination: '0x6E9483f00cCd685c5F12709Fd542Da1FB20c4d2e', miner: E16,
currency: 'ETH',
applicant:
{ username: 'bluce'} }
Current request is unsigned, and the request needs to be hashed with SHA256 algorithm and signed, and the hash signature is put into the request with the following format:
{ balance: 100E18,
timestamp: 1512719484736,
destination: '0x6E9483f00cCd685c5F12709Fd542Da1FB20c4d2e', miner: E16,
currency: 'ETH',
applicant:
{ username: 'bluce',
sign: '474w3zgKRLwaddG6LadzKQ3ut1JyQUc4HpVLkydR6xdk2TwS7zEXKf4E5AyGHxQkfLYxJsccx hqdY5Qm5352P2H4' } }
The employee's request can only be approved by its corresponding employee management group account.
After approval by the employee management group, the request (including signature) will be hashed and signed. The request after the signature is handed over to the upper level management for approve, the upper level management signs the hash after verifying the lower level signature. Repeat the approval process until the final level.
The final approved transaction request is considered as a transaction, and it is named as transbox.
The transbox hash is the trade ID. After the access layer verifies transbox and matches the corresponding boxflow, then the trade ID (hashed) is recorded on the private chain for voting. Signature machine will be notified for transaction on public chain after successful voting.
After receiving transbox, the signature machine extracts the boxflow and verifies validity, and then verifies the transbox signature. Transaction on public chain is issued after transbox verification by signature machine. TxID is recorded in private chain and access layer can check the status anytime.
3. Multiple Boxflow
In the first version, BOX only supports a single boxflow. Multiple boxflow will be supported in future upgrades.
vi. Boxflow Safe ProtocolThere are two important parts to secure auto-transaction. One is the security of the private key (refer to “Private Key Safe Protocol”) and the other one is the security of usage rights. This chapter will explain of boxflow.
1. Boxflow Validity
A valid boxflow needs to go through private chain record, PKApp authorization and public chain confirmation. The valid boxflow is confirmed by N enterprise approvers together and recorded in the private chain; the boxflow validity is tamper-proof.
2. Transbox Generation
The transaction request is initiated and signed by the EApp. After the employee management group and the approvers verify the correct signatures, the transbox is generated. As the public and private keys exist only on the Apps, transbox generation is tamper-proof.
3. Transbox Validity
Transbox validity includes two parts, one is the signature validity, and the other one is the boxflow validity. BOX uses a nested signature method, you only need to validate the signature in sequence, and you will know the signature validity. The transbox itself corresponds to one boxflow which needs to be verified. If both conditions are satisfied, it is proved that transbox was confirmed by boxflow and it’s tamper-proof.
vii. Communication Safe Protocol1. Signature Machine and Private Chain Communication
Communication between signature machine and private chain use bi-direct gRPC + SSL/TLS authentication. gRPC is a high-performance RPC framework which is designed with the standard HTTP/2 protocol, developed with ProtoBuf (Protocol Buffers) serialized protocol. HTTP/2 protocol requires encrypted data transmission (SSL/TLS). BOX system will develop signature machines for all public chains. Security will be greatly ensured with the SSL / TLS mutual authentication. Man-in-the-middle attacks can be prevented as the connection request will be immediately denied once an abnormal connection appears.
2. Employee APP and Access Layer Communication
All Apps that communicate with the access layer use the HTTPS protocol. The private key for employee's signature is issued through the MApp.
Steps are as follows:
a) MApps generate employee private key and corresponding random number for encryption;
b) MApps encrypt employee's private key via symmetric-key algorithm;
c) MApps inform employee password offline;
d) Access layer cached the encrypted employee private key from management APP
e) EApp downloads the encrypted data from the access layer and decrypts it with the given password.
3. Access Layer and Private Chain Nodes Communication
Communication between access layer and private chain is internal communication via TCP / IP protocol connection. The data passed by the access layer to the private chain has been authorized by the signature and generates a message digest. The private chain only needs to use the signature verification program to verify the data. If the verification fails, the service is denied. The access layer sends a request to all private chain nodes, each private chain node corresponds to one account. Each account uploads the verified data to private chain, the data is successfully confirmed once more 50% accounts confirmed. Access layer provides voting to the access layer. The above process can be summarized into two formulas:
signature =sign(hash)
public key == recover(hash, signature)
viii. Private Key Cold BackupPrint and store in the bank safe!
We recommend that all key sentences be physically backed up to avoid unable to reset private key in any circumstances. For example, each private key APP holder prints the encrypted key sentences via an offline printer, then store printer/key sentences separately in two different banks safe. Key can be kept by enterprise lawer and only be used with the consent resolution of enterprise board.
ix. Road Map 2017.10 Project planning;
2018.01 Demo Version;
2018.04 Version 1.0- open source;
2018.05 DEFCON Hacking Conference
2018.07 Version 2.0- open source;
2019.01 Version 3.0- open source;[/li]
[li][/li]
[/list]
Show Posts
