CCSS Matrix 8.1 with Evidence

CCSS Matrix 8.1 with Evidence

CategoryAspectAspect Objective Aspect ControlLevel IRationaleEvidenceLevel IIRationaleEvidenceLevel IIIRationaleEvidence
AspectAspect ObjectiveAspect ControlRequirementRationaleRequirementRationaleRequirementRationale
Cryptographic Asset Management1.01 Key/Seed GenerationThis 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 / Seed1.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 IIINot 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 IINot required for level IINo additional requirements for level IIINot required for level III
1.01.2 Creation methodology is validatedNot required for level INot required for level I1.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 IIINot required for level III
Not required for level INot required for level I1.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 IIINot required for level III
1.01.3 DRBG ComplianceNot required for level INot required for level INot required for level IINot required for level II1.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 INot required for level INot required for level IINot required for level II1.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 Pool1.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 IINot required for level IINo additional requirements for level IIINot required for level III
1.02 Wallet CreationThis 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 signingNot required for level INot required for level I1.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 IIINot required for level III
1.02.2 Redundant key for recoveryNot required for level INot required for level I1.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 IIINot required for level 3
1.02.3 Geographic distribution of keysNot required for level INot required for level I1.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 IIINot required for level III
1.02.4 Organizational distribution of keysNot required for level INot required for level INot required for level IINot required for level II1.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 policyNot required for level INot required for level I1.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 IIINot required for level III
1.03 Key StorageBy 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 encrypted1.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 IINot required for level IINo additional requirements for level IIINot required for level III
1.03.2 Backup key exists1.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 IIINot required for level III
Aspect ControlRequirementRationaleRequirementRationaleRequirementRationale
Aspect ControlRequirementRationaleRequirementRationaleRequirementRationale
Aspect ControlRequirementRationaleRequirementRationaleRequirementRationale
Aspect ControlRequirementRationaleRequirementRationaleRequirementRationale
AspectAspect ObjectiveAspect ControlRequirementRationaleRequirementRationaleRequirementRationale
Aspect ControlRequirementRationaleRequirementRationaleRequirementRationale
Aspect ControlRequirementRationaleRequirementRationaleRequirementRationale
Aspect ControlRequirementRationaleRequirementRationaleRequirementRationale
Aspect ControlRequirementRationaleRequirementRationaleRequirementRationale
Aspect ControlRequirementRationaleRequirementRationaleRequirementRationale
Aspect ControlRequirementRationaleRequirementRationaleRequirementRationale
Aspect ControlRequirementRationaleRequirementRationaleRequirementRationale
AspectAspect ObjectiveAspect ControlRequirementRationaleRequirementRationaleRequirementRationale
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.
Aspect ControlRequirementRationaleRequirementRationaleRequirementRationale
AspectAspect ObjectiveAspect ControlRequirementRationaleRequirementRationaleRequirementRationale
Aspect ControlRequirementRationaleRequirementRationaleRequirementRationale
1.03.4 Backup key is access-controlled1.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 IINot required for level IINo additional requirements for level IIINot required for level III
1.03.4 Backup key is access-controlled1.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 IINot required for level IINo additional requirements for level IIINot required for level III
1.03.5 Backup key has tamper-evident sealNot required for level INot required for level I1.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 IIINo additional requirements for level III
1.03.5 Backup key has tamper-evident sealNot required for level INot required for level I1.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 IIINo additional requirements for level III
1.03.6 Backup key is encryptedNot required for level INot required for level INot required for level IINot required for level II1.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.03.6 Backup key is encryptedNot required for level INot required for level INot required for level IINot required for level II1.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.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.
CCSS Matrix Version 8.1