Don’t be fooled: Blockchains are not miracle security solutions

The idea that blockchains may bring benefits in terms of cybersecurity is a widespread myth. Even the US Department of Defense fell for this myth in a recent report “DoD Digital Modernization Strategy” with plans to build a “Block Chain Cybersecurity Shield” allowing to “transmit secure messages” and “develop unhackable code.” It’s important to set the record straight on these complex topics.

But before I get into it properly, let’s begin with a few general points to set the stage:

1) Blockchains are not designed to solve security issues. They minimize trust. They allow unidentified users to exchange scarce digital unit of value, by preventing double spending without relying on trusted third parties. If blockchains happen to include security features, it’s not inherently but rather by design, in order to achieve trust minimization.

2) The words “blockchain” and “distributed ledger” have lost their meaning. If somebody generalizes a feature of Bitcoin such as tamper resistance to all the other blockchains, then that person is either ignorant or a fraud. At this stage, for 10 blockchain implementations there are 10 different risk profiles. Therefore, the link between blockchains and cybersecurity is the same as between the coding language Java and cybersecurity (no link!).

The 💜 of EU tech

The latest rumblings from the EU tech scene, a story from our wise ol' founder Boris, and some questionable AI art. It's free, every week, in your inbox. Sign up now!

3) Blockchains are regularly hacked. This site lists 68 incidents corresponding to nine types of security weaknesses.

4) If blockchains use cryptography, most of them are not encrypted. The shared data is generally accessible to all the users.

5) Blockchains are essentially distributed transaction logs. Even if they were systematically secure, you would only have a secure audit trail: A cryptographic proof that someone did something when. You wouldn’t have any other security features such as identity and access management, endpoint security or network security; and you wouldn’t be protected against brain hacking (phishing, social engineering, etc.). Back to point no. 3.

We could almost stop there by saying that blockchains, like any other systems, are as secure as you design them. They must be considered from an ecosystem perspective including users, physical devices, software clients and third-party service providers.

Digging deeper

There are three types of blockchain implementation, with very distinct features: Real blockchains, pseudo blockchains, and conventional applications leveraging real blockchains as third-party solutions.

a) Real blockchains are public permissionless systems not controlled by anybody. Assuming the network is sufficiently large, the ledger itself is redundant, tamper evident and tamper resistant. The ledger’s attack surface is generally very small (POW systems are only vulnerable to 51-percent attacks), precisely because it’s designed to work in adversarial environments. 

Why do I say generally? The more layers you add to the system, the more the attack surface grows. For instance, Ethereum allows to execute code on its platform making it vulnerable to uncontrollable flaws, such as the one that wrecked The DAO and led to a fork in Ethereum. In this context, the security audit of the software code must be carried out even more carefully than for a conventional system.

If we consider these blockchains in the typical configuration of a user with a physical client, on which a client software is installed and connecting to the “network,” their characteristics are similar to conventional distributed systems:

• Users must be trained in security — they are the first line of defense!
• Physical clients must be password protected, use hardware encryption, an antivirus, a VPN, a software firewall and a backup solution
• Software clients need to be updated/patched regularly and use two-factor authentication
• Internet connections must be secured (password, browser configuration, physical firewall, etc.)

b) Permissioned blockchains used in a business context are pseudo blockchains. They keep the complex design of real blockchains and remove their key benefit. It’s software by another name, a marketing trap. They are uninteresting because it’s almost always possible to implement the same services, but cheaper and faster, with regular databases and cryptographic libraries. In theory a pseudo blockchain audit trail should be more secure than the one from a conventional system, but I wouldn’t trust it because the solution provider is incompetent for suggesting a blockchain in the first place. We cannot say anything a priori about the security of such systems without a detailed evaluation.

c) Some firms, having understood that pseudo blockchains are uninteresting, recommend combining traditional business applications with real blockchains, leveraged as external transaction rails. There are still some conceptual flaws in this approach, as distributed systems are always slower and more expensive than their centralized counterparts. From a cybersecurity perspective, the external system should be considered as a third-party solution and a security due diligence should be conducted as for any other third party. The CISO, CRO, and CCO will be obstacles on the path of anybody who wants to push that in a bank. For instance, the Ethereum blockchain used by Societe Generale to issue a bond wouldn’t pass DFS part 500.11 cybersecurity requirement in the state of New York.

To conclude, blockchains are neither security holes nor miracle security solutions. They must be considered within their ecosystem and be addressed using standard security methodologies such as NIST CSF, FFIEC CAT, or ISO27001. Their security must be assessed thoroughly, and security controls must be implemented to fill the identified gaps, based on the organization’s risk appetite, like for any other system.