The commonly cited expression “not your keys, not your crypto” conveys the purist’s philosophy of cryptographic key management. In this wallet security model, only an individual (or a group via “multisig”) has direct and sole control over their own private keys – and, therefore, has true ownership of their crypto assets. Crypto wallets adhering to this hard-line approach are called “non-custodial,” meaning no outside parties have access to keys.
Except, not so fast. The situation isn’t so simple. A number of high-profile “non-custodial” wallet hacks – including the Slope wallet hack that compromised more than 8,000 accounts in August, the Trinity wallet hack that lost more than $2 million worth of IOTA tokens in 2020, the Parity wallet hack that allowed an attacker to steal 150,000 ETH in 2017, plus discoveries of various hardware wallet vulnerabilities, and other incidents – undermines the conventional distinction between custodial and non-custodial wallets. In many of these cases, victims who believed they were using a non-custodial wallet found attackers were able to hijack their coveted keys. A contradiction, no?
Indeed, the story is more complex than a catchphrase can capture. Non-custodial wallets do not really put users in full control of their keys. That’s because wallets are typically created by, and operated via, someone else’s software or hardware. Users constantly put their trust in other people, products, and computer programs. They accept using blockchain command-line-interfaces, wallet software and devices, centralized platforms, smart contract code, decentralized applications, and all the various wallet connection integrations in between. Each touchpoint adds risk; the sum of all these interlocking parts shatters the illusion of the non-custodial wallet.
Custodianship is, in reality, non–binary. What might at first appear to be non-custodial may actually involve many custodial elements whose reliability people often take for granted. The traditional dichotomy – custodial vs. non-custodial – is a false one.
Instead, it’s better to regard wallets with more nuance. The key questions to ask are: How big an attack surface am I comfortable accepting, and how many responsibilities am I willing to take on in my quest to eliminate trust in third parties? In general, key management – the foundation of wallet security – can be divided into three areas, each of which has unique opportunities for exposure. The subcategories are as follows:
This overview is intended to help web3 users better understand the intricacies involved in securing their assets by way of the rubric above. Further, we aim to help engineers identify and shore up frequent points of failure in wallet development. We hope that applying this guide – sourced from our many years of combined experience building crypto and security systems across Docker, Anchorage, Facebook, and a16z crypto – will help people to avoid security mishaps, whether they’re interacting with, participating in, or building web3 tech.
Below, we cover common features and pitfalls of crypto wallet security and custody platforms as they exist today. We also cover areas we believe require the most attention and development in the coming months and years to improve the safety of users’ web3 experiences.
Any discussion of wallet security must begin with key generation, the process of creating cryptographic keys. Whether the wallet is considered custodial or non-custodial, the security properties of the key generation step are paramount to the keys’ safety thereafter. During key generation, there are three overarching concerns to keep in mind: using reliable code, implementing the code properly, and safely handling the output.
If you’re not a crypto expert, it can be difficult to verify that all of the following factors are being done by the book. Check to see whether you can access a trusted audit report, which some wallet providers publish on their official websites or Github repositories. In lieu of that, do your own research to try to determine whether there’s a reputable company behind the wallet. If information is sparse, significant user and developer activity might be the next indicator of reputability.
Follow these guidelines to reduce your risk exposure. If a wallet fails the below checks, run away!
Cryptographers have a saying: “don’t roll your own crypto.” The gist is similar to the adage “don’t reinvent the wheel.” The wheel is fine as is and any attempt to rebuild one from scratch is likely to result in a worse product. Same goes for crypto, a science that is hard to get exactly right. The code composing a wallet should have a reputation for working well. Choosing poorly written software – or attempting to develop one’s own alternative de novo – can lead to mishaps such as key leakage or revealing secret information to unauthorized parties. This is what was behind a recently exploited vulnerability in Profanity’s vanity address tool. Before anything else, it should be clear the wallet in question uses an audited and reputable key generation library and process.
Even if the code uses reputable cryptography libraries, it still must be integrated properly. Vetted software will typically set up correct parameters by default, but there can be gaps in execution. For instance, a strong source of entropy, or dose of mathematical randomness, is required to make to-be-generated keys unpredictable and, therefore, more secure. For certain key generation processes, such as for many Multi-Party Computation (MPC) algorithms, in which many separate keys – or shards, fragments of keys – must be generated and coordinated, the wallet ought to follow the precise protocol as specified by the algorithm. The algorithm may also require multiple rounds of computation as well as refreshing keys, which the wallet must integrate properly to maintain the security of the funds.
The final phase of the key generation process involves the actual operation and output of the software. Be aware of where the keys are being generated and in what form.
Ideally, the keys should be generated in isolated hardware, and the information should be encrypted with a reputable algorithm. An example of a weak one to be avoided is Data Encryption Standard, or DES, which is today considered broken. Keys left in plaintext – especially in memory, on-disk, or in the middle-zone between those two places known as “swap” – are a major security risk. In general, key material should not leave the hardware it’s generated on and should not escape onto networks accessible by others. (That is, unless the key material is encrypted, in which case the encryption key must be secured too.)
The keys for Slope, the wallet that got hacked this summer, were logged in plaintext to outside servers after being generated. This is the kind of security lapse that could have surfaced in an audit or open source implementation of the code. Wallets that lack transparency – featuring closed-source code, no available third party security audits to the public – should raise red flags.
After keys are generated, they will need to be stashed somewhere – never in plaintext, always encrypted. But merely owning the device on which keys are stored does not necessarily equate to key ownership and control. Many factors such as the supply chain security of the device, how connected the device is, and what other components the device interacts with must be considered. Furthermore, each storage method has its own set of trade-offs between security, accessibility, maintainability, and usability.
Below, we break down the most common categories based on their associated level of perceived risk.
The concept doesn’t actually have much to do with temperature. When it comes to key storage options, a wallet is considered “hot” if it’s connected to the internet. A wallet is considered “cold,” on the other hand, if it’s offline and isolated. All else being equal, cold wallets are more secure than hot wallets – but they’re also more difficult to access and use. A wallet that is connected to any network is more susceptible to hacks as it allows attackers more chances for access to discover and exploit vulnerabilities.
Hot wallets can take a few forms.
These are the riskiest options. Here, the wallet software, custodial or not, has direct access to the keys – all while being connected to the outside internet. The keys should ideally be encrypted, and the other set of keys used to encrypt them should be stored in a dedicated key management system (KMS) with highly restricted access controls such as an operating system keychain or a cloud key management system.
For software-based hot wallets, it is critical to isolate the key management and authorization from the rest of the software components. Problems can crop up in logging, error management, and memory management (especially heap-based, where keys may not be properly “zeroized,” or erased), all of which can mistakenly leak passwords, encryption keys, signing keys, or other sensitive cryptographic material. When that happens, interlopers can gain unauthorized access through connected applications or web servers, side channel attacks, or insider threats.
No matter how a service labels itself, if the signing keys are unencrypted at any time in the online system’s memory, then the model should be considered a hot software wallet. (Even if the keys are later stored at rest in a secure enclave.)
Connected hardware is generally considered less risky than connected software, but it’s still not as secure as cold storage. In connected hardware, keys are generated and live only inside special-purpose hardware devices. These can then be connected either to internal or public networks. Such devices generally take on multiple responsibilities related to key management, including security for key generation, signing, and storage.
Connected hardware comes in several varieties. There are hardware wallets, such as Trezor and Ledger devices, which slightly more sophisticated crypto users commonly use. (Many more people should be using these devices, as they’re vastly safer than using connected software alone.) There are also hardware security modules, or HSMs, which are commonly used in more traditional business settings such as ones that handle sensitive data processing, like credit card payments.
Devices are only as safe as the supply chain that produced and configured them. When considering connected hardware, ask yourself: What’s the likelihood that either the devices – or firmware – were tampered with before coming into your possession? To reduce this risk, it’s best to buy devices directly from trusted vendors. Have them shipped directly from the source. Make sure the packages do not appear to be compromised – no rips, tears, broken seals, etc. – which might indicate tampering amid transport. It’s also advisable to verify the firmware version and configuration before use. The steps to do so vary depending on the hardware, but all should provide instructions.
Of course, there’s always the possibility that a hardware wallet could later be stolen or accessed by an unauthorized party. Given these threats, it’s important to make sure hardware wallets also have secure access control layers – safeguards ensuring they aren’t just blindly signing any and all transactions. Controls can include password requirements, prompts asking for explicit permission for every step of a transaction, and plain English summaries describing what transactions are actually doing. In addition, most hardware wallets support private key encryption, also known as “key wrapping.” Even better, secure wallets will not allow keys to be exported in raw plaintext form, even if one wished for them to be.
This is the level of safety that is required to truly safeguard crypto assets.
Less heat, lower risk. Cold wallets are, all else being equal, generally considered more secure than hot ones, though they’re also generally less usable. Cold wallets are commonly called “airgapped” wallets, meaning they have no connection to any internal or public network.
Loneliness is a virtue in this case. Airgapping involves implementing rigorous physical isolation and authorization measures. These measures can include the use of Faraday cages (shields that block wireless signals), biometrics access (like fingerprint or iris scanners), motion sensors (to trip alarms in case of unauthorized use), and SCIFs, or Sensitive Compartmented Information Facilities (special areas for processing classified information).
Let’s review some cold wallet options in more detail.
Because an attacker can steal or take a machine online at any time, cold wallets should be designed with security systems that hold up even if they are brought online. Keys should be split in key shards – requiring the pieces to be rejoined to be made usable – through a standard method, such as Shamir’s Secret Sharing or Multi-Party Computation. Special purpose hardware, such as HSMs, are highly recommended over connected software as they generally offer more controls.
This solution is considered the safest of all. Similar to the previous category, one should assume the hardware can be stolen and taken online. For that reason, it’s important again for these systems to include properly implemented access control layers, as discussed earlier. Many HSM vendors require a quorum of physical smartcards to come together before access to keys can be unlocked. Even if the device does not have a display screen, it should offer some way for users to verify the details of transactions.
Because cold or airgapped wallets are the safest category, most funds managed by big players are stored in this manner. Major retail services, such as Coinbase, Gemini, Kraken, and others, as well as services for institutional users such as Anchorage, are among those that do so. Many of these players choose to have another line of defense in the form of backups and recovery, just in case – heaven forbid – they lose access, or machines are corrupted, stolen, or destroyed.
Signing keys should always be backed up after being encrypted. It is critical to have redundancy of both encrypted signing keys and key-wrapping keys. Methods to back up a signing key differ, but one should always prefer hardware native solutions.
For hardware wallets, backups usually involve a 12-word plaintext seed phrase from which private keys are derived. This seed phrase should be stored non-digitally (think paper, metal) and in the most secure way available (a physical vault at home, inside a bank vault). The phrase can be split into parts that are geographically distributed to prevent easy compromise of the entire secret. (People sometimes explain this approach by referencing the fictional horcruxes which dark wizards use effectively to “backup” their souls in Harry Potter.)
Many HSMs natively handle some of the challenges related to backup and recovery. Standard ones have mechanisms that can export keys that are, by default, encrypted with access controls. If the access controls are satisfied, keys can then be imported into other HSMs. Usefully, fleets of HSMs can also be provisioned with a common encryption key, derived from a quorum of smartcards. Decoupling the hardware from the key materials in this manner helps avoid single points of failure.
Finally, human factors need addressing. Recovery mechanisms should be able to withstand the temporary or permanent unavailability of any individual involved in account management operations. Individuals should make sure to provide ways for close family members or other trusted parties to recover keys in case of death or other emergencies. Group operations, meanwhile, should define a quorum – such as 2-out-of-3 or 3-out-of-5, say – that can reasonably operate despite life events, travel, illness, or accidents.
After keys are generated and stored, they can be used to create digital signatures that authorize transactions. The more software and hardware components in the mix, the greater the risk. To reduce risk, wallets should abide by the following guidelines for authorization and authentication.
Wallets should require authentication. In other words, they should verify that users are who they say they are, and that only authorized parties can access the wallet’s contents. The most common safeguards here are PIN codes or passphrases. As always, these should be sufficiently long and complex – using many different types of characters – to be maximally effective. More advanced forms of authentication can include biometrics or public key encryption-based approvals, such as cryptographic signatures from multiple other secured devices.
Wallets should use well-established cryptography libraries. Do some research to ensure they’re audited and safe so as to avoid key material leakage or complete loss of private keys. Complicating the matter, even trusted libraries can have unsafe interfaces, as was recently the case with these Ed25519 libraries. Be careful!
A well-studied key usage pitfall is the inadvertent reuse of certain cryptographic signature parameters. Some signature schemes may require a nonce meaning, “number used once,” an arbitrary number only meant to be used, well, once in a system. Elliptic Curve Digital Signature Algorithm (ECDSA) is one such signature scheme that does so. If a nonce is reused with ECDSA, it can lead to key compromise. Various other algorithms are not affected so, as usual, make sure well-established cryptographic libraries are being used. (Certain cryptographic libraries ensure unique nonces by hashing transaction data, which include other unique data such as account nonces.) But this attack vector has been exploited before in high-profile hacks outside of web3, such as this 2010 Sony PlayStation 3 hack.
Another best practice is avoiding reuse of a key for more than a single purpose. Separate keys should be kept for encryption and signing, for example. This follows the principle of “least privilege” in case of compromise, meaning that access to any asset, information, or operation should be restricted only to the parties or code that absolutely require it for the system to work. The principle of “least privilege” can, when properly implemented, drastically limit the blast radius of a successful attack. Different keys will have different requirements for backups and access management depending on their purpose. In the context of web3, it is a best practice to separate keys and seed phrases between assets and wallets, so compromise of one account does not affect any other.
The custodial or non-custodial nature of key ownership is not so black and white as conventional thinking would have one believe. The situation is complicated by the many moving parts involved in key management – from key generation to storage to usage. Every piece of hardware or software along the chain introduces risks that expose even supposedly non-custodial wallet options to custodial-type hazards.
For the future, we expect more development work to be done to secure wallets against attacks and to mitigate the risks discussed above. Areas of improvement include:
Specifically, we would be particularly excited to see development for shared and open-source:
The above list is non-exhaustive, but it’s a good starting point. All this is to say, the situation is more complicated than the slogan “not your keys, not your crypto” indicates. Key possession is a tricky matter given the many interacting parts and phases from generation and storage through usage.
If you’re already working on a project that addresses any of the above, or would be interested in doing so, please reach out! We look forward to more progress on these fronts.
***
Editor: Robert Hackett, @rhhackett
***
The views expressed here are those of the individual AH Capital Management, L.L.C. (“a16z”) personnel quoted and are not the views of a16z or its affiliates. Certain information contained in here has been obtained from third-party sources, including from portfolio companies of funds managed by a16z. While taken from sources believed to be reliable, a16z has not independently verified such information and makes no representations about the current or enduring accuracy of the information or its appropriateness for a given situation. In addition, this content may include third-party advertisements; a16z has not reviewed such advertisements and does not endorse any advertising content contained therein.
This content is provided for informational purposes only, and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisers as to those matters. References to any securities or digital assets are for illustrative purposes only, and do not constitute an investment recommendation or offer to provide investment advisory services. Furthermore, this content is not directed at nor intended for use by any investors or prospective investors, and may not under any circumstances be relied upon when making a decision to invest in any fund managed by a16z. (An offering to invest in an a16z fund will be made only by the private placement memorandum, subscription agreement, and other relevant documentation of any such fund and should be read in their entirety.) Any investments or portfolio companies mentioned, referred to, or described are not representative of all investments in vehicles managed by a16z, and there can be no assurance that the investments will be profitable or that other investments made in the future will have similar characteristics or results. A list of investments made by funds managed by Andreessen Horowitz (excluding investments for which the issuer has not provided permission for a16z to disclose publicly as well as unannounced investments in publicly traded digital assets) is available at https://a16z.com/investments/.
Charts and graphs provided within are for informational purposes solely and should not be relied upon when making any investment decision. Past performance is not indicative of future results. The content speaks only as of the date indicated. Any projections, estimates, forecasts, targets, prospects, and/or opinions expressed in these materials are subject to change without notice and may differ or be contrary to opinions expressed by others. Please see https://a16z.com/disclosures for additional important information.
