Is the Blockchain really secure?
What is a Blockchain?
A Blockchain is a P2P distributed ledger in which all the blocks agree to the state of a block after pre-requisite conditions are fulfilled for the transactions.
The Blockchain has mainly four different fields:
- Previous Hash: Hash pointer pointing the previous block (a chained data structure)
- Timestamp: Approximate time at which the block is created.
- Nonce: A unique number counter (for the proof-of-work consensus) used to prevent a block from replaying attacks.
- Merkle Root tree: Also knows as a Binary Hash Tree having multiple cryptographic hashes, in which the intermediate nodes are hashed and pointing towards the next node and the leaf node contains the transaction with a unique hash fingerprint. It uses double-SHA256 and the time complexity to find a transaction is O(log(n)) in base 2.
"previous_hashblock" : "007aae23389a8e6ce6ab5951d76f832065164afc90947bb320161bbf18eb98df"
"hash_block" : "ab4395482119d6689ccfbd9834761502eaf763ab7776dcf2a92435f21bb48700",
"version" : 1,
"merkle_root" : "94baab89f3a32518a98c31bc87f618f73373e2cc825298fadb32100278afb361",
"timestamp" : 2318005781,
"nonce" : 3976253884,
"next_hashblock" : "2987d9ff728a8e5116ab5951d76f499856428afcabf27ee320161ddfbdfa7602"
}
Bitcoin verification of a block using P2PKH (Pay-to-pubkey Hash):
A) scriptSig:
Signature + public-key
B) scriptPubKey:
op_DUP -> Duplicate public-key so that changes could be made in the duplicated key
op_hash160 -> calculate Hash of the duplicated public-key (previous step)
op_equalverify -> verify if hash160(duplicate_pubkey) ==
hash160(initial_locked_pubkey)op_checksig -> op_checksig checks the signature against the public key
<signature><public-key>OP_DUP OP_HASH160 <public-key-hash> OP_EQUALVERIFY OP_CHECKSIG304502203f004eeed0cef2715643e2f25a27a28f3c578e94c7f0f6a4df104e7d163
f7f8f022100b8b248c1cfd8f77a0365107a9511d759b7544d979dd152a955c867af
ac0ef78601044d05240cfbd8a2786eda9dadd520c1609b8593ff8641018d57703d02ba687cf2f
187f0cee2221c3afb1b5ff7888caced2423916b61444666ca1216f26181398cOP_DUPop_hash1602E67490797078511CFDE499434ED6A564AD41EF0op_equalverifyop_checksig
Security attacks in the blockchain:
1. 51% Attack:
So, we are already aware that crypto mining requires a large amount of computing power, especially for a high-scale public blockchain. But, what if a miner or a group of miners gather enough resources and try to attain more than 50% of a blockchain network’s mining power? Having more than 50% of the power means having control over the distributed-ledger and the ability to manipulate it. Specifically, in a PoW-based blockchain, if a single minor hash function occupies more than 50% of the entire blockchain’s total hash function, a 51% attack gets initiated. This happens if the mining hash rate gets concentrated to a single mining pool. Furthermore, private blockchains are not affected by 51% attack.
By starting a 51% attack, an attacker can arbitrarily manipulate and change the blockchain information and performs the following actions:
I) Reversal of the transaction and initiating a double-spending attack*.
II) Suppressing the transaction orders.
III) Disrupting the general mining operations of honest miners.
IV) Affecting the verification of normal transactions.
*Double-Spending attack
A successful transaction is duplicated with the same funds as the token spent twice for a legit transaction.
But if a miner controls more than half of the computational capacity amongst all miners, in theory, losing their power to dominate double-spending incentives.
You may ask why? Let’s assume double-spending happened in a single large mining pool which controls a 51% hash rate. If a double-spending takes place in the same mining pool itself such that both source and destination were present in that same pool, may results in not achieving a double-spending incentive.
2. Liveness Attack:
In this attack, acknowledgement time or the confirmation time of the target transaction is detained.
This attack gets executed in 3 phases:
I) The phase of attack preparation: In this phase, the attacker gains an advantage over the honest miners (which is also known as selfish-mining attack*) before the transaction is broadcasted to the public chain. The attacker secretly builds the private chain longer than the public chain.
II) Transaction denial phase: In this phase, The attacker holds privately the block containing the transaction to prevent it from getting added to the public chain.
III) Blockchain retarder phase: In the growth process of the public chain, transactions cannot be held on in private for a certain period. In this case, the attacker will publish the block containing transactions. When the depth of the block containing the transaction is higher than a constant length, the transaction is considered valid in some blockchains models. The attacker will therefore continue to build a private chain to harness an advantage over the public chain. Finally, The attacker will then publish blocks secretly into the public chain to slow the growth rate of the public chain. The liveness attack ends when the transaction is checked in the public chain and verified using the digital signature. So till the delta time, the blocks of transactions are considered to be stale.
*Selfish-Mining Attack
So this is how it happens, firstly attackers try to fork the public chain by making the recognized block private then these so called illegtimate miners try to maintain a longer private chain than the public/genesis chain to mine through it and holding new blocks.
At the same time, honest miners continue to put efforts in the public chain without knowing about this private chain forking. As the public chain almost catches the length of the private branch, the new block mined by the attacker is revealed, thus misspending honest miners’ computing power and keeping them from earning what they should have earned.
3. Sybil Attack:
Sybil attack happens when the blockchain nodes behave differently for different transactions such that there is no actual identity of the node.
Publishing the fraud transactions with different identities may harm the entire network affecting the integrity or consistency of the network as the attacker nodes disagree with the smart contract, resulting in not updating the honest node’s ledger.
Furthermore, an eclipse attack* can promote a Sybil attack because, in a distributed-ledger environment, an attacker tries to take over a blockchain node or a subset of nodes (i.e., victim nodes) by manipulating the immediate neighbour nodes of the victim node. In this way, the victim node may get confused as it disagrees with the smart contract to update the transaction with the neighbour nodes as they have turned out to be rogue. The attacker takes advantage of this and isolates the victim node from its operational environment. In this way, a set of nodes are controlled by an attacker.
Eclipse attack can even give rise to the double-spending attack, as the victim nodes get misguided instructions from the attacker to accept an invalid transaction or accept a transaction with the same input which has already been validated by the legitimate chain. Moreover, an attacker fools the victim node in wasting miner power to find the next block as the victim node is unaware of the attack.
Therefore, it is recommended to:
i) follow the private blockchain model.
ii) apply a behaviour-based smart contract policy among the blockchain nodes to identify, if nodes are accepting or updating the block from a single user.
iii) apply an incentive-based smart policy to reward honest nodes for identifying a Sybil node.
4. Fork Attack:
Forking happens when the different blocks disagree with each other to update UTXO (Unspent transaction output) due to two cases:
i) Intentional forking for software up-gradation: In this forking, blockchain developers intentionally fork the chain to improve the time efficiency, scalability or any other factors which improve the quality of the blockchain.
ii) Flaws in smart contracts or consensus mechanisms: In this forking, the attacker intentionally modifies the smart contract which follows a certain consensus algorithm.
Due to the above process, the nodes in the blockchain are of two types, i.e., old nodes and new nodes. The transaction blocks delivered by the old nodes may or may not be accepted by the newly established nodes and vice versa, because of which fork problem arises.
A potential attacker can build a consensus agreement that makes the blockchain fork and disrupt the consistency and integrity of the chain. Newly deployed agreement in consensus rule also gets changed between the decentralized nodes. Therefore, it is recommended to implement a robust consensus agreement protocol as the consensus may ensure that the original information moves safely to the subsequent blocks. The three main features of an acceptable consensus model are consistency, aliveness and fault-tolerant.
There are two types of forking:
i) Hard Fork: As we know that forking happens due to the disagreement between the blocks. Additionally, the new nodes request the old nodes to update with the current version of the consensus agreement. If old nodes disagree with the new consensus immediately, the newly formed blockchain nodes (which is following the new consensus) continue to build a separate chain creating a new version of history which implies that the genesis chain doesn’t exist for the new separate chain.
Is it possible to identify whether the hard fork is due to the ethical developers or an attacker ? Let me know in the comment section !!!
The following areas get affected due to hard forking:
i) New op-codes for implementation of the new chain.
ii) Changes to the size limits of the overall chain and the distributed ledger.
iii) Modification in the next block mining rate.
iv) Can fix bugs (or can create some).
ii) Soft Fork: In soft forking, the new nodes request the old nodes to update with the current version of the consensus agreement which need not be agreed upon immediately. Old nodes gradually reflect the consensus up-gradation over a period, as the blockchain can have many blocks and practically updating nodes with a consensus protocol may take time to absorb the changes. We can add new features to the chain which only limit the set of valid transactions and need to cover the majority of the chain nodes to enforce new consensus.
Soft Fork Example {Pay-to-scipt-hash -> P2PKH}<signature>
<<public-key> OP_CHECKSIG>OP_HASH160 <hash-of-redemption-script>
OP_EQUAL
Furthermore, soft forking will have only one chain, unlike hard forking. All the old nodes will approve the new transactions as per the new consensus rule but, there is a risk of mining the “now-invalid” or stale blocks. Also, the old nodes only approve the hash fingerprint but do not run the embedded redemption script, unlike new nodes which approve the block hash fingerprint as well as executes the redemption script.
Use Cases:
- Cloud security via Single-sign-on authentication or Federated-sign-on authentication using a blockchain model.
- Protection from Smart Contract based internet of vehicles.
- Applying security in Digital fingerprint-based authentication for distributed device software/firmware up-gradation.