CCSS:1
Page 1 of 23
Table of Contents
Version History........................................................................................................3
Introduction.............................................................................................................4
Summary.................................................................................................................5
Overview.................................................................................................................5
Levels......................................................................................................................7
Level I..................................................................................................................7
Level II.................................................................................................................7
Level III................................................................................................................7
Aspects...................................................................................................................8
Key/Seed Generation..........................................................................................8
Wallet Creation....................................................................................................9
Key Storage.......................................................................................................11
Key Usage.........................................................................................................12
Key Compromise Policy....................................................................................14
Keyholder Grant/Revoke Policies & Procedures...............................................15
Third-Party Security Audits / Penetration Tests................................................16
Data Sanitization Policy....................................................................................17
Proof of Reserve...............................................................................................18
Audit Logs.........................................................................................................18
Conclusion............................................................................................................19
Appendices...........................................................................................................20
Appendix A Audit Checklist............................................................................20
CCSS:1
Page 2 of 23
Version History
0.33, 2015-01-30 Mike Belshe, BitGo Review and content edits
0.32, 2015-01-27 John Velissarios, Armory Enterprise Security Review and
content edits
0.30, 2015-01-20 Michael Perklin, C4 + Joshua McDougall, C4 Added
Fire/Flood/EMP controls, updated draft with feedback from
industry peers, and added checklist to Appendix A
0.20, 2015-01-07 Michael Perklin, C4 Updated draft with additional feedback
0.15, 2014-11-27 Michael Perklin, C4 Updated draft with first round of
industry feedback
0.10, 2014-11-03 Michael Perklin, C4 Completed first draft
0.05, 2014-11-03 Joshua McDougall, C4 Filled in details of many aspects
0.04, 2014-11-02 Will OBrien, BitGo Review and content edits
0.03, 2014-10-29 Michael Perklin, C4 Updates based on peer review
0.02, 2014-10-27 Michael Perklin, C4 Initial Draft for discussion purposes
0.01, 2014-10-10 Michael Perklin, C4 Document Skeleton
#.##, YYYY-MM-DD Author Name, Organization Version Comment
CCSS:1
Page 3 of 23
Introduction
Security is an evolution that requires constant updates to address new
threats. In the development of the commercial Internet, technologies like
TLS/SSL were invented by businesses to address a market need. The best of
these ideas emerged into standards and were embraced by leading web
companies and harnessed by service providers to build security platforms like
Verisign. The human and system processes for deploying these technologies
also became certifiable standards that could be audited. Once standards were in
place, the Internet ecosystem was able to thrive, and we experienced rapid
growth in e-commerce and web-based innovation.
As we begin 2015, Bitcoin sits at a similar stage of development as the
Internet in 1994. There is substantial merchant adoption, venture capital
financing, and company creation. However, the security of Bitcoin remains
fragmented and brittle because nearly every company in the industry is creating
their own custom security models, and many are taking dangerous shortcuts.
The result of this inconsistent and immature approach to security has
resulted in notable theft and loss, such as the collapse of leading Bitcoin
exchange MtGox, and the recent ~19,000 BTC theft from BitStamp. These
security breaches of course harm the employees, customers and shareholders of
these companies, while the industry as a whole loses credibility with each new
event. Although some companies are employing sophisticated technology and
techniques to secure customer funds, other companies ignore the risks and
operate without necessary protection of digital assets.
The security of digital and physical assets has been standardized in every
financial industry around the world including banking, stocks, bonds, and
commodities. In order for the cryptocurrency space to meet the security demands
of customers, a common industry standard is required.
Through a collaboration between BitGo, Inc., a company committed to
building high-security bitcoin platforms, and CryptoCurrency Certification
Consortium (C4), a not-for-profit organization dedicated to the standardization of
the cryptocurrency industry, the CryptoCurrency Security Standard (CCSS) was
authored and published. Additional input was provided by Armory Enterprise
Security.
CCSS:1
Page 4 of 23
This standard will be a catalyst for the next phase of growth for Bitcoin and
cryptocurrencies. Companies that comply with the standard will instill more
confidence in their customers, investors, and business partners. Traditional
players like auditors and insurance carriers will see this standard as a pathway
for them to engage in the industry, much like predecessors SAS70/SSAE-16
engendered a vibrant ecosystem for the Internet.
The simple goal of this standard is to collect and define the current best
practices and give Bitcoin organizations a bar to meet when holding digital assets
for their customers.
Summary
CryptoCurrency Security Standard (CCSS) is a set of requirements for all
information systems that make use of cryptocurrencies. By standardizing the
techniques and methodologies used by systems around the globe, end-users will
be able to easily make educated decisions about which products and services to
use and with which companies they wish to align.
CCSS is designed to complement existing information security standards
(i.e. ISO 27001:2013) by introducing guidance for security best practices with
respect to cryptocurrencies such as Bitcoin. CCSS is not designed to substitute
or replace these standards. As with any standard, knowledgeable and
experienced security professionals and/or auditors are necessary when
implementing any information system to ensure coverage of all classes of attack
as well as the appropriate handling of all potential risks.
Overview
CCSS covers a list of 10 security aspects of an information system that
stores, transacts with, or accepts cryptocurrencies. An information system is a
collection of technologies (hardware and/or software), personnel, policies and
procedures that work together to provide a secure environment. A security aspect
is a discrete technique of securing one piece of an information system. The
minimum value of all 10 aspects determines an information systems overall
score within three (3) levels of increasing security: Level I is the lowest and offers
strong security measures, while Level III is the highest and offers the most
comprehensive security.
CCSS:1
Page 5 of 23
These 10 aspects are organized into 2 domains that help structure the
guidelines. A summary of the standard can be expressed with the CCSS Security
Matrix, which is provided on the next page:
CCSS:1
Page 6 of 23
CCSS:1
Page 7 of 23
Levels
CCSS is broken into three (3) levels of increasing security. Details of these
are outlined in this section.
Level I
An information system that has achieved Level I security has proven by
way of audit that they protect their information assets with strong levels of
security. Most risks to the systems information assets have been addressed by
controls that meet industry guidelines. While this is the lowest level within CCSS,
it still represents strong security.
Level II
An information system that has achieved Level II security has proven by
way of audit that they exceed strong levels of security with additional enhanced
controls. In addition to covering most risks to the information systems assets, the
use of decentralized security technologies such as multiple signatures have been
employed which exceed industry guidelines and provide redundancy if any one
key or person becomes unavailable or compromised.
Level III
An information system that has achieved Level III security has proven by
way of audit that they exceed enhanced levels of security with formalized policies
and procedures that are enforced at every step within their business processes.
Multiple actors are required for all critical actions, advanced authentication
mechanisms ensure authenticity of all data, and assets are distributed
geographically and organizationally in such a way to be resilient against
compromise of any person or organization.
CCSS:1
Page 8 of 23
Aspects
CCSS is comprised of 10 aspects, each of which represents a different
piece of the information systems security. These aspects, their descriptions, and
the possible values are explained in this section.
Key/Seed Generation
This aspect covers the generation of cryptographic keys and seeds that
will be used within a cryptocurrency system. The secure creation of cryptographic
keys and seeds requires two things to be secure: 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.
The 3 Levels associated with this aspect are as follows, building on top of
one another:
I. The following goals must be met to classify as Level I:
II. In addition to the Level I goals above, the following goals must be met
to classify as Level II:
CCSS:1
Wallet Creation
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 keys 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
CCSS:1
Page 10 of 23
confidentiality of the wallet that would make it difficult to associate a wallet with a
particular actor. The three levels associated with this aspect are as follows:
I. The following goals must be met to classify as Level I:
II. In addition to the Level I goals above, the following goals must be
met to classify as Level II:
CCSS:1
III. In addition to the Level II goals above, the following goals must be
met to classify as Level III:
Key Storage
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. The three levels
associated with this aspect are as follows:
I. The following goals must be met to classify as Level I:
CCSS:1
Page 12 of 23
II. In addition to the Level I goals above, the following goals must be
met to classify as Level II:
CCSS:1
Key Usage
This aspect covers the use of cryptographic keys and/or seeds to ensure
they are used in a secure manner that minimizes the risks to the confidentiality of
private keys and integrity of funds. This section does not cover the usage of key
backups which are only used in the event the primary key is
lost/damaged/inaccessible. A variety of risks are present when using keys that
can lead to the loss of funds including dirty signature vulnerabilities (i.e. re-used
R values), opportunity for malware to copy or modify keys, and malicious
insiders who use their authorized access to send unauthorized transactions. The
three levels associated with this aspect are listed below along with the security
goals for each level.
I. The following goals must be met to classify as Level I:
CCSS:1
Page 14 of 23
CCSS:1
III. In addition to the Level II goals above, the following goals must be
met to classify as Level III:
CCSS:1
Page 16 of 23
CCSS:1
Page 17 of 23
Page 18 of 23
CCSS:1
Page 19 of 23
team in order to remove the concerns from the system. These audits
decrease the risks associated with institutional blindness and provide
confidence in the organizations controls and procedures;
III. Regular Audits: 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 ones results allowing for a more focused and cost effective
assessment;
CCSS:1
Page 20 of 23
Proof of Reserve
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;
The three values associated with this aspect are as follows:
I. Proof of Reserve Audit Completed: 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;
II. Regularly-Scheduled PoR Audits: 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;
III. No PoR Audits Necessary (Open Ledger): 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;
Audit Logs
This aspect covers the information systems 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
CCSS:1
Page 21 of 23
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 systems ability to correct any inaccuracies.
The four values associated with this aspect are as follows:
I. Partial Audit Logs: Audit trails exist for a subset of actions that are
performed within the information system. Examples of this would
include recording audit information of all withdrawals and deposits
made with the system;
II. Full Audit Trail of All User Actions: 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;
III. Full Audit Trail with Backup: 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;
Conclusion
Securing an information system goes beyond simply choosing a fullfeatured piece of wallet software. It doesnt matter how secure the technology is if
the users arent properly trained in its use, or if proper procedures arent followed
to protect sensitive pieces of information.
CCSS provides a framework for organizations and developers to work
within to ensure their software and services meet a standard level of security, as
well as providing auditors and assessors a common methodology so that
systems can be graded consistently by anyone who understands the standard.
CCSS:1
Page 22 of 23
Appendices
Appendix A Audit Checklist
CCSS:1
Page 23 of 23