Advantages and Disadvantages of Blockchain

For all the multifaceted design, the potential of blockchain as a decentralized sort of record-keeping is about unbounded. From more prominent user privacy and raised security to lower handling expenses and fewer errors, BCT might just observe applications beyond those discussed in Section 9.4. In the following, we list some prominent advantages as well as disadvantages using BCT.

Advantages

Some advantages of blockchain are as follows:

  • • Remove human interventions, and improve accuracy in verification.
  • • Third-party verification is eliminated which reduces cost consumption.
  • • Decentralization makes it harder to tamper the blocks information.
  • • Transactions are secure, private, as well as proficient.
  • • Transparent technology in nature.
  • • Easy to trace any block information.

Disadvantages

Some disadvantages of blockchain are also listed as follows:

  • • Significant technology cost is associated with mining Bitcoin.
  • • Transaction delay is there.
  • • Low transactions occur per second.
  • • History of use in illicit activities.
  • • Susceptibility is being hacked.

Limitations and Drawbacks of Blockchain

Regardless of the radiant characteristics of blockchains, there are as yet numerous

impediments that will be considered in it. In the following, we list some limitations/

drawbacks of blockchain. [1]

Comparative Study on Authentication Protocols for Blockchain Technology

In this section, we consider various existing authentication protocols which were lightweight and ultra-lightweight in nature, and are aimed to adopt BCT including IoT environment. For such existing authentication protocols, a rigorous comparative study is performed on the security and functionality features, computation, and communication costs.

We only consider the lightweight and ultra-lightweight authentication protocols which can adopt the blockchain and use only the lightweight cryptographic primitives, such as “collision-resistant one-way cryptographic hash function” (for example, Secure Hash Standard (SHA-2) algorithm [2]), symmetric encryption (for example, Advanced Encryption Standard (AES) [1]), bitwise exclusive-OR (XOR), rotation operations in terms of left/right, and Hamming weight.

Fan et al. [16] suggested two 5G framed “radio frequency identification” (RFID) mutual authentication protocols applicable and utilized for IoT environment. Their first design is “lightweight radio frequency identification mutual authentication protocol with cache in the reader” (LRMAPC), whereas the second design is “ultra-lightweight RFID mutual authentication protocol with cache in the reader” (ULRMAPC). But, Li et al. [28] investigated Fan et al.’s first design (LRMAPC) [16] and shown that LRMAPC fails to restrict the impersonation of the reader, and resist the eavesdropping attack and tag forgery attack. Furthermore, their both schemes fail to stipulate untraceability property.

The “low-cost authentication protocol for the distributed database RFID system (HGLAP protocol)” [17] is targeted for the distributed database RFID system to provide a low-cost authentication. This protocol is considered efficient as it helps in minimizing the search time in the back-end database for a tag identity. A “challenge-response authentication protocol,” namely CRMAP protocol [40], relies on a “cryptographic collision-resistant hash function” and resists replay attack as well as spoofing attack. There are few more protocols that were intended either for “central trusted server” or “distributed database” using RFID systems [17,40].

An ultra-lightweight primitive-based scheme was presented by Mujahid et al. [35], which is known as “pseudo-Kasami code.” In their primitive, the secret for RFID structures is accomplished by techniques for using the sporadic property of secret keys. Furthermore, using “pseudo-Kasami code,” Hamming weight, bitwise rotation, and bitwise XOR operations. Another RFID protocol, namely, Gen2V2 [3], was proposed w'ith an extra security feature that can overcome the drawback of Mujahid et al.’s [35] protocol (for instance, untraceable command). This untrace- able command authorizes a tag to uncover the secret credentials (for instance, “Electronic Product Code” (EPC)). Since any unapproved reader gathering with Gen2V2 protocol can request as a favored reader itself and can likewise fix a tag’s untraceable component, such security highlight (untraceable command) prompts security assaults.

Toyoda et al. [48] structured a framework for RFID attached item for anticounterfeits so as to apply it in the post-supply chain for blockchain-based item ownership management problem. The security protocol was framed to empower every entity which includes the partners and customers of the supply chain so that “ownership of RFID tag-attached products” can be transferred and can be proved based on the EPC which is a fixed component in the overall process. Based on the EPC, an attacker has the freedom to monitor the progress of the RFID-tag-connected items.

Sidorov et al. [44] designed a scheme for supply chain using ultra-lightweight RFID for blockchain. The problem with this scheme is that the communicated messages are computed using simple bitwise rotate operations and transmitted them over a public channel, which gives an advantage to the attacker to extract the tactful credentials. According to Masoumeh and Mahyar’s recommendation [41], the protocol still be insecure even if the applications utilize single or multiple “bitwise rotate” (ROT) with “bitwise XOR” operations.

A new' design, namely “lightweight blockchain-enabled RFID-based authentication protocol for supply chains” (LBRAPS) in 5G mobile edge computing environment was proposed very recently by Srinivas et al. [22]. LBRAPS is efficient, because it was based on bitwise rotation, bitwnse XOR, and “one-w'ay cryptographic hash” operations. Furthermore, it is showrn to be secure against various attacks.

Comparison of Security and Functionality Features

In this section, as shown in Table 9.6, the existing authentications schemes of Sidorov et al. [44], Mujahid et al. [35], Fan et al. [16], and Srinivas et al. [22] are compared on the basis of the listed security and functionality features SFFA, (/ = 1,2,..., 11). It is worth noticing that these features are extremely important to ensure the security of the authentication schemes w'hich can be applied in real-world applications.

By SFFAf: “anonymity property,” it is meant that an attacker cannot know the identity of communicating entities during the communication. By SFFA2: “trace- ability property,” we mean that the attacker cannot link between tw'o messages sent/ received by the same entity during different sessions while executing an authentication protocol. The security feature SFFA}: “privileged-insider attack” means that an insider user of a trusted party, being a privileged-insider attacker, can misuse the sensitive credentials of an entity (for example, if a user provides his/her secret credentials to the trusted authority during the registration process). With the help of the knowm registration information, the insider attacker can also mount other attacks in a network. In SFFA4: “denial-of-service attack,” an adversary takes “an action that prevents authorized users from accessing targeted computer systems, devices or other network resources” [15]. By SFFA5: “replay attack,” an attacker may try to misdirect another legal entity by recording the communicating messages and later reusing them in other attack(s) [15]. Under SFFAh: “impersonation attacks,” an attacker successfully assumes “the identity of one of the authorized entities in the system or in a communication protocol” [15]. By SFFA7: “man-in-the-middle attack,” an attacker intercepts “the transmitted messages and then attempts to modify or delete the contents of the messages delivered to the recipients” [15]. SFFA9: “Ephemeral Secret Leakage” (ESL) attack means that if only the short-term (temporary) secrets or long-term secrets are compromised, the session key computation between two communicating parties should be computational infeasible task by an attacker.

TABLE 9.6

Comparison of Security and Functionality Features

Attribute

Sidorov et al. [44]

Mujahid

et al. [35]

LRMAPC

[16]

U LRMAPC 116]

Srinivas et al. [22]

SFFA,

/

X

/

/

sffa2

/

/

X

X

/

SFFA,

X

X

/

/

SFFA4

/

X

/

/

SFFA5

/

/

/

/

SFFA6

X

X

X

/

SFFA,

X

X

/

/

SFFA,

/

/

/

/

SFFA,

X

X

X

/

SFFA,,

/

X

X

X

/

SFFAn

/

X

X

X

/

Note: /: "a scheme supports an attribute or resists an attack”; x: “a scheme does not support an attribute or does not resist an attack.”

SFFA,: “anonymity property”; SFFA2 “traceability property”; SFFA“privileged-insider attack”; SFFA4: “denial-of-service attack”; SFFAs: “replay attack”; SFFA,;. “impersonation attacks”; SFFA7: “man-in-the- middle attack”; SFFAs: “mutual authentication”; SFFA"ephemeral secret leakage (ESL) attack”; SFFA l0: “formal security verification using automated validation of Internet security protocols and applications (AVISPA) tool [7]”; and SFFA,,: “whether blockchain enabled.”

This means that both forward and backward secrecy properties need to be preserved under the resistant of an ESL attack.

In recent years, the formal security verification using the automated software verification tool becomes very popular [14,45-47,53-55]. In this case, we have considered a widely accepted automated formal security verification tool, known as “Automated Validation of Internet Security Protocols and Applications” (AVISPA) [7]. AVISPA is “a push-button tool for the automated validation of Internet security-sensitive protocols and applications, and it also provides a modular and expressive formal language for specifying protocols and their security properties, and integrates different backends that implement a variety of state-of-the-art automatic analysis techniques” [7]. A tested security protocol requires to be implemented using the “High-Level Protocol Specification Language” (HLPSL) [7], which is a “role-oriented language.” There are two kinds of roles defined in HLPSL: (1) basic roles and (2) composite roles. While the composite roles are compulsory to be defined, the basic roles need not be defined compulsorily. The HLPSL code is then translated into the “Intermediate Format” (IF) using the HLPSL2IF translator, and the IF is given to one of the four available back-ends of AVISPA: “On-the-fly Model-Checker (OFMC),” “Constraint Logic- Based Attack Searcher (CL-AtSe),” “SAT-Based Model-Checker (SATMC)and “Tree Automata based on Automatic Approximations for the Analysis of Security Protocols” (TA4SP). After that, the “Output Format” (OF) will be produced by one of the back-ends, which will specify whether tested protocol was “safe” or “unsafe.” AVISPA has the ability to test a security protocol for the “replay attack” and “man- in-the-middle attack.” For more detailed discussions on AVISPA and its HLPSL, the interested readers can be directed to the user manual documents of AVISPA and HLPSL provided in Ref. [7].

It is worth seeing that the authentication protocols of Mujahid et al. [35], LRMAPC [16], and ULRMAPC [16] are not exactly blockchain enabled. The comparative analysis on security and functionality features shown in Table 9.6 suggests that LBRAPS [22] is only supporting functionality features as compared to other state-of-art authentication protocols.

Comparison of Communication Costs

In this section, the comparison of communication costs of the existing authentication schemes is performed by considering 160 bits for each of identities, hash output (if SHA-1 hash function [2] is applied), random numbers, and Hamming weight, and 32 bits for timestamp. For “Hello” message in the protocols of Sidorov et al. [44] and Mujahid et al. [35], and “Query” in two protocols of Fan et al., namely, LRMAPC [16] and ULRMAPC [16], we have considered 160 bits. The total communication cost of Sidorov et al.’s scheme [44] is 1760 bits, Mujahid et al.’s scheme [35] is 960 bits, LRMAPC [16] is 1,440 bits. Fan et al.’s ULRMAPC [16] is 1632 bits, and Srinivas et al.’s LBRAPS [22] is 2,240 bits. The details are displayed in Table 9.7. In our observation, LBRAPS consumes more communication cost as compared to other schemes. From Table 9.6, it is observed that LBRAPS is the only scheme which is potentially restricting the listed security attacks and is also able to protect RFID system effectively. Furthermore, in comparison with other schemes shown in Table 9.6, only two schemes (LBRAPS and Sidorov et al.’s scheme [44]) are aimed to integrate their design towards blockchain and the other schemes (Mujahid et al.’s scheme [35], LRMAPC [16], and ULRMAPC [16]) are not suitable to integrate them towards blockchain. As a security concern, Mujahid et al.’s scheme and ULRMAPC [16] fail to design session key establishment between the communicating entities.

TABLE 9.7

Comparison of Communication and Computation Costs

Attribute

CCB

NEM

CCT

Sidorov el al. [44]

1760

5

15Timeim + 14TimeKor +12TimeXoR ~ 0.0048 s

Mujahid el al. [35]

960

4

Timenw + 29TimeKor + 29Timexon ~ 0.00032 s

LRMAPC [16]

1440

5

(/i + к + 2)TimexoR + (« + k + 6)TimeiM, ~ 0.00032(и + k) + 0.00192 s

ULRMAPC [16]

1632

5

22TimexoR + 977/ne/jor(neglibile time)

Srinivas el al. [22]

2240

5

12Timena:ih + 5TimcROT + 251'imexor ~ 0.00384 s

Note: CCB: communication cost in bits; NEM: number of exchanged message; and CCT: computation cost with rough estimated time in seconds.

Comparison of Computation Costs

In this section, the comparison of computation costs among the existing state-of- art authentication schemes is made. For this purpose, we consider the computational time as follows: TimeHash, TimeXOR, TimeR0T, and TimeHW are the execution time taken for one-way hash function, bitwise XOR, rotation operations in terms of left/right, and Hamming weight, respectively. According to the experimental results used in [45], TimeHash ~ TimeHW ~ 0.00032 seconds. As TimeROT and TimeXOR are very negligible, we omit these costs in comparison. In LRMAPC [16] protocol, in the cache, the number of keys is denoted by n and the size of the keys in the database is denoted by k. The total computation cost of the compared schemes of Sidorov et al. [44] is 5TimeHW + l4TimeROT + 12TimeX0R ~ 0.0048, Mujahid et al. [35] is 1 TimeHW + 29TimeROT + 29TimeXOR ~ 0.00032, Fan et al.’s LRMAPC [16] is (n + к + 2) TimeX0R + (n + к + 6) TimeHasll ~ 0.00032 (n + k) + 0.00192, ULRMAPC [16] is 22TimeXOR + 9TimeR0T (negligible time), and Srinivas et al. [22] LBRAPS is 12TimeHash + 15TimeROT seconds. The details are provided in Table 9.7. It is observed that the computation costs of LBRAPS are less compared to those for Sidorov et al.’s scheme [44]. Furthermore, the computation cost of Mujahid et al.’s scheme [35] is less in comparison with LBRAPS and Sidorov et al.’s protocols, but their scheme fails to provide session key establishment between the entities. Mujahid et al.’s scheme [35] cannot be considered as efficient. Although we observe that ULRMAPC [16] consumes minimal computation cost by distinguishing other schemes as shown in Table 9.7, due to failures of the functionality and security attributes, ULRMAPC [16] cannot be considered for practical application. Overall, we observe that Srinivas et al.’s LBRAPS [22] proves to be effective and robust against various knowm attacks.

  • [1] Highly expensive: The nodes need logically basic prizes for achievingtransactions in a business, which work with the code of interest andsupply. • Small-scale ledger: This could impact security and perpetual quality of theblockchain, and all of the data set is stored in it. • Denser transactions: The transactions could be more deferred than fundamental procedure even with the non-appearance of the involved thirdparties. • Transaction expenses and speed of network: The transactions charge of theBCT is genuinely high in the wake of being advanced as “about free” during the initial couple of years. Similarly, the enlisting capacity and reactionspeed of BCT cannot meet the necessities of the high-recurrence trade anddispatch of smart grids. • Error risk: This threat is ceaselessly present if the human factor is verifiednotwithstanding the way that the blockchain is an astoundingly confirmeddevelopment. • Wasteful: Every node in the blockchain must approve the transactions madeand keep up the agreement over the blockchain. This is inefficient, becauseeach node rehashes the undertaking to arrive at the accord settled upon.
 
Source
< Prev   CONTENTS   Source   Next >