Listen to a16z talk about security: the "non-custodial" fallacy of the wallet

Original title: "Wallet Security: The "Non-Custodial" Fallacy"

Original author: Nassim Eddequouaq, Riyaz Faizullabhoy, a16z

Original compilation: Katie Koo, Odaily Planet daily

Individuals have direct and sole control (and ownership) of their own private keys (and cryptoassets) - crypto wallets that adhere to this philosophy are called It is a "non-custodial" wallet, which means that the keys cannot be accessed externally.

Until a series of "non-custodial" wallet hacking incidents - in September, the Wintermute private key was "brute force cracked" and lost 160 million US dollars, and in August more than 8,000 wallets were hacked The Slope wallet hack of accounts, the Trinity wallet hack that stole over $2 million in IOTA in 2020, the Parity wallet hack that stole 150,000 ETH   safety boundaries between. 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 do not really give users full control over their own keys, because wallets are usually created and run by other people's hardware and software of. 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 of these connection points add up to shattering the rosy illusions people have about the concept of "unmanaged".

"Unmanaged" may actually refer to many managed elements.

Generally speaking, key management (the basis of wallet security) can be divided into three directions:

1. Key generation (creation of encryption keys) ;

2. Key storage (protecting static keys);

3. 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, covering the areas that need the most attention and development in the future , designed to help Web3 users better understand the complexities of securing crypto 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

Security of the key generation step very important. At this stage, there are three overarching issues to keep in mind: use solid 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 a wallet that has not been tested for a long enough time

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 crypto library, 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 "secret-keeping" wallet

The final stage of the key generation process involves to the actual operation and output of the software. Note where and in what form the key is generated. Ideally, keys should be generated in independent hardware and 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

Once 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

Other things 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:

< b>· Connection software: online database or web server application memory, browser extensions

These are the highest risk. 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.

· Connecting Hardware: Dedicated Devices, Mobile Secure Enclave, Online Hardware Security Modules (HSM)

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 in which they are produced and configured. When considering connecting hardware, it's best to purchase equipment directly from trusted vendors. 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 that a hardware wallet will later be stolen or accessed by an unauthorized party. 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 risk: cold wallet

Under the same conditions, cold wallet Generally considered more secure than hot wallets, although they are 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 or offline wallets are the most secure type, 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 keys are generated and stored, they can be used to create authorizations Digital signature of the transaction. 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.

Trusted, but also verified

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 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 for a long enough time

The wallet should use a perfect Cryptography library. 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 that certain cryptographic signatures Unintentional reuse of 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 for one use

Another best practice is to avoid creating multiple purpose to reuse the same key. 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.

Summary

The many interacting parts and stages from generation to storage to consumption, Key custody is a tricky issue. 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 wallets from attacks and reduce the risks discussed above. Areas for improvement include:

· Sharing secure open source key management and transaction signing libraries across mobile and desktop operating systems ;

· Shared open source transaction approval framework.

There are also shared and open source development:

·  Implement optimal secure key generation libraries across different storage backends (encryption on disk, secure hardware, etc.);

·< /b> Key management and transaction signing library for mobile and desktop operating systems;

· Transaction approval Process framework for specialized verification such as biometrics, PKI-based approvals, authorization recovery, etc.

Original link< /a>