By Adam Everspaugh, Ph.D.
Coinbase security engineer, Adam Everspaugh, Ph.D., provides a deep dive into what it takes to usher in the utility phase of cryptocurrencies without degrading security. In particular, he looks at how the Coinbase security team designed a way for customers who store their assets with Coinbase Custody to participate in Maker (MKR) Governance and Tezos (XTZ) staking from the security of cold storage.
How does one permit customers to participate in cryptocurrency ecosystems while still protecting funds?
Coinbase operates a world-class cold storage system for storing private keys. This is coupled with an elaborate offline key generation ceremony. Together, these enable us to protect over a billion dollars worth of digital assets spread over 30+ distinct asset types.
But investing, speculating, and hodling isn’t enough–our customers are active participants not just investors. They invest because they believe in the interesting and untapped properties of programmable money. They want to use their digital assets: to vote, participate in staking, lend, borrow, and more verbs.
In order to support our customers, the security and engineering teams at Coinbase were tasked with enabling some of these actions without putting funds at any additional risk. The challenge here is that actively engaging typically requires hot keys (private keys held in memory and used multiple times); but the stronger, and preferable, protection of funds uses cold keys (private keys stored offline and used only once).
This post discusses the challenges and technical solutions through two case studies: Maker (MKR) governance voting and Tezos (XTZ) staking. The solutions demonstrate a pattern that is instructive for implementers managing funds and for protocol developers. This design pattern can encourage network participants to engage actively in a network’s protocols and still protect funds with offline private keys, if desired.
The Ice Box
Coinbase’s cold storage protects private keys with a defense-in-depth strategy including offline storage, printed materials, threshold cryptography, and encryption. Necessary steps for key reassembly require designated individuals around the world to collaborate and access information on paper stored in secure vaults; interact with HSMs; and then reassemble and decrypt private keys in a secure enclave. Once recovered, a cold storage private key is valid just long enough to sign and broadcast a transaction. After recovery, a cold storage key is marked as “burned”. In our design, once a cold private key is recovered, all funds are transferred out of the address so that the private key is never re-used. In the case of a partial withdrawal, residual funds are sent to a fresh cold storage address.
Maker Governance Voting
To permit our customers to participate in regular (usually weekly) governance votes with the MKR token, we designed a voting system in concert with MakerDAO. MKR is an ERC20 token used for governance voting. To vote, token holders deposit MKR into a designated voting smart contract on the ethereum network. Token holders are credited for their deposits and cast votes in the voting contract. When MKR tokens are withdrawn, votes that have been cast are also withdrawn.
Overview of Coinbase’s Maker Voting design.
1. MKR tokens sent to proxy contract.
2. MKR tokens deposited (“locked”) into Maker voting contract.
3. Administration key used to cast votes through the proxy contract.
4. MKR funds returned to pre-designated cold storage address.
We designed, in collaboration with MakerDAO, a pair of smart contracts and internal systems to enable MKR voting for Coinbase Custody customers. When a Custody customer enables voting for MKR funds, internal systems originate a fresh VoteProxy smart contract on the ethereum network. This VoteProxy contract is associated with a pair of addresses: an administration address (backed by a hot key) and a cold address (corresponding to a fresh, unused cold private key). Customers funds are moved from their cold storage address (causing this cold storage key to be burned) and deposited into the VoteProxy contract. Using the administration key (stored in-memory in a secure enclave), transactions are signed to lock MKR funds into the voting contract. Customers then designate votes to cast and those transactions are signed and broadcast using the administration key.
In the event the administration key is compromised, an attacker could release votes or alter votes. However, the smart contract, by design, restricts the administration key from transferring funds to any address other than the designated cold storage address.
As a contingency, in case the administration key is compromised or lost, the cold storage private key can be used to return all funds to the cold storage address with a single transaction. In this case, the VoteProxy contract and the administration key are effectively useless.
As part of our security process for building MKR voting, we put our design, smart contract source code, and the source code for the MakerDAO through an expert, 3rd-party audit. Thanks to this diligence: auditors identified critical vulnerabilities in the Maker voting smart contract; MakerDao rapidly fixed and deployed a new voting contract with no impact to user funds; and Coinbase confidently deploys MKR voting knowing that customer funds are secure.
The critical design pattern here is a separation of concerns through multiple private keys. Actions (lock, release, vote in the case of MKR) are executed with an administration key–which can be kept online (hot). But the administration key cannot transfer funds anywhere except to the previously-designated cold storage address. Funds remain protected at the same level of security as our cold key. And compromise or loss of the hot key does not put funds at risk. Full control of funds is possible in this contingency because the cold private key can be restored and used to sign transactions. (Coinbase has strong disaster recovery in place for cold storage keys.)
The same pattern emerges in the Tezos protocol’s proof-of-stake block validation. In fact, we modeled MKR voting on our experience building Tezos staking. The Tezos protocol supports this separation of concerns natively. To support staking, internal systems at Coinbase originate smart contracts on the Tezos network. The smart contract (a KT address) is created by an administration (hot) key and is associated with a managing (cold storage) address which delegates staking rights to the Coinbase staking node. This delegation is recorded on-chain. Funds are then deposited into the smart contract (KT) and they can only be transferred using the managing private key from cold storage.
Once funds are delegated to the staking node, delegators (Coinbase customers in this case) earn rewards for each block validated and published by the staking node.
Thanks to excellent availability by our engineers, our Tezos staking node has staked more than 100% of the opportunities granted through the lottery for some cycles. The additional opportunities arise when a Coinbase staking node is a runner-up and the designated node is unable to complete its duties within the defined time frame.
Recommendations to protocol designers
Digital assets are meant to be used, but they still need to be secure. In many situations, offline storage without key reuse is the preferred means to manage large funds. Protocol designers should take this into account and permit the use of distinct keys for separation of concerns: voting, staking, funds transfer, delegation, and other actions. Distinct keys permit system builders to manage risks individually for each activity. Depending on the quantity of funds, insurance considerations, performance requirements, and the operating environment, different security measures may be warranted.
The other critical recommendation is to have source code audited by competent, external auditors. These audits should ideally occur before production deployment. Extensive testing is great. Extensive testing and a fresh pair of eyes is best. External security audits are one of the criteria that Coinbase considers when assessing the security posture of a digital asset.
This website may contain links to third-party websites or other content for information purposes only (“Third-Party Sites”). The Third-Party Sites are not under the control of Coinbase, Inc., and its affiliates (“Coinbase”), and Coinbase is not responsible for the content of any Third-Party Site, including without limitation any link contained in a Third-Party Site, or any changes or updates to a Third-Party Site. Coinbase is not responsible for webcasting or any other form of transmission received from any Third-Party Site. Coinbase is providing these links to you only as a convenience, and the inclusion of any link does not imply endorsement, approval or recommendation by Coinbase of the site or any association with its operators.
Unless otherwise noted, all images provided herein are by Coinbase.
Powered by WPeMatico