Article last updated in July 2022 for CCSS Version 8.0.
Marc Krisjanous is one of the first CCSS Auditors and assisted C4 in the development of their auditors program.
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. We will be publishing a series of articles going into depth on the CCSS aspects over the coming days.
CCSS Aspect 1.01 Key / Seed Generation
In this article we will explore how an auditor could interpret the CCSS Aspect 1.01 Key/Seed Generation.
Aspect 1.01 Key/Seed Generation addresses the creation of keys and seeds including the confidentially of key and seed creation and the systems which generate random data. The Aspect’s objective defined within the CCSS is provided below.
“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.“
Aspect Controls
There are four controls to this Aspect. In this article we will address each control.
- 1.01.1 Operator-created Key / Seed
- 1.01.2 Creation methodology is validated
- 1.01.3 DRBG Compliance
- 1.01.4 Entropy Pool
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
The CCSS glossary provides the following definition for an “actor”:
“A person, organization, system, or service that (for the purposes of this specification) makes direct use of a cryptographic key or seed is an actor in the context of that key or seed.“
Therefore, the actor definition encompasses an organizations personnel and all branches and locations of an organization. The definition, by our interpretation, allows for a person within the organization to create a key/seed on behalf of another person within the same organization. Note: this is an important consideration for the CCSSA as the assessed entity may have a process that allows for personnel within the assessed entities organization to create a key/seed on behalf on another person and therefore must ensure that the person who created the key/seed destroys all key data in their procession after transferring the key/seed to the person who will use the key/seed. The CCSSA must consider the confidentially and integrity of the key/seed during this process.
The requirements rationale provides guidance for the CCSSA:
“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.“
The rationale allows for the transferring of a key/seed from one actor to another actor as part of the initial configuration of an automated signing agent. The actor definition therefore allows for one organization to create a key/seed and transfer the key/seed to another organization (actor) if the purpose of the key/seed is to be used solely by an automated signing agent. We assume that an “automated signing agent” does not include personnel having direct access to the key/seed but that personnel can only initiate the signing process via programmatic means – e.g. an application interface. The CCSSA must consider the confidentially and integrity of the key/seed during this process.
The CCSSA should review all policy, standards and procedures related to this process and ensure that the confidentially and integrity of the key/seed is addressed. Transferring a private key/seed from one organization to another, as allowed for by the “actor” definition is, in our opinion, results in high risk for the confidentially and integrity of the key/seed.
The CCSSA should interview a sample of personnel who are involved with the generation of a key/seed to ensure the policy, standards and procedures are adhered to.
The CCSSA should inspect the configuration of systems involved with the generation and use of a key/seed to ensure the systems are configured to be compliant with applicable CCSS requirements.
The requirement comprises of the following sub-requirements:
- 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.
- [The key/seed] securely deleted using CCSS-compliant data sanitization techniques to protect the confidentiality of the key/seed
We will now review each sub-requirement.
Sub-requirement 1: The administrator of that system generate the key/seed on a suitable offline system with sufficient entropy.
The sub-requirement states that the key/seed must be generated on a “suitable offline system”. The CCSS glossary does not provide a definition of “offline system” but one can deduce that an “offline system” is a system which is not connected to a computer network. This could equate to the system’s network interfaces such as ethernet and wifi ports being disabled or not connected to a computer network via an Ethernet cable for example. Another approach to the term is that the system is “air gapped”. NIST defines “air gap” as:
“An interface between two systems at which (a) they are not connected physically and (b) any logical connection is not automated (i.e., data is transferred through the interface only manually, under human control).”
Based on the definitions we provided and our assumptions as to what a “suitable offline system” is, the CCSSA should ensure that the system which generates a key/seed should not be connected to a computer network at the time of the key/seed generation process. We cannot, based on the requirement definition, expect that the system is air-gapped as our assumption would be that an air gapped device is never connected to a computer network. Where the “offline system” term in CCSS, does not specifically demand or imply the system is permanently removed from a computer network.
The CCSSA should review policy, standards and procedures to ensure that a system which generates a key/seed is taken offline from the computer network(s) before the start of the key/seed generation.
The CCSSA should interview a sample of personnel who are responsible for generating keys/seeds and ensure that the system is taken offline.
If possible, the CCSSA should observe a system which generates a key/seed being taken offline.
The sub-requirement also requires that the system which generates a key/seed provides “sufficient entropy“. The CCSS glossary defines “entropy” as:
“Randomness, usually collected from hardware, environmental factors (time of execution), or external sources (user-input).“
The CCSSA should consult the NIST 800-90B – Recommendation for the Entropy Sources Used for Random Bit Generation to ensure that the entropy source(s) used by the assessed entity are “sufficient” based on NIST recommendations.
Sub-requirement 2: Have this key/seed transferred securely onto the target device.
The sub-requirement requires that the key/seed is “securely transferred” to the “target device“. The CCSS Committee at the time of this articles publishing [August 2022] has not provided any guidance for secure transport of keys/seeds. However, NIST SP 800-57 Part 1 Rev. 5 – Recommendation for Key Management: Part 1 – General – Section 6.2.1 Protection Mechanisms for Key Information in Transit provides detailed recommendations for the secure transport of keys/seeds. The CCSSA should use the recommendations provided to ensure the assessed entity is securely transporting keys/seeds.
Sub-requirement 3: [The key/seed] securely deleted using CCSS-compliant data sanitization techniques to protect the confidentiality of the key/seed
CCSS requirement 2.02.1.2 identifies NIST 800-88 – Guidelines for Media Sanitization as a recommended source of secure data sanitization techniques. The CCSSA should ensure that the assessed entity applies industry recognized standards such as NIST 800-88 to their data sanitization processes.
The CCSSA should review policy, standards and procedures to ensure data sanitization techniques conform to industry best practices for data sanitization techniques.
The CCSSA should review a sample of change request records for data sanitization of media conducted within the assessed period to ensure policy, standards and procedures have been adhered to.
The CCSSA should interview personnel who have conducted data sanitization processes within the assessed period to ensure policy, standards and procedures have been followed.
The CCSSA should consult the NIST 800-90B – Recommendation for the Entropy Sources Used for Random Bit Generation to ensure that the entropy source(s) used by the assessed entity are “sufficient” based on NIST recommendations.
Evidence gathering recommendations have already been covered in our review of requirement 1.01.1.2 above.
Level 2 Compliance
The CCSS Committee at the time of this articles publishing [August 2022] has not provided any guidance if this requirement applies to in-house developed software which generates keys/seeds and/or the use of third-party libraries to assist in generating keys used within the in-house developed software or the requirement only applies to “off-the-shelf” software.
The CCSSA will have to decide if in-house developed software must be signed by the assessed entities own certificate. The CCSSA should enquire from the assessed entity if a risk assessment has been undertaken as to the risk of in-house developed software that generates keys/seeds being compromised and if so, if signing of the software has been considered as part of the risk treatment process.
The CCSSA should consider the use of checksums generated for software or other auditable means of ensuring that the software has not been modified without authorization if the assessed entity is not signing the software.
It is our opinion that any “off-the-shelf” software that generates keys must be signed by the software creator and validated by the assessed entity before each use as part of the key management processes.
The CCSSA should review policy, standards and procedures to ensure that “off-the-shelf” software is signed by the software creator with a valid certificate and that the software is validated before each execution process by the assessed entity. If the software has been developed in-house and the software is not signed then the CCSSA should ensure other auditable means of ensuring software has not been modified without authorization such as checksums has been implemented.
The requirement provides two sub-requirements for the validating the key/seed methodology:
- 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. DRGBs).
The CCSSA should review policy, standards and procedures to ensure that the software generating keys/seeds does not implement restrictions that cause the security of the key/seed generation process to be impacted. Further, that the software configurations do not allow for transmission of key/seeds to another actor without express permission from an authorized user.
The CCSSA should inspect any implementation of a physical random number generator to ensure determinism is not present. We recommend this article for an interesting implementation of physically based source of entropy.
To assist the CCSSA in the review we recommend reviewing NIST SP 800-90B – Recommendation for the Entropy Sources Used for Random Bit Generation
Level 3 Compliance
The CCSSA should review policy, standards and procedures to ensure that either a DRBG with at least two separate cryptographically secure sources of entropy which have been combined in a cryptographically secure manner or a TRNG is used for the generation of a key/seed.
To assist the CCSSA in the review we recommend reviewing NIST SP 800-90B – Recommendation for the Entropy Sources Used for Random Bit Generation.
The CCSSA should inspect the configuration of the system which generates keys/seeds to ensure that the configuration meets applicable CCSS requirements.
The CCSSA should review the policy, standards and procedures addressing the generation of keys/seeds. The CCSSA should ensure that there is clear separation of duties applied to the processes.
Summary
In this article we reviewed the requirements for Aspect 1.01 Key/Seed Generation. We recommended the use of NIST Recommendations to provide guidance for the CCSSA on the systems which generate keys/seeds. We do also recommend further research and study on the subject on key/seed generation including MPC.
