CryptoCurrency Security Standard (CCSS) - Key Usage Requirements
[Article Updated August 2023 for CCSS Version 8.1]?
Marc Krisjanous is one of the first CCSS Auditors, assisted C4 in developing 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 of 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.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.?
CCSS Levels
CCSS provides three levels of compliance - Level 1 being the base level of implementing CCSS requirements and 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.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.
The requirements rationale guides what CCSS deems as "other factors":
Multi-factor authentication restricts access and thus increases security. Examples of additional authentication factors 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 that 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)." #1
The CCSSA should ensure that each user account with access to the primary key/seed is required to provide at least two authentication factors. The CCSSA should:
Requirement: 1.04.2.1 All keys/seeds are only used in trusted environments.
The CCSS Glossary defines the "Trusted Environment" as:
For this specification, a trusted environment is defined as the physical location, hardware and software used in any private key-related operations.
I have already authored an article on defining the CCSS "Trusted Environment" here. However, I will provide a summary in this article. 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 with 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 that 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, and vulnerability scan reports for in scope systems are also "in-scope" for the audit.
Technology - any device or system that transmits, processes or stores a private key, such as an HSM appliance, a hardware/software/web browser extension wallet, authentication and authorization systems, or a safe that stores written key data.
The CCSSA must ensure that all people, processes and technology involved in or could impact the security of a private key being transmitted, processed or stored are included in 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, processes and technology components 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.
Requirement: 1.04.3.1 All key/seed holders have had their references checked before being trusted to hold one of the organization’s keys/seeds.
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 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 with access to a cryptocurrency key/seed phrase and those 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 has been performed and that the results of that reference check have been recorded and processed.
Also, the CCSSA should seek assurance regarding the organization that conducted the reference check and that the organization is qualified to conduct reference checks and is independent of the assessed entity.
Requirement: 1.04.4.1 All key/seed holders (individuals and organizations) have undergone identity verification to ensure they are who they say they are.
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:
领英推荐
In cases of an organization, the supporting records can include:
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 that 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 undertaken to perform an identity verification check, and the results of the verification check must be acknowledged and recorded.
The CCSSA should request a list of all personnel with access to a cryptocurrency key/seed phrase and those who could impact the security of the private key/seed phrase. For each person on 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.
Requirement: 1.04.7.1 No two master keys/seeds of the same multi-signature wallet are ever present on the same device.
The CCSSA should review the policy, standards and procedures to ensure that not more than one key for a multi-signature wallet resides on a device.
The CCSSA should request the key inventory that records all assessed entity 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 to store keys used for a multi-signature wallet and ensure that only one key resides on the device.
Requirement: 1.04.8.1 Digital signatures must use a ‘k’ value that is never repeated.
There is currently no definition of "k" value provided by the CCSS committee. The author has assumed that the CCSS committee is referring to the random integer that is generated during the signing process as defined within RFC 6979 #2 Section: 3.2. Generation of k.
NIST FIPS PUB 186-4 Digital Signature Standard #3 - Section: 6.3 Secret Number Generation provides the requirements for generating 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 entity's policy, standards and procedures require using 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
Requirement: 1.04.6.1 Verification of fund destinations and amounts is performed via Approved Communication Channels prior to key/seed use.
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 entity policy requires "Approved Communication Channels" when conducting functions or processes using cryptocurrency assets. The policy and/or standards should list the assessed entity's approved communication channels.
The assessed entity's 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 conducting 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 that authorized the cryptocurrency transaction to ensure verification of the fund destinations and amounts to transfer was undertaken and recorded.
Level 3 Compliance
Requirement: 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.
This requirement has the same objective as requirement 1.04.1.1 except that three other factors are required.
Requirement: 1.04.5.1 All individual key/seed holders have had background checks performed by law enforcement personnel or investigative firms.
The CCSSA should ensure that the requirement for all "key/seed holders" to have a background check before accessing a private key or seed phrase is documented at a policy level. Procedures must be documented that define the process 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 with access to a cryptocurrency key/seed phrase and those 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 has been performed and that the results of that background check have 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