How do companies manage & store cryptocurrency private keys?

Question

For an individual, I see a some options for storing private keys, such as printing them on paper in a vault, using a hardware wallet, encrypting and storing on the machine, using AWS Secret Manager, and so on.

However, I have a need to create a few accounts for a firm (maybe using metamask), and I'm not quite sure what the best practice to store the private keys. I have the following questions:

1. Who in the company should own them? How to keep them secure in the long run?

2. How dev/qa teams share among them to validate especially those accounts are used in mainnet via metamask.

The company is managing their own keys, not depending on a 3rd party (Custodian).

Answer 1

I believe a company would be doing themselves a major disservice if they were not using a multi-signature scheme to protect their important funds. Each withdrawal from the company funds should need to be authorized by a minimum threshold of private keys controlled by key persons, preferably technically-minded higher-ups.

Different blockchains have slightly different approaches to this functionality, but the solution almost always involves the use of an m-of-n multi-signature wallet. Such a wallet requires any outbound transaction to be signed by m of n private keys (in this case presumably owned by m of n people) to be considered valid on the blockchain. These private keys can be kept in software, on paper, or in specialized hardware devices ("hardware wallets"), which many people find to be an acceptable trade off between security and ease-of-use.

Taking the Bitcoin blockchain as an example, you would want to generate an m-of-n multi-signature address. First, have each of your key persons generate a private key in a secure way. Then, gather the n corresponding public keys and use them to generate a multi-sig address. Several pieces of software are available to make this process more user-friendly. Transactions outbound from that address will require signatures from m of the n pre-set participants in order to be valid.

Ethereum, on the other hand, does not have native multi-signature transaction support. However, several multi-sig smart contracts have been developed, the most popular and arguably most thoroughly audited of which is Gnosis Safe. The multisig wallet creation process involves using their interface to deploy an instance of the Safe contract, then configure the m-of-n requirements as well as additional smart contract settings. Then, to spend the funds, a specially crafted transaction, signed by m of the n participants, is presented to the smart contract which authorizes the withdrawal. Because this solution is contract-based it's very flexible; its parameters can easily be updated in the future to add or remove participants or change other settings.

That covers the top two most popular blockchains. Other blockchains have their own ways of handling multi-signature wallets, but a common theme is this m-of-n scheme.

And to answer your two questions specifically:

1. To keep these keys secure in the long run, implement a policy by which the keys can be rotated if a multisig holder leaves the company, or if there's any chance that one of the keys has been compromised. With Gnosis Safe, this is as simple as using the UI to create and authorize a smart contract call that invalidates an old private key and adds a new one. With native Bitcoin multi-sig, you would need to generate a new multi-sig address and move the funds over manually.

2. Dev and QA teams could inspect outgoing transactions either before they are signed, or in a block explorer such as Blockchain.com (for Bitcoin) or Etherscan (for Ethereum) after they are broadcasted to the blockchain.

Answer 2

There are two major usages for private keys, and in large companies they can be handled differently:

• true individual keys that are used to identify a person or sign a document. Those keys should be owned by only one person, and ideally they should reside on a physical thing like a smartcard or a USB key, and cannot be extracted but are directly used on the physical device. That way, you can have a legal proof that a specific human being is the responsable for something.
• keys that are used to exchange encrypted documents. Those kind of keys are processed almost like true individual ones, except that a copy of the private key is also stored in a global safe. The rationale is that the real owner of the data is the organization, and that the data must be recoverable even if the recipient (and their private key) in no longer there (retirement, accident, disease, etc.)

---

BTW when I find myself thinking about how a specific IT problem should be handled, I try to think how it would be in real world. A physical key if never handled by an organization, but is given to a trusted person. If we need more control, you can have a (physical) thing that required 2 different keys given to 2 different persons. IMHO private keys for an organization should be handled the same: they should be given to specific members.

Of course, machine keys are different. They are available to the machine, so to any of its admins. And because of that they cannot carry the same level of trust, the reason why I did not focus on them. IMHO they should not be seen as real keys nor sign tools but only as a technical way to protect a data exchange.