Abstract
Communication security between IoT devices is a major concern in this area, and the blockchain has raised hopes that this concern will be addressed. In the blockchain concept, the majority or even all network nodes check the validity and accuracy of exchanged data before accepting and recording them, whether this data is related to financial transactions or measurements of a sensor or an authentication message. In evaluating the validity of an exchanged data, nodes must reach a consensus in order to perform a special action, in which case the opportunity to enter and record transactions and unreliable interactions with the system is significantly reduced. Recently, in order to share and access management of IoT devices information with distributed attitude a new authentication protocol based on blockchain is proposed and it is claimed that this protocol satisfies user privacy preserving and security. However, in this paper, we show that this protocol has security vulnerabilities against secret disclosure, replay, traceability, and reuse attacks with the success probability of 1 and constant complexity of also 1. We also proposed an improved blockchain-based authentication protocol (IBCbAP) that has security properties such as secure access management and anonymity. We implemented IBCbAP using JavaScript programming language and Ethereum local blockchain. We also proved IBCbAP’s security both informally and formally through the Scyther tool. Our comparisons showed that IBCbAP could provide suitable security along with reasonable cost.
1. Introduction
With the advent of Internet of Things (IoT) technologies, a large number of intelligent devices have been developed and integrated into daily life [1–5]. By increasing number of devices and users, current architecture and the communication protocols (centralized system) cannot give enough response to system requirements such as authentication, authorization, and access management. Although security and privacy are important issues in communication, various solutions have been proposed for security and privacy in Internet of Things (IoT) networks [6–12]. One of the important solutions is use of distributed networks instead of centralized or decentralized networks [13–20]. A new and powerful distributed system is blockchain [21] which for the first time proposed by Satoshi Nakamoto. Blockchain is a technology comprising few old concepts, such as the ledger and the consensus (the agreement of members of a group on an issue). This technology combines these concepts with the help of a peer-to-peer network to access a distributed database with privacy preserving and security properties. Blockchain has many security features such as integrity, distribution, and tamper-proofing. In a blockchain network, all network members take part in the verification process of information which takes part in the alternative role of the trusted third party (TTP) on the system. It is very difficult to manipulate information because of public surveillance of information. Public surveillance is done by a method called consensus that means 51% of network members need to collaborate to unauthorized changes in the information. Distributing the role of the TTP among network members has also reduced the likelihood of distributed denial of service (DDoS) attacks. As a result, system security is ensured. In contrast, the processing amount and system messages sent to the members of each node in the network are very high. Also, because of the transparency of all information, privacy preserving becomes difficult and new solutions are needed and these solutions should not impede the consensus process. Another problem is its low scalability because of the fixed and unchangeable data and setting. Therefore, the cost of changing some parts of the blockchain network is much more than building a new network. As a result, the cost of upgrading the system is very high.
In this regard, Cha et al. in [22] have presented an authentication scheme for the IoT using blockchain, claiming that their protocol has made it possible for users to access and manage IoT device information with privacy. In fact, they claimed that their protocol was able to establish user privacy and trust in IoT applications. In this paper, we show that the protocol designed by Cha et al. has drawbacks that make their design vulnerable to various attacks such as secret disclosure, traceability, replay, and reuse of attacks, which leads to loss of privacy and trust. Security analysis of the Cha et al.’s protocol before use prevents a lot of possible damage. It also makes designers aware of such errors in protocol design and avoid repeating them in their designs. In this paper, we also offer suggestions for troubleshooting this protocol. Using these suggestions, we provide an improved version of the protocol in terms of security and cost, which is called IBCbAP.
1.1. Main Contribution
The contributions of the paper are as follows:(1)Presenting security weaknesses of Cha et al. blockchain-based authentication and secure management of privacy preferences scheme.(2)Addressing security pitfalls of Cha et al.’s scheme and proposing a new improved one called IBCbAP.(3)Formal and informal security analysis of IBCbAP. Formal proofing is done using the Scyther tool.(4)Implementation of IBCbAP through JavaScript language and Ethereum local blockchain and considering its functionality and correctness.
1.2. Paper Organization
We organize the rest of the paper as follows. In Section 2, we will look at related works on the blending of two technologies of blockchain and IoT and also provide some explanations on their security requirements and existing issues. We review the Cha et al.’s blockchain-based authentication protocol and describe its security pitfalls in Sections 3 and 4, respectively. In Section 5, we propose a new improved protocol called IBCbAP and describe its security and functionality features. We analyze the security and functionality of IBCbAP in Sections 6 and 7, respectively. In Section 8, we compare the proposed protocol in terms of the type of blockchain used, the implementation platform, and security features with other related authentication schemes in this area, and at last Section 9 concludes the paper with concluding remarks and suggestions for future works.
2. Related Works and Preliminaries
This section addresses the important security requirements for access control systems in the IoT networks and briefly presents a few related works. Since we used the blockchain to store critical information securely in our proposed protocol, the definition of blockchain technology and how it works are also explained in this section. Also, we briefly explain the smart contract and its usage in our proposed protocol. Finally, we will talk about how the blockchain was used in the related works.
2.1. Blockchain
Blockchain was proposed in 2008 by Satoshi Nakamoto [21]. Blockchain includes blocks where blocks are interconnected like a chain. Each block contains information such as block number, the hash of the previous block, a nonce, and transaction information. By storing the hash of the previous block in each block, the chain will be formed. This chain is called the ledger. Figure 1 shows a simple example of the blockchain ledger. Each node in the network has its ledger. Blockchain uses consensus mechanisms [23, 24] to verify the transaction and update the entire ledger. At the time of adding a new transaction in the ledger, all nodes in the network will check the correctness of the information and, after approving, will add the new transaction to their ledger. Each user subscribes to the network by registering a pair of public and private keys on the network. This is done by recording a transaction. Each user’s keys are stored in their wallet. Miners created the blocks. Miners are nodes in the network, tasked with generating and approving blocks to the blockchain. To generate a block, the corresponding node solves a difficult problem, and the one who solves the problem sooner registers its block in the blockchain. Changing an approved block in the ledger is costly and difficult. There are two types of blockchain: public and private. In a public blockchain, anyone can participate in the block generation and consensus process, but in a private blockchain, only preapproved nodes can do this operation. Bitcoin [21] and Ethereum [25] are examples of the public type, and Hyperledger [26] is an example of the private type blockchain.
2.2. Smart Contract
Smart contracts are executable codes and memories, which are stored as transactions in the blockchain. Smart contracts are executed by miners with a fixed cost. By knowing the transaction address, it is possible to call the smart contract for the network members. Because blockchain is irremovable, smart contracts can provide a great deal of confidence. One of the famous blockchains, which is a smart contract provider, is Ethereum [25]. In the Ethereum network, any member can create a smart contract and share it with anyone. In this paper, we use the testRPC [27] to implement the blockchain network. This library creates a local Ethereum blockchain network.
2.3. Related Work
In the following, we introduce several related kinds of research which have tried to use blockchain’s security features, such as distribution, integrity, and tamper-proof properties to create security and privacy in communications protocols. The first blockchain is provided by Bitcoin [21], which stores financial transactions about coins. In Bitcoin, if the transactions change, it can store identity information and access policies. Ouaddah et al. designed a system to maintain privacy and security in a distributed manner, which is their main idea [28]. A problem with Ouaddah et al.’s design is the high computational cost for network members. Novo [29], by decreasing of distribution, has attempted the computations to fit the resources of the devices. Novo separated the blockchain network from the general network and communicates with the devices using management hubs. This solution boosts performance and reduces distribution. Compared to Ouaddah et al.’s design, it boosts computational power to devices and increases the probability of distributed denial of service (DDoS) attacks. In Novo’s protocol, miners cannot be a member of the network just cooperating to the blockchain network. The high computational load results from the block generation process. Using the lighter block generation process, we can efficiently use the blockchain network in the Internet of Things (IoT). Dorri et al. proposed a method for the block generation process and consensus, which is based on the limitation of the number of blocks generated per unit time per node [30]. Dorri et al. have claimed that the proposed method is scalable and provides a proportional computational burden to network members. In their scheme, miners are members of the network and their number and membership are changed based on few parameters. Dorri et al. used smart homes network scenario. The interior management of each home is done by a central point inside the house, and it is described in [31]. Lin et al. by using blockchain, ABS (Attribute-Based Signature), and MRE (Multi-Receiver Encryption) have proposed a system for managing industrial devices and data collection [32]. In fact, Lin et al.’s protocol is presented for the development of industry V.4 by blockchain. The structure of Lin et al.’s protocol has five entities, including terminals, blockchain, cloud, industrial network, and physical resources. In this scheme, commands are stored by the terminals at blockchain. The cloud and industrial network monitor the blockchain and find the commands and then perform the operations. Lin et al. have used distributed reductions to adapt their protocol to IoT conditions.
Hammi et al. have proposed a system to authenticate and authorize IoT devices that also meet security requirements such as confidentiality and integrity. They based the main idea behind their scheme on the use of blockchain security benefits and the segmentation of system components into unique areas. In these areas, known as bubbles, all members are allowed to communicate with their bubble members and identify other bubble members as attackers. ECDLP (Elliptic Curve Discrete Logarithm Problem) based cryptography is used by Hammi et al. This system has appeared in highly practical results, and the authors emphasized that they have achieved very satisfactory results. Xie et al. in [33] used the blockchain to improve security and privacy on the Internet of Vehicles (IoV) and transportation systems using 5G-VANET [34]. In Xie et al.’s scheme, all RSU (Road Side Unit-5G-Station–Vehicle) members are connected and controlled by a central SDN (Software Defined Network) controller. The number of messages sent by any vehicle and the message authorization status are stored in the blockchain. In this scheme, transactions are unchangeable and the vehicles cannot deny sending. As a result, as the error coefficient of a vehicle increases, the miners define more restrictions on the transmission of the vehicle transaction, which will increase system’s security. In fact, in their scheme vehicles with data encryption protect privacy. Huang et al. have introduced a system for controlling access to device resources according to device policies in [35]. The overall structure of Huang et al.’s scheme is very similar to the overall structure of Cha et al.’s scheme. Huang et al. used DAG (Directed Acyclic Graph)-based blockchains [36]. DAG-based blockchains are suitable for IoT applications because of their lightness and high speed. Also, Huang et al. have proposed a consensus method. In their proposed consensus method, the nodes have a credit value which comprises two variables: node activity and node honesty. The difficulty of the problem solved in block generation is inversely related to the credit value. The speed of storing a device’s transactions depends on its credit value. By reducing the credit value of a malicious device, the cost and time of attack increase. Yao et al. introduced a lightweight blockchain-based authentication system in [37]. Yao et al. specifically recommends this system for using in distributed vehicular fog servers. Yao et al. have enabled one-time authentication to access the services. They used the blockchain to store authentication history and reauthentication is selected by the devices. Sidorov et al. have proposed a blockchain-based supply chain system in [38]. They have used RFID tags to track products and also have used blockchain as a trusted third party. Sidorov et al. have claimed that they created a high level of privacy and security. The used blockchain type in the Sidorov et al.’s system is private and messages are encrypted only using rotation operation, XOR (Exclusive OR) operation, and HW (Hamming Weight) function. Dwivedi et al. have provided a blockchain-based healthcare system in [39]. The need for privacy preserving and distribution in healthcare systems is justifiable reasons for using blockchain in this plan. Dwivedi et al.’s scheme has used cloud and smart contracts, which are used to store patient data and analyze data according to the instructions of the healthcare provider. They used blockchain to secure the information in the cloud and keep track of changes. In Dwivedi et al.’s scheme, the patient sends information to the smart contract by wearing and using IoT devices and the smart contract decides according to the healthcare provider orders and notifies the relevant doctor.
As seen in this section, many attempts have been made to integrate blockchain technology with the IoT. All of these efforts lead to the growth and maturity of blockchain use in the Internet of Things [40–43]. An example is Cha et al.’s scheme [22], in which the authentication of IoT devices is done through blockchain. In this paper, we show that Cha et al.’s designed structure has its drawbacks and we offer solutions to address them.
3. Cha et al.’s Blockchain-Based Protocol
In this section, we explain Cha et al.’s blockchain-based protocol [22] and its security analysis including secret disclosure, replay, traceability, and reuse attacks.
3.1. Cha et al.’s Protocol
Recently, in [22], Cha et al. proposed a new authentication protocol based on blockchain for share and access management of IoT device information as a distributed attitude. In this protocol, there are three main entities called device, user, and blockchain connected gateway (BCG). Devices are the nodes in the network that share information or resources with conditions called Device policy, and other users, device, or people who want to use the information and resources of the devices. BCG is an intermediary between the device and the user. These gateways assess users’ eligibility (permissions and authentication) to use the information and resources of the devices according to policies.
We use the scenario described in [22] to explain communication and process sequencing. In this scenario, each user joins the blockchain network and registers its public and private key pair. The BCGs and administrator of devices deploy their smart contract in the blockchain network. Authentication processes and access policies management are done by smart contracts. In this scenario, each device is connected to a BCG. This connection is a logical connection and saved in the device and in the BCG smart contracts. When a device connects to a BCG, it can be said that access to device information is done by this BCG.
As shown in Figure 2, the user first finds the BCG smart contract address and then accesses the list of subset devices. To use any device, the user must declare their agreement with the device’s privacy policies. This agreement is stored in the blockchain network so that the BCG can be used at the time of request for access to device information by the user.
3.1.1. Smart Contracts
Here, we explain the implicit smart contract and their obligations in Cha et al.’s authentication protocol. Interactions between the device and the BCG (logical communication), control of device information and privacy policies and BCG management are all done through smart contracts. As shown in Figure 3, the communication between the devices and the BCG is recorded in the blockchain and is done through it. We can say the blockchain plays the role of a trusted third party (TTP). Therefore, there is no possibility of manipulating or violating information for the protocol’s parties.
3.1.2. Cha et al.’s Proposed Signature
The signature used in [22] is based on ECDLP (Elliptic Curve Discrete Logarithm Problem) and has six steps including SETUP, SET-PARTIAL-PRIVATE-KEY, SET-SECRET-VALUE, SET-PUBLIC-KEY, SIGN, and VERIFY. These steps by using notations represented in Table 1 will be briefly discussed in the following subsections and also are shown in Figure 4.
(1) Setup. In the first step, according to the secret value of , the BCG selects two groups of and with the same prime order. The relationship between and is , where is the generator of . has bilinear pairing attribute, so the following relationship exists:
The BCG selects its private and public key pair as and , respectively. Also BCG chooses three hash functions with definitions , and , and ultimately the values of are published by the BCG.
(2) Set-Partial-Private-Key. In this step, the BCG calculates , , , and values as below:
In the above calculations, a random number is used which is generated using public parameters, master private key, and the user ’s identity . After that, BCG sends to the user; the user once receives the messages immediately checks , where .
(3) Set-Secret-Value. In this step, the user selects a random number as his private key. This key is notated with .
(4) Set-Public-Key. In this step, the user using his secret key, i.e., , generates his public key as .
(5) Sign. At the beginning of this step, the user calculates the amount of , where is the message to be signed, and calculates . At the end, the user sends to the verifier.
(6) Verify. In this step, the verifier computes the value of as using the values of and received . After that, the verifier calculates as and verifies the correctness of signature by checking whether . If the condition is fulfilled, the signer is authentic.
3.1.3. Device Binding
The user sends a consent of the device policies to the BCG. Each BCG has a root key. The user’s public key is also specified. The BCG initially generates a random number (nonce ) and then, using this value, the public key of the user, BCG root key, and a hash function , generates a key . The combination of user consent, policy , and timestamp are encrypted with the generated key and then stored in the blockchain. The BCG sends the transaction and the generated key to the user because the user is sure of its accuracy. In future communications, stored information is the basis for licensing access to the device. Figure 5 illustrates the device binding of Cha et al.’s protocol.
3.1.4. Access to the Device
Figure 6 illustrates how the user is accessing the device. The implications of Figure 6 will be discussed in the following.(i)The user generates a signature for the access request message using , , , , , , as and sends to the BCG. Once the BCG receives the message, it checks the authenticity of the signature by checking whether or not. If so, the BCG generates a random value and then calculates , , , and at last the BCG sends to the user in response. After receiving from the BCG, the user verifies the validity of the received values by computing and checking whether or not. If the accuracy of the received information is verified, the access is calculated as below:
Finally, the user may use the device by sending to the device. Access permission depends on the result of verifying the validity of the received by the device.
4. Security Analysis of Cha et al.’s Blockchain-Based Authentication Protocol
In this section, we will investigate Cha et al.’s protocol’s security. This analysis includes the presentation of security attacks. We have applied four attacks on Cha et al.’s protocol comprising secret disclosure, replay, traceability, and reuse attacks. This section describes how the attacks are performed, their success probability and complexity, and a solution to prevent the occurrence of the attacks. We base the proposed protocol on these solutions.
4.1. The Adversary Model
Here, we used the common adversary model [44–48] in which the adversary can fully control and eavesdrop the public communication channel. So, he/she can eavesdrop, replay, modify, and delete any message or fabricate a new message.
4.2. Secret Disclosure Attack
According to (3), the is generated by the values of the sent messages. Since Cha et al. do not consider the channel secure, the attacker can eavesdrop the transferred messages through the channel. As a result, generating by the attacker is only possible through the eavesdropping of the channel, resulting in threats to the device’s resources and security. For this attack, the attacker proceeds as below:(1)The attacker eavesdrops transferred messages for one run of the access to device phase of Cha et al.’s protocol(2)Using , , , and which eavesdropped in access to device phase of Cha et al.’s protocol, the attacker can calculate as (3)Using calculated in the previous step, the attacker can access and use the intended IoT device
The success probability of the attack is 1 and its complexity is one run of the protocol. We will fix this weakness in our proposed protocol, i.e., IBCbAP. To solve this problem, we do signature using HMAC (Hash-Based Message Authentication Code) function and ECDLP (Elliptic Curve Discrete Logarithm Problem) encryption. Their details will be explained in Section 5.2.
4.3. Replay Attack
Because of the absence of new random values in each session, messages from each session are not different from other sessions, so a message is acceptable in all sessions. The attacker can gain BCG approval by sending messages sniffed in previous sessions and impersonating the user. The steps of this attack are as follows:(1)The attacker eavesdrops one session and stores message as (2)The attacker starts a new session with BCG by sending to the BCG(3)BCG checks correctness of and because of the mentioned weakness in Cha et al.’s protocol, BCG confirms the authenticity of the information(4)BCG sends to the attacker(5)The attacker accesses the device.
This attack is possible with the success probability of one and complexity of only one run of protocol’s eavesdropping.
4.4. Traceability Attack
Because of the absence of nonces or timestamp in Cha et al.’s protocol’s transferred messages, all of them are static, so it is possible for the attacker to trace the protocol parties using the content of the transferred messages. For this attack, it is enough for the attacker to proceed as below:(1)The attacker eavesdrops one run of protocol and stores the transferred messages(2)The attacker gets related to user, notated (3)After that, if the attacker sniffs the protocol messages and compares the with , he/she can determine whether the message is for the user or not, so recognizing the user
The attacker can detect a user, with the probability of 1 and the complexity of eavesdropping one run of the protocol. This attack is possible because in Cha et al.’s protocol, the is calculated only once and does not change in each session. By adding random nonces or timestamp to messages which are generated by all protocol parties, messages sent in each session are different, and the possibility of tracing users is vanishing.
4.5. Reuse Token Attack
Cha et al. in [22] did not explain their method for verifying the (in (3)) by the device. Also, despite the existing parameters in the protocol messages, the device cannot ensure that the has not duplicated and is correct. In other words, the user or attacker by receiving a can use the device’s resources unlimitedly, and the BCG or device cannot detect this situation. This is because no fresh variable (such as random numbers or timestamps) is used in the and the device has no role in creating the . So, by getting a , the attacker and a malicious user can use the repeatedly and any members of the network do not figure out. This issue causes the abuse of device resources and violates the claim made by Cha et al. to manage privacy policies. We will solve this problem by using random numbers in each separately which are generated by all members who take part in the network. In the next section, we will address all of abovementioned vulnerabilities which lead to proposing an improved version of Cha et al.’s blockchain-based authentication protocol called IBCbAP. We also will conduct formal security analysis and informal security analysis of IBCbAP. Formal proof will be done using the Scyther tool. To show the functionality of IBCbAP, we will implement it by JavaScript language and the Ethereum local blockchain network.
5. IBCbAP: The Improved Protocol
Here, we improve Cha et al.’s protocol’s weaknesses by using the HMAC function instead of Cha et al.’s proposed signature. We named the proposed protocol IBCbAP (Improved Blockchain-based Authentication Protocol). According to [49], the speed and memory consumption in an ECDLP (Elliptic Curve Discrete Logarithm Problem) encryption are less than RSA. Therefore, we use the ECDLP encryption method. We do the initial setting and selection of constant values just like Cha et al.’s protocol. As shown in Figures 7 and 8, respectively, the steps of IBCbAP are as below.(i)Confirm access policy phase: In this phase, the user, after finding device policy by associated BCG, sends its consent to device policies to the BCG. Also, the BCG generates a secret key and shares with the user. In this phase, the used channel is secure.(ii) Create access phase: In this phase, the BCG creates a for the user for using the device. is generated by the user, the device, and the BCG participants securely. The key used in this phase is generated in the Confirm access policy phase in which the used channel is secure.
5.1. Confirm Access Policy
In the first step, the user needs to find the device access policies and agree to them. To accept the device policy, he/she sends a message to the BCG according to the policy. The BCG generates a nonce upon which it receives . The shared key between the device and the BCG is created using the equation below:
This key is used in subsequent messages where is a hash function, and is a secret value associated with the BCG. The , , and a timestamp are encrypted using the generated key and stored as a transaction in the blockchain. The transaction address along with the is sent to the user through the secure channel. It is worth noting that the channel between the BCG and the user is secure.
5.2. Create Access Token
The user accesses the device through the following steps:(i)The user produces , where , , and are the transaction number associated with accepting device policies, a random number, and a shared secret key between himself and the BCG, respectively. The user sends to the device.(ii)The device once receives the message, generates a random number , and computes and sends to the BCG.(iii)Upon receipt of the message, the BCG generates a signature and compares it with the received signature . The continuation of the protocol is related to the satisfying condition. BCG decrypts the and ensures the user’s claim using the blockchain network. In the next step, the BCG generates another random number and the value of . And finally, it sends to the user.(iv)Once the user received the message, it verifies the authority of the BCG. This is accomplished by checking whether or not. The device already knows the value of , , and . The continuation of the protocol is conditional upon the generated signature of the user and the signature from the BCG. In the following, the user generates a signed message as and sends it to the BCG.(v)The BCG checks whether , where . If so, it creates access and computes and sends it to the user. Also, it computes and sends it to the device.
When the user receives the message and decrypts it with the key , if obtained is equal to its one, the user trusts the received . The same is true for the device.
6. IBCbAP Security Analysis
In this section, we consider the security of IBCbAP informally and also formally. We perform the formal security checking using the Scyther tool [50].
6.1. Informal Security Analysis
Here, we informally prove that the improved protocol can resist against different attacks. Informal analysis is based on the knowledge and creativity of the analyst.
6.1.1. Resistance to DDoS Attack
Because of using blockchain, the architecture of the system moves toward distribution architecture. The distribution of a system reduces the probability of the DDoS attack. However, because of the lack of participation of IoT devices in the blockchain network and IoT devices connected to the blockchain network by BCG, the distribution of the system decreases. IoT devices cannot directly participate in blockchain network, because many resources are needed for this purpose. Due to the use of blockchain as the trusted third party (TTP) and the distribution of IoT devices between different BCGs, the possibility of a DDoS attack on the system is reduced. Also, since keys are not changed at each session and the existence of different keys per user for each device, the possibility of changing values and system desynchronization is eliminated.
6.1.2. Resistance to Replay Attack
Since, in the proposed protocol, all members of the network participate in the Create access phase, the possibility of the replay attack is eliminated. Existence of shared secret values between protocol parties and use of freshly random values by protocol parties lead each session’s messages to be different from previous sessions messages; as a result, the possibility of the replay attack vanishes.
6.1.3. Resistance to Secret Disclosure Attack
Important messages sent between the user and the BCG are encrypted by a shared key, such as which is encrypted as . We also encrypt important messages sent between the device and the BCG, such as , using a shared secret value, i.e., . Due to the encryption of messages in the session, important information remains confidential. Also, the existence of shared secret values allows the protocol members to generate the message authentication code such as and , so they can authenticate each other and avoid sending the data to an unauthorized party.
6.1.4. Resistance to Traceability Attack
As mentioned before, because of the involvement of random numbers in all transferred messages and changing these random numbers in each session, the attacker cannot find any fixed value. As a result, the attacker is not capable of tracing protocol’s parties using protocol’s transferred messages. Also, it is not possible for the attacker to reveal any data in the current session, by eavesdropping the previous transferred messages because of the lack of correlation between messages sent in each session.
6.1.5. Unlinkability of Device
In the proposed protocol, we issue a separate key for each device. Each user is required to process, accept policies phase, and create an access phase to use each device independently. We can say that the user uses a separate for each device, so with the disclosure of a , other devices are not threatened.
6.2. Formal Security Analysis
We have used the Scyther tool to check out the formal security of our proposed bockchain-based authentication protocol. The Scyther is created with Python [51] language and works according to security claims. Claim events are used in role specifications to model intended security properties [52]. There are several predefined claim types in the Scyther tool which are represented in Table 2.
We have used Nisynch, Niagree, and Secret claims. The Nisynch claim checks desynchronization possibility. Niagree claim considers that an agreement will not commit to the changed values between the parties and the Secret claim states that the amount referred to it is secret. IBCbAP written in the Scyther language, i.e., security protocol description language (spdl) with three roles, i.e., user, device, and blockchain connected gateway, and security claims along with the output of the Scyther tool for its security verification are shown in Figures 9 and 10, respectively.
As you can see in Figure 10, the Scyther tool could not find an attack for IBCbAP. Therefore, IBCbAP provides a good level of security.
7. IBCbAP Implementation
We have implemented IBCbAP to test the functionality and the feasibility of implementation with existing technologies. We have used JavaScript in the form of Nodejs [53] technology to simulate the proposed protocol. The reason for this choice is WEB3.js [54] library to contact blockchain. This library uses the RPC (Remote Procedure Call) protocol to interact with blockchain nodes. The system used in this simulation includes features such as 4 GB RAM, 1 TB HDD, and Core i7 2.47 GHz CPU.
7.1. Confirm Access Policy
The implemented architecture has four participants (user, BCG, device, and blockchain network). User to use device sends the to the BCG and then receives the shared key between itself and BCG through a secure channel. How to generate is explained in Section 5.2. The user uses this key in the create access phase. At the Confirm access policy phase, the channel is secure. We run this phase 10 times and took 1363 milliseconds. Most of the time spent in this phase is due to storing the user information in the blockchain. A view of connecting to the device and confirming the device steps are shown in Figures 11 and 12, respectively.
7.2. Create Access
Figure 8 shows the Create access phase. At this phase, the user starts the process of issuing the access by sending and to the device. According to what was mentioned in Section 5.2, the device starts the creation process when the user receives the message. Finally, BCG creates a and sends it as to the user and as to the device. We performed this phase 10 times and have a total time of 1200 milliseconds. The major time consumed at this phase is related to encryption operations. Figure 13 shows the graphical user interface indicating successful receipt of the from BCG.
7.3. Ethereum Network
To implement the blockchain network, we have used the testRPC [27] library. This library creates a local blockchain network. Figure 14 illustrates the launch of this library. The testRPC default creates 10 accounts when building a local blockchain. We use one of these accounts. We used Remix tool to deploy the initial smart contract of the BCG, and Solidity language wrote the smart contract (see Figure 15). It is worth noting that the smart contract used is simplified and is suitable for implementing Confirm access policy and Create access phase. We used the Crypto [55] library and the sha256 algorithm to generate HMAC. We used the ecccrypto [56] library to perform ECC encryption. Also, we used the Express [57] framework to build the server for each protocol party. It should be noted that we set up the servers for each protocol party and blockchain network on a single system on separate ports. As a result, each phase is short. So, here we have shown it is possible to implement the proposed protocol with existing technologies and facilities. It is worth noting that we achieve measured times with only one device, one user, and one port.
8. Comparison
In this section, we compare our proposed protocol with its predecessor, i.e., Cha et al.’s protocol as well as other related schemes. As can be seen in Table 3, our proposed protocol has complete security compared to other protocols. Since the type of blockchain used and the specifications of the system are very different in different designs, we only got the time in our system and it was not possible to compare time with other designs. The time of our proposed protocol for Create access and Confirm access policy phases is 1200 and 1363 milliseconds, respectively.
9. Conclusion
Nowadays, blockchain and Internet of Things (IoT) technologies are bonding. The blockchain first attracted attention as part of a wave of crypto currencies, especially Bitcoin, which challenged the normal course of financial transactions. But it was not the blockchain financial transactions that caught the attention of IoT activists, but rather the data exchanges. Blockchain is essentially an antihacking, distributed, and event logging mechanism that appears to be very useful for solving key issues related to networks where connected devices automatically interact with each other, i.e., IoT. Because of the importance of security in IoT, many schemes have been proposed in this subject. In this paper, we examined Cha et al.’s blockchain-based authentication protocol. We illustrated the weaknesses of Cha et al.’‘s protocol by applying secret disclosure, replay, traceability, and reuse attacks with a success probability of one and complexity of one run of protocol. To address Cha et al.’s protocol’s security vulnerabilities, we also proposed an improved protocol called IBCbAP and proved its security in an informal way and also in formal way by the Scyther tool. Finally, we implemented IBCbAP using the JavaScript programming language and the Ethereum local blockchain network. We investigated the feasibility of implementing IBCbAP and measured the timing of some processes. The comparisons show that IBCbAP compared to its predecessor, i.e., Cha et al.’s protocol, is completely secure and the cost and time of its implementation are reasonable. One of the most important issues in the IoT network is the transfer of ownership. In future works, we plan to work on the design of blockchain-based ownership transfer protocols which enables the transfer of ownership in a distributed and secure manner.
Data Availability
No data were used to support this study.
Conflicts of Interest
The authors declare that there are no conflicts of interest regarding the publication of this paper.