Category Aspect Component Uncertified Level I Level II Level 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 Wallets/addresses are reused Unique addresses are generated for every transaction Unique addresses are generated for every 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)
    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