This is a guest posting by Michael Solomon PhD CISSP PMP CISM
Blockchain technology allows multiple people or devices that don’t trust one another to share trusted data. The way blockchain works makes it nearly impossible for a malicious party to tamper with the data without being caught, so it has been called “unhackable technology.”
But is blockchain really unhackable? Let’s look at the security and privacy that blockchain really provides.
Blockchain is widely predicted to disrupt business practices as we know them. Most expectations are that blockchain technology, and the applications that run on the technology, are more secure than legacy alternatives. But is that truth or hype? The answer, as with nearly all technology questions, is “It depends.”
Blockchain app security depends on doing these three things well:
- Applying blockchain in appropriate use cases
- Designing security into the application from the beginning
- Extensively testing for secure operation before deploying the application
These three principles may sound pretty obvious, but they are often overlooked or ignored when schedules and budgets get tight. But because blockchain is fairly new, it’s essential to be purposeful when the goal is designing secure applications on this technology.
Get TestRail FREE for 30 days!
The Basic Tenets of Security: The CIA Triad
Before getting into whether blockchain apps are really secure, let’s look at what security means.
Blockchain technology is all about sharing a ledger of data among untrusting nodes. The primary focus is on the security of the data.
At its core, data security is based on ensuring three properties:
- Confidentiality: Only authorized subjects can access protected data
- Integrity: Only authorized subjects can modify protected data
- Availability: Authorized subjects can access protected data on demand
These three tenets of security are so foundational, they are often referred to as the CIA triad.
Most legacy approaches to data security depend on some trusted authority to limit access to data and enforce access restrictions. The key to this approach is that all users must trust the authority. Blockchain makes it possible to remove the trusted authority and still provide security guarantees.
Confidentiality
Every authorized user can access the whole blockchain. For public, or permissionless, blockchains, that means everyone can see all the blocks. For private, or permissioned, blockchains, the blockchain owner enforces access restrictions as to who can access the blocks. Because private blockchains reintroduce the trusted authority, we’ll just focus on public blockchain security in this article.
Public blockchains provide confidentiality through encryption. Instead of preventing access to the data, access is controlled by whoever has the decryption key. Even though everyone else can see your data stored in the blocks, only you (and anyone else you give your key to) can decrypt the block contents. Of course, this leads to other key management issues, but we’re focusing on the basics of security guarantees here.
Integrity
This is an area in which the blockchain approach is novel. Blockchain data integrity relies on several complementary techniques.
Firstly, all new blocks must be approved by more than half of the participating nodes in order to be added to the blockchain. That means that while anyone can add data, everyone must agree that the data is valid for the blockchain. In blockchain, the majority rules. All nodes agree to accept the majority view of correct data.
Once a block is added to the blockchain, it cannot change. Blockchain implementations use strong cryptographic hashes to ensure that each block remains in its original state once added to the chain. Hashes make it fast and easy to verify the integrity of the blockchain, and any small change to any block is immediately evident.
Availability
The last basic security guarantee is that data is available on demand. Most legacy application data storage techniques rely on central storage, which implies a single point of failure. By its very design, blockchain technology ensures that a complete copy of the entire blockchain is shared among many nodes, and the integrity of the blockchain is maintained among all the nodes.
In other words, every full node stores an identical copy of the whole blockchain. If any node fails or goes offline, the blockchain is still available on the other nodes. This design feature removes the single point of failure and strengthens availability.
Join 34,000 subscribers and receive carefully researched and popular article on software testing and QA. Top resources on becoming a better tester, learning new tools and building a team.
Blockchain, Apps and Security
Data security is at the heart of all security concerns. Even when we talk about application security, we’re really talking about how well the application protects data security. So, are blockchain apps really secure?
While blockchain doesn’t automatically provide security, its features do lend themselves well to some aspects of security. You’ll get the best results by understanding what blockchain can do for your organizations, and then applying the technology to the right use cases.
However, to complicate matters, all the hype surrounding blockchain technology has introduced some perceptions and beliefs that just aren’t correct. Let’s look at three major blockchain security myths.
Myth 1: Blockchain encryption makes it secure
This is one comment I see repeated over and over. Transactions that are stored in blocks are generally encrypted, but that isn’t required. And encrypting data can provide confidentiality, but only if the encryption keys are managed securely. Managing keys is a challenge that extends far beyond blockchain.
Blockchain isn’t built on encryption, but cryptographic hashes do play an integral part. Each block is connected, or linked, to the previous block in the chain by recording the cryptographic hash of the previous block in the current block header. Because the previous block’s hash is part of the current block’s header, part of that data is used to calculate the hash of the current block (which is then stored in the block header of the next block).
The use of a cryptographic hash provides a guarantee of integrity only. If any block is modified, the hash value of the modified data will not match the hash value that is stored in the next block. That situation would essentially break the chain and data would be easy to detect. While this feature does provide integrity, it does not provide confidentiality or availability.
Myth 2: Blockchain is unhackable
Blockchains are said to be immutable. That means that once a block is added to the chain, it can never be modified. That is generally true, but not as an ironclad guarantee. A better way to phrase it is that blockchains are tamper-resistant — or at least tamper-evident. Hashes provide the ability to easily detect any meddling with the blocks.
However, it is theoretically possible to modify a blockchain and escape detection. The most popular consensus mechanism in blockchains, proof of work, requires that a majority of nodes validate and accept new blocks. Once a majority consensus has been achieved, remaining nodes accept the majority decision and allow the new block. As long as the nodes are free from malicious collusion, this approach virtually guarantees blockchain integrity.
On the other hand, if 51 percent or more of the nodes on a blockchain network agree to falsify a new block validation, an unauthorized block could be added to the blockchain and minority nodes would be forced to accept it. However, the mutual distrust among nodes and the overhead required to carry out such collusion make this type of attack expensive and unlikely.
Myth 3: Smart contracts are error-free
Blockchains store much more than just data. Smart contracts are procedures, or even small applications, that are stored in blocks on the blockchain and run on every node. The purpose of smart contracts is to provide a consistent set of rules for interacting with blockchain data. Smart contracts are crucial for verifying transactions before they are allowed to be recorded in a block.
For example, a smart contract may provide very basic financial transaction validation. Suppose you are buying a cappuccino using bitcoin. Before you are allowed to transfer your bitcoin to the coffee shop, a smart contract would check your bitcoin balance to ensure that you have sufficient funds to continue. This is a simple example of how smart contracts govern blockchain data interaction.
Smart contracts are stored in blockchain blocks (which means they are immutable and can’t be changed) and run automatically and consistently. You can’t turn off smart contracts, and you can’t change them once they’ve been deployed. They are just blocks of code that developers wrote to carry out some tasks.
Just like with any other software, smart contracts may not always produce the desired results. They may be buggy.
Designing and Testing for Security
Just as with all other types of software, blockchain apps can be secure, or they can lack good security. It is important to consider data security from the very beginning of the design process. And because smart contracts are immutable upon deployment, getting it right the first time is of upmost importance.
If you’re wondering how bugs are handled in smart contracts, it is possible to address program flaws. If you do find a bug in your smart contract code, you can simply invalidate the old code and deploy a new version. But you have to be careful that all references to the old code address are updated and that any blockchain data that was added using the old smart contract is valid using the new smart contract. In some cases, the data format has changed. This can cause some headaches when trying to fix bugs in smart contracts and trying to juggle multiple data formats. These issues make it that much more important to get it right the first time.
There is no substitute for fully testing software applications to identify flaws. Blockchain apps are no different from legacy apps in this regard. Comprehensive testing for proper functionality and data security will take more time, but it will always result in cleaner software with less rework required.
At the end of the day, whether blockchain apps are reliably secure depends on the quality of your design and testing.
Article written by Michael Solomon PhD CISSP PMP CISM, Professor of Information Systems Security and Information Technology at University of the Cumberlands.
Test Automation – Anywhere, Anytime
