Individuals have direct and sole control (and ownership) of their private keys (and crypto assets) - crypto wallets that adhere to this philosophy are known as "non-custodial" wallets, meaning the keys are not accessible to outsiders.
Until a series of "non-custodial" wallet hacking incidents-September Wintermute private key was "brute force cracked" and lost $160 million, August Slope wallet hacker intruded into more than 8,000 accounts, 2020 Trinity that stole more than $2 million IOTA Wallet hacks, the Parity wallet hack that stole 150,000 ETH in 2017, and various hardware wallet vulnerabilities blur the security lines between custodial and non-custodial wallets. In such cases, victims believe they are using a non-custodial wallet, only to discover that the private keys have been stolen.
In fact, non-custodial wallets don't really give users full control over their keys, because wallets are usually created and run by someone else's hardware and software. Users are increasingly trusting third-party products. These products integrate or use blockchain command-line interfaces, wallet software and devices, centralized platforms, smart contract code, decentralized applications, and each touchpoint increases risk. All these join points add up to shattering the rosy illusions people have about the concept of "unmanaged".
"Unmanaged" can actually refer to many managed elements.
Generally speaking, key management (the basis of wallet security) can be divided into three directions:
- key generation (creation of encryption keys);
- key storage (protecting keys at rest);
- Key usage (using key authorization).
Each direction has unique risk points.
This article will introduce the characteristics and shortcomings of encrypted wallet security and custody platforms, cover the areas that need the most attention and development in the future, and aim to help Web3 users better understand the complexity of protecting encrypted assets in a non-custodial manner. In addition, we also want to help engineers identify and avoid common failure points in wallet development, and use our years of comprehensive experience in Docker, Anchorage, Facebook, and a16z encryption systems to help users and project parties avoid security incidents.
key generation
The security of the key generation step is critical. At this stage, there are three overarching issues to keep in mind: use reliable code, implement code correctly, and handle output safely.
Audit reports published by some wallet providers on their official websites or Github repositories. Do your own research and try to determine if there is a reputable company behind the wallet. If information is scarce, significant user and developer activity may be useful indicators.
Follow these guidelines to reduce risk. If your wallet fails the following checks, run away.
Do not use wallets that have not been tested long enough
The code that makes up the wallet should have a good reputation. Choosing poorly written software, or trying to develop your own alternatives, can lead to "catastrophic events" such as leaking keys or disclosing confidential information to unauthorized parties.
Use a wallet with multiple insurance
Even if the code uses a reputable cryptographic library, it must be properly integrated. Audited software often defaults to the correct parameters, but bugs can arise during execution. For certain key generation processes, such as many multi-party computation (MPC) algorithms, where many individual keys must be generated and reconciled — or key fragments, key fragments — wallets should follow a protocol specified by the algorithm. The algorithm may also require multiple rounds of calculations and refresh keys, which must be properly integrated by wallets in order to maintain the security of funds.
Use a wallet that "keeps a secret"
The final stage of the key generation process involves the actual operation and output of the software. Note where and in what form the key is generated. Ideally, the keys should be generated in independent hardware and the information should be encrypted using a reliable algorithm.
The keys to the Slope wallet, which was hacked this summer, were generated to log in to an external server in clear text. This kind of security hole can appear in audits of code or in open source implementations. Lack of transparency in wallets – characterized by closed source code and no third-party security audits available to the public should raise alarm.
key storage
After the keys are generated, they need to be hidden somewhere (not in plaintext, always encrypted). However, mere possession of the device that stores the key does not necessarily equate to ownership and control of the key. Many factors must be considered, such as the supply chain security of the device, how the device is connected, and which other components the device interacts with. Additionally, each storage method has its own trade-offs between security, accessibility, maintainability, and availability.
Below, we have categorized the most common wallet security categories according to their associated known risk levels.
High Risk: Hot Wallets
All else being equal, cold wallets are more secure than hot wallets, but they are also more difficult to use. A wallet connected to any network is more likely to be hacked because it gives attackers more opportunities to find and exploit vulnerabilities.
There are two forms of hot wallet networking:
- Connectivity software: online database or web server application memory, browser extensions
These are the highest risks. Because the wallet software, whether hosted or not, has direct access to the keys—all of which are connected to the outside internet. Ideally the keys should 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 like operating system keys chain or cloud key management system.
- Connected hardware: dedicated appliances, mobile secure enclaves, in-line hardware security modules (HSMs)
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 only generated in dedicated hardware devices. These can then be connected to internal or public networks. Such devices typically take on multiple responsibilities related to key management, including key generation, signing, and security of storage.
There are also hardware wallets such as Trezor and Ledger. There are also hardware security modules, or HSMs, which are often used in more traditional business settings, such as those handling sensitive data processing such as credit card payments.
Devices are only as secure as the supply chains that produce and configure them. When considering connecting hardware, it's best to purchase equipment directly from trusted suppliers. Shipped directly from the source, making sure the package doesn't look damaged. It is also possible to verify the firmware version and configuration before use.
Of course, there is always the possibility of hardware wallets being stolen or accessed by an unauthorized party later on. Given these threats, it's important to ensure that hardware wallets also have a secure layer of access controls — safeguards to ensure they don't blindly sign any and all transactions. Controls can include password requirements, prompts asking for explicit permission for each step of the transaction, and simple summaries describing the actual operation of the transaction. Additionally, most hardware wallets support private key encryption, also known as "key wrapping."
Less Risky: Cold Wallets
All else being equal, cold wallets are generally considered more secure than hot wallets, although they're also generally not as easy to use. Cold wallets are not connected to any internal or public network.
Let's review some cold wallet options:
- Offline software: Offline server application
Because an attacker can steal or bring the machine online at any time, cold wallets should be designed to be secure while online. Special purpose hardware such as HSMs are highly recommended as they usually provide more control than connecting software.
- Offline Hardware: Offline Hardware Wallet, Offline Hardware Security Module (HSM)
This solution is considered the safest. Similar to the previous categories, we should assume that hardware can be stolen and obtained online. Therefore, as discussed earlier, these systems must include a properly implemented access control layer. Many HSM vendors require that a certain number of physical smart cards must be brought together before unlocking key access. Even if the device doesn't have a display screen, it should provide some way for the user to verify the details of the transaction.
Because cold wallets or offline wallets are the most secure category, most funds managed by large companies are stored this way, such as Coinbase, Gemini, Kraken, etc., and Anchorage. Many of these players also opt for another line of defense -- backup and recovery, in case they lose access, or the machine is damaged, stolen or destroyed.
backup and restore
Signing keys should be backed up after encryption. The repetition of the cryptographic signing key and the key wrapping key is critical. Methods for backing up signing keys vary, but hardware-native solutions should always be chosen.
For hardware wallets, the backup usually involves a plain text seed from which the private key is derived. Standard encryption keys have a mechanism that can derive keys that are encrypted with access control by default. Keys can be imported to other HSMs if access controls are satisfied. A large number of HSMs can also provide a common encryption key derived from a quorum of smart cards. Separating hardware from critical materials in this way helps avoid single points of failure.
Finally, there are human factors to consider. Recovery mechanisms should be able to withstand the temporary or permanent unavailability of any individual involved in account management operations. Individuals should ensure that there is a way to retrieve keys in the event of an outage or other emergency. At the same time, group operations should determine a number of people who can continue to operate in the event of an emergency.
key usage
After the keys are generated and stored, they can be used to create digital signatures that authorize transactions. The greater the combination of software and hardware, the greater the risk. To mitigate risk, wallets should adhere to the following authorization and authentication guidelines.
Trust, but also verify
The wallet should require verification. In other words, the user's identity should be verified and only authorized parties should have access to the contents of the wallet. The most common security measure here is a PIN code or passphrase. More advanced forms of authentication can include biometrics or approvals based on public key cryptography, such as cryptographic signatures from multiple other security devices.
Do not use a wallet that has not been tested long enough
Wallets should use sound cryptography libraries. Do some research to make sure they are audited and secure to avoid key material leaks or complete loss of private keys. Compounding the problem, even trusted libraries can have unsafe interfaces, as was the case with these recent Ed25519 libraries.
Nonce reuse
A well-studied key usage pitfall is the unintentional reuse of certain cryptographic signature parameters. Some signature schemes may require a one-time meaning, "number used only once" (an arbitrary number), meant to be used once in a system. Therefore, make sure you are using a sound encryption library. But this attack vector has also been exploited in high-profile hacks outside of Web3, such as the Sony PlayStation 3 hack in 2010.
one key one use
Another best practice is to avoid reusing the same key for multiple purposes. For example, separate keys should be kept for encryption and signing. This follows the principle of "least privilege" in compromised situations, which means that access to any asset, information, or operation should be restricted to only those parties or code that are absolutely necessary for the system to work. Depending on the usage, different keys have different requirements for backup and access management. In the Web3 ecosystem, it is best practice to separate keys and seed phrases between assets and wallets, so that compromise of one account does not affect other accounts.
Summarize
Custody of keys is a thorny issue with many interacting parts and stages from generation to storage to use. The custodial or non-custodial nature of key ownership is not as black and white as conventional wisdom has it. 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 on the chain introduces risk, even exposing options that are not originally part of a custodial wallet to custodial risk.
For the future, we hope to do more development work to protect the wallet from attacks and reduce the risks discussed above. Areas for improvement include:
- Share secure open source key management and transaction signing libraries across mobile and desktop operating systems;
- A shared open source transaction approval framework.
There are also shared and open source developments:
- Implement best-of-breed secure key generation libraries across different storage backends (encryption on disk, secure hardware, etc.);
- Key management and transaction signing libraries for mobile and desktop operating systems;
- Transaction approval process framework, enabling specialized verification such as biometrics, PKI-based approval, authorization recovery, etc.
Hui Xin
Brian
Alex
Kikyo
Joy