Security for blockchains and more advanced Distributed Ledger Technologies (DLTs) is evolving rapidly. As soon as interest in the original blockchain grew past crypto-currency into mainstream business applications, it became apparent that the core ledger would need to augmented in several ways.
The naked blockchain by nature has to be open to all participants, to achieve the scale needed to keep out corruption of Bitcoin, but in real world business, account holders need to be subject to entry rules, and the "miners" that support the network need a governance, system. These considerations lead to with permissioned blockchains with access controls. Another enterprise requirement is confidentiality; most businesses need their records generally kept out of the public domain, and that means encryption or blockchain entries before they are lodged.
Access controls and encryption might be regarded as conventional security layers, but what few people appreciate is that these measures conflict with the rationale of the original blockchain algorithm, which was expressly meant to dispel administration.
My new Constellation Research paper looks at these tensions, what they mean for public and private blockchain systems, and provides some detailed guidance for blockchain technology security:
- Permissioned blockchains and private DLTs must implement access controls to determine who has the appropriate privileges to write to the ledger.
- Remember that any administrative agencts operating off-chain dilute the benefits of Proof of Work algorithms.
- If confidentiality is required for sensitive data written to a public blockchain, then additional key distribution and management is needed, but these can create single points of failure needing mitigation.
- Private DLTs become much more concentrated compared with pure blockchains, and need administration to protect against insider threats and to prevent fraud.
- The quality of cryptography in all customised DLTs is critical. Algorithms must be correctly programmed and must execute without interference.
- Hardware Security Modules (HSMs) are increasingly practical, thanks to dedicated cloud HSM options emerging at cloud providers and should be considered. HSMs should be certified to Common Criteria EAL4+, or FIPS 140 level 3+.
- Software quality in general must not be overlooked. Bugs in “smart contracts” and novel blockchain cases like the “Distributed Autonomous Organization” (The DAO) have made the headlines. DLT projects must take care of the software development lifecycles.
A snapshot of "How to Secure Blockchain Technologies" can be downloaded here.