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