CryptoCurrency Security Standard (CCSS) - Key Storage Requirements
[Article Updated August 2023 for CCSS Version 8.1]?
Marc Krisjanous is one of the first CCSS Auditors, assisted C4 in the development of their auditors program and is a member of the CCSS Steering Committee.
**** Free CCSS Implementation Guide! ****
Marc also co-authored the CCSS Implementation Guide for a Full System - click here to download - it's free!
In this series we will review each of the core Aspects in the CCSS and provide our interpretation for each of the Aspect's requirements and what possible evidence could provide assurance to the auditor that a requirement is in-place.
In this article we will explore how an auditor could interpret the CCSS Aspect 1.03 Key Storage.
Aspect 1.03 Key Storage addresses the importance of protecting keys and seeds while at-rest. The Aspects objective defined within the CCSS is provided below.
"By separating the wallet’s keys across multiple locations, the risks associated with localized disruptions to business (e.g., fire, flood, earthquake, break-ins) do not affect the organization’s ability to spend funds."
Aspects Controls
There are six controls to this Aspect. In this article we will address each control.
CCSS Levels
CCSS provides three levels of compliance - Level 1 being the base level of implementing CCSS requirements up to Level 3 being the most in-depth implementation of CCSS requirements. We shall review each compliance level and provide our thoughts on what evidence an auditor should seek to provide assurance that the requirements are in-place.
Level 1 Compliance?
Requirement: 1.03.1.1 Cryptographic keys and/or seeds must be stored with the use of strong encryption when not in use.
The CCSS committee has provided an official definition for "strong encryption" #1. The definition offers AES-256 as an acceptable encryption algorithm. However, the definition does not provide any reference standards that one can refer to for guidance if, for example, if the assessed entity is not using AES-256.
SP 800-57 Part 1 Rev. 5 - Recommendation for Key Management: Part 1 – General #2 and SP 800-131A Rev. 2 - Transitioning the Use of Cryptographic Algorithms and Key Lengths #3 in our opinion provide industry recognized and accepted guidance on encryption algorithms that are deemed to provide what is considered "strong" encryption.
The CCSSA should review the system(s) that provide the storage facility for the keys and/or seeds to ensure the encryption settings meet the CCSS requirements. This will involve reviewing the configuration settings of the storage facility and how the keys used to encrypt the storage facility are protected. It is no use storing keys and/or seeds within a storage facility providing encryption protection when the storage facilities own keys are weak or not protected from unauthorized access.?
Requirement: 1.03.2.1 A backup of the cryptographic key/seed must exist. The backup can take any form (e.g., paper, digital).
In order to confirm that there is a backup for each key or seed phrase a list that identifies in some way the current active keys and seed phases must be provided to the CCSSA. Using the inventory list, the CCSSA can then confirm each key or seed phase has at least one backup. Ensure evidence is provided by the assessed entity proving that there is a backup for each key or seed phase. This can be done by the CCSSA observing the location of the backup such as a physical safe or a virtual vault.?
If the assessed entity states that the backup is managed by a third-party and can only be assessed in emergencies or key rotation events, then ensure documentation is provided from the third-party that officially lists the keys and seed phases under their care and the process to retrieve the keys and seed phrases from the third-party.
NOTE: we do not recommend that the CCSSA receive the actual keys or seed phases when asking for an inventory list. We would expect that there is a serial number or other identification that represents a particular key or seed phase.?
Requirement: 1.03.3.1 The backup must be protected against environmental risks such as fire, flood, and other acts of God.?
If the backup media is physical such as removable electronic media, paper, wood or metal ensure that the backup is protected using a safe, safe deposit box, or locked cabinet review the following:?
Requirement: 1.03.4.1 The backup must be protected by access controls that prevent unauthorized parties from accessing it.
As part of the CCSSA's process of observing the location of each backup for a key or seed phase, ensure that the backup is protected by access controls. An access control can be physical or logical depending on the type of media storing the key or seed phase.
If the backup media is physical such as removable electronic media, paper, wood or metal, ensure that the backup is protected using a safe, safe deposit box, or locked cabinet review the following:?
领英推荐
If the backup is stored virtually review the following:
NOTE:?The CCSS Aspect that addresses audit logs (2.03 Audit Logs) does not define how long access logs or CCTV video records are to be retained for. Therefore, the CCSSA must review the assessed entities data retention policy for their data which the CCSSA can refer to for guidance. The CCSSA is seeking assurance regarding the retention of access logs and CCTV records, that during an incident, the log entries and CCTV records will assist forensic examination tasks and police enquirers when needed.
Level 2 Compliance
Requirement: 1.03.2.2 A backup must exist for at least as many keys as are required to spend funds.
Ensure that there is documentation which defines the number of keys required to spend funds. The documentation should provide detailed information as to the number of keys required from the pool of available keys.
Once the documentation has been reviewed ensure that the defined number of keys required for spending funds have backups. The CCSS requirement provides examples as to how many keys are to have backups for a M-of-N wallet setup.
Requirement: 1.03.3.2 The backup key/seed must be stored in a location that is geographically separate from the usage location of the primary key/seed. For example, if the primary key is kept at an office, the backup key could be in escrow with a trusted 3rd party.
There is not much to add or break down for this requirement. The only consideration we can see is using the home as a backup location of a production key/seed is not very secure unless there are multiple access controls in-place such as a safe and CCTV camera recording all access to the safe.
Requirement: 1.03.5.1 The backup must employ some form of tamper evident mechanism that allows an operator to determine when it has been accessed.
For auditing, it is always preferable that a control is compliant or certified to an industry standard. This provides assurance to the auditor that the control has undertaken a certification process that provides some consistency in review of the control and meets a standard's recommendations. There appears to be standards for tamper evident mechanisms, one of which is German Federal Institute for Materials Research and Testing (BAM). This web page provides a good overview of what features a tamper evident envelope could provide as a guide for the CCSSA. NOTE: we do not endorse nor have any relationship with the product owners or the website - this is merely a website that was located during research and provides criteria that could guide the CCSSA.?https://shiftcrypto.ch/tamper-evident-bags/
Level 3 Compliance
Requirement: 1.03.3.3 Backups are resistant to electromagnetic pulses that could induce currents in electronics and damage the data stored within. A common methodology to secure against this risk is to store a seed or key on paper, wood, metal, or on another non-digital medium, or to place the digital medium within a sealed faraday bag designed to protect contents from electro-magnetic interference.
As with the tamper evident bags above, the auditor should research and identify standards and certifications for mechanisms providing a faraday capability and ensure that the mechanism implemented is certified or complies to those standards.
Requirement: 1.03.6.1 Backups of cryptographic keys and/or seeds must be stored with the use of strong encryption when not in use that is at least equal to the security prescribed for cryptographic keys/seeds above.
As described above, SP 800-57 Part 1 Rev. 5 - Recommendation for Key Management: Part 1 – General #2 and SP 800-131A Rev. 2 - Transitioning the Use of Cryptographic Algorithms and Key Lengths #3 provide industry recognized and accepted guidance on encryption algorithms that are deemed to provide what is considered "strong" encryption. This requirement states that the backups of the key/seed must be protected by "strong" encryption while at rest to at least the same encryption strength as the production key/seed version.
Summary
In this post we explored aspect?1.03 Key Storage of the CCSS with our auditors hat on to determine how an auditor could approach the evidence gathering required so that an opinion could be reached as to if the assessed entity is compliant to Level 1, Level 2 or Level 3 for this aspect.