diff --git a/1_aspects.html b/1_aspects.html index c342fd0..718c1e0 100644 --- a/1_aspects.html +++ b/1_aspects.html @@ -5,109 +5,81 @@ --- -{% assign aspects_sorted = '101-KeySeedGeneration|102-WalletCreation|103-KeyStorage|104-KeyUsage|105-KeyCompromisePolicy|106-KeyholderGrantRevokePoliciesAndProcedures|201-SecurityAuditsAndPentests|202-DataSanitizationPolicy|203-ProofOfReserve|204-AuditLogs' | split: '|' %} +{% assign aspects_sorted = '101-KeySeedGeneration|102-WalletCreation|103-KeyStorage|104-KeyUsage|105-KeyCompromisePolicy|106-KeyholderGrantRevokePoliciesAndProcedures|201-SecurityAuditsAndPentests|202-DataSanitizationPolicy|203-ProofOfReserve|204-AuditLogs' | split: '|' %}
- - -

Definitions

-
+ + {{ aspect.description | replace:'](#','](../Definitions#' | markdownify }} +

+

Aspect Components Include

+ +

+ +

+

+

+ {% endfor %} - diff --git a/2_matrix.html b/2_matrix.html index ba60ed8..6809ae7 100644 --- a/2_matrix.html +++ b/2_matrix.html @@ -4,86 +4,70 @@ permalink: /Matrix/ --- -{% assign aspect_count = "0 28 9" | split: ' ' %} +{% assign aspect_count = "0 28 9" | split: ' ' %} {% assign category_count = 0 %} -{% assign aspects_sorted = '101-KeySeedGeneration|102-WalletCreation|103-KeyStorage|104-KeyUsage|105-KeyCompromisePolicy|106-KeyholderGrantRevokePoliciesAndProcedures|201-SecurityAuditsAndPentests|202-DataSanitizationPolicy|203-ProofOfReserve|204-AuditLogs' | split: '|' %} +{% assign aspects_sorted = '101-KeySeedGeneration|102-WalletCreation|103-KeyStorage|104-KeyUsage|105-KeyCompromisePolicy|106-KeyholderGrantRevokePoliciesAndProcedures|201-SecurityAuditsAndPentests|202-DataSanitizationPolicy|203-ProofOfReserve|204-AuditLogs' | split: '|' %}
- + {% if category != aspect.category %} + {% assign category = aspect.category %} + {% assign category_count = category_count | plus: 1 %} + + {{category}} + {% endif %} + {{ aspect.title }} + + {% for part in aspect.components %} + {% if rower %} + + {% endif %} + {{ part.title_short }} + {{ part.uncertified }} + {{ part.level_one}} + {{ part.level_two}} + {{ part.level_three }} + + {% assign rower = true %} + {% endfor %} + + + {% endfor %} + + + +
diff --git a/3_checklist.html b/3_checklist.html index b287087..0f2892d 100644 --- a/3_checklist.html +++ b/3_checklist.html @@ -4,85 +4,67 @@ permalink: /Checklist/ --- -{% assign aspect_count = "0 28 9" | split: ' ' %} +{% assign aspect_count = "0 28 9" | split: ' ' %} {% assign category_count = 0 %} -{% assign aspects_sorted = '101-KeySeedGeneration|102-WalletCreation|103-KeyStorage|104-KeyUsage|105-KeyCompromisePolicy|106-KeyholderGrantRevokePoliciesAndProcedures|201-SecurityAuditsAndPentests|202-DataSanitizationPolicy|203-ProofOfReserve|204-AuditLogs' | split: '|' %} +{% assign aspects_sorted = '101-KeySeedGeneration|102-WalletCreation|103-KeyStorage|104-KeyUsage|105-KeyCompromisePolicy|106-KeyholderGrantRevokePoliciesAndProcedures|201-SecurityAuditsAndPentests|202-DataSanitizationPolicy|203-ProofOfReserve|204-AuditLogs' | split: '|' %}
- + {% if category != aspect.category %} + {% assign category = aspect.category %} + {% assign category_count = category_count | plus: 1 %} + {{category}} + {% endif %} + {{ aspect.title }} -
+ {% for part in aspect.components %} + {% if rower %} + + {% endif %} + {{ part.title_short }} + + + + + + {% assign rower = true %} + {% endfor %} + + {% endfor %} + + + + + + diff --git a/6_definitions.html b/6_definitions.html new file mode 100644 index 0000000..f030220 --- /dev/null +++ b/6_definitions.html @@ -0,0 +1,25 @@ +--- +layout: default +title: Definitions +permalink: /Definitions/ +--- + +
+

Definitions

+ +
diff --git a/_config.yml b/_config.yml index bc75e83..578a6ba 100644 --- a/_config.yml +++ b/_config.yml @@ -2,14 +2,14 @@ title: Open Standard Repository email: info@cryptoconsortium.org description: > # this means to ignore newlines until "baseurl:" - The CryptoCurrency Certification Consortium (C4) establishes cryptocurrency - standards that help ensure a balance of openness & privacy, security & - usability, and trust & decentralization. + The CryptoCurrency Certification Consortium (C4) establishes cryptocurrency + standards that help ensure a balance of openness & privacy, security & + usability, and trust & decentralization. baseurl: "/CCSS" # the subpath of your site, e.g. /blog/ url: "https://cryptoconsortium.github.io" # the base hostname & protocol for your site twitter_username: _CFour_ github_username: cryptoconsortium logo: CCSS Logo.png -org_logo: C4 Logo.png +org_logo: C4 Logo.png # Build settings markdown: kramdown diff --git a/_data/aspects/101-KeySeedGeneration.yml b/_data/aspects/101-KeySeedGeneration.yml index c4866e1..a77945b 100644 --- a/_data/aspects/101-KeySeedGeneration.yml +++ b/_data/aspects/101-KeySeedGeneration.yml @@ -4,7 +4,7 @@ # # Copyright (c) 2015, CryptoCurrency Certification Consortium (C4) # See license.md -# +# ################################################### id: 1.01 @@ -15,17 +15,21 @@ file: 101-KeySeedGeneration category: Cryptographic Asset Management description: > - 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: privacy and un-guessable numbers. Privacy 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 private and un-guessable manner. + This aspect covers the generation of [cryptographic keys](#key) and [seeds](#seed) that will be used within a cryptocurrency system. The secure creation of cryptographic keys and seeds requires two things to be secure: privacy and un-guessable numbers. Privacy 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 private and un-guessable manner. level_one: - - The cryptographic keys and seeds are created by the actor who will be using it. This ensures privacy of the key as the only person/system that will ever hold it is the one that will use it. Any system that involves one actor creating a key or seed and then giving it to another actor for use will fail to achieve Level I. + - The [cryptographic keys](#key) and [seeds](#seed) are created by the [actor](#actor) who will be using it. This is an attempt to protect privacy 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. + - Notably, transferring a cryptographic secret for backup purposes does not violate the above requirement, however those secrets must be transmitted and stored in a [strongly encrypted](#strong-encryption) format. level_two: - - 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, or features that store or transmit the generated seed to another party. Once this assertion has been made, a digital signature should be validated prior to each use 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 (i.e. dice, a deck of cards, or other non-digital means), 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](#key) or [seed](#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](#actor), except where such features enhance the effective security of the software (e.g. [DRBGs](#drbg)). + - After software has been audited, a digital signature should be generated and 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](#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.). level_three: - - 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 (i.e. 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 lays in the ability to discover the DRBG’s seed. - - 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. + - The [key](#key) or [seed](#seed) is generated using a [Deterministic Random Bit Generator (DRBG)](#drbg) that conforms to [NIST SP 800-90A](http://http://csrc.nist.gov/publications/nistpubs/800-90A/SP800-90A.pdf), and has been seeded with at least two separate cryptographically secure sources of [entropy](#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](https://en.wikipedia.org/wiki/Dual_EC_DRBG) 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](http://www.stat.fsu.edu/pub/diehard/), Crypt-X, or [NIST STS](http://csrc.nist.gov/groups/ST/toolkit/rng/documentation_software.html). components: @@ -34,22 +38,22 @@ components: title_short: Operator-created Key / Seed uncertified: Keys/seeds are issued to the keyholder by another actor level_one: Keys/seeds are created by the key/seed operator themselves - level_two: Keys/seeds are created by the key/seed operator themselves + level_two: Keys/seeds are created by the key/seed operator themselves level_three: Keys/seeds are created by the key/seed operator themselves - component: &010102 id: 1.1.2 title_short: Creation methodology is validated uncertified: level_one: - level_two: Key/seed creation methodology is validated prior to use + level_two: Key/seed creation methodology is validated prior to use level_three: Key/seed creation methodology is validated prior to use - component: &010103 id: 1.1.3 title_short: DRBG Compliance uncertified: Keys / seeds are created with a non-compliant DRBG level_one: Key/seed is created using a NIST SP 800-90A compliant DRBG - level_two: Key/seed is created using a NIST SP 800-90A compliant DRBG that has been seeded with a single cryptographically-secure sources of entropy + level_two: Key/seed is created using a NIST SP 800-90A compliant DRBG that has been seeded with a single cryptographically-secure sources of entropy level_three: | 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) + OR + A NRBG that passes industry-standard statistical tests (DIEHARD, Crypt-X, NIST STS) diff --git a/_data/aspects/102-WalletCreation.yml b/_data/aspects/102-WalletCreation.yml index f6aa974..aa8c718 100644 --- a/_data/aspects/102-WalletCreation.yml +++ b/_data/aspects/102-WalletCreation.yml @@ -3,7 +3,7 @@ # CryptoCurrency Security Standard (CCSS) # # Copyright (c) 2015, CryptoCurrency Certification Consortium (C4) -# +# ################################################### id: 1.02 @@ -13,31 +13,31 @@ file: 102-WalletCreation category: Cryptographic Asset Management description: > - This aspect covers the creation of “wallets” or cryptocurrency accounts (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. + This aspect covers the creation of [wallets](#wallet) or [addresses](#address) 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](#actor). level_one: - - Unique wallets must be generated for every transaction. This enhances privacy by making it more difficult to determine which wallets belong to which entities. One of the most common methods of implementing this requirement is to use a deterministic seed for all wallets. - - In addition, systems that enforce new wallets for every transaction implicitly prevent 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. + - Unique [addresses](#address) must be generated by the [wallet](#wallet) for every transaction. This enhances privacy by making it more difficult to determine which addresses belong to which [actors](#actor). One of the most common methods of implementing this requirement is to use a [deterministic wallet](#hd-wallet) to generate all addresses. + - In addition, systems that enforce new [addresses](#address) for every transaction implicitly mitigate cases where a compromised [wallet](#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. level_two: - - Wallets must require a minimum of 2 signatures in order to spend funds, where a separate actor holds each 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) - - Wallets are assigned deterministically based on a seed that is 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. - - 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. + - Any [address](#address) generated by a [wallet](#wallet) must require a minimum of 2 signatures in order to spend funds, where a separate [actor](#actor) holds each signing [key](#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](#multisig) 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](#key) are assigned to each [wallet](#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](#addresses) are assigned [deterministically](#hd-wallet) based on [seeds](#seed) that are kept private. Using JBOK wallets requires regular backups of each new [key](#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](#key) that have signing authority on a single [wallet](#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. level_three: - - 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. + - Any [keys](#key) that have signing authority on a single [wallet](#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](#actor). components: - component: &010201 id: 1.2.1 - title_short: Unique wallet per transaction + title_short: Unique address per transaction uncertified: Wallets/addresses are reused - level_one: Unique wallets/addresses are generated for every transaction - level_two: Unique wallets/addresses are generated for every transaction - level_three: Unique wallets/addresses are generated for every transaction + level_one: Unique addresses are generated for every transaction + level_two: Unique addresses are generated for every transaction + level_three: Unique addresses are generated for every transaction - component: &010202 id: 1.2.2 title_short: Multiple keys for signing @@ -57,8 +57,8 @@ components: title_short: Deterministic wallets uncertified: level_one: - level_two: Wallets are assigned deterministically - level_three: Wallets are assigned deterministically + level_two: Addresses are assigned deterministically + level_three: Addresses are assigned deterministically - component: &010205 id: 1.2.5 title_short: Geographic distribution of keys @@ -71,7 +71,5 @@ components: title_short: Organizational distribution of keys uncertified: level_one: - level_two: + level_two: level_three: Keys are distributed across multiple organizational entities - - diff --git a/_data/aspects/103-KeyStorage.yml b/_data/aspects/103-KeyStorage.yml index 96796fb..4fb0134 100644 --- a/_data/aspects/103-KeyStorage.yml +++ b/_data/aspects/103-KeyStorage.yml @@ -3,7 +3,7 @@ # CryptoCurrency Security Standard (CCSS) # # Copyright (c) 2015, CryptoCurrency Certification Consortium (C4) -# +# ################################################### id: 1.03 @@ -14,22 +14,23 @@ file: 103-KeyStorage category: Cryptographic Asset Management description: > - This aspect covers how cryptographic private keys and seeds are stored when not being used. To maximize the confidentiality of keys/seeds, they should be stored in as secure a manner as the business 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. + This aspect covers how cryptographic private [keys](#key) and [seeds](#seed) are stored when not being used. To maximize the confidentiality of keys/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. level_one: - - Cryptographic keys and/or seeds must be stored with the use of strong encryption when not in use. Strong encryption is defined as using an industry-standard encryption or key derivation algorithm with an encryption key or password that would take the estimated global combined computing power 1,000x more time to brute force than the expected life of the key or seed. 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. - - A backup of the cryptographic key/seed must exist. The backup can take any form (paper, digital, etc.). + - Cryptographic [keys](#key) and/or [seeds](#seed) must be stored with the use of [strong encryption](#strong-encryption) when not in use. + - A backup of the cryptographic [key](#key)/[seed](#seed) must exist. The backup can take any form (paper, digital, etc.). - 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. level_two: - - 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 you use the primary key at work, the backup key can be stored at home but not at work. Another example includes leaving the backup in escrow with a trusted 3rd party. + - A backup must exist for at least as many [keys](#key) 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](#key)/[seed](#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 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 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. level_three: - - 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 should 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 the seed in Extended Key format 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. + - Backups of cryptographic [keys](#key) and/or [seeds](#seed) must be stored with the use of [strong encryption](#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](#seed) or [key](#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. components: @@ -50,7 +51,7 @@ components: - component: &010303 id: 1.3.3 title_short: Backup key has environmental protection - uncertified: + uncertified: level_one: Key/seed backup is protected from environmental damage level_two: Key/seed backup is protected from environmental damage level_three: Key/seed backup is protected from environmental damage @@ -58,7 +59,7 @@ components: id: 1.3.4 title_short: Backup key is access-controlled uncertified: - level_one: + level_one: level_two: Key/seed backup is protected by access controls to prevent unauthorized access (i.e. safe/safe deposit box) level_three: Key/seed backup is protected by access controls to prevent unauthorized access (i.e. safe/safe deposit box) - component: &010305 @@ -73,7 +74,7 @@ components: title_short: Backup key is encrypted uncertified: level_one: - level_two: + level_two: level_three: Key/seed backup is stored with strong encryption equal/better than that used to protect primary key - component: &010307 id: 1.3.7 @@ -82,6 +83,3 @@ components: level_one: level_two: level_three: Key/seed backup is resistant to ElectroMagnetic Pulses (EMPs) - - - diff --git a/_data/aspects/104-KeyUsage.yml b/_data/aspects/104-KeyUsage.yml index 9a22c13..3e09f79 100644 --- a/_data/aspects/104-KeyUsage.yml +++ b/_data/aspects/104-KeyUsage.yml @@ -1,9 +1,9 @@ ################################################### # # CryptoCurrency Security Standard (CCSS) -# +# # Copyright (c) 2015, CryptoCurrency Certification Consortium (C4) -# +# ################################################### id: 1.04 @@ -13,31 +13,31 @@ file: 104-KeyUsage category: Cryptographic Asset Management description: > - 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. + This aspect covers the use of cryptographic [keys](#key) and/or [seeds](#seed) 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. level_one: - - Access to the primary key/seed requires a username, password, and at least 1 (one) other factor of authentication, which restricts access to the authorized operator. This other factor of authentication can take any form provided it identifies the authorized operator. Common forms of supplementary authentication include a Google Authenticator token, a digital signature from a private key, in-person verification by a guard, the possession of a physical key that’s required to access a locked container, or a countersigning organization who can remotely attest to the authenticity of the key holder. - - Keys/seeds are only used in trusted environments. This reduces the risks of unauthorized copies being made by malware and key loggers, as well as the risk that the key may remain resident on a machine, allowing it to be recovered by another user. A trusted environment guards against unauthorized persons learning private keys, passwords, or other sensitive information. Trusted environments include a machine owned by the organization with appropriate antivirus/anti-malware software installed, a machine owned by a keyholder, or other machine upon which the organization permits the use of keys/seeds. Furthermore, trusted environments involve minimum forms of 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. - - 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. - - No two keys/seeds of the same 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 un-repeated numbers 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. + - Access to the primary [key](#key)/[seed](#seed) requires an identifier (e.g. username, email, etc.) and at least 2 (two) other [factors of authentication](#authentication-factor), 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](#key)/[seeds](#seed) are only used in [trusted environments](#trusted-environment). 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](#key)/[seed](#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. + - No two [master keys](#key)/[seeds](#seed) of the same [multi-signature](#multisig) 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](#signature) must use a 'k' value that is never repeated. This can be accomplished through the use of a [deterministic random bit generator (DRBG)](#drbg) that is compliant with [NIST SP 800-90A](http://http://csrc.nist.gov/publications/nistpubs/800-90A/SP800-90A.pdf), or a deterministic scheme compatible with [RFC 6979](https://tools.ietf.org/html/rfc6979). Using strong sources of [entropy](#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)](#prng) supplied by popular operating systems, or an RFC 6979-compatible scheme. level_two: - - Key/seed holders have undergone identity verification to ensure they are who they say they are. This reduces the risks associated with impersonation and social engineers gaining access to organizational or customer funds. Identities must be verified with at least two forms of government-issued identification (driver’s license, passport, etc.) and two proofs of residency at the person’s home (utility bills, bank statements, etc.). - - Verification is performed of fund destinations and amounts 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. + - All organizational [key](#key)/[seed](#seed)-holders have undergone [identity verification](#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. + - Verification is performed of fund destinations and amounts prior to [key](#key)/[seed](#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](#address)/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](#signature) addresses, or the use of systems that display images and business names instead of cryptocurrency addresses greatly simplify this verification process. level_three: - - Access to the key/seed requires a username, password, and at least 2 other factors of authentication. Similar to the requirement of 1 additional factor in Level I, the other two factors of authentication in Level III can take any form that provides confirmation of an authorized user’s identity. Two factors of authentication in addition to username and password help provide additional security that discovered keys, passwords, or authenticator tokens cannot be used by unauthorized individuals to gain access to organization or user funds. - - Key/seed holders have 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. + - Access to the [key](#key)/[seed](#seed) requires an identifier (e.g. username, email, etc.) and at least 3 (three) other [factors of authentication](#authentication-factor). 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 organizational [key](#key)/[seed](#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. components: - component: &010401 id: 1.4.1 title_short: Key access requires user/pass/nth factor uncertified: Access to key/seed does not require sufficient factors of authentication to provide adequate security - level_one: Access to key/seed requires username, password, and at least 1 other factor (2FA token, in-person verification by guard, IP address whitelist, physical key to gain access to secured storage, countersigning organization) - level_two: Access to key/seed requires username, password, and at least 1 other factor (2FA token, in-person verification by guard, IP address whitelist, physical key to gain access to secured storage, countersigning organization) - level_three: Access to key/seed requires username, password, and at least 2 other factors (2FA token, in-person verification by guard, IP address whitelist, physical key to gain access to secured storage, countersigning organization) + level_one: 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) + level_two: 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) + level_three: 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) - component: &010402 id: 1.4.2 title_short: Keys are only used in a trusted environment @@ -55,22 +55,22 @@ components: - component: &010404 id: 1.4.4 title_short: Operator ID checks - uncertified: - level_one: + uncertified: + level_one: level_two: Key/seed holders have identify verified level_three: Key/seed holders have identify verified - component: &010405 id: 1.4.5 - title_short: Operator background checks - uncertified: - level_one: - level_two: + title_short: Operator background checks + uncertified: + level_one: + level_two: level_three: Key/seed holders have undergone background checks - component: &010406 id: 1.4.6 title_short: Spends are verified before signing - uncertified: - level_one: + uncertified: + level_one: level_two: Verification of fund destinations and amounts are performed prior to key usage level_three: Verification of fund destinations and amounts are performed prior to key usage - component: &010407 @@ -91,7 +91,7 @@ components: level_two: > 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 are created deterministically according to RFC 6979 level_three: > The 'k' values in digital signatures are created using a NIST SP 800-90A compliant DRBG OR diff --git a/_data/aspects/105-KeyCompromisePolicy.yml b/_data/aspects/105-KeyCompromisePolicy.yml index e52f24d..7bb2059 100644 --- a/_data/aspects/105-KeyCompromisePolicy.yml +++ b/_data/aspects/105-KeyCompromisePolicy.yml @@ -3,7 +3,7 @@ # CryptoCurrency Security Standard (CCSS) # # Copyright (c) 2015, CryptoCurrency Certification Consortium (C4) -# +# ################################################### id: 1.05 @@ -13,16 +13,16 @@ file: 105-KeyCompromisePolicy category: Cryptographic Asset Management description: > - This aspect covers the existence and use of a policy 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. As a critical aspect, the lack of a KCP will prevent an organization from achieving Level III certification. + This aspect covers the existence and use of a [policy](#key-compromise-policy) that dictates the actions that must be taken in the event a cryptographic [key](#key)/[seed](#seed) or its [operator/holder](#actor) 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. As a critical aspect, the lack of a KCP will prevent an organization from achieving Level III certification. level_one: - - 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 their keys become compromised. + - An inventory of all [keys](#key)/[seeds](#seed) exists, and awareness of which keys are critical to the successful operation of the information system exists within the organization. While no formal [KCP](#key-compromise-policy) documents exist, there are staff members who are able to direct operators in the procedures necessary to regenerate cryptographic keys, regenerate cryptocurrency [wallets](#wallet), and send funds to these newly-generated wallets in the event any operator or keys become compromised. level_two: - - A proper Key Compromise Policy outlines each specific class of key used throughout the system along with a detailed plan of dealing with its compromise. 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. + - A proper [Key Compromise Policy](#key-compromise-policy) outlines each specific class of key used throughout the system along with a detailed plan of dealing with its compromise. 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. level_three: - - Tests of the Key Compromise Policy 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. Improvements identified during the tests are written back into the policy to ensure the most effective and efficient policy is always maintained. As changes are made to the information system, the Key Compromise Policy is revisited to assure it is updated with any new class of key. + - Tests of the [Key Compromise Policy](#key-compromise-policy) 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. Improvements identified during the tests are written back into the policy to ensure the most effective and efficient policy is always maintained. As changes are made to the information system, the Key Compromise Policy is revisited to assure it is updated with any new class of key. components: - component: &010501 @@ -35,7 +35,7 @@ components: - component: &010502 id: 1.5.2 title_short: KCP Training + Rehearsals - uncertified: - level_one: - level_two: + uncertified: + level_one: + level_two: level_three: Regular training is provided to keyholders to ensure they are prepared to invoke the policy when required. diff --git a/_data/aspects/106-KeyholderGrantRevokePoliciesAndProcedures.yml b/_data/aspects/106-KeyholderGrantRevokePoliciesAndProcedures.yml index ddee5ae..c9ff562 100644 --- a/_data/aspects/106-KeyholderGrantRevokePoliciesAndProcedures.yml +++ b/_data/aspects/106-KeyholderGrantRevokePoliciesAndProcedures.yml @@ -3,7 +3,7 @@ # CryptoCurrency Security Standard (CCSS) # # Copyright (c) 2015, CryptoCurrency Certification Consortium (C4) -# +# ################################################### id: 1.06 @@ -13,16 +13,16 @@ file: 106-KeyholderGrantRevokePoliciesAndProcedures category: Cryptographic Asset Management description: > - This aspect covers the policies and procedures surrounding granting and revoking access to cryptographic keys that protect 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. + This aspect covers the policies and procedures surrounding granting and revoking access to cryptographic [keys](#key) or [seeds](#seed) that protect 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](#signature) authority for certain transactions. level_one: - - 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. + - 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. level_two: - - 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. + - 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](#key). level_three: - - 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. + - 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. components: - component: &010601 @@ -35,7 +35,7 @@ components: - component: &010602 id: 1.6.2 title_short: Grant/Revoke Audit Trail - uncertified: - level_one: - level_two: + uncertified: + level_one: + level_two: level_three: An audit trail records every change of access including who performed the change diff --git a/_data/aspects/201-SecurityAuditsAndPentests.yml b/_data/aspects/201-SecurityAuditsAndPentests.yml index 591224a..ed40bf5 100644 --- a/_data/aspects/201-SecurityAuditsAndPentests.yml +++ b/_data/aspects/201-SecurityAuditsAndPentests.yml @@ -3,7 +3,7 @@ # CryptoCurrency Security Standard (CCSS) # # Copyright (c) 2015, CryptoCurrency Certification Consortium (C4) -# +# ################################################### id: 2.01 @@ -16,13 +16,13 @@ description: > 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 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. level_one: - - 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 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. level_two: - A single audit and/or penetration 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. level_three: - - Security audits and/or penetration 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. + - Security audits and/or penetration 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. components: - component: &020101 diff --git a/_data/aspects/202-DataSanitizationPolicy.yml b/_data/aspects/202-DataSanitizationPolicy.yml index 3f0be58..99cdf77 100644 --- a/_data/aspects/202-DataSanitizationPolicy.yml +++ b/_data/aspects/202-DataSanitizationPolicy.yml @@ -3,7 +3,7 @@ # CryptoCurrency Security Standard (CCSS) # # Copyright (c) 2015, CryptoCurrency Certification Consortium (C4) -# +# ################################################### id: 2.02 @@ -13,16 +13,16 @@ file: 202-DataSanitizationPolicy category: Operations description: > - 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. + This aspect covers the removal of cryptographic [keys](#key) 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. level_one: - - 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. + - 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](#key) that may be required during the maintenance of the information system. level_two: - - 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. + - A detailed policy outlining the requirements for sanitization of digital media that holds/held cryptocurrency [keys](#key) exists and is read/understood by all staff who have access to cryptographic keys. Procedure documents outline where sanitization is required in their processes. level_three: - - 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. + - 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. components: - component: &020201 @@ -34,8 +34,8 @@ components: level_three: Detailed policy covering sanitization requirements, procedures, and validation steps for every media type used by business - component: &020202 id: 2.2.2 - title_short: Audit Trail of all media sanitization - uncertified: - level_one: - level_two: + title_short: Audit Trail of all media sanitization + uncertified: + level_one: + level_two: level_three: Audit trails are maintained for every piece of sanitized media diff --git a/_data/aspects/203-ProofOfReserve.yml b/_data/aspects/203-ProofOfReserve.yml index b251361..dc31ba9 100644 --- a/_data/aspects/203-ProofOfReserve.yml +++ b/_data/aspects/203-ProofOfReserve.yml @@ -3,7 +3,7 @@ # CryptoCurrency Security Standard (CCSS) # # Copyright (c) 2015, CryptoCurrency Certification Consortium (C4) -# +# ################################################### id: 2.03 @@ -13,16 +13,16 @@ file: 203-ProofOfReserve category: Operations description: > - 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. + 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](#proof-of-reserve) provide assurance to the public that all funds are available to the system which eliminates the risks of fund loss. level_one: - - 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. + - 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. level_two: - - 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 organization conducts regularly-scheduled [proof of reserve](#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. level_three: - - 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. + - 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. components: - component: &020301 diff --git a/_data/aspects/204-AuditLogs.yml b/_data/aspects/204-AuditLogs.yml index 091b824..df64f80 100644 --- a/_data/aspects/204-AuditLogs.yml +++ b/_data/aspects/204-AuditLogs.yml @@ -3,7 +3,7 @@ # CryptoCurrency Security Standard (CCSS) # # Copyright (c) 2015, CryptoCurrency Certification Consortium (C4) -# +# ################################################### id: 2.04 @@ -16,13 +16,13 @@ description: > 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. level_one: - - 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. + - 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. level_two: - 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. level_three: - - 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. + - 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. components: - component: &020401 @@ -35,7 +35,7 @@ components: - component: &020402 id: 2.4.2 title_short: Backup of Audit Logs - uncertified: - level_one: - level_two: + uncertified: + level_one: + level_two: level_three: Backups of audit data are performed regularly \ No newline at end of file diff --git a/_data/definitions/Actor.yml b/_data/definitions/Actor.yml index eb48e27..6a6a602 100644 --- a/_data/definitions/Actor.yml +++ b/_data/definitions/Actor.yml @@ -1,4 +1,6 @@ -word: Actor +id: actor +term: Actor +file: Actor description: > - A person, organization or service. \ No newline at end of file + A person, organization, system, or service that (for the purposes of this specification) makes direct use of a cryptographic [key](#key) or [seed](#seed) is an actor in the context of that key or seed. \ No newline at end of file diff --git a/_data/definitions/Address.yml b/_data/definitions/Address.yml new file mode 100644 index 0000000..b1fecab --- /dev/null +++ b/_data/definitions/Address.yml @@ -0,0 +1,6 @@ + +id: address +file: Address +term: Address +description: > + A cryptocurrency address is (usually) an encoded form of a public key from a [wallet](#wallet) that can be used as the recipient of a transaction. In [multi-signature](#multisig) 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](https://en.bitcoin.it/wiki/Pay_to_script_hash) address. \ No newline at end of file diff --git a/_data/definitions/AuthenticationFactor.yml b/_data/definitions/AuthenticationFactor.yml new file mode 100644 index 0000000..ad8000b --- /dev/null +++ b/_data/definitions/AuthenticationFactor.yml @@ -0,0 +1,13 @@ + +id: authentication-factor +file: AuthenticationFactor +term: Factor of Authentication +description: > + [Multi-factor authentication](https://en.wikipedia.org/wiki/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](#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](https://en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm) 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](#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. \ No newline at end of file diff --git a/_data/definitions/DRBG.yml b/_data/definitions/DRBG.yml new file mode 100644 index 0000000..e036d75 --- /dev/null +++ b/_data/definitions/DRBG.yml @@ -0,0 +1,6 @@ + +id: drbg +file: DRBG +term: Deterministic Random Bit Generator +description: > + A kind of [PRNG](#prng) that can produce some number of values (usually [keys](#keys)) from a single [seed](#seed). DRBGs are primarily useful due to their ability to limit a system's reliance secure sources of [entropy](#entropy) \ No newline at end of file diff --git a/_data/definitions/Entropy.yml b/_data/definitions/Entropy.yml new file mode 100644 index 0000000..4d10123 --- /dev/null +++ b/_data/definitions/Entropy.yml @@ -0,0 +1,6 @@ + +id: entropy +file: Entropy +term: Entropy +description: > + Randomness usually collected from hardware, environmental factors (time of execution), or external sources (user-input). [Wikipedia](https://en.wikipedia.org/wiki/Entropy_%28computing%29) \ No newline at end of file diff --git a/_data/definitions/HDWallet.yml b/_data/definitions/HDWallet.yml new file mode 100644 index 0000000..3d59ef3 --- /dev/null +++ b/_data/definitions/HDWallet.yml @@ -0,0 +1,7 @@ + +id: hd-wallet +file: HDWallet +term: Hierarchical Deterministic Wallet +description: > + A [wallet](#wallet) that uses a cryptographically secure key derivation function (e.g. [PBKDF2](https://en.wikipedia.org/wiki/PBKDF2)) to create an arbirtarily large number of unique [addresses](#address) from a single master [seed](#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](#multisig) 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](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) as proposed by Pieter Wuille. [BIP44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) introduced additional functionality allowing sub-paths to be shared without compromising the security of the entire wallet. \ No newline at end of file diff --git a/_data/definitions/IdentityVerification.yml b/_data/definitions/IdentityVerification.yml new file mode 100644 index 0000000..2a95e63 --- /dev/null +++ b/_data/definitions/IdentityVerification.yml @@ -0,0 +1,10 @@ + +id: identity-verification +file: Identity Verification +term: Identity Verification +description: > + Identity verification is a tiered process by which an organization or system attempts to confirm the authenticity of an [actors'](#actor) claim to be a given individual. + Typical methods of identity verification 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) diff --git a/_data/definitions/Key Compromise Policy.yml b/_data/definitions/Key Compromise Policy.yml deleted file mode 100644 index 3f1052d..0000000 --- a/_data/definitions/Key Compromise Policy.yml +++ /dev/null @@ -1,4 +0,0 @@ - -word: Key Compromise Policy -description: > - A document that outlines what actions are to be taken in the event that a key may have been compromised. \ No newline at end of file diff --git a/_data/definitions/Key.yml b/_data/definitions/Key.yml new file mode 100644 index 0000000..282a19f --- /dev/null +++ b/_data/definitions/Key.yml @@ -0,0 +1,8 @@ + +id: key +file: Key +term: Key +description: > + (stub) A cryptographic key is an input to a cryptographic function. [Wikipedia](https://en.wikipedia.org/wiki/Key_%28cryptography%29) + In [public-key cryptography](https://en.wikipedia.org/wiki/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](#signature) 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](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#user-content-extended-keys). 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. \ No newline at end of file diff --git a/_data/definitions/KeyCompromisePolicy.yml b/_data/definitions/KeyCompromisePolicy.yml new file mode 100644 index 0000000..b56e75b --- /dev/null +++ b/_data/definitions/KeyCompromisePolicy.yml @@ -0,0 +1,6 @@ + +id: key-compromise-policy +file: KeyCompromisePolicy +term: Key Compromise Policy +description: > + A document that outlines what actions are to be taken in the event that a key may have been compromised. \ No newline at end of file diff --git a/_data/definitions/Multisig.yml b/_data/definitions/Multisig.yml new file mode 100644 index 0000000..af24160 --- /dev/null +++ b/_data/definitions/Multisig.yml @@ -0,0 +1,6 @@ + +id: multisig +file: Multisig +term: Multi-signature +description: > + A common security feature of cryptocurrency [wallet](#wallet) applications is to require multiple signatures from different [keys](#key) to create a valid transaction. \ No newline at end of file diff --git a/_data/definitions/OTP.yml b/_data/definitions/OTP.yml new file mode 100644 index 0000000..ae7cdc1 --- /dev/null +++ b/_data/definitions/OTP.yml @@ -0,0 +1,8 @@ + +id: otp +term: One-Time Password +file: OTP +description: > + A one-time password is any token (often used as a [factor of authentication](#authentication-factor)) 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." \ No newline at end of file diff --git a/_data/definitions/PRNG.yml b/_data/definitions/PRNG.yml new file mode 100644 index 0000000..76074f9 --- /dev/null +++ b/_data/definitions/PRNG.yml @@ -0,0 +1,7 @@ + +id: prng +file: PRNG +term: Pseudo-Random Number Generator +description: > + An algorithm, program, or system used to produce arbitrary difficult-to-guess values for cryptographic applications. Typically [seeded](#seed) with some source of [entropy](#entropy), PRNGs are used, among other things, to generate [cryptographic keys](#key). Sometimes CSPRNG (Cryptographically Secure PRNG). See related: [DRBG (Deterministic Random Bit Generator)](#drbg). + [Wikipedia](https://en.wikipedia.org/wiki/Pseudorandom_number_generator) \ No newline at end of file diff --git a/_data/definitions/ProofOfReserve.yml b/_data/definitions/ProofOfReserve.yml new file mode 100644 index 0000000..ff76fd6 --- /dev/null +++ b/_data/definitions/ProofOfReserve.yml @@ -0,0 +1,6 @@ + +id: proof-of-reserve +file: ProofOfReserve +term: Proof of Reserve +description: > + 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://en.wikipedia.org/wiki/Fractional-reserve_banking) \ No newline at end of file diff --git a/_data/definitions/Seed.yml b/_data/definitions/Seed.yml new file mode 100644 index 0000000..0afae04 --- /dev/null +++ b/_data/definitions/Seed.yml @@ -0,0 +1,6 @@ + +id: seed +file: Seed +term: Seed +description: > + A slice of [entropy](#entropy) typically used to initialize a [PRNG](#prng)/[DRBG](#drbg) or other crypto-system (e.g. [HD Wallets](#hd-wallet), [deterministic signatures](https://tools.ietf.org/html/rfc6979)). \ No newline at end of file diff --git a/_data/definitions/Signature.yml b/_data/definitions/Signature.yml new file mode 100644 index 0000000..3e4470b --- /dev/null +++ b/_data/definitions/Signature.yml @@ -0,0 +1,6 @@ + +id: signature +file: Signature +term: Digital Signature +description: > + (stub) [Wikipedia](https://en.wikipedia.org/wiki/Digital_signature) \ No newline at end of file diff --git a/_data/definitions/StrongEncryption.yml b/_data/definitions/StrongEncryption.yml new file mode 100644 index 0000000..be5bd14 --- /dev/null +++ b/_data/definitions/StrongEncryption.yml @@ -0,0 +1,8 @@ + +id: strong-encryption +term: Strong Encryption +file: StrongEncryption +description: > + A system for [encrypting](https://en.wikipedia.org/wiki/Encryption) 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](https://en.wikipedia.org/wiki/PBKDF2) as described [BIP 39](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki). + [Wikipedia](https://en.wikipedia.org/wiki/Strong_cryptography) \ No newline at end of file diff --git a/_data/definitions/TrustedEnvironment.yml b/_data/definitions/TrustedEnvironment.yml new file mode 100644 index 0000000..912b9ca --- /dev/null +++ b/_data/definitions/TrustedEnvironment.yml @@ -0,0 +1,15 @@ + +id: trusted-environment +file: TrustedEnvironment +term: Trusted Environment +description: > + 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](#keys)/[seeds](#seeds). + + An organization's trusted environment policy should require hard disk encryption, short screen-lock timeouts, sufficiently [entropic](#entropy) 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. \ No newline at end of file diff --git a/_data/definitions/Wallet.yml b/_data/definitions/Wallet.yml new file mode 100644 index 0000000..1ac28e9 --- /dev/null +++ b/_data/definitions/Wallet.yml @@ -0,0 +1,13 @@ + +id: wallet +file: Wallet +term: Wallet +description: > + In the context of most cryptocurrencies, a wallet is a public-private keypair, where some encoding of the public key (an [address](#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: + - JBOK (Just a Bunch of Keys) Wallets where the wallet uses a [PRNG](#prng) to generate each keypair and stores them for use. + - [HD (Hierarchical Deterministic) Wallets](#hd-wallet) which derives an arbitrary number of keypairs from one random [seed](#seed). + + Wallet software can introduce additional complexity, for example by combining multiple keypairs into single addresses, as in the case of a [multi-signature](#multisig) wallet. + + For the purposes of this document, the term 'wallet' refers to some *collection* of cryptocurrency [addresses](#address). \ No newline at end of file diff --git a/_includes/footer.html b/_includes/footer.html index 852eb63..8a897cb 100644 --- a/_includes/footer.html +++ b/_includes/footer.html @@ -2,13 +2,12 @@
-
    • - +
diff --git a/_includes/header.html b/_includes/header.html index fcce889..c8b4081 100644 --- a/_includes/header.html +++ b/_includes/header.html @@ -2,7 +2,7 @@
- {{ site.title }} + {{ site.title }}