Mapping Hong Kong VATP Key Management Requirements to CCSS

The Hong Kong SFC’s Virtual Asset Trading Platform Operators Licensing regime provides comprehensive infrastructure requirements for a Platform Operator. In this article, we will map the VATP’s key management requirements (Part 10.8) to the Cryptocurrency Security Standard (CCSS) to highlight how CCSS can provide additional assurance to the regulators and the external auditors that the entity's key management processes are robust and secure.

Introduction to CCSS

The Cryptocurrency Security Standard (CCSS) is an information security standard focused on systems providing cryptocurrency functions. CCSS requirements focus on key management, wallet management, access management, user management, incident response management, log management, and third-party security assurance - all tailored to the unique properties of cryptocurrency systems.

CCSS is not a baseline information security standard such as ISO27001 and PCI DSS, which focuses on the absolute basics of information security, such as patch management, vulnerability management, change management, deployment management, and time management. Nor can CCSS be compared to a SOC2 Type1/2 audit, as a CCSS audit goes far more into the technical details of the information systems and information security controls than a SOC2 audit requires.

CCSS complements the baseline information security controls by adding additional requirements focused solely on the people, processes and technology components that provide the cryptocurrency functions of the information system and addressing the unique properties of cryptocurrency systems such as wallets, multi-sig/MPC/single-sig, blockchain design.

The CCSS audit process is rigorous and in-depth. Evidence-gathering techniques required are interviews, inspection, observation, and documentation review covering all in-scope people, process and technology components.

Mapping VATP Key Management Requirements to CCSS

In this section, we will break down the VATP key management requirements, which can be found in section 10.8 of the Hong Kong SFC’s Guidelines for Virtual Asset Trading Platform Operators (June 2023) document and map each requirement and sub-requirement to a specific CCSS requirement(s).

We hope the reader is able to see that for every SFC VATP key management requirement, there is a corresponding CCSS requirement(s).

Platform Operator Guidelines: Part X - Custody of Client Assets

We will provide the VATP requirement using the LinkedIn quote format and, directly underneath, provide the applicable CCSS requirement(s).

Please note: LinkedIn only provides the most basic formatting tools; unfortunately, table formatting is not one of them. We have attempted to provide a style of formatting in this article that is easily read. However, we have provided a table-based version of the mappings here (PDF).

Section 10.8

A Platform Operator should establish and implement strong internal controls and governance procedures for private key management to ensure all cryptographic seeds and private keys are securely generated, stored and backed up. The Platform Operator should ensure that the Associated Entity establishes and implements the same controls and procedures. These will include the following:

(a) The generated seeds and private keys must be sufficiently resistant to speculation or collusion. The seeds and private keys should be generated in accordance with applicable international security standards and industry best practices so as to ensure that the seeds (where Hierarchical Deterministic Wallets, or similar processes, are used) or private keys (if seeds are not used) are generated in a non-deterministic manner which ensures randomness and thus are not reproducible. Where practicable, seeds and private keys should be generated offline and kept in a secure environment, such as a HSM, with appropriate certification for the lifetime of the seeds or private keys.

There are several sub-requirements in requirement (a), so we will break down each below.

The generated seeds and private keys must be sufficiently resistant to speculation or collusion.

CCSS Applicable Requirement(s)

CCSS requires the use of mechanisms that generate strong entropy. For example, the seed or key must either be generated with a 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 or 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.

1.01 Key/Seed Generation Aspect - requirements: 1.01.2.1, 1.01.2.2, 1.01.3.1, 1.01.3.2, 1.01.4.1

The seeds and private keys should be generated in accordance with applicable international security standards and industry best practices so as to ensure that the seeds (where Hierarchical Deterministic Wallets, or similar processes, are used) or private keys (if seeds are not used) are generated in a non-deterministic manner which ensures randomness and thus are not reproducible.

CCSS Applicable Requirement(s)

CCSS states NIST SP 800-90A conformance and industry-standard statistical tests for randomness, such as DIEHARD, Crypt-X, or NIST STS.

The entity responsible for the information system must also consider other relevant industry-recognized standards that the information system must adopt. The CCSSA, during the CCSS audit, must also ensure that relevant standards have been applied to the information system based on its functions.

1.01 Key/Seed Generation Aspect - all requirements

Where practicable, seeds and private keys should be generated offline.

CCSS Applicable Requirement(s)

Requirement 1.01.1.2 specifically requires a suitable offline system with sufficient entropy to generate a seed or key. The requirement addresses when an automated agent uses a seed or key.

1.01 Key/Seed Generation Aspect - requirement: 1.01.1.2

[...] and kept in a secure environment, such as a HSM, with appropriate certification for the lifetime of the seeds or private keys.

CCSS Applicable Requirement(s)

CCSS defines requirements that address the protection of a seed or key during generation, transmission, use, storage, and destruction.

CCSS defines the "Trusted Environment", which comprises the people, processes, and technology components that provide a secure environment where the seed and key are protected from authorized access and use. The CCSSA, as part of the audit process, must ensure that the Trusted Environment is correctly defined and that all seeds and keys are within the Trusted Environment.

CCSS provides requirements for ensuring personnel with access to a key or seed are given the least possible privileges to perform their role and have been vetted before access is granted to a seed or key.

1.03 Key Storage Aspect - requirement: 1.03.1.1

1.04 Key Usage Aspect - requirements: 1.04.1.1, 1.04.1.2, 1.04.2.1, 1.04.3.1 (covers the people component), 1.04.4.1 (covers the people component), 1.04.5.1 (covers the people component), 1.04.7.1, 1.04.8.1

(b) Detailed specifications for how access to cryptographic devices or applications is to be authorised and validated, covering key generation, distribution, use, storage and destruction, as well as the immediate revocation of a signatory’s access as required. Where practicable, multi-factor authentication is used to authenticate authorised personnel for access to applications governing the use of private keys.

There are several sub-requirements in requirement (b), so we will break down each below.

Detailed specifications for how access to cryptographic devices or applications is to be authorised and validated, covering key generation, distribution, use, storage and destruction.

CCSS Applicable Requirement(s)

CCSS requires documented policies and procedures starting from seed or key generation, which includes requiring "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." to destruction policies and procedures.

Documented access management policies and procedures, not only by systems but also by personnel, are required.

The CCSSA, during the CCSS audit, must ensure that there are sufficiently detailed policies and procedures in place, known to required personnel and used by personnel for all phases of a seed or key's life cycle.

CCSS provides requirements for ensuring personnel with access to a key or seed are given the least possible privileges to perform their role and have been vetted before access is granted to a seed or key.

1.01 Key/Seed Generation Aspect - requirement: 1.01.3.2

1.02 Wallet Creation Aspect - requirement: 1.02.5.1

1.04 Key Usage Aspect - requirements: 1.04.1.1, 1.04.1.2

1.06.1 Grant/Revoke Procedures/Checklist Aspect - requirements: 1.06.1.1, 1.06.1.2, 1.06.2.1, 1.06.3.1

[...] as well as the immediate revocation of a signatory’s access as required.

CCSS Applicable Requirement(s)

CCSS addresses this requirement in the 1.06.1 Grant/Revoke Procedures/Checklist Aspect, which requires documentation for all required tasks to be performed when a user does not require access to a seed or key. Audit logs must also be maintained, which record all tasks performed and the user who performed each task.

The CCSSA, during the CCSS audit, must ensure that the revocation of access to a seed or key is performed promptly, which can be immediately.

1.06.1 Grant/Revoke Procedures/Checklist Aspect - requirements: 1.06.1.1, 1.06.1.2, 1.06.2.1, 1.06.3.1

Where practicable, multi-factor authentication is used to authenticate authorised personnel for access to applications governing the use of private keys.

CCSS Applicable Requirement(s)

CCSS Level 1 requires access to a seed or key, requiring at least two authentication factors. CCSS Level 3 requires three factors of authentication.

Note: CCSS does not include an account identifier as an authentication factor e.g. user ID.

1.04 Key Usage Aspect - requirements: 1.04.1.1, 1.04.1.2

(c) Access to seeds and private keys relating to client virtual assets is tightly restricted amongst authorised personnel who have undergone appropriate screening and training, no single person has possession of information on or access to the entirety of the seeds, private keys or backup passphrases, and controls are implemented to mitigate the risk of collusion amongst authorised personnel.

There are several sub-requirements in requirement (c), so we will break down each below.

Access to seeds and private keys relating to client virtual assets is tightly restricted amongst authorised personnel who have undergone appropriate screening and training.

CCSS Applicable Requirement(s)

CCSS addresses this requirement in the 1.04 Key Usage Aspect, which requires background checks, ID checks, and reference checks on personnel with access to a seed or key.

1.04 Key Usage Aspect - requirements: 1.04.2.1, 1.04.3.1, 1.04.4.1, 1.04.5.1

no single person has possession of information on or access to the entirety of the seeds, private keys or backup passphrases, private keys or backup passphrases [...]

CCSS Applicable Requirement(s)

Currently, no CCSS requirement directly addresses this VATP requirement. However, the CCSSA, during the CCSS audit, must ensure that a seed or key is protected from unauthorized access, and the ability to sign a transaction without authorization cannot be done.

1.02 Wallet Creation Aspect - requirement: 1.02.3.1 - not definitive requirement but will reduce risk

1.03 Key Storage Aspect - requirement: 1.03.4.1 - not definitive requirement but will reduce risk

1.04 Key Usage Aspect - requirement: 1.04.7.1 - not definitive requirement but will reduce risk

[...] and controls are implemented to mitigate the risk of collusion amongst authorised personnel.

CCSS Applicable Requirement(s)

CCSS addresses this requirement in several CCSS Aspects:

1. 1.02 Wallet Creation Aspect - requirement 1.02.3.1: requires a wallet's signing keys to be separated from each other across multiple locations.

2. 1.03 Key Storage Aspect - requirement 1.03.4.1: all backups containing a seed or key must be protected from unauthorized access.

3. 1.04 Key Usage Aspect contains several requirements to ensure personnel with access to a seed or key are vetted before gaining access.

1.02 Wallet Creation Aspect - requirement: 1.02.3.1 - not definitive requirement but will reduce risk

1.03 Key Storage Aspect - requirement: 1.03.4.1 - not definitive requirement but will reduce risk

1.04 Key Usage Aspect - requirements: 1.04.2.1, 1.04.3.1, 1.04.4.1, 1.04.5.1, 1.04.7.1 - not definitive requirement but will reduce risk

(d) Distributed backups of seeds or private keys are kept so as to mitigate any single point of failure. The backups need to be distributed in a manner such that an event affecting the primary location of the seeds or private keys does not affect the backups. The backups should be stored in a protected form on external media (preferably HSM with appropriate certification). Distributed backups should be stored in a manner that ensures seeds or private keys cannot be re-generated based solely on the backups stored in the same physical location. Access control to the backups needs to be as stringent as access control to the original seeds or private keys.

There are several sub-requirements in requirement (d), so we will break down each below.

Distributed backups of seeds or private keys are kept so as to mitigate any single point of failure.

CCSS Applicable Requirement(s)

CCSS addresses this requirement in 1.03 Key Storage Aspect - requirement 1.03.3.2 which requires that a seed or key must be stored in a different location from the primary seed or key.

1.03 Key Storage Aspect - requirement: 1.03.3.2

The backups need to be distributed in a manner such that an event affecting the primary location of the seeds or private keys does not affect the backups.

CCSS Applicable Requirement(s)

CCSS addresses this requirement in 1.03 Key Storage Aspect - requirement 1.03.3.2 requires storing a seed or key in a different location from the primary seed or key.

1.03 Key Storage Aspect - requirement: 1.03.3.2

The backups should be stored in a protected form on external media (preferably HSM with appropriate certification)

CCSS Applicable Requirement(s)

CCSS addresses this requirement in 1.03 Key Storage Aspect with several requirements covering the protection of backups from environmental disasters, unauthorized access, and encryption of the backups at rest.

1.03 Key Storage Aspect - requirements: 1.03.3.1, 1.03.3.3, 1.03.4.1, 1.03.5.1, 1.03.6.1

Distributed backups should be stored in a manner that ensures seeds or private keys cannot be re-generated based solely on the backups stored in the same physical location

CCSS Applicable Requirement(s)

Our interpretation of this requirement is that the backups could be used to regenerate production seeds and keys. If our assumption is correct, then CCSS requirement "1.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." addresses this requirement.

All backups of a seed or key must be encrypted at rest with strong encryption. The CCSSA auditing the system must ensure that the key used to encrypt the backup is not stored in the exact location as the backup or that the encryption key (Data-Encrypting-Key "DEK") is encrypted with another key (Key-Encrypting-Key "KEK") that is not stored in the exact location as the backup.

1.03 Key Storage Aspect - requirement: 1.03.6.1

Access control to the backups needs to be as stringent as access control to the original seeds or private keys.

CCSS Applicable Requirement(s)

CCSS addresses this requirement in 1.03 Key Storage Aspect by implementing controls to stop unauthorized access. The use of tamper-evident mechanisms is also required for the backups.

1.03 Key Storage Aspect - requirements: 1.03.4.1, 1.03.5.1

Summary

In summary, our exercise of mapping SFC VATP key management requirements to CCSS highlights that CCSS can address the SFC VATP key management requirements and, in doing so, provide a high level of assurance to the SFC and third-party auditors that the CCSS-certified system has implemented effective and secure key management practises.

**** Free CCSS Implementation Guide! ****

Marc also co-authored the CCSS Implementation Guide for a Full System - click here to download - it's free!