CryptoCurrency Security Standard (CCSS)

https://cryptoconsortium.github.io/CCSS/

CryptoCurrency Security Standard (CCSS) is a set of requirements for all information systems that make use of cryptocurrencies, including exchanges, web applications, and cryptocurrency storage solutions. By standardizing the techniques and methodologies used by systems around the globe, end-users will be able to easily make educated decisions about which products and services to use and with which companies they wish to align.

CCSS is designed to complement existing information security standards (i.e. ISO 27001:2013) by introducing guidance for security best practices with respect to cryptocurrencies such as Bitcoin. CCSS is not designed to substitute or replace these standards; in fact, following the CCSS to the letter while ignoring standards like ISO 27001:2013 will likely lead to compromise. CCSS is a cryptocurrency standard that augments standard information security practices. As with any standard, knowledgeable and experienced security professionals and/or auditors are necessary when implementing any information system to ensure coverage of all classes of attack as well as the appropriate handling of all potential risks.

Overview

CCSS covers a list of 10 security aspects of an information system that stores, transacts with, or accepts cryptocurrencies. An information system is a collection of technologies (hardware and/or software), personnel, policies and procedures that work together to provide a secure environment. A security aspect is a discrete technique of securing one piece of an information system. The minimum value of all 10 aspects determines an information system’s overall score within three (3) levels of increasing security: Level I is the lowest and offers strong security measures, while Level III is the highest and offers the most comprehensive security.

These 10 aspects are organized into 2 domains that help structure the guidelines. A summary of the standard can be seen in the below example which depicts sample results after auditing Acme Exchange, a “Level I” system. You’ll note that even though there are some aspects with scores in the Level II and Level III range, Acme Exchange is classified a Level I system overall since that is the lowest consistent grade across all aspects:

Acme Exchange’s CCSS Audit Results: img

Scope

The CCSS covers controls that increase the security of the cryptocurrency portion of an information system, however it does not cover common standards and practices for increasing the cybersecurity of an information system. For this reason, CCSS should be considered as a separate set of recommendations that are applied overtop standard security practices in other domains including business continuity, disaster recovery, network intrusion prevention, physical security, and vulnerability management.

Applicability

The CCSS applies to any information system that makes use of cryptocurrencies. This includes (but is not limited to):

  • Cryptocurrency Exchanges (i.e. Information Systems that allow its users to exchange cryptocurrencies for other forms of money)
  • Cryptocurrency Marketplaces (i.e. Information Systems that allow its users to exchange cryptocurrencies for other goods and services)
  • Cryptocurrency Games (i.e. Information Systems that allow users to gamble their cryptocurrencies for a chance at winning more)
  • Cryptocurrency Processors (i.e. Information Systems that automate the acceptance of cryptocurrencies for payment)
  • Cryptocurrency Storage (i.e. Information Systems that facilitate the receipt and transmission of cryptocurrencies amongst other actors)
  • Any Information System that handles cryptocurrencies as part of its business logic.

Levels

CCSS is broken into three (3) levels of increasing security. Details of these are outlined in this section.

Level I

An information system that has achieved Level I security has proven by way of audit that they protect their information assets with strong levels of security. Most risks to the system’s information assets have been addressed by controls that meet industry guidelines. While this is the lowest level within CCSS, it still represents strong security.

Level II

An information system that has achieved Level II security has proven by way of audit that they exceed strong levels of security with additional enhanced controls. In addition to covering most risks to the information system’s assets, the use of decentralized security technologies such as multiple signatures have been employed which exceed industry guidelines and provide redundancy if any one key or person becomes unavailable or compromised.

Level III

An information system that has achieved Level III security has proven by way of audit that they exceed enhanced levels of security with formalized policies and procedures that are enforced at every step within their business processes. Multiple actors are required for all critical actions, advanced authentication mechanisms ensure authenticity of all data, and assets are distributed geographically and organizationally in such a way to be resilient against compromise of any person or organization.

This Repository

This repository is meant to operate as a collaborative document. Wherever possible, the details of the standard have been separated from the design elements to allow for both to easily evolve independently. Your contribution to either is encouraged.

See the _data directory for discussion on the standard.

See the Jekyll project for more information regarding the structure/design of this static site.

  • 1.01 Key / Seed Generation

    Edit | History | Discuss | Top

    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

    Edit | History | Discuss | Top

    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

    Edit | History | Discuss | Top

    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

    Edit | History | Discuss | Top

    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)

    Edit | History | Discuss | Top

    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

    Edit | History | Discuss | Top

    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

    Edit | History | Discuss | Top

    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)

    Edit | History | Discuss | Top

    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)

    Edit | History | Discuss | Top

    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

    Edit | History | Discuss | Top

    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.

　

CategoryAspectComponentUncertifiedLevel ILevel IILevel III
Cryptographic Asset Management Key / Seed Generation Operator-created Key / Seed Keys/seeds are issued to the keyholder by another actor Keys/seeds are created by the key/seed operator themselves Keys/seeds are created by the key/seed operator themselves Keys/seeds are created by the key/seed operator themselves
Creation methodology is validated     Key/seed creation methodology is validated prior to use Key/seed creation methodology is validated prior to use
DRBG Compliance Keys / seeds are created with a non-compliant DRBG Key/seed is created using a NIST SP 800-90A compliant DRBG Key/seed is created using a NIST SP 800-90A compliant DRBG that has been seeded with a single cryptographically-secure sources of entropy Key/seed is created using a NIST SP 800-90A compliant DRBG that has been seeded with multiple cryptographically-secure sources of entropy OR A NRBG that passes industry-standard statistical tests (DIEHARD, Crypt-X, NIST STS)
Entropy Pool Keys / seeds are created on system with insufficient entropy Key/seed is created on a system with sufficient entropy Key/seed is created on a system with sufficient entropy Key/seed is created on a system with sufficient entropy
Wallet Creation Unique address per transaction       Unique addresses are generated for every transaction
Multiple keys for signing     Transactions require signatures from 2 or more keys Transactions require signatures from 2 or more keys
Redundant key for recovery     Redundant keys are assigned for recovery purposes (i.e. 2of3, 3of5, etc.) Redundant keys are assigned for recovery purposes (i.e. 2of3, 3of5, etc.)
Deterministic wallets     Addresses are assigned deterministically Addresses are assigned deterministically
Geographic distribution of keys     Keys are distributed across multiple separate locations Keys are distributed across multiple separate locations
Organizational distribution of keys       Keys are distributed across multiple organizational entities
Key Storage Primary keys are stored encrypted Keys/seeds are stored in plain text Key/seed is stored with strong encryption Key/seed is stored with strong encryption Key/seed is stored with strong encryption
Backup key exists No key backups exist Key/seed backup exists Key/seed backup is stored in a separate location from primary key/seed Key/seed backup is stored in a separate location from primary key/seed
Backup key has environmental protection   Key/seed backup is protected from environmental damage Key/seed backup is protected from environmental damage Key/seed backup is protected from environmental damage including electromagnetic pulse
Backup key is access-controlled   Key/seed backup is protected by access controls to prevent unauthorized access (i.e. safe/safe deposit box) Key/seed backup is protected by access controls to prevent unauthorized access (i.e. safe/safe deposit box) Key/seed backup is protected by access controls to prevent unauthorized access (i.e. safe/safe deposit box)
Backup key has tamper-evident seal     Key/seed backup employs tamper-evident seal Key/seed backup employs tamper-evident seal
Backup key is encrypted       Key/seed backup is stored with strong encryption equal/better than that used to protect primary key
Key Usage Key access requires user/pass/nth factor Access to key/seed does not require sufficient factors of authentication to provide adequate security Access to key/seed requires an identifier and at least 2 other factors (password, MFA token, in-person verification by guard, IP address whitelist, physical key to gain access to secured storage, countersigning organization) Access to key/seed requires an identifier and at least 2 other factor (password, MFA token, in-person verification by guard, IP address whitelist, physical key to gain access to secured storage, countersigning organization) Access to key/seed requires an identifier and at least 3 other factors (password, MFA token, in-person verification by guard, IP address whitelist, physical key to gain access to secured storage, countersigning organization)
Keys are only used in a trusted environment Keys/seeds are used on public/untrusted machines, or in environments where passwords/secrets can be disclosed Keys/seeds are only used in trusted environments Keys/seeds are only used in trusted environments Keys/seeds are only used in trusted environments
Operator reference checks No checks are performed on key/seed holders Key/seed holders have references checked Key/seed holders have references checked Key/seed holders have references checked
Operator ID checks ID of one or more operators is not established Key/seed holders have identify verified Key/seed holders have identify verified Key/seed holders have identify verified
Operator background checks       Key/seed holders have undergone background checks
Spends are verified before signing     Verification of fund destinations and amounts are performed prior to key usage Verification of fund destinations and amounts are performed prior to key usage
No two keys are used on one device Multiple keys for a single asset used on one device No two keys belonging to the same wallet are present on any one device No two keys belonging to the same wallet are present on any one device No two keys belonging to the same wallet are present on any one device
DRBG Compliance Signatures use a non-compliant DRBG and may be susceptible to "dirty signature" vulnerabilities The 'k' values in digital signatures are created using a NIST SP 800-90A compliant DRBG OR The 'k' values are created deterministically according to RFC 6979 The 'k' values in digital signatures are created using a NIST SP 800-90A compliant DRBG OR The 'k' values are created deterministically according to RFC 6979 The 'k' values in digital signatures are created using a NIST SP 800-90A compliant DRBG OR The 'k' values are created deterministically according to RFC 6979
Key Compromise Protocol (KCP) KCP Exists No staff has the necessary knowledge/experience/training required to rebuild the keys/wallets when necessary An employee with knowledge/experience with the system is able to direct staff with appropriate tasks to remove the risk of compromise. A written checklist/procedure document exists that outlines procedures for each actor to carry out in order to remove the risk of compromise. Document is maintained as warranted by changes to the system. A written checklist/procedure document exists that outlines procedures for each actor to carry out in order to remove the risk of compromise. Document is maintained as warranted by changes to the system.
KCP Training + Rehearsals       Regular training is provided to keyholders to ensure they are prepared to invoke the protocol when required.
Keyholder Grant/Revoke Policies & Procedures Grant/Revoke Procedures/Checklist No Policy/Procedures in place Permission changes for incoming/outgoing staff are performed by someone knowledgeable with the system A written checklist/procedure document exists that is followed for on/offboarding. The checklist outlines every permission to grant/revoke for every role in the information system. A written checklist/procedure document exists that is followed for on/offboarding. The checklist outlines every permission to grant/revoke for every role in the information system.
Requests made via Authenticated Communication Channel     All grant/revoke requests are made via an Authenticated Communication Channel All grant/revoke requests are made via an Authenticated Communication Channel
Grant/Revoke Audit Trail       An audit trail records every change of access including who performed the change
Operations Security Audits / Pentests Security Audit No proof of security A developer who is knowledgeable about bitcoin security has assisted in the design and development of the system A security audit has been completed by another entity who did not assist in the development of the system External security audits are conducted regularly (at least 1/yr)
Data Sanitization Policy (DSP) DSP Exists No sanitization is performed on decommissioned media Staff is aware of how data remains on digital media after deletion, how to securely wipe data, and when secure wiping should be used Destruction guidelines exist to educate/remind staff about securely deleting data data, and where they should do this within their workflow Detailed policy covering sanitization requirements, procedures, and validation steps for every media type used by business
Audit Trail of all media sanitization       Audit trails are maintained for every piece of sanitized media
Proof of Reserve (PoR) Proof of Reserve Audits No audit has been performed A PoR audit has been completed Regularly-scheduled release of PoR audits The system does not hold any funds at all OR The ledger is openly viewable by all, so no PoR audits are necessary
Audit Logs Application Audit Logs No audit logs Audit logs exist for some actions within the system Full audit trail exists of all user/admin actions Full audit trail exists of all user/admin actions
Backup of Audit Logs       Backups of audit data are performed regularly
CategoryAspectComponentLevel ILevel IILevel III
Cryptographic Asset Management Key / Seed Generation Operator-created Key / Seed      
Creation methodology is validated      
DRBG Compliance      
Entropy Pool      
Wallet Creation Unique address per transaction      
Multiple keys for signing      
Redundant key for recovery      
Deterministic wallets      
Geographic distribution of keys      
Organizational distribution of keys      
Key Storage Primary keys are stored encrypted      
Backup key exists      
Backup key has environmental protection      
Backup key is access-controlled      
Backup key has tamper-evident seal      
Backup key is encrypted      
Key Usage Key access requires user/pass/nth factor      
Keys are only used in a trusted environment      
Operator reference checks      
Operator ID checks      
Operator background checks      
Spends are verified before signing      
No two keys are used on one device      
DRBG Compliance      
Key Compromise Protocol (KCP) KCP Exists      
KCP Training + Rehearsals      
Keyholder Grant/Revoke Policies & Procedures Grant/Revoke Procedures/Checklist      
Requests made via Authenticated Communication Channel      
Grant/Revoke Audit Trail      
Operations Security Audits / Pentests Security Audit      
Data Sanitization Policy (DSP) DSP Exists      
Audit Trail of all media sanitization      
Proof of Reserve (PoR) Proof of Reserve Audits      
Audit Logs Application Audit Logs      
Backup of Audit Logs      

Definitions

    • Hierarchical Deterministic Wallet

      Edit | History | Discuss | Top

      A wallet that uses a cryptographically secure key derivation function (e.g. PBKDF2) to create an arbirtarily large number of unique addresses from a single master seed. These are beneficial as only the master seed needs to be backed up to protect against loss. Some HD wallet software can also support multi-signature configurations where multiple master seeds are combined when creating addresses. HD Wallets generally organize addresses into an n-ary tree structure, where each address is associated with a path through the tree. The first HD wallet standard adopted by many applications in the bitcoin community was BIP32 as proposed by Pieter Wuille. BIP44 introduced additional functionality allowing sub-paths to be shared without compromising the security of the entire wallet.

    • Key Compromise Protocol

      Edit | History | Discuss | Top

      A document that outlines the specific actions that are to be taken by every actor in an Information System in order to regenerate the system’s set of keys in the event that a key may have been compromised.

    • Seed

      Edit | History | Discuss | Top

      A slice of entropy typically used to initialize a PRNG/DRBG or other crypto-system (e.g. HD Wallets, deterministic signatures).

    • Wallet

      Edit | History | Discuss | Top

      In the context of most cryptocurrencies, a wallet is a public-private keypair, where some encoding of the public key (an address) can be used in transaction outputs to transfer funds. The private key can then be used to generate a valid signature for a transaction spending those funds. In practice, however, ‘wallet’ usually refers to an application that manages a large number of these keypairs, allowing a new address to be used for each transactions. Wallet applications generally fall into one of two categories:

      Wallet software can introduce additional complexity, for example by combining multiple keypairs into single addresses, as in the case of a multi-signature wallet. For the purposes of this document, the term ‘wallet’ refers to some collection of cryptocurrency addresses.

    • Pseudo-Random Number Generator

      Edit | History | Discuss | Top

      An algorithm, program, or system used to produce arbitrary difficult-to-guess values for cryptographic applications. Typically seeded with some source of entropy, PRNGs are used, among other things, to generate cryptographic keys. Sometimes CSPRNG (Cryptographically Secure PRNG). See related: DRBG (Deterministic Random Bit Generator). Wikipedia

    • Digital Signature

      Edit | History | Discuss | Top

      (stub) Wikipedia

    • One-Time Password

      Edit | History | Discuss | Top

      A one-time password is any token (often used as a factor of authentication) that is valid for one and only one use. OTP tokens are generally as secure as the weakest of:

      1. The channel used to deliver the OTP to the intended user, if any.
      2. The system where the OTP is generated and stored until “redeemed.”

    • Address

      Edit | History | Discuss | Top

      A cryptocurrency address is (usually) an encoded form of a public key from a wallet that can be used as the recipient of a transaction. In multi-signature schemes, an address may be an encoding of information including several public keys and/or other information as in the case of a bitcoin P2SH address.

    • Authenticated Communication Channel

      Edit | History | Discuss | Top

      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.

    • Deterministic Random Bit Generator

      Edit | History | Discuss | Top

      A kind of PRNG that can produce some number of values (usually keys) from a single seed. DRBGs are primarily useful due to their ability to limit a system’s reliance secure sources of entropy

    • Key

      Edit | History | Discuss | Top

      (stub) A cryptographic key is an input to a cryptographic function. Wikipedia In public-key cryptography a public key is used to encrypt data that can only be decrypted using a corresponding private key. Similarly, the private key can be used to generate irreproducible signatures for arbitrary data which the public key can verify. In cryptocurrency, a private key may often include additional application-specific information such as bitcoin’s chain code. In such cases, the term key can apply to extended key information OR partial information which might be used to reconstruct a full key as both are sensitive, private information.

    • Trusted Environment

      Edit | History | Discuss | Top

      For the purposes of this specification, trusted environments include:

      • machines owned by the organization with appropriate antivirus/anti-malware software installed
      • machines owned by a keyholder
      • other machines upon which the organization permits the use of keys/seeds.

      An organization’s trusted environment policy should require hard disk encryption, short screen-lock timeouts, sufficiently entropic account passwords, and other sensible security measures.
      Additionally, trusted environments should, where possible, make use of physical access control to prevent “shoulder surfing” of keyboard and screen by unauthorized individuals.
      Public machines such as those in Internet cafes, libraries, and other public spaces are not trusted environments.

    • Strong Encryption

      Edit | History | Discuss | Top

      A system for encrypting data using an industry-standard encryption or key derivation algorithm with an encryption key or password such that modern cryptanalysis techniques would require the estimated global combined computing power and 1,000x more time than the expected life of the key or seed to decrypt the encrypted data. An example of an encryption algorithm that would provide the necessary level of security at the time of this writing (and potentially for the next few decades barring the discovery of a new attack vector) is AES-256. An example of a password-based key derivation function is PBKDF2 as described BIP 39. Wikipedia

    • Identity Verification

      Edit | History | Discuss | Top

      Identity verification is a tiered process by which an organization or system attempts to confirm the authenticity of an actors’ 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.

    • Factor of Authentication

      Edit | History | Discuss | Top

      Multi-factor authentication schemes require multiple demonstrations of identity. The most common example is a username and password combination, where each input is a factor of authentication. To access protected information in this scheme, an actor must provide those two pieces of information. Additional factors generally (although with diminishing returns) increase the security of the system. Common examples include:

      • A TOTP token may be required, where the token can only be obtained from a device seeded with the TOTP secret (Google Authenticator), which effectively requires the actor be in possession of a specific pre-authorized device.
      • An OTP can be delivered to a phone number via SMS, MMS, or a voice call.
      • A biometric scan may be required - although this is usually only useful if the access point is in a controlled and trusted environment.

      Colloquially, a username is not considered a factor of authentication since usernames are not commonly secret information. The same applies to email addresses, phone numbers, and other pieces of data which only “identify” actors. The requirement imposed by a factor of authentication should only be satisfiable by the actor identified.

    • Entropy

      Edit | History | Discuss | Top

      Randomness usually collected from hardware, environmental factors (time of execution), or external sources (user-input). Wikipedia

    • Actor

      Edit | History | Discuss | Top

      A person, organization, system, or service that (for the purposes of this specification) makes direct use of a cryptographic key or seed is an actor in the context of that key or seed.

    • Multi-signature

      Edit | History | Discuss | Top

      A common security feature of cryptocurrency wallet applications is to require multiple signatures from different keys to create a valid transaction.

    • Proof of Reserve

      Edit | History | Discuss | Top

      A demonstration that an organization has access to all funds to which it claims ownership is called a Proof-of-Reserve. Cryptocurrencies based on a public ledger (blockchain) enable proofs of reserve to be conducted and publicly verified, although the term can also be applied to private audits intended to assure some audience that an organization is operating in good faith and not as a fractional reserve

【推广】 免费学中医，健康全家人
原文地址：https://www.cnblogs.com/dhcn/p/14524855.html