Web3 systems rely heavily on private keys. Web3 represents the decentralised web, which is built on blockchain technology and aims to provide a more secure, transparent, and user-controlled experience. Therefore, it is critical for Web3 platforms to ensure that their private keys and other private key data, such as seed phrases, are protected from unauthorised access.
In this article, I will present several threats and vulnerabilities to key management systems and provide security controls that can be applied to reduce the risk of unauthorised access to keys.
Even though most of the threats and vulnerabilities discussed here have been known for decades, it's important to place them in the context of Web3 key management systems and address any unique properties of blockchain-based systems.
Each threat and vulnerability is presented in a table below, providing a cause for the vulnerability. A comment section provides more detail on how the vulnerability or threat originates, and finally, a section on the type of security controls that can be implemented.
Threats and Vulnerabilities to Web3 Systems Threat: Vulnerabilities in custom software such as smart contracts.
Cause: | 1. Poor training for developers in secure coding techniques.
2. Poor testing of code prior to deployment. |
Comments: | 1. If developers are not trained in secure coding techniques, there is a high probability that vulnerabilities in the software code will be present.
2. Insufficient testing of custom software code also increases the chance that vulnerabilities within the custom software code end up in production. |
Controls: | 1. Establish a training program for developers that covers vulnerabilities introduced through poor coding techniques and how they can be avoided by applying secure coding techniques. Ensure the training is relevant to the software languages used. For example, if the software language is not susceptible to buffer overflow, then only address that attack vector at the highest level, but don’t focus any deeper.
2. Ensure that all code is peer-reviewed by another developer who did not contribute to the code being reviewed. Ensure that the peer-review process is well documented and checks for poor software development.
3. Ensure that a thorough testing program is in place and that code cannot be deployed to production unless testing and peer review have been completed and relevant approvals have been provided and documented. |
Threat: Loss of Key Data
Cause: | 1. Forgetting where key data is stored.
2. Not having backups of key data. |
Comments: | 1. If the location of key data is not securely recorded, knowledge of its location could be lost over time.
2. Additionally, backups of key data must be created in case the production key data is lost. |
Controls: | 1. Ensure there is a key inventory that lists all keys used within the environment (this will not include keys used for one transaction only). The key inventory must record information about the key's criticality, purpose, location, who has access to it, cryptoperiod, backup locations, etc
2. Ensure there are backups of the key data and that the backups are secured from unauthorised access. |
Threat: Insufficient control of access to key data.
Cause: | Poor access management controls. |
Comments: | Only users with a business need should be allowed to access key data. This applies to offline storage of cold wallet key data, backup key data and key data stored on systems or in system memory for hot/warm wallets. |
Controls: | 1. Implement RBAC for access to the key data.
2. Management must approve access to the key data, and employees must have only the privileges needed to perform their roles.
3. There should be a default “deny all” mechanism to catch all access not defined.
4. Physical access controls, such as locked doors/cabinets, restricted access to facilities, CCTV installed covering key areas, and a visitor sign-in process, are implemented. |
Threat: Unpatched software.
Cause: | Poor vulnerability and patch management controls. |
Comments: | It is important to patch not only the actual key management software but also the entire software stack, such as the operating system on which it is hosted and utility functions such as access controls, log management controls, monitoring controls, etc. |
Controls: | 1. Implement patch management to ensure all patches are reviewed and at least critical and high patches are installed no later than one month after the patch is released.
2. Implement vulnerability management to ensure all vulnerabilities are detected. A vulnerability scanner is an effective control to implement in order to detect vulnerabilities within the environment. |
Threat: Staff do not recognize attacks such as phishing, or social engineering.
Cause: | No or poor security awareness training. |
Comments: | Humans are the weakest link in information security, so training is vital to ensure that attacks such as phishing and social engineering are detected as soon as possible. |
Controls: | 1. Implement security awareness training for all personnel on hire and at least annually. Review the training material at least annually to ensure all new threat vectors are covered in the training material. |
Threat: Weak encryption protocols used in key generation.
Cause: | Industry-approved cryptographic protocols are ignored in favour of "homegrown" protocols. |
Comments: | Weak cryptographic protocols are sometimes used to generate entropy, producing predictable or insufficiently random values. Weak encryption should also not be used to protect key data at rest or in transit. |
Controls: | 1. Ensure policies state that only industry-accepted ciphers and algorithms are used for encryption.
2. Ensure all custom software code that provides encryption or decryption functions are audited by a third-party skilled in auditing encryption and decryption functions. |
Threat: Poor architectural design of systems.
Cause: | Industry best practices are ignored in favour of a cheaper/quicker system release, such as using hot wallets to store the majority of users' virtual assets. |
Comments: | Key management systems must be designed using industry best practices to ensure their security. Shortcuts to the design of these systems to save cost or time to market must be avoided. |
Controls: | 1. Require personnel who are knowledgeable in information security to be included in all aspects of the architecture and design of a system to ensure security principles are adhered to.
2. Ensure industry-recognised best practices and standards for secure architecture and design are used. |
Threat: Incorrect spending amounts/loss of funds to incorrect address.
Cause: | Poor verification procedures for confirming fund amount to transfer and destination address. |
Comments: | All transactions should be verified before sending using tools designed to verify and control fund amounts, verify destination addresses and ensure only authorised personnel can send transactions. |
Controls: | 1. Destination wallet addresses and fund amounts must be verified before approving the transaction to be processed. |
Threat: Malicious or unauthorised activity by entity personnel.
Cause: | Poor HR processes result in insider threats. |
Comments: | All personnel must be vetted before being granted access to seed phrases and signing keys. Malicious actors have been known to apply for developer roles in order to gain access to key data. |
Controls: | 1. All personnel must be vetted before accessing key data. Vetting must include criminal, reference, and background checks.
2. Initial access to key data requires a trusted member of the entity to monitor the new hire to ensure the documented key management processes are followed.
3. Implement logging and monitor on access and usage of key data. Any suspicious activity triggers an alert that is sent to relevant personnel for review.
4. Implement RBAC and implement the least privilege and need-to-know principles to user accounts that have access to key data. |
Threat: Malicious or unauthorised activity by service providers.
Cause: | Poor due diligence processes for service providers. |
Comments: | Supply chain attacks are a common attack vector. Potential service providers must be vetted and their information security posture reviewed at least annually. |
Controls: | 1. Implement service provider management, which includes vetting potential service providers and, at minimum, annual reviews of the service provider's security program. |
Threat: Natural disasters.
Cause: | Mother nature. |
Comments: | The protection of key management systems must consider natural and man-made disasters to ensure access to key data remains. |
Controls: | 1. Implement a disaster recovery plan and business continuity plan.
2. Ensure key data backups are distributed to other geo-locations from the primary key data. |
Threat: Impossible funds recovery.
Cause: | Late detection of hacks occurs because addresses are not automatically monitored, and there is no alert system for fund movements. |
Comments: | Hackers launder money before the funds are labelled as stolen in blockchain tracking tools. For example, exchanges may not flag the deposit of these funds as suspicious unless the funds come directly from a tumbler such as Tornado Cash. After the funds are cashed out from the exchange, recovery becomes difficult or even impossible in some jurisdictions. |
Controls: | 1. Implement controls to monitor wallet addresses for any suspicious activity. |
Threat: Complexity of use.
Cause: | Making systems more complicated to use than they should be. |
Comments: | An example would be the messages displayed by the wallet software to the end user when transacting or connecting to a platform. Most of the time the end user has no understanding of the meaning of a message and will blindly click the ok button. |
Controls: | 1. Reduce the complexity of the functions that the user interacts with directly.
2. Present messages with more helpful statements instead of displaying system messages.
3. Provide help guides such as online training videos to help the user understand the processes better. |
Threat: Quantum computing.
Cause: | Most cryptographic algorithms implemented within the virtual asset sector are not currently quantum-resistant. |
Comments: | Though not an immediate threat, quantum computing technology has been rapidly developing, so implementing controls to reduce the attack surface now can significantly bolster the resilience of cryptocurrency systems. |
Controls: | 1. Apply shorter key lifetimes: Regularly rotating keys to limit the window of vulnerability.
2. Storing keys securely: Using hardware security modules (HSMs) and other secure key storage solutions to protect against unauthorised access. "You cannot break the key if you cannot get hold of it". |
Threat: Poor/weak encryption used in the transmission of private keys.
Cause: | Roll-your-own or weak algorithm choices result in inadequate encryption protecting private keys during transmission and result in them being stolen. |
Comments: | With hot/warm wallets it is sometimes necessary to transmit keys digitally between systems so it is vital to ensure that the transmission mechanism is using strong encryption. |
Controls: | 1. Ensure that the transmission mechanism is using strong encryption.
2. Ensure that the transmission mechanism is configured to not accept any protocols or ciphers that are not considered strong encryption. |
Threat: Third-party malicious software/libraries/scripts incorporated into the system.
Cause: | Not verifying the source and validity of software/libraries/scripts used by the system. |
Comments: | Third-party software/libraries/scripts used by the system must be verified to ensure the software is not malicious. |
Controls: | 1. Implement a process for reviewing all third-party software/libraries/scripts before use, and once implemented, monitor for vulnerabilities and updates. |
Summary
The threats and vulnerabilities listed in this article are what I consider to be the most important currently, but there will be more as new technologies come into play. It's vital that Web3 platforms have a risk management process in place to identify security risks to the systems' people, processes, and technology components and update the threat register at least every 12 months.
The controls listed can be found in most baseline information security standards, such as ISO27001 and PCI DSS. However, I recommend that anyone responsible for the security of a Web3 platform also consider adopting the CryptoCurrency Security Standard (CCSS) as this standard has been built solely for blockchain based systems and addresses attack vectors that are unquie to blockchain.
Finally, if you have any questions regarding CCSS or implementing security controls in your Web3 platform please don’t hesitate to contact me at marc.krisjanous@confide.co.nz.