| Category | Aspect | Aspect Objective | Aspect Control | Level I | Rationale | Evidence | Level II | Rationale | Evidence | Level III | Rationale | Evidence |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Aspect | Aspect Objective | Aspect Control | Requirement | Rationale | Requirement | Rationale | Requirement | Rationale | ||||
| Cryptographic Asset Management | 1.01 Key/Seed Generation | This aspect covers the generation of cryptographic keys and seeds that will be used within a digital asset and blockchain protocol. The secure creation of cryptographic keys and seeds requires two things to be secure: confidentiality and unpredictable numbers. Confidentiality is required to ensure that the newly created keys or seeds are not read/copied by an unintended party. Nondeterministic and unpredictable numbers are required to ensure the newly created key cannot be guessed or determined by an unintended party. Each of the goals listed provide assurance that the keys and/or seeds are created in a confidential and un-guessable manner. | 1.01.1 Operator-created Key / Seed | 1.01.1.1 The cryptographic keys and seeds are created by the actor who will be using it. | This is an attempt to protect the confidentiality of the key. Any system that requires one actor to transfer a key or seed to another actor after generating it will fail to achieve Level I, with the exception of the initial configuration of an automated signing agent. | 1.01.1.3 A digital signature for the key creation software is generated, published, and validated prior to each execution. | This ensures the software has not been altered. | Not required for level III | Not required for level III | |||
| 1.01.1.2 In cases where an automated agent will make use of a cryptographic key/seed, it is required that the administrator of that system generate the key/seed on a suitable offline system with sufficient entropy, have this key/seed transferred securely onto the target device, and then securely deleted using CCSS-compliant data sanitization techniques to protect the confidentiality of the key/seed. | This is an attempt to protect the confidentiality of the key for any system using an automated signing agent. | No additional requirements for level II | Not required for level II | No additional requirements for level III | Not required for level III | |||||||
| 1.01.2 Creation methodology is validated | Not required for level I | Not required for level I | 1.01.2.1 The key or seed generation methodology is validated prior to use. Software does not include features that restrict which values can be used. Software does not include features that store or transmit data to another actor, unless that feature enhances security (e.g. DRBGs) | Features that restrict the entropy of seed generation and don't protect the transmission of data result in decreased security. | No additional requirements for level III | Not required for level III | ||||||
| Not required for level I | Not required for level I | 1.01.2.2 In cases where keys or seeds are created without the use of software (e.g., dice, a deck of cards, or other non-digital source of entropy), the creation methodology must be validated to ensure determinism is not present (e.g., there are no weighted dice, each card in the deck is unique). | Features that restrict the entropy of seed generation result in decreased security. | No additional requirements for level III | Not required for level III | |||||||
| 1.01.3 DRBG Compliance | Not required for level I | Not required for level I | Not required for level II | Not required for level II | 1.01.3.1 The key or seed is generated using either a 1) Deterministic Random Bit Generator (DRBG) that conforms to NIST SP 800-90A, and has been seeded with at least two separate cryptographically secure sources of entropy that have been combined in a cryptographically secure manner (e.g., SHA256[UnguessableFactor1 + UnguessableFactor2]) or 2) a Non-deterministic Random Bit Generator (NRBG), or a “True Random Number Generator” (TRNG) that passes industry-standard statistical tests for randomness such as DIEHARD, Crypt-X, or NIST STS. The Dual_EC DRBG has been demonstrated to be vulnerable and thus must not be used. | NIST SP 800-90A is a recommendation that ensures that deterministically-generated numbers follow a random distribution with respect to a deterministic seed. Thus, the ability to determine these random numbers is reducible to the ability to discover the DRBG’s seed. | ||||||
| Not required for level I | Not required for level I | Not required for level II | Not required for level II | 1.01.3.2 The key/seed generation process has been documented including a detailed run book showing all steps performed and signed-off by different parties that each procedure was performed and checked. The documentation shows clear segregation of duties and/or the presence of an independent third party to observe and validate the procedures. | Documentation and sign-off of the key/seed generation process ensures consistency in the process and segregation of duties and/or the presence of an independent third party to observe and validate the procedures prevents an individual from manipulating the process. | |||||||
| 1.01.4 Entropy Pool | 1.01.4.1 The cryptographic keys and seeds are created on a system with sufficient entropy to ensure the keys are not created with any bias towards a reduced range of values, or other deterministic properties. | This is to create seeds in an unguessable and unrepeatable manner. | No additional requirements for level II | Not required for level II | No additional requirements for level III | Not required for level III | ||||||
| 1.02 Wallet Creation | This aspect covers the creation of wallets or addresses that can receive digital assets. Wallets are created using key signing methodologies that can require a single key’s signature, multiple keys’ signatures, or a minimum number of signatures from many keys. Furthermore, wallets can be created individually (commonly referred to as JBOK wallets, or “Just a Bunch Of Keys”) or in a deterministic way that allows a set of addresses/key pairs to be created from a single master seed. Security of wallet creation is derived from the integrity of the wallet in the face of various risks such as a lost/stolen/compromised key, and the confidentiality of the wallet that would make it difficult to associate a wallet with a particular actor. | 1.02.1 Multiple keys for signing | Not required for level I | Not required for level I | 1.02.1.1 Any address generated by a wallet must require a minimum of 2 signatures (commonly referred to as a multi-sig wallet) in order to spend funds, where a separate actor holds each signing key. The actors can either be human or system (i.e. two humans, two systems, or one human and one system) but must be separate entities that each manage their own key for the wallet. | Requiring 2 or more signatures on a wallet increases the integrity of funds by reducing the risk of theft associated with a compromised key or key holder. | No additional requirements for level III | Not required for level III | ||||
| 1.02.2 Redundant key for recovery | Not required for level I | Not required for level I | 1.02.2.1 Redundant keys are assigned to each wallet for recovery purposes. | This ensures that the funds are still available in the event one of the primary keys becomes inaccessible for any reason. One common method of achieving this goal is to create a wallet that requires any 2 of 3 possible signatures in order to spend funds (i.e., there is 1 redundant key) | No additional requirements for level III | Not required for level 3 | ||||||
| 1.02.3 Geographic distribution of keys | Not required for level I | Not required for level I | 1.02.3.1 Any keys that have signing authority on a single wallet must be stored in different locations. | 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. | No additional requirements for level III | Not required for level III | ||||||
| 1.02.4 Organizational distribution of keys | Not required for level I | Not required for level I | Not required for level II | Not required for level II | 1.02.4.1 Any keys that have signing authority on a single wallet must be stored by multiple organizational entities/business units. | By giving keys to separate business units and legal entities (such as lawyers, accountants, or other businesses), legal risks that can disrupt your business will not necessarily disrupt your funds. Note that this does not violate the Key/Seed Generation Level I requirement, as the separate organizations fail to meet the definition of an actor. | ||||||
| 1.02.5 Documented wallet creation policy | Not required for level I | Not required for level I | 1.02.5.1 The organization has a documented custody policy in place which details the company’s internal policies and procedures and covers the relevant areas of wallet creation. | A documented custody policy provides transparent consistency and limits errors. | No additional requirements for level III | Not required for level III | ||||||
| 1.03 Key Storage | 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. | 1.03.1 Primary keys are stored encrypted | 1.03.1.1 Cryptographic keys and/or seeds must be stored with the use of strong encryption when not in use. | Strong encryption provides key security. | No additional requirements for level II | Not required for level II | No additional requirements for level III | Not required for level III | ||||
| 1.03.2 Backup key exists | 1.03.2.1 A backup of the cryptographic key/seed must exist. The backup can take any form (e.g., paper, digital). | A backup of the key/seed reduces risk of key/seed loss. | 1.03.2.2 A backup must exist for at least as many keys as are required to spend funds. | A backup of as many key/seed as is required to spend funds reduces risk of inability to access assets. For example, in a 2-of-3 signing setup where any two of three keys are required to spend funds, backups must exist for at least 2 of these keys. In a 5-of-9 setup, backups must exist for at least 5 keys. | No additional requirements for level III | Not required for level III | ||||||
| 1.03.3 Backup key has environmental protection | 1.03.3.1 The backup must be protected against environmental risks such as fire, flood, and other acts of God. | Protection against environmental risks reduce likelihood of key/seed loss. Common methods to achieve this include a water-tight bag for flood protection and a safe or firebox for fire protection. Specific mechanisms of environmental protection may change depending on the type of medium used for backup. | 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. | Further reduces risk of backup key/seed loss. | 1.03.3.3 Backups are resistant to electromagnetic pulses that could induce currents in electronics and damage the data stored within. | Resistance to devices from outside signals prevents data from being altered and reduces risk of backup key/seed manipulation. 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. | ||||||
| 1.03.4 Backup key is access-controlled | 1.03.4.1 The backup must be protected by access controls that prevent unauthorized parties from accessing it. | Access-controlled protection reduces risk of unauthorized use of backup key. Examples of this include safes, safe deposit boxes, or locked drawers where only the operator holds the key/combination for the lock. | No additional requirements for level II | Not required for level II | No additional requirements for level III | Not required for level III | ||||||
| 1.03.5 Backup key has tamper-evident seal | Not required for level I | Not required for level I | 1.03.5.1 The backup must employ some form of tamper evident mechanism that allows an operator to determine if it has been accessed. | Reduces risk of backup key/seed compromise. A secure method of achieving this involves a serial-numbered tamper-evident bag, however properly sealed paper envelopes with handwritten signatures over the seal could also suffice provided the specific envelopes in use are able to reveal evidence of tampering. | No additional requirements for level III | No additional requirements for level III | ||||||
| 1.03.6 Backup key is encrypted | Not required for level I | Not required for level I | Not required for level II | Not required for level II | 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. | Storing backups with strong encryption increases security. | ||||||
| 1.04 Key Usage | This aspect covers the use of cryptographic keys and/or seeds to ensure they are used in a secure manner that minimizes the risks to the confidentiality of private keys and integrity of funds. This section does not cover the usage of key backups which are only used in the event the primary key is lost/damaged/inaccessible. A variety of risks are present when using keys that can lead to the loss of funds including dirty signature vulnerabilities (i.e. re-used ‘R’ values), opportunity for malware to copy or modify keys, and malicious insiders who use their authorized access to send unauthorized transactions. | 1.04.1 Key access requires user/pass/nth factor | 1.04.1.1 Access to the primary key/seed requires an identifier (e.g. username, email, GUID, etc.) and at least 2 (two) other factors of authentication, which restricts access to the authorized operator. | Multi-factor authentication restricts access and thus increases security. Examples of additional factors of authentication include Google Authenticator tokens, digital signatures from a private key, in-person ID verification, possession of a physical key or token, or a countersigning organization who can remotely attest to the authenticity of the key holder. | No additional requirements for level II | Not required for level II | 1.04.1.2 Access to the key/seed requires an identifier (e.g., username, email, GUID) and at least 3 (three) other factors of authentication. | Additional factors of authentication restricts access and increases security. Similar to the requirement of 2 additional factors in Level I, the other 3 factors of authentication in Level III can take any form that provides confirmation of an authorized user’s identity. | ||||
| 1.04.2 Keys are only used in a trusted environment | 1.04.2.1 All keys/seeds are only used in trusted environments. | This decreases/reduces the risk of unauthorized copies being made by malware, as well as mitigating the risk of storing (even inadvertently) a key on a machine, allowing it to be recovered by another user or intruder. An effective trusted environment guards against unauthorized persons learning private keys, passwords, or other sensitive information. | No additional requirements for level II | Not required for level II | No additional requirements for level III | Not required for level III | ||||||
| 1.04.3 Operator reference checks | 1.04.3.1 All key/seed holders have had their references checked prior to being trusted to hold one of the organization’s keys/seeds. | This helps ensure the person is being truthful about their past and were not dismissed from prior employment for reasons that would represent a risk to the organization. | No additional requirements for level II | Not required for level II | No additional requirements for level III | Not required for level III | ||||||
| 1.04.4 Operator ID checks | 1.04.4.1 All key/seed holders (individuals and organizations) have undergone identity verification to ensure they are who they say they are. | This reduces the risks associated with impersonation and social engineering attacks which may result in access to organizational or customer funds. | No additional requirements for level II | Not required for level II | No additional requirements for level III | Not required for level III | ||||||
| 1.04.5 Operator background checks | Not required for level I | Not required for level I | Not required for level II | Not required for level II | 1.04.5.1 All individual key/seed holders have had background checks performed by law enforcement personnel or investigative firms. | This verifies that each key/seed holder is who they say they are and does not have evidence in their past of actions that would represent a risk to the organization if they had signing authority on organization or user funds. | ||||||
| 1.04.6 Spends are verified before signing | Not required for level I | Not required for level I | 1.04.6.1 Verification of fund destinations and amounts is performed via Approved Communication Channels prior to key/seed use. | This verifies that fund destinations and amounts are accurate prior to sending funds. | No additional requirements for level III | Not required for level III | ||||||
| 1.04.7 No two keys are used on one device | 1.04.7.1 No two master keys/seeds of the same multi-signature wallet are ever present on the same device. | Placing two keys of the same wallet on a single device exposes the keys to information leakage by either a malicious operator or malicious software. Ensuring every key of a wallet is used on dedicated devices reduces these risks, thereby increasing security. | No additional requirements for level II | Not required for level II | No additional requirements for level III | Not required for level III | ||||||
| 1.04.8 DRBG Compliance | 1.04.8.1 Digital signatures must use a ‘k’ value that is never repeated. | This is to create seeds in an unguessable and unrepeatable manner. This can be accomplished through the use of a deterministic random bit generator (DRBG) that is compliant with NIST SP 800-90A, or a deterministic scheme compatible with RFC 6979. A common implementation of this is to use the pseudo-random number generator (PRNG) supplied by popular operating systems, or an RFC 6979-compatible scheme. | No additional requirements for level II | Not required for level II | No additional requirements for level III | Not required for level III | ||||||
| 1.05 Key Compromise Policy | This aspect covers the existence and use of a protocol that dictates the actions that must be taken in the event a cryptographic key/seed or its operator/holder is believed to have become compromised. Organizations must be prepared to deal with a situation where a private key has – even potentially – become known, determinable, or destroyed. Proper policies and procedures to govern these events decrease the risks associated with lost funds and disclosed trade secrets, and increase the availability of the information system to its users. Examples of when a KCP would be invoked include the identification of tampering of a tamper-evident seal placed on key material, the apparent disappearance of an operator whose closest friends and family cannot identify their whereabouts, or the receipt of communication that credibly indicates an operator or key is likely at risk of being compromised. The execution of Key Compromise Protocols must make use of Approved Communication Channels to ensure KCP messages are only sent/received by authenticated actors. | 1.05.1 KCP Exists | 1.05.1.1 An inventory of all keys/seeds exists and the organization has an awareness of which keys are critical to the successful operation of the information system. | This decreases the risks associated with lost funds and disclosed trade secrets. | 1.05.1.3 A Key Compromise Protocol is documented which details: each specific classification of key used throughout the system; a detailed plan of dealing with its compromise that includes the use of Approved Communication Channels during execution; identities of actors via roles (not names), and includes secondary actors in the event any primary actor is unavailable to carry out the KCP. | This further decreases the risks associated with lost funds and disclosed trade secrets. | No additional requirements for level III | Not required for level III | ||||
| 1.05.1.2 While no formal KCP documents may exist, there is a staff member who is able to direct operators in the procedures necessary to regenerate cryptographic keys, regenerate cryptocurrency wallets, and send funds to these newly-generated wallets in the event any operator or keys become compromised. | This decreases the risks associated with lost funds and disclosed trade secrets. | |||||||||||
| 1.05.2 KCP Training + Rehearsals | Not required for level I | Not required for level I | Not required for level II | Not required for level II | 1.05.2.1 The Key Compromise Protocol is tested periodically to confirm the viability of the procedures and to ensure staff remain trained to use them in the case of a compromise. Logs of executed tests exist which outline any/all comments of the test. Improvements identified during the tests are written back into the protocol to ensure the most effective and efficient protocol is always maintained. As changes are made to the information system, the Key Compromise Protocol is revisited to assure it is updated with any new class of key. | This ensures that any potentially compromised keys are quickly and efficiently handled. The regularity of testing may be based on the classification of the keys as called out in 1.05.1.2 | ||||||
| 1.06 Keyholder Grant/Revoke Policies & Procedures | This aspect covers the policies and procedures surrounding granting and revoking access to cryptographic keys or seeds that store organizational or end-user funds. Staff typically have greater access to an information system with respect to accessing its information, invoking privilege-restricted actions, and representing the organization to the public. Improper management of the onboarding and offboarding of personnel introduce risks of privileged accounts remaining when staff depart, as well as unrevoked keys that persist signing authority for certain transactions. | 1.06.1 Grant/Revoke Procedures/Checklist | 1.06.1.1 An awareness of how roles should be managed when onboarding or offboarding staff from keyholder positions exists within the organization. A staff member who is knowledgeable about the system is able to ensure that permissions are granted/revoked to/from the affected staff appropriately. | This reduces the risks associated with the possession of un-revoked keys. | 1.06.1.2 The organization maintains checklists that cover all tasks that must be completed when staff vacate or transition into keyholder roles within the organization. These checklists have been reviewed by knowledgeable personnel to ensure “least privilege principles” are applied to the information system, as well as necessary access where required. | This reduces the risks associated with missed privileges and the possession of un-revoked keys. | Not additional requirements for Level III | Not required for level III | ||||
| 1.06.2 Requests made via Approved Communication Channel | Not required for level I | Not required for level I | 1.06.2.1 All keyholder grant/revoke requests are conducted over Approved Communication Channels. | This provides high confidence of the identities of the communicating parties. | No additional requirements for Level III | Not required for Level III | ||||||
| 1.06.3 Grant/Revoke Audit Trail | Not required for level I | Not required for level I | Not required for level II | Not required for level II | 1.06.3.1 The organization’s checklists include auditing information that record the identity of the staff member that performs the grant/revoke operations. Each entry within the audit trail is attested to by the staff member who performed that task. | Documentation of the checklists and audit trail further verifies identities and ensures grant/revoke processes are completed. | ||||||
| Operations | 2.01 Security Tests/ Audits | This aspect covers third-party reviews of the security systems, technical controls, and policies that protect the information system from all forms of risk as well as vulnerability and penetration tests designed to identify paths around existing controls. Regardless of the technical skills, knowledge, and experience of staff who build and maintain an information system, it has been proven that third-person reviews often identify risks and control deficiencies that were either overlooked or underestimated by staff. For the same reasons that development companies require different people to test a product from those who write it, different people than those who implement a cryptocurrency system should assess its security. Third parties provide a different viewpoint and are independent of the technical controls and can be objective without risk of retaliation. | 2.01.1 Security Audit | 2.01.1.1 A developer who is knowledgeable about digital asset security has assisted in the design and implementation of the information system and documentation of an internal assessment exists. | Having this knowledge available during the design and implementation stages helps ensure best practices are followed to minimize risk. Examples of evidence of this knowledge might look like checking if the developer has attended any training for digital asset security including smart contract coding if applicable; asking developer to describe what they learnt from the training; checking that the assessed entity has secure coding policies and standards. | 2.01.1.2 A regular security assessment that includes vulnerability and penetration testing has been completed by an independent qualified third-party. Documentation shows that all concerns raised by the assessment have been evaluated for risk and addressed by the organization. | Security audits, in addition to regular vulnerability and penetrations test, not only reduce the risks of unknown deficiencies in security but also reduce the overall cost of security as each audit builds on top of the last one’s results allowing for a more focused and cost effective assessment. Vulnerability and penetration tests decrease the risks associated with institutional blindness and provide confidence in the organization’s controls and procedures. | 2.01.1.3 A regular security audit at a level similar to SOC2, ISAE3402, or ISO-27001, that includes vulnerability, penetration testing, and code audit (if applicable) has been completed by an independent qualified third-party. Documentation shows that all concerns raised by the audit have been evaluated for risk, addressed by the organization, and known vulnerabilities have been removed from the system. Ongoing audits are scheduled on a (minimum) yearly basis. | Security audits, in addition to regular vulnerability and penetrations test, not only reduce the risks of unknown deficiencies in security but also reduce the overall cost of security as each audit builds on top of the last one’s results allowing for a more focused and cost effective assessment. Vulnerability and penetration tests decrease the risks associated with institutional blindness and provide confidence in the organization’s controls and procedures. Completing these regularly increases security. | |||
| 2.02 Data Sanitization Policy | This aspect covers the removal of cryptographic keys from digital media. Due to the manner in which file systems allocate data on digital media, digital forensic techniques can be employed to read old data that has previously been deleted. Proper sanitization of digital media ensures the proper removal of all keys, eliminating the risk of information leakage from decommissioned devices like servers, hard disk drives, and removable storage. | 2.02.1 DSP Exists | 2.02.1.1 The organization’s staff is aware of how data persists on digital media after deletion. Staff also have access to tools that perform secure deletion of data and understand when to use such tools to permanently destroy any transient copies of cryptographic keys that may be required during the maintenance of the information system. | Awareness of why digital sanitization is important and how to conduct digital sanitization reduces the risk of information leakage. | 2.02.1.2 A detailed policy that aligns to NIST 800-88 by outlining the requirements for sanitization of digital media that holds/held cryptocurrency keys exists is read/understood by all staff who have access to cryptographic keys. Procedure documents outline where sanitization is required in their processes. | Implementation of a detailed policy of digital sanitization reduces error and the risk of information leakage. | No additional requirements for level III | Not required for level III | ||||
| 2.02.2 Audit Trail of all media sanitization | Not required for level I | Not required for level I | Not required for level II | Not required for level II | 2.02.2.1 An audit trail is maintained for every piece of sanitized media conforming to the NIST 800-88 recommendation. These audit documents identify the staff member who performed the sanitization, the specific identifiers of the media that was sanitized, which tool and configuration was used to perform the sanitization, and all other relevant pertinent information. | An audit trail provides evidence of media sanitization being performed. | ||||||
| 2.03 Audit Logs | This aspect covers the information system’s maintenance of audit logs that provide a record of all changes to information throughout the system. In the event of unexpected behavior or security incidents, audit logs are an extremely valuable tool that can help investigators understand how the unexpected symptoms occurred and how to resolve the inconsistencies to return the information system to a consistent state. The maintenance of audit logs significantly reduces the risks associated with operational awareness and increases the information system’s ability to correct any inaccuracies. | 2.03.1 Application Audit Logs | 2.03.1.1 Audit trails exist for a subset of actions that are performed within the information system. | Audit trails reduce the risks associated with operational awareness and increase the information system’s ability to correct any inaccuracies. Examples of this would include recording audit information of all withdrawals and deposits made with the system. | 2.03.1.2 All actions by all users are logged. Audit logs are retained for at least 1 year in a trusted environment. | These records provide significant assistance to investigations into unexpected behavior of the information system and can help identify malicious actors and responsible systems or persons. | No additional requirements for level III | Not required for level III | ||||
| 2.03.2 Backup of Audit Logs | Not required for level I | Not required for level I | 2.03.2.1 In addition to recording all actions performed within the system, this audit information is periodically backed up to a separate server. | This action helps preserve valuable investigative information in the event the audit log is altered/destroyed during an attack on the information system. | 2.03.2.2 In addition to recording all actions performed within the system, this audit information is continually backed up to a separate server. | This action helps further preserve valuable investigative information in the event the audit log is altered/destroyed during an attack on the information system. | ||||||
| CCSS Matrix Version 8.1 |
