• 1.01 Key / Seed Generation

    This aspect covers the generation of cryptographic keys and seeds that will be used within a cryptocurrency system. The secure creation of cryptographic keys and seeds requires two things to be secure: confidentiality and un-guessable numbers. Confidentiality is required to ensure that the newly created keys or seeds are not read/copied by an unintended party. Un-guessable numbers are required to ensure the newly created key cannot be guessed or determined by an unintended party. Each of the goals listed below provide assurance that the keys and/or seeds are created in a confidential and un-guessable manner.

    Aspect Components Include

    • 1.1.1 Operator-created Key / Seed
    • 1.1.2 Creation methodology is validated
    • 1.1.3 DRBG Compliance
    • 1.1.4 Entropy Pool

      • The cryptographic keys and seeds are created by the actor who will be using it. 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.

      • In cases where an automated agent will make use of a cryptographic key/seed, it is recommended that 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, and then securely deleted using CCSS-compliant data sanitization techniques to protect the confidentiality of the key/seed.

      • Notably, transferring a cryptographic secret for backup purposes does not violate the "Same Actor" requirement, however those secrets must be transmitted and stored in a strongly encrypted format.

      • The cryptographic keys and seeds are created on a system with sufficient entropy to ensure the keys are not created with any bias towards a reduced range of values, or other deterministic properties

      • The key or seed generation methodology is validated prior to use. Software that is used to generate seeds should be free from any features that restrict the generated seed to conform to deterministic values and features that store or transmit the generated seed to another actor, except where such features enhance the effective security of the software (e.g. DRBGs).

      • After software has been audited, a digital signature should be generated and published. The signature should be validated prior to each execution to ensure the software has not been altered since it passed its security audit.

      • In cases where keys or seeds are created without the use of software (e.g. dice, a deck of cards, or other non-digital source of entropy), the creation methodology should be validated to ensure determinism is not present (i.e. there are no weighted dice, each card in the deck is unique, etc.).

      • The key or seed is generated using a Deterministic 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 (e.g. SHA256[UnguessableFactor1 + UnguessableFactor2]). NIST SP 800-90A is a standard that ensures that deterministically-generated numbers follow a random distribution with respect to a deterministic seed. Thus, the ability to determine these random numbers is reducible to the ability to discover the DRBG’s seed.

      • The Dual_EC DRBG from NIST SP 800-90A has been demonstrated to be vulnerable and should not be used.

      • Optionally, instead of a NIST SP 800-90A compliant DRBG with a combination of two seeds as specified above, the key or seed may also be generated by 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.02 Wallet Creation

    This aspect covers the creation of wallets or addresses that can receive cryptocurrencies. Wallets are created using key signing methodologies that can require 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.

    Aspect Components Include

    • 1.2.1 Unique address per transaction
    • 1.2.2 Multiple keys for signing
    • 1.2.3 Redundant key for recovery
    • 1.2.4 Deterministic wallets
    • 1.2.5 Geographic distribution of keys
    • 1.2.6 Organizational distribution of keys

      • Systems that enforce new addresses for every transaction implicitly mitigate cases where a compromised wallet continue to receive funds from actors who are not informed about the compromise as was seen in the days following the BitStamp compromise of early 2015. Since the previously generated addresses will remain valid and there is no way to prevent users from (accidentally or otherwise) sending transactions to old addresses, an automated wallet sweeping system that flushes any funds delivered to the compromised address to a new, secure wallet is recommended in the event of a compromise.

      • Any address generated by a wallet must require a minimum of 2 signatures in order to spend funds, where a separate actor holds each signing key. Requiring 2 or more signatures on a wallet increases the integrity of funds by reducing the risk of theft associated with a compromised key or key holder. This is commonly referred to as a multi-sig wallet. The actors can either be human or system (i.e. two humans, two systems, or one human and one system) but must be separate entities that each manage their own key for the wallet.

      • Redundant keys are assigned to each wallet for recovery purposes. This ensures that the funds are still available in the event one of the primary keys becomes inaccessible for any reason. One common method of achieving this goal is to create a wallet that requires any 2 of 3 possible signatures in order to spend funds (i.e. there is 1 redundant key)

      • All addresses are assigned deterministically based on seeds that are kept private. Using JBOK wallets requires regular backups of each new key that is generated which increases the complexity of the system. This raises the risk of human error that can cause disruptions to the business or accidental loss of funds if a backup does not include certain keys. Wallets that are assigned deterministically remove this risk and improve the integrity of the system.

      • Any keys that have signing authority on a single wallet must be stored in different locations. By separating the wallet’s keys across multiple locations, the risks associated with localized disruptions to business (i.e. fire, flood, earthquake, break-ins) do not affect the organization’s ability to spend funds.

      • Unique addresses must be generated by the wallet for every transaction. This enhances privacy by making it more difficult to determine which addresses belong to which actors. One of the most common methods of implementing this requirement is to use a deterministic wallet to generate all addresses.

      • Any keys that have signing authority on a single wallet must be stored by multiple organizational entities. By giving keys to separate legal entities, such as lawyers, accountants, or other businesses, legal risks that can disrupt your business will not necessarily disrupt your funds. Note that this does not violate the Key/Seed Generation level 1 requirement, as the separate organizations fail to meet the definition of an actor.

  • 1.03 Key Storage

    This aspect covers how cryptographic private keys and seeds are stored when not being used. To maximize the confidentiality of key material (i.e. keys and seeds), they should be stored in as secure a manner as business concerns will allow and make use of strategies such as encryption, secret sharing, and physical locks where appropriate. To maximize the integrity of keys/seeds, backups should exist that allow the keys/seeds to be recovered in the event the primary keys become inaccessible. Care should be taken to ensure that backups are stored with at least as much security as the primary keys, if not more. Notably, cryptographic assets that are generated by end-users of a system are not subject to the backup requirements of this section, as enforcing good behavior on end-users is effectively impossible.

    Aspect Components Include

    • 1.3.1 Primary keys are stored encrypted
    • 1.3.2 Backup key exists
    • 1.3.3 Backup key has environmental protection
    • 1.3.4 Backup key is access-controlled
    • 1.3.5 Backup key has tamper-evident seal
    • 1.3.6 Backup key is encrypted

      • Cryptographic keys and/or seeds must be stored with the use of strong encryption when not in use.

      • A backup of the cryptographic key/seed must exist. The backup can take any form (paper, digital, etc.).

      • The backup must be protected by access controls that prevent unauthorized parties from accessing it. Examples of this include safes, safe deposit boxes, or locked drawers where only the operator holds the key/combination for the lock.

      • The backup must be protected against environmental risks such as fire, flood, and other acts of God. While the specific mechanisms of environmental protection may change depending on the type of medium used for backup, in general, common methods to achieve this include a water-tight bag for flood protection and a safe or firebox for fire protection.

      • A backup must exist for at least as many keys as is required to spend funds. For example, in a 2-of-3 signing setup where any two of three keys are required to spend funds, backups must exist for at least 2 of these keys. In a 5-of-9 setup, backups must exist for at least 5 keys.

      • The backup key/seed must be stored in a location that is geographically separate from the usage location of the primary key/seed. For example, if the primary key is kept at an office, the backup key can be stored at an employee’s personal home. Another example could involve leaving the backup in escrow with a trusted 3rd party.

      • The backup must employ some form of tamper evident mechanism that allows an operator to determine when it has been accessed. A secure method of achieving this involves a serial-numbered tamper-evident bag, however properly sealed paper envelopes with handwritten signatures over the seal could also suffice provided the specific envelopes in use are able to reveal evidence of tampering.

      • 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. If backups use a less-secure mechanism than the key/seed itself, the system can not be certified as Level III.

      • Backups are resistant to electromagnetic pulses that could induce currents in electronics and damage the data stored within. A common methodology to secure against this risk is to store a seed or key on paper, wood, metal, or on another non-digital medium, or to place the digital medium within a sealed faraday bag designed to protect contents from electro-magnetic interference.

  • 1.04 Key Usage

    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.

    Aspect Components Include

    • 1.4.1 Key access requires user/pass/nth factor
    • 1.4.2 Keys are only used in a trusted environment
    • 1.4.3 Operator reference checks
    • 1.4.4 Operator ID checks
    • 1.4.5 Operator background checks
    • 1.4.6 Spends are verified before signing
    • 1.4.7 No two keys are used on one device
    • 1.4.8 DRBG Compliance

      • 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. 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.

      • All keys/seeds are only used in trusted environments. This somewhat reduces the risk of unauthorized copies being made by malware, as well as mitigating the risk of storing (even inadvertently) a key on a machine, allowing it to be recovered by another user or intruder. An effective trusted environment guards against unauthorized persons learning private keys, passwords, or other sensitive information.

      • All key/seed-holders have had their references checked prior to being trusted to hold one of the organization’s keys/seeds. This helps ensure the person is being truthful about their past and were not dismissed from prior employment for reasons that would represent a risk to the organization.

      • All key/seed-holders (individuals and organizations) have undergone identity verification to ensure they are who they say they are. This reduces the risks associated with impersonation and social engineering attacks which may result in access to organizational or customer funds.

      • No two master keys/seeds of the same multi-signature wallet are ever present on the same device. Placing two keys of the same wallet on a single device exposes the keys to information leakage by either a malicious operator or malicious software. Ensuring every key of a wallet is used on dedicated devices reduces these risks, thereby increasing security.

      • Digital signatures must use a ‘k’ value that is never repeated. This can be accomplished through the use of a deterministic random bit generator (DRBG) that is compliant with NIST SP 800-90A, or a deterministic scheme compatible with RFC 6979. Using strong sources of entropy is required in order to prevent “dirty signature” vulnerabilities that can allow attackers to recover the private key that was used to compute the signature. A common implementation of this is to use the pseudo-random number generator (PRNG) supplied by popular operating systems, or an RFC 6979-compatible scheme.

      • Verification of fund destinations and amounts is performed via a Authenticated Communication Channel prior to key/seed use. This can be performed by humans before using their keys/seeds to ensure they’re sending the right amount of funds to the right addresses/people/companies, or by systems that perform automated signing by checking destination addresses against whitelists and spending limits before the signature is applied. The implementation of payment protocols that provide digitally signed addresses, or the use of systems that display images and business names instead of cryptocurrency addresses greatly simplify this verification process.

      • Access to the key/seed requires an identifier (e.g. username, email, GUID, etc.) and at least 3 (three) other factors of authentication. Similar to the requirement of 2 additional factors in Level I, the other 3 factors of authentication in Level III can take any form that provides confirmation of an authorized user’s identity.

      • All individual key/seed holders have had background checks performed by law enforcement personnel or investigative firms. This ensures each key/seed holder is who they say they are and does not have evidence in their past of actions that would represent a risk to the organization if they had signing authority on organization or user funds.

  • 1.05 Key Compromise Protocol (KCP)

    This aspect 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. The lack of a KCP will prevent an organization from achieving Level III certification. Examples of when a KCP would be invoked include the identification of tampering of 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. The execution of Key Compromise Protocols must make use of Authenticated Communication Channels to ensure KCP messages are only sent/received by authenticated actors.

    Aspect Components Include

    • 1.5.1 KCP Exists
    • 1.5.2 KCP Training + Rehearsals

      • An inventory of all keys/seeds exists, and awareness of which keys are critical to the successful operation of the information system exists within the organization. While no formal KCP documents exist, there are staff members who are able to direct operators in the procedures necessary to regenerate cryptographic keys, regenerate cryptocurrency wallets, and send funds to these newly-generated wallets in the event any operator or keys become compromised.

      • A proper Key Compromise Protocol outlines each specific class of key used throughout the system along with a detailed plan of dealing with its compromise including the proper use of Authenticated Communication Channels during execution. The plan identifies actors via roles and not names and includes secondary actors in the event any primary actor is unavailable to carry out the KCP.

      • Tests of the Key Compromise Protocol are executed regularly to confirm the viability of the procedures and to ensure staff remain trained to use them in the case of a compromise. Logs of executed tests exist which outline any/all comments of the test. Improvements identified during the tests are written back into the protocol to ensure the most effective and efficient protocol is always maintained. As changes are made to the information system, the Key Compromise Protocol is revisited to assure it is updated with any new class of key.

  • 1.06 Keyholder Grant/Revoke Policies & Procedures

    This aspect 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 with respect to accessing its information, invoking privilege-restricted actions, and representing the organization to the public. Improper management of the onboarding and offboarding of personnel introduce risks of privileged accounts remaining when staff depart, as well as unrevoked keys that persist signing authority for certain transactions.

    Aspect Components Include

    • 1.6.1 Grant/Revoke Procedures/Checklist
    • 1.6.2 Requests made via Authenticated Communication Channel
    • 1.6.3 Grant/Revoke Audit Trail

      • An awareness of how roles should be managed when onboarding or offboarding staff from keyholder positions exists within the organization. A staff member who is knowledgeable about the system is able to ensure that permissions are granted/revoked to/from the affected staff appropriately.

      • The organization maintains checklists that cover all tasks that must be completed when staff vacate or transition into keyholder roles within the organization. These checklists have been reviewed by knowledgeable personnel to ensure “least privilege principles” are applied to the information system, as well as necessary access where required. This eliminates the risks associated with missed privileges and the possession of un-revoked keys.

      • All keyholder grant/revoke requests are conducted over Authenticated Communication Channels

      • The organization’s checklists include auditing information that record the identity of the staff member that performs the grant/revoke operations. Each entry within the audit trail is attested to by the staff member who performed that task.

  • 2.01 Security Audits / Pentests

    This aspect covers third-party reviews of the security systems, technical controls, and policies that protect the information system from all forms of risk as well as penetration and vulnerability 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 very 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 and are independent of the technical controls and can be objective without risk of retaliation.

    Aspect Components Include

    • 2.1.1 Security Audit

      • A developer who is knowledgeable about bitcoin security has assisted in the design and implementation of the information system. Having this knowledge available during the design and implementation stages helps ensure best practices are followed to minimize risk.

      • A single audit and/or penetration/vulnerability test has been completed by a third-party entity prior to – or shortly after - launch. The audit covered both static and dynamic analysis of source code to ensure secure programming patterns were used wherever applicable, and cryptographic libraries were used properly wherever they have been employed. In addition, documentation shows that all concerns raised by the audit have been addressed by the system’s team in order to remove the concerns from the system. These audits decrease the risks associated with institutional blindness and provide confidence in the organization’s controls and procedures.

      • Security audits and/or penetration/vulnerability tests are performed on a defined schedule of at least once per calendar year, and documentation exists that shows how each of the concerns within the audit were addressed. Regular audits/penetration tests not only reduce the risks of unknown deficiencies in security but also reduce the overall cost of security as each audit builds on top of the last one’s results allowing for a more focused and cost effective assessment.

  • 2.02 Data Sanitization Policy (DSP)

    This aspect covers the removal of cryptographic keys from digital media. Due to the manner in which 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.

    Aspect Components Include

    • 2.2.1 DSP Exists
    • 2.2.2 Audit Trail of all media sanitization

      • The organization’s staff is aware of how data persists on digital media after deletion. Staff also have access to tools that perform secure deletion of data and understand when to use such tools to permanently destroy any transient copies of cryptographic keys that may be required during the maintenance of the information system.

      • A detailed policy outlining the requirements for sanitization of digital media that holds/held cryptocurrency keys exists and is read/understood by all staff who have access to cryptographic keys. Procedure documents outline where sanitization is required in their processes.

      • In addition to the above, an audit trail is maintained for every piece of sanitized media. These audit documents identify the staff member who performed the sanitization, the specific identifiers of the media that was sanitized, which tool and configuration was used to perform the sanitization, and all other relevant pertinent information.

  • 2.03 Proof of Reserve (PoR)

    This aspect covers the proof of control of all funds that should be held by the information system. 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 reserve provide assurance to the public that all funds are available to the system which eliminates the risks of fund loss.

    Aspect Components Include

    • 2.3.1 Proof of Reserve Audits

      • An audit has been completed and published online that proves full control of all funds held by the information system. The audit has been signed by an independent party that attests to the accuracy of the audit at the time it was performed which reduces the risks associated with inaccurate or misleading reports.

      • The organization conducts regularly-scheduled proof of reserve audits that provide proof that the organization continues to operate on a full reserve and that all user funds are accessible at the time each audit is completed.

      • The information system is designed in such a way that an independent audit is not necessary to prove complete accessibility of user funds. The information system makes use of public ledgers such as blockchains themselves to make this information available to the public allowing anyone to conduct an audit independently.

  • 2.04 Audit Logs

    This aspect covers 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 behaviour or security incidents, audit logs are an extremely valuable 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 reduce the risks associated with operational awareness and increase the information system’s ability to correct any inaccuracies.

    Aspect Components Include

    • 2.4.1 Application Audit Logs
    • 2.4.2 Backup of Audit Logs

      • Audit trails exist for a subset of actions that are performed within the information system. Examples of this would include recording audit information of all withdrawals and deposits made with the system.

      • All actions by all users are logged. These records provide significant assistance to investigations into unexpected behaviour of the information system and can help identify malicious actors and responsible systems or persons.

      • In addition to recording all actions performed within the system, this audit information is regularly backed up to a separate server. This act helps preserve valuable investigative information in the event the audit log is altered/destroyed during an attack on the information system.