Cryptocurrency Security Standard Compliance Guide

The Cryptocurrency Security Standard (CCSS) focuses on the information security of systems that use cryptocurrencies. Recently we covered the basics of CCSS and who needs it. Here’s what you can expect in this article:

• CCSS components and requirements
• CCSS compliance levels
• Why CCSS audits and what is a CCSSA?
• Who manages CCSS?

The Cryptocurrency Security Standard is at version 8. However, there are no previous versions. For example, there is no version 2, 3, 4, 5, 6, or 7. The CCSS Committee went from an initial “draft” version published in 2015 to version 8 as a nod to how long the standard has been around.

What are the CCSS Aspects and Requirements?

CCSS provides two categories of controls: Cryptographic Asset Management and Operations. Each category then breaks down further into 10 Aspects which can be thought of in terms of high-level requirements. Then, each Aspect contains several requirements. The 10 Aspects and their associated objective is documented below.

1.01 Key/Seed Generation

The key/seed generation component 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: confidentiality and unpredictable numbers.

Confidentiality

Confidentiality is required to ensure that the newly created keys or seeds are not read/copied by an unintended party.

Unpredictable numbers

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 provides assurance that the keys and/or seeds are created in a confidential and un-guessable manner.

1.02 Wallet Creation

This component of the CCSS covers the creation of wallets or addresses that can receive digital assets. Wallets are created using key signing methodologies requiring 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.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.04 Key Usage

Key usage 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 the 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.

Various risks are present when using keys that can lead to the loss of funds, including:

• Dirty signature vulnerabilities (i.e., re-used ‘R’ values)
• The opportunity for malware to copy or modify keys
• Malicious insiders who use their authorized access to send unauthorized transactions

1.05 Key Compromise Policy (KCP)

The key compromise policy component of CCSS 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 with 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

Key Compromise Protocols must be executed using Approved Communication Channels to ensure KCP messages are only sent/received by authenticated actors.

1.06 Keyholder Grant/Revoke Policies & Procedures

The keyholder grant/revoke policies & procedures part of the CCSS 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 concerning accessing its information, invoking privilege-restricted actions, and representing the organization to the public.

Improper management of the onboarding and offboarding of personnel introduces risks of privileged accounts remaining when staff departs and unrevoked keys that persist signing authority for certain transactions.

2.01 Security Tests/Audits

The security tests/audits cover third-party reviews of the security systems, technical controls, policies that protect the information system from all forms of risk and 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, are independent of the technical controls, and can be objective without risk of retaliation.

2.02 Data Sanitization Policy

The data sanitization policy covers removing cryptographic keys from digital media. Due to how 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.03 Proof of Reserve

With the proof of reserve aspect of the CCSS, the information system should hold the proof of control of all funds. There have been known cases where information systems that should be operating with a full reserve of user funds have been operating with a fraction of that reserve instead, leading to an inability of the system to cover simultaneous withdrawals by all users. These proofs of the reserve assure the public that all funds are available to the system, eliminating the risks of fund loss.

2.04 Audit Logs

Audit logs cover 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 a special 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.

CCSS Compliance Levels

What are the three levels of CCSS Compliance?

Level 1 CCSS Compliance

Level 1 covers the baseline level requirements provided by CCSS and should be considered the absolute minimum of security controls to implement to meet the objective of the requirement.

When reviewing recent breaches of crypto-related services, you can see that even with just implementing security controls for Level 1 CCSS compliance, many attacks would have failed or have dramatically reduced the impact of a breach.

For example, with Aspect 1.03 Key Storage at Level 1, key storage basics are addressed to protect key data at rest.

How many times have we read in media reports that a significant hack resulted in the theft of a cryptocurrency wallet’s private key(s) because they were stored in plain text?

Below are the CCSS Level 1 requirements for protecting key data at rest.

• 1.03.1.1 – Cryptographic keys and/or seeds must be stored with strong encryption when not in use
• 1.03.2.1 – A backup of the cryptographic key/seed must exist. The backup can take any form (e.g., paper, digital)
• 1.03.3.1 – The backup must be protected against environmental risks such as fire, flood, and other acts of God
• 1.03.4.1 – The backup must be protected by access controls that prevent unauthorized parties from accessing it

Level 2 CCSS Compliance

Level 2 offers a higher level of CCSS compliance by adding further rigor to the applicable security controls.

Considering Aspect 1.03 Key Storage at Level 2, further rigor is required. By requiring a backup of each production key needed to spend funds (requirement 1.03.2.2) and physical security controls such as physical separation of keys (requirement 1.03.3.2) and use of tamper-evident seals for physical copies of key data (requirement 1.03.5.1).

Level 3 CCSS Compliance

CCSS Level 3 adds even more rigor to the security controls. Aspect 1.03 Key Storage at Level 3 requires backups of keys must be encrypted at rest with strong encryption at least equal to the encryption strength used for production keys (requirement 1.03.6.1) and “Backups are resistant to electromagnetic pulses” – requirement 1.03.3.3.

How Do CCSS Audits Work?

When an assessed entity is audited for CCSS compliance, the auditor (a CCSSA) will review the entity’s compliance level for each aspect.

Each aspect has a set of requirements under the three compliance levels. The auditor may find that the assessed entity is at compliance level 3 for some aspects, and for other elements, the assessed entity is only at level 1.

NOTE: When writing this article, the CCSS Committee has not provided any guidance regarding the scaling or determination factors for calculating an entity’s overall compliance level. We can assume that if the assessed entity has met level 3 compliance requirements for all aspects, the overall compliance level will be CCSS Level 3. However, the “devil is in the detail” where the aspect compliance levels are different, and the need for guidance on deciding the overall compliance level is required from the CCSS Committee.

Is Anyone CCSS Compliant?

On inquiry, the CCSS Committee stated that no entity is CCSS compliant at any CCSS Level. It should also be noted that an entity cannot self-assess and state they are CCSS certified.

To gain CCSS certification, the entity must engage an independent CCSSA and undertake a CCSS audit with the CCSSA. Suppose the CCSSA deems the assessed entity to be compliant. In that case, the CCSSA will send the Summary Report on Compliance (SROC) and Appendix 1 to C4, who will issue the assessed entity a Certificate of Compliance (COC).

CCSS Is Not A Base-line Information Security Standard

The CCSS Committee states that CCSS does not replace baseline information security management system standards such as PCI DSS and ISO 27001 but adds additional cryptocurrency-focused information security requirements for systems that use cryptocurrencies.

Who Maintains the CCSS?

The CCSS is maintained by the CCSS Steering Committee, which has as its members highly regarded subject matter experts in the field of cryptocurrency.

How Does an Organisation Become CCSS Compliant?

An entity seeking to become CCSS compliant must engage an external CCSS-certified auditor – a CCSSA. The entire audit process flow is documented in the CCSS Auditors Guide, here.

Of particular note to any organization seeking CCSS certification is that a listing fee is required by C4. The listing fee is covered in the CCSS Auditors Guide. However, a brief description is provided here. Any entity that accepts cryptocurrency and is not responsible for any other entity’s cryptocurrency is considered a merchant and pays an annual fee of USD 1000.00.

If the assessed entity (e.g., an Exchange or provides custody services) is responsible for another entity’s cryptocurrency or private keys, then the assessed entity is deemed a Service Provider. The base fee for a service provider is USD 10,000.

If the service provider also benefits financially from their customer’s transactions, then the base fee changes from USD 10,000 to USD 15,000, and an additional fee is also required. This additional fee is scaled based on the total client assets custodied by the service provider.

Summary

The Cryptocurrency Security Standard (CCSS) is an important information security standard for any entity using cryptocurrency to certify against.

Suppose you review a sample of the hacks that have occurred in cryptocurrency. In that case, it is clear that even if the organization aligned to CCSS Level 1, most of the hacks would have been severely restricted in their impact or stopped altogether.

Mainstream adoption of cryptocurrency will only occur if the general public feels that information security is taken seriously by organizations offering products and services in this space.

Anyone would not accept their bank not comply with any information security standards or regulations, and never should they with the cryptocurrency sector.