Edge-Based Blockchain Architecture for IoT Security
In this section, we describe the proposed edge-based blockchain architecture for IoT security. First, we describe the whole architecture, along with the details of each component, including the consensus mechanism, the privacy mechanism, and smart contract designs. Then, we discuss the role of edge-based blockchain in IoT security. Finally, we demonstrate the effectiveness of the proposed architecture in different IoT security scenarios.
Blockchain System Architecture
The blockchain system design proposed in this work is shown in Figure Ю.З. It consists of three parts, including edge devices with authorization, the blockchain network, and the cloud. The blockchain network is built on the open source Flyperledger Fabric, which is a permissioned consortium blockchain platform. Fabric has several features . In terms of the edge devices, only the nodes (devices) that have the enrollment certificates (ECerts) issued by the Fabric certificate authority (CA) can participate in the network. In other words, the system guarantees information confidentiality, since data cannot be accessed by unauthorized nodes. Furthermore, once a node suffers from malicious attacks or is no longer needed, the authority can revoke its ECerts at any time.
FIGURE 10.3 Blockchain System Architecture [Edge Devices send data to Blockchain Network, then synchronize it to Cloud. Blockchain Network includes three organizations, five orderers, and six peers.]
Inside the Blockchain network depicted in Figure 10.3, we use the Docker Compose tool to deploy the system with three organizations, w'here an organization is a managed group of device members classified into peers and orderers. Peers are in charge of the ledgers and invocation of smart contracts, whereas orderers are responsible for packaging transactions into blocks and distributing them to anchor peers. Organization Orgl is deployed in the cloud, w'hile the other two organizations, Org2 and Org3, are deployed on two different nodes, corresponding to two Raspberry Pi 3 platforms: Device 1 and Device2. Note that each organization has two peers, namely PeerO and Peerl. Orgl in the cloud has 3 orderers (Orderer, Orderer2, Orderer3), while the edge nodes have only one orderer each, including Orderer4 on Device 1 and Orderer5 on Device2. Thus, in this setup, the cloud organization has three times the chance to be the leader (as described in the Raft consensus later in this chapter), and thus can make the system more robust with a higher fault tolerance, due to the powerful computation ability of the cloud. The leader orderer packages transactions generated by smart contracts into blocks, and distributes them to the anchor peers of other organizations across the network. More important, the cloud administrator can access the data and rapidly be notified as soon as the data of edge devices are abnormal.
The mechanisms used to protect the information security of edge devices, including the consensus mechanism, private data, and smart contracts, are as follows.
• Practiced Byzantine Fault Tolerance (PBFT): PBFT is a replication algorithm designed by Barbara Liskov and Miguel Castro, in order to solve the Byzantine General’s Problem. It solves the defect of the low efficiency of the original Byzantine fault tolerance algorithm (e.g., Proof of Work or Proof of Stake in permissionless blockchains). A PBFT system can tolerate less than one-third malicious nodes in the network, as shown in Equation 1, where R is the number of replicas and/is the maximum number of faulty replicas .
- • Raft Consensus: Despite improving on the shortcomings of the original BFT algorithm. PBFT requires high time-complexity, due to its three stages and the broadcasting to all the other nodes in the network. Raft tries to resolve fault tolerance with 2/ + 1 nodes only, which exhibits more efficiency and supports a larger number of faulty nodes. A brief introduction to Raft and its practical design are given in the rest of this subsection.
- 1. Raft: Proposed by Diego Ongaro and John Ousterhout, Raft promises a distributed consensus with enhanced understandability from an intuition- focused approach and proof of safety . Nodes are divided into three characters (i.e.. Follower, Candidate, and Leader) and go through two main procedures, namely Leader Election and Log Replication. When a leader crashes, a new election is triggered by the heartbeat mechanism. The newly elected leader appends all commands to its log, while issuing AppendEntries RPCs in parallel to each of the other nodes. There is only one leader at any time.
FIGURE 10.4 Orderer 3 Elected as Leader in Raft Consensus [Orderer 3 received 3 MsgVoteResp votes from other Orderer and became raft leader at term2.]
- 2. Practical Design: A flexible and practical implementation of the Raft consensus is Etcd/raft, which is a library written in the Golang language and is new, as of Fabric vl.4.1. As shown in Figure 10.4, Orderer3 was the elected leader among Orderers by receiving MsgVoteResp (i.e., its decisions would be replicated by the followers). Now, we bring down the leader Orderer3 as in Figure 10.5. Then, Orderer2 is elected as the new leader, which is called lst-Fault tolerance; if Orderer2 is also shutdown, another new leader is elected, which is 2nd-Fault tolerance, and so on. The network is more secure and fault tolerant, when there are more and more nodes in it.
- • Private Data: In some applications, the data information is private in the sense that it should not be visible across specific organizations. An example could be the competitive relationship of data among organizations. In our system, we adopt private data collection, which was newly introduced in Fabric vl.2 to address the privacy issue. Without creating a separate channel, private data stored in an individual private state database  can be accessed only by authorized organizers, thus ensuring the privacy of IoT devices, as well as data confidentiality.
- • Smart Contracts: In contrast to the first generation blockchains (i.e., Bitcoin), the advent of smart contracts in the second generation blockchains gave the ability to implement transaction logic that can be executed automatically under specific circumstances. Predefined conditions and logic instructions are written in smart contracts, and then the participating nodes can invoke them to make decisions or access data, among other functionalities. This can be useful when it comes to IoT security, since all the interactions with smart contracts are tamper-resistant and stored in the blockchain. Additionally, the data information of edge devices can be monitored by the proposed smart contracts in our edge- based blockchain system. More implementation details are described in the next subsection.
FIGURE 10.5 Orderer 2 Elected as Leader in Raft Consensus [Orderer 2 received 3 MsgVoteResp votes from other Orderer and became raft leader at term3.]