Rego’s Cold Wallet Security Schema- Basic Security for CryptoCurrency Cold Wallet Management

Filed under Business and Cryptocurrency and Security

No system can be made 100% secure. I take no responsibility for the misuse or lack of effectiveness in implementation of any security methods or techniques described, alluded to, or linked in this blog. Treat everything as hypothetical and experimental. I am not an affiliate of any of the links provided in this entry. No product referenced in this blog is an endorsement. I’m just a guy posting a thing.

Security is not convenient. Implementing security practices requires discipline. It shouldn’t need to be said, but I find myself repeating those facts often, and that’s because it’s is something I’ve seen very little of in the world of cryptocurrency, a world I stumbled into some time ago.

The “run-and-gun attitude” has made llaissez-faire “cryptobroh” culture a target rich environment for cybercriminals. I’ve seen first hand how cryptocurrency holders and companies become targets for cybercriminals. From SIM card clone attacks, spear phishes, and good old fashion malware payloads, I’ve first-hand seen people directly attacked for cryptocurrency or leverage to it.

Recent news of QuadrigaCX would have us believe that a single person had access to a cold wallet password key that held 145 Million USD worth of cryptocurrency digital assets, and, now, that access is *gone*. I’m going to lay aside the speculation of an exit scam and just focus on the risk of key management.

You see, I’d been tinkering with a schema to protect a cold wallet for the last several months in the cryptocurrency bear run that people are now calling “Crypto Winter”.

One of the challenging things about the cryptocurrency market is that when the price dips and continues on a bear run investor interest drops and customers begin to back away. Pivoting with GPU or general computing units is a possibility, but not so with ASIC hardware. Making cost effective decisions and one consolidating one’s equipment to run to cover one’s costs may be the only realistic option (provided that it’s profitable enough to do so).  There are a myriad of security issues with hot wallets, and it may not be feasible to sell as the digital asset is produced with the way the market is. Cryptocurrency can be highly speculative that way. I wouldn’t propose to dictate the business strategy a person should chose, but these are the general facts of the industry, such as it is.

This forced me recently to reevaluate my schema and attempt to refine a divided trust schema for a cryptocurrency cold wallet holding.

Rego’s Cold Wallet Model of Decentralized Trust

The schema follows a separated model of trust involving the following:

This schema is represented in the following image:

Rego's Cold Wallet Schema

Rego’s Cold Wallet Schema

Initiating the Schema:

  1. Obtain safety deposit box. All three holders are to verify ownership of keys.
  2. “Key-Gen Party”: (keep reading)
  3. Agent and Holders are all in attendance.
  4. Unbox New Hardware Wallet
  5. Agent uses NEW computer running a LIVE thumbdrive boot OS from a secure internet connection to create new cold wallet key pairs.
  6. The Agent uses a non bleeding, felt tip ink pen (the kind used for checks is leech resistant) on standard matte paper using a glass or metal surface backer. The sections are divided into thirds and labeled 1-3 and distributed to the holders.
  7. The agent calls each holder to the computer to verify each section of the wallet phrase as is standard practice in wallet creation. IMPORTANT: The holders never share their wallet phrase section with each other.
  8. The Agent Assigns a PIN and establishes 2FA. IMPORTANT: Only the Agent knows the PIN. Only The Agent has access to the 2FA/MFA.
  9. The Agent verifies the wallet is functional.
  10. The Agent shuts down the computer.
  11. The Agent cleans the Glass or Metal Backer with a scouring sponge and Windex.
  12. All three of the Holders accompany/escort the Agent to the bank.
  13. The agent places the Hardware Wallet in the safety deposit box.
  14. A Holder secures the hardware wallet.
  15. The holders secure there 1/3 of the paper wallet independently

And the usage lifecycle begins.

Using the Wallet: Separation of Duties at work

The wallet is stored offsite at a secure facility such as a bank because, well, it’s secure. You have far less of a risk associated with fire or flood in a bank safety deposit box than you do almost any other location.

Because each of the Holders has a physical access key they can each obtain the wallet hardware. However, because none of them know the PIN or have access to the 2FA/MFA as the Agent does, they are unlikely to gain access to the funds without the Agent or other Holders being aware of it. No individual with the bank organization has the key, either.

The Agent has the ability to authorize transactions with the wallet, but does not have physical access to the wallet at will, preventing unknown and/or unauthorized transactions.

In the event that the Agent is unable or unwilling to perform their duties, the three holders, together possessing the individual components of the paper wallet, can reconstruct the cold wallet on a new hardware wallet and bypass the PIN and 2FA/MFA controls in the previous wallet. Conversely, if one of the three holders is unable and/or unwilling to cooperate in maintaining the schema the other two Holders can authorize the Agent to transfer funds to a newly generated wallet, rendering the rouge Holder invalid.

This model attempts to reduce the needed trust, but there are still several elements of trust in this model. To name a few:

  1. The model requires that the Agent NOT possess a photographic memory. The Agent must NOT be capable of recalling the paper wallet phrase.
  2. The agent must be entrusted to be impartial to all of the holders. If the agent favors one of the holders, and that holder is corrupt, the funds could be accessed without the other members
  3. All three Holders must be able/willing to work together in the event of Agent displacement

The ideal usage for this schema requires all holders be in agreement on how funds are to be used, such as in a board meeting, with the Agent acting as a sort of secretary to perform the signing action. Ideally, these transactions should be completed “at the moment” of decision with all parties accounted for. The same, LIVE boot OS environment should be used each and every time the hardware wallet is used, and safe internet connection is vital.

If intending to allow remote authorization of funds from the holders to the Agent, it’s vital that ‘duress codes’ be worked into the mechanism, so that the Agent and/or other Holders know if another member of their Schema is under threat. My suggestion would be to include an authentication challenge mechanism that a Holder is required to provide before funds can be transferred. For example, as an agent I may distribute a sheet that has three columns like this:

cake    ice-cream    lollypop

cat    dog    fish

happy    sad    mad

I hold a master sheet that looks like this:

soft    cold    hard

solo    loyal    wet

green    blue    red

     We may only have agreed to do transactions one day of the week, and depending on that day being an even or odd day, I may expect you to answer with the first or second line. If you, as holder were under objection, you may respond to the challenge the wrong line, if you are under duress, you may answer the third line, indicating the level of your situation or nature of the threat. For instance, ‘mad’ would literally translate to ‘Code Red.’

I’m sure this model could be improved, but as is, it’s fairly straightforward.

To some, this might seem like a lot of work, and they would be right. To some others, it’s more discipline than they can muster. I challenge you to read the article above and ask yourself it this kind of thing is worth it, because according to QuadrigaCX, not having something like this in place just cost them CAD 190 Million.

Stay safe out there.