For financial services companies, the security of the funds that are under their management is critically important. One of the most important tasks in the development of a centralized cryptocurrency exchange is the protection of customer funds. Within the framework of my column at Decenter.org, I spoke on the example of his own developments, explaining why multi-signature systems are good ways to protect Bitcoin and its forks that use the UTXO transaction model.
Clients transfer their funds to the exchange through a special hot wallet, which is under full control of the exchange operators. For each customer, a unique address is created in the hot wallet, and to ensure anonymity in the blockchain, users can create a new address for each deposit. The funds received are not assigned to the client in any way. The withdrawal of funds from the exchange can be made from any addresses that choose the proper algorithm for generating the transaction. Usually, these are the addresses to which other customers have previously deposited funds. You can also use addresses from dust wallets that accumulate dust from previous transactions, or addresses from cold wallets, where surplus funds that are not participating in daily operations can be transferred for additional security.
Under this scheme, the exchange must work with a wallet in the real world, since anyone who has access to the wallet is the rightful owner of its contents. Therefore, in our developments, we decided to implement some security measures: all operational wallets were encrypted and moved to an isolated protected environment, the procedures for working with which are strictly regulated. The administrator sends a command to decrypt the wallet only at the time of signing the withdrawal transactions, and the original password of the wallet can only be recreated by the owner of the backup (the owner of the exchange).
These security measures have created problems for the business requirements, however, which is having an unlimited stock of addresses for deposits that customers can create at any time. Then we decided to apply the standard BIP 32 Hierarchical Deterministic Wallet(the open-source implementation of this standard). This library works for Bitcoin out of the box, but it can be adapted for any fork by adding the parameters of the necessary networks.
Thanks to the use of BIP 32, the necessary number of addresses for the deposit can be instantly created in the exchange and then added to the hot wallet in the watch-only mode to track the deposit transactions. The private keys are recreated at the time of the next decryption of the wallet for such addresses and the deposits that come to them are placed at the disposal of the exchange.
Continuing with the analogy of the real wallet, we can say that our developers put it in the safe and installed video surveillance. Reliable enough, but better options are available. The function of saving funds can be entrusted to an insured bank, and a chief accountant can be hired for management. This division of responsibility on the blockchain has been realized long ago. It is called a multiple signature, or multi-signature protocol.
This is a special case of the BIP 16 standard Pay to Script Hash (P2SH), which allows you to add additional validation rules to the transactions of the block. Together with the signature of the withdrawal transaction on the side of the hot wallet, it was decided to certify it with a second signature. The new side, which adds a second signature before sending the transaction to the network is called a co-signer. Here, the responsible officer can study the details of the transaction before giving his approval and make sure that it is legitimate—that is, ensuring that it consists of legitimate applications for withdrawal of funds from real users of the exchange.
To transfer funds onto the exchange, users now need to create special multi-signature addresses. To move the deposit sent, it is necessary to know both private keys that were used to create the address of the deposit. One private key is stored in an encrypted form in the hot wallet, and the second on the accounting server. To maintain confidentiality, the keys of the second signature must be generated in the same volume and stored independently of the rest of the project. It remains to be decided how to get an unlimited supply of multi-signature addresses for the deposits on the exchange.
When analyzing the ways of implementing multi-signature, we found no working solutions. Multi-signature addresses for the deposit must be determined from a pair of addresses (public keys), or the addresses from a hot wallet and the corresponding address from the accounting department. For accounting, we can once again apply the already familiar BIP 32 to operate on the exchange only with public keys without violating the confidentiality of private keys. By having a pair of public keys corresponding to the desired multi-signature address on the exchange server, the BIP 45 Structure for Deterministic P2SH Multisignature Wallets standard can be applied. This standard allows for the generation of deterministic multi-signature addresses for a deposit using only public keys. This is the only reasonable option because the use of private keys from several parties in this procedure violates their confidentiality. As a bonus, a backup of deposits is provided. At any time, you can restore all addresses by receiving the public keys to the hot wallet and the accounting department.
The team of our programmers did not find any libraries working with the BIP 45 standard, and decided to combine existing technologies to implement this standard. By adding the Bitcoin-ruby library to our toolchain, we developed a new library that fully complies with the BIP 45 standard. This approach proved to be very effective since it allowed the most rapid development of the necessary tool, which is absent in the market.
It all required another change related to the security of funds for dust wallets. Over the course of the project, significant amounts of money can accumulate there. You can try to minimize the effect, for example, by storing these funds in a cold wallet. We used another approach and transferred these addresses to the multi-signature scheme. This did not require a change in architecture. When generating transaction outputs, an address is used from a new address pool “for delivery,” which is filled in according to the same scheme as the addresses for deposits.
The implementation of the new solution did not significantly affect the existing scheme of work. Multi-signature addresses for the deposit are still generated on the side of the exchange and are stored in hot wallets. This is where one of a pair of private keys necessary for managing the funds can be found. The second private keys are located on a new site dedicated to accounting. All outgoing transactions signed on the hot wallet are sent to this site to receive the second signature. Only after confirmation can these transactions fall into the block. We made the infrastructure of the site for accounting completely independent of the main project in order to minimize the damage from the possible hacking of the project’s servers.
As a result of the introduction of multi-signature technology, the level of protection of funds which users entrust to the exchange has increased. No individual employee has access to all information, which makes it impossible to spend these funds internally. The servers of hot wallets and accounting are on different sites, their service is limited by the rules, and it is the responsibility of corresponding personnel who are not in direct contact with each other. All private keys are encrypted. Protection against external threats has grown significantly. To gain access to the tools, the attacker will now need to consistently hack three independent sites, as well as figure out the passwords with which the wallets are encrypted. Backup copies of master keys for the hot wallet and accounting wallet are stored separately in safe places. And it is possible to restore 100 percent of the hot wallet infrastructure and accounting infrastructure from scratch on the basis of the backups.
The original article is available here: https://decenter.org/en/protection-of-funds