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. Make sure to read our other in-depth articles on the CCSS Aspects:
CCSS Aspect 1.04 Key Usage
In this article we will explore how an auditor could interpret the CCSS Aspect 1.04 Key Usage.
Aspect 1.04 Key Usage addresses the security of keys when in use. The Aspects objective defined within the CCSS is provided below.
“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.”
Aspects Controls
There are eight controls to this Aspect. In this article we will address each control.
- 1.04.1 Key access requires user/pass/nth factor
- 1.04.2 Keys are only used in a trusted environment
- 1.04.3 Operator reference checks
- 1.04.4 Operator ID checks
- 1.04.5 Operator background checks
- 1.04.6 Spends are verified before signing
- 1.04.7 No two keys are used on one device
- 1.04.8 DRBG Compliance
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 requirements rationale provides guidance on what CCSS deems as “other factors“:
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.
NIST defines an Authentication Factor as:
“Authentication using two or more factors to achieve authentication. Factors include: (i) something you know (e.g., password/personal identification number [PIN]); (ii) something you have (e.g., cryptographic identification device, token); or (iii) something you are (e.g., biometric).“
The CCSSA should ensure that each user account with access to the primary key/seed is required to provide at least two factors of authentication. The CCSSA should:
- Review policy, standards and procedures to ensure that an identifier and two factors (or more) of authentication are required to access the primary key/seed for all user accounts with access.
- Inspect all authentication and authorization systems that control access to the primary key/seed to ensure the configuration enforces multi-factor authentication for each user account with access to the primary key/seed.
- Observe a sample of personnel provide their identifier and two factors of authentication to the authentication and authorization systems in order to access the primary key/seed. The observation should include successful and failed authentication attempts (failed attempts should prove the two factors of authentication are required).
The CCSS Glossary defines the “Trusted Environment” as follows:
For the purposes of this specification, trusted environment is defined as the physical location, hardware and software used in any private key related operations.
The CCSS “Trusted Environment” can be thought of as the “in-scope environment” or the “boundaries of audit”. The CCSS “Trusted Environment” represents the people, process and technology that transmit, process and store a cryptocurrency private key or can impact the security of the private key. I have provided an example below of people, process and technology components that would be considered part of the CCSS “Trusted Environment” and therefore are “in-scope” for the CCSS audit.
People – any personnel who have access to a private key such as key operators and key custodians. Also, any personnel who could impact the security of a private key such as a system administrator who has administrative privileges on the HSM that provides the key management functions as well as storing the private key.
Process – policy, standards and procedures which address any cryptocurrency and/or private key operations and functions such as a “key management policy”. Additionally, records such as a key asset inventory, key custodian acknowledgement forms, a vulnerability scan report for in-scope systems are also “in-scope” for the audit.
Technology – any device or system which transmits, processes or stores a private key such as a HSM appliance, a hardware/software/web browser extension wallet, authentication and authorization systems, a safe that stores written key data.
The CCSSA must ensure that all people, process and technology that are involved in or could impact the security of a private key being transmitted, processed or stored, are included within the CCSS “Trusted Environment” definition. A private key must not be outside of the CCSS “Trusted Environment” even if, for example, the private key is non-operational (e.g. has been retired).
NOTE: Defining the CCSS “Trusted Environment” is the responsibility of the assessed entity. The assessed entity provides the CCSSA with a list of the people, process and technology components that are within the CCSS “Trusted Environment”. The CCSSA’s responsibility is to review the assessed entities defined CCSS “Trusted Environment” and ensure that the CCSS “Trusted Environment” is valid and meets the CCSS requirements.
The CCSS Glossary defines a “Key Holder” as:
“A (key/seed) holder is a person, organization, system, or service that (for the purposes of this specification) makes direct use of a cryptographic key or seed (or shard of a key or seed as might be the case.) A key holder is also called an actor.”
The CCSSA should ensure that the requirement for all “key/seed holders” must have a reference check before having access to a private key or seed phrase, is documented at a policy level. Procedures must be documented that define the process that is undertaken to have a reference check performed and the results of the reference check acknowledged and recorded.
The CCSSA should request a list of all personnel who currently have access to a cryptocurrency key/seed phrase and also personnel who could impact the security of the private key/seed phrase. For each person in the list the CCSSA must request evidence from the assessed entity that a reference check have been performed and that the results of that reference check has been recorded and processed.
Further, the CCSSA should seek assurance regarding the organization which conducted the reference check that the organization is qualified to conduct reference checks and is independent of the assessed entity.
The CCSS glossary provides the following definition for “identity verification“:
“Identity verification is a tiered process by which an organization or system attempts to confirm the authenticity of an actor’s claim to be a given individual or organization.
Typical methods of identity verification for individuals include:
- one or more forms of government-issued identification (driver’s license, passport, etc.)
- one or more proofs of residency at the individual’s home (utility bills, bank statements, etc.)
- successful completion of challenge questions through a reputable identity-verification service operating in the individual’s country of residence (e.g. Equifax)
In cases of an organization, the supporting records can include:
- Employer Identification Number (“EIN”), Business Number, or similar identifier based on jurisdiction
- D-U-N-S Number
- Articles of Incorporation
In either case, enough supporting documentation should be provided and verified to support the actor’s identity claim.”
The CCSSA should ensure that the requirement for all “key/seed holders” must have undergone an identity verification process before having access to a private key or seed phrase, is documented at a policy level. Procedures must be documented that define the process that is undertaken to perform an identity verification check and the results of the identity verification check acknowledged and recorded.
The CCSSA should request a list of all personnel who currently have assess to a cryptocurrency key/seed phrase and also personnel who could impact the security of the private key/seed phrase. For each person in the list the CCSSA must request evidence from the assessed entity that an identity verification check has been performed and that the results of that identity verification check have been acknowledged and recorded.
The CCSSA should review the policy, standards and procedures to ensure that not more than one key for a multi-signature wallet is to reside on a device.
The CCSSA should request the key inventory that records all of the assessed entities keys used for cryptocurrency functions. The key inventory should list all the locations of each key. The CCSSA should review the key inventory and ensure that not more than one key is located on a device for a particular multi-signature wallet.
The CCSSA should also inspect each location used to store keys used for a multi-signature wallet and ensure only one key resides on the device.
There is currently no definition of “k” value provided by the CCSS committee. The author has made an assumption that the CCSS committee is referring to the random integer which is generated during the signing process as defined within RFC 6979 Section: 3.2. Generation of k.
Additionally, NIST FIPS PUB 186-4 Digital Signature Standard Section: 6.3 Secret Number Generation provides the requirements for the generation of a “k” value.
Based on our research the CCSSA should ensure that the mechanism performing digital signatures complies with RFC 6979’s “k” generation requirements and/or NIST FIPS PUB 186-4 Digital Signature Standard – Section: 6.3 Secret Number Generation requirements.
The CCSSA should ensure that the assessed entities policy, standards and procedures require the use of a RFC 6979 and/or NIST FIPS PUB 186-4 Digital Signature Standard – Section: 6.3 Secret Number Generation compliant digital signature mechanism.
The CCSSA should inspect the configuration of the digital signing mechanism to ensure the mechanism complies with RFC 6979’s “k” generation requirements and/or NIST FIPS PUB 186-4 Digital Signature Standard – Section: 6.3 Secret Number Generation requirements.
Level 2 Compliance
The CCSS glossary defines “Approved Communication Channels” as:
“A communication channel that provides high confidence of the identities of the communicating parties. This could be a voice call where the sound of their known voice is verified, a digitally-signed message (using strong encryption such as PGP/GPG or S/MIME), or a combination of multiple separate channels that are unlikely to be simultaneously compromised, such as an email + an SMS message + an instant message via Slack.”
The CCSSA should ensure that the assessed entities policy requires the use of “Approved Communication Channels” when conducting functions or processes using cryptocurrency assets. The policy and/or standards should list the assessed entities approved communication channels.
The assessed entities procedures should cover the official locations of where to download the approved communication software, how to install and configure the approved communication software and the process for conducing verification of fund destinations and amounts before conducting the transaction.
The CCSSA should interview a sample of personnel who have conducted cryptocurrency transactions for the assessed entity to ensure they understand the required processes for fund destination and amount verification.
The CCSSA should review change requests or other records which authorized the cryptocurrency transaction to ensure verification of the fund destinations and amounts to transfer was undertaken and recorded.
Level 3 Compliance
This requirement has the same objective as requirement 1.04.1.1 except that three other factors are required.
The CCSSA should ensure that the requirement for all “key/seed holders” must have a background check before having access to a private key or seed phrase, is documented at a policy level. Procedures must be documented that define the process that is undertaken to have a background check performed and the results of the background check acknowledged and recorded.
The CCSSA should request a list of all personnel who currently have access to a cryptocurrency key/seed phrase and also personnel who could impact the security of the private key/seed phrase. For each person in the list the CCSSA must request evidence from the assessed entity that a background check have been performed and that the results of that background check has been recorded.
The CCSSA should seek assurance regarding the organization which conducted the background check that the organization is qualified to conduct background checks and is independent of the assessed entity.
Summary
In this article we reviewed Aspect 1.04 Key Usage. The Aspect covers the usage of keys/seeds including who should have access to the keys/seeds as well as the location of keys/seeds. The Aspect also requires reference and background checks and identify verification on personnel who have access to private keys/seeds
