In Search of Lost Keys
This is a “blast from the past” article, which I think is appropriate, given that the New Year is nearly upon us. Satoshi Nakamoto launched Bitcoin, the first ever blockchain, on January 3rd, 2009. And so we are almost upon the 15th anniversary of the occasion.
Blockchains use wallets as their main user interface, and over the last decade and a half, wallets and the management of private keys have developed significantly. For this article, written with the help of the engineers over at Resonance Security, I go through some of the problems experienced in the past by developers and users of blockchain wallets.
This should give you a clearer understanding as to why wallets are so important, and why they are such a difficult technology to provide securely and reliably.
What’s a wallet?
Satoshi’s first release included both the software for running a blockchain node and a blockchain wallet. Wallet software manages the private keys that are used by those owning assets on a blockchain to authorize transactions. These private keys derive the public blockchain addresses that hold the digital assets and are used to digitally sign the approvals for the transactions involving those assets.
Blockchains use asymmetric key cryptography; typically ECDSA, and that means that to generate a private key you need to select a random 256-bit number (a number between 1 and about 1.157 * 10⁷⁷, which is approximately 1 followed by seventy-seven zeroes, or a hundred quattuorvigintillion).
It turns out that a) selecting a truly random un-guessable 256-bit number is rather hard, and b) looking after that number without losing it or allowing someone else to access and steal it is even harder.
The original wallet
The first blockchain wallet mentioned above is sometimes referred to as the Satoshi client. In the early days, the Satoshi client generated private keys randomly using a C++ random number generator and stored them in a file called wallet.dat.
Initially, the file was unencrypted, which meant that once bitcoin began to have a dollar value, hackers started trying to hack into networked computers running the client to steal a copy of the wallet.dat file and hence the crypto stored in the derived bitcoin addresses.
Laterwallet.dat was encrypted with a random master key, which was itself encrypted with a password called a wallet passphrase. Sometimes users selected wallet passphrases that were too simple and could be guessed by trial and error over time.
People still occasionally find old installations of the early Bitcoin software on their decommissioned computers and hard drives, with wallet.dat files storing keys providing access to old stashes of bitcoin. If the files are early enough to be unencrypted, or the original owner can remember the passphrase, this can lead to an unexpected crypto-windfall.
Brainless wallets
Around 2013 or so, some people came up with an idea that initially seemed brilliant — create a password or a passphrase, and hash it with the SHA256 cryptographic hash function to obtain a 256-bit number that could be used as a private key. That way, you can carry your bitcoin around in your head!
There are two problems with this approach. The first is that people are not good at remembering things over long periods of time. A passphrase may seem memorable today, but a year or a decade from now … not so much.
The second is that humans are not good at coming up with truly random passwords, and so many brainwallets turned out to be guessable. For example, someone thought that a line from the Simpsons season 5, episode 7 would make a good passphrase: “You don’t win friends with salad!”, using it to generate the public address 15gCfQVJ68vyUVdb6e3VDU4iTkTC3HtLQ2
This was guessed by someone, who drained the three bitcoin it was holding at the time. Fortunately, these were subsequently returned, and the original owner learned a lesson that could have cost them tens or hundreds of bitcoins.
Pseudo-random number generators
It does not matter how careful you are with your wallet, keeping it offline and storing your seed phrase in a safe in the back of a bank vault, if the method used to generate the private keys was not truly random in the first place.
This is a recurring problem in computer programming. Computers do not do random very well — they are deterministic machines. In most cases, for example, if you are writing a game with enemies spawning randomly, using a fast pseudo-random number generator (PRNG) is good enough.
But PRNGs generate the same sequence of “random” numbers on any computer, provided you kick off the process with the same seed value, and developers often use the current time as the PRNG seed value.
No one is going to put time and effort into determining exactly where a bunch of goblins or zombies are going to appear in a computer game, but if the random numbers are used to generate blockchain addresses, and those blockchain addresses are holding cryptocurrency, then it makes sense to try a bunch of seed inputs to see if they generate value-holding addresses.
It turned out that a wallet provider called Cakewallet made exactly this mistake in their code. Given that the first Cakewallet release was in 2018, and the flaw wasn’t discovered until 2021, that left a three-year window of vulnerable wallet addresses.
And three years is only 95 million seconds. All those wallet addresses could therefore be brute forced with less than 100 million tries, which is not an especially large number if you’re running your cracking software offline and have a decent computer and a few months.
Custodial failures
When given too much responsibility, the instinctive approach taken by many is to find someone to act as a parent and take on the duties and liabilities. Hence custodial wallets. Transfer your assets to a company or a person, and have them handle the headache of securing the wallets, remembering the passwords, and preventing hackers.
The theory is that an organization dedicated to safeguarding bitcoin and other digital assets has efficiencies of scale, and can hire a gamut of security consultants, cryptography software developers, and experienced network engineers to make sure everything runs smoothly.
In practice, there are plenty of examples of custodial wallets failing, large and small. Two of the most famous are:
- Mt. Gox shutting down in 2014 when it became apparent that hundreds of thousands of bitcoin were stolen from their hot cryptocurrency wallet over a period of two years. Missing funds: approximately 650 thousand bitcoin and $27 million.
- FTX closing shop in 2022 after revelations that the exchange did not have anywhere near the asset holdings required to back deposits made, having fraudulently traded, lent, and spent a large proportion of them on political donations and property in the Bahamas. Missing funds: approximately $8 billion.
The problem with custodianship is that there is no guarantee the custodian is any more competent than you are and may be a criminal to boot. Furthermore, cryptocurrency has no Federal Deposit Insurance Corporation guaranteeing your assets against theft or loss. What’s more, a centralized custodian makes a rich single target for hacker groups.
Trusting a smart contract
How about cutting out custodians, or holding on to your own assets, and using a smart contract? That’s exactly what the Parity wallet smart contract library on Ethereum was designed for. The assets are transferred to the wallet smart contract using the library, and multiple authorization signatures are required to move the assets back out of the wallet later on.
This multisig approach seemed like a good one (and indeed it is): require several people to sign off, for example, three out of six board members. Then if one or two of them lose their passphrase due to phishing or oversight, or are corrupt embezzlers, the assets are still safe.
Unfortunately, the Parity wallet library contained a bug. When it was deployed (or rather, re-deployed to fix another bug), back in 2017, the wallet library wasn’t initialized to have an owner. A “kill” function was included in the code, which could be called by the owner of the contract. Someone going by the handle of devops199 first called the initialization function to take ownership of the library and then called the kill function, freezing all the funds being held by multiple multisig wallets using the Parity wallet library.
The total lost? 513,743 ETH, or about 1.2 billion US dollars in today’s prices.
Summary
Looking after your crypto-assets seems like a game of “head you lose, tails the hackers win.” It’s hard to look after them yourself and even harder to let someone else do it for you.
The fact remains that crypto is still in the wilderness. You have to decide — do I go with a tour guide (and how can I assess how competent they are), or do I learn survival skills and rely on myself. Until the blockchain space becomes a park, that is the way it will be.
Till then, protecting yourself and your assets involves work:
- spend time educating yourself about cryptocurrencies and secure practices,
- check for certifications and audits, and follow up by investigating the certification or auditing entity, and
- remember that if it looks too good to be true, it certainly is.
And now all that remains is for me and Resonance Security to wish you a prosperous, but above all, a safe New Year.
