BCoT Sentry: A Blockchain-Based Identity Authentication Framework for IoT Devices

Abstract

In Internet of Things (IoT) environments, privacy and security are among some of the significant challenges. Recently, several studies have attempted to apply blockchain technology to increase IoT network security. However, the lightweight feature of IoT devices commonly fails to meet computational intensive requirements for blockchain-based security models. In this work, we propose a mechanism to address this issue. We design an IoT blockchain architecture to store device identity information in a distributed ledger. We propose a Blockchain of Things (BCoT) Gateway to facilitate the recording of authentication transactions in a blockchain network without modifying existing device hardware or applications. Furthermore, we introduce a new device recognition model that is suitable for blockchain-based identity authentication, where we employ a novel feature selection method for device traffic flow. Finally, we develop the BCoT Sentry framework as a reference implementation of our proposed method. Experiment results verify the feasibility of our proposed framework.

1. Introduction

Commonly, an IoT device equipped with tags or sensors is attached to “a thing” and collects, stores, and transmits information via an IoT network. The management of the network is typically achieved through a centralized architecture [1,2]. In recent years, the total number of IoT devices has grown exponentially. It was expected that the number of connected devices in use in 2019 was 14.2 billion, and this number is expected to increase to 25 billion by 2025 [3,4].

Meanwhile, cyberattacks against IoT devices and networks have become more frequent. The consequences could be devastating and lead to major threats to society [5]. For instance, the Mirai virus is a typical example of malicious attacks against device authentication. It targets the security vulnerability of IoT devices, turns them into remote-controlled ”zombie” devices, and uses them for DDoS attacks. A well-known incident happened in 2016 when Mirai attacked the US DNS service provider Dyn, which nearly took down half of the Internet service in the United States [6].

Existing efficient security solutions are often centralized infrastructure (such as PKI), which relies on trusting third-party service providers. However, this mechanism suffers from single point of failure (SPOF), many-to-one traffic, and reduced scalability. Unlike full functional computing nodes, IoT devices generally have limited security measures for authentication. It is necessary to propose a new authentication system for IoT that has the following characteristics: (1) allows an easy integration of new IoT devices; (2) fully adapted to IoT requirements and needs; and (3) does not depend on the type of device, nor on the use case architecture and design [7].

IoT devices are distributed via connections between different types of physical networks. Devices communicate with IoT applications or other devices through various network protocols, such as ZigBee, Z-Wave, and MQTT. By their nature, IoT devices exist in a heterogeneous distributed network environment, and a huge number of devices are capable of peer-to-peer communication. These features can be directly linked to blockchain architecture, which is also based on a decentralized infrastructure and uses a distributed computational paradigm. It involves three key concepts [8]: (1) encrypted chain-like blocks for data storage; (2) distributed node and consensus algorithms for data generation and updates; (3) smart contracts for data manipulation and operation.

The concept of BCoT is therefore proposed to merge IoT with blockchain [9]. However, IoT device security is still an open research field in BCoT research and practices, especially device identity authentication, which remains an active research direction in both academia and industry [10].

Most of the IoT devices are enabled with IP-connected network functionality yet limited resources for computational intensive security models [11]. Specifically, the following questions need to be addressed: (a) How to deploy blockchain in IoT scenarios, i.e., how to manage IoT data through blockchain? (b) How to store device identity information in a blockchain network where participant nodes have limited computational power? (c) How to utilize the smart contract mechanism to enhance device identity authentication?

Goals and Contributions. This paper responds to the above questions by proposing BCoT Sentry—a framework that integrates blockchain with an IoT network and enhances network security by analyzing device traffic flow patterns obtained from data storage in blockchain.

The main contributions of this study are listed as follows:

• We design an IoT blockchain architecture to store device identity information in a distributed ledger.
• We propose a BCoT Gateway to facilitate the recording of authentication transactions in a blockchain network without modifying existing device hardware or applications.
• We propose a new device recognition model that is suitable for blockchain-based identity authentication, where a novel device traffic flow feature selection method is proposed.
• We develop a BCoT Sentry framework as a reference implementation of our proposed method.

This paper is organized as follows: First, in Section 2, we describe the motivation and related works, and then in Section 3, we lay out the framework design and propose our device recognition model. In Section 4, we introduce the reference implementation of our model and framework. In Section 5, we explain the experiments and evaluation metrics. Finally, we summarize our conclusion and the potential future directions.

2. Motivation and Related Work

2.1. IoT Network Security

IoT integrates sensors, transmitters, and controllers through various communication networks. Powered by advanced data analysis and other technologies, IoT greatly improves manufacturing efficiency and product quality, and meanwhile, reduces product costs and resource consumption.

In a typical industrial IoT scenario, a gateway device is commonly applied to isolate terminal sensors and controllers from the upper-layer network. Data collected by sensors are transmitted to centralized IoT applications that may remotely control executable units in order to achieve certain business logic requirements. However, this type of setting has known vulnerability. For instance, Stuxnet damaged the property of a number of parties outside Iran, which sustained only 60% of the Stuxnet infections [12]. In the local industrial infrastructure, the programmable logic controllers (PLCs) from Siemens were attacked.

Moreover, industrial robots exposed directly to the Internet could also be attacked via FTP services or industrial routers [13,14]. Among the total 83,673 robots surveyed in their studies, 5105 devices do not have an authentication mechanism at all; 59 devices have known embedded vulnerabilities, and 6 devices identified with new security holes.

Another widely adopted IoT scenario is an intelligent warehouse management system (WMS). It involves electronic labels, RFID scanners, and various warehouse supporting facilities. Different types of environmental sensors and safeguard devices need to be properly identified and inter-communicated in a stable and robust network environment. If the WMS is equipped with less-secure sensors or robots, attackers can tamper with raw sensor data and execute malicious operations through the robots, which might cause significant loss.

Gope et al. [15] propose a computationally efficient lightweight and privacy-preserving mutual user authentication scheme. In the proposed scheme, physical security of devices as well as the sensor nodes deployed in the open hostile environment are protected. These devices and sensor nodes are not required to store any sensitive information, such as secret credentials on the sensing devices. However, this research uses a centralized architecture, which has limited scalability and is vulnerable to SPOF.

The concept of ’Smart City’ is referred to as the safe, secure, environmental, and efficient urban center of the future with advanced infrastructures, such as sensors, electronic devices, and networks, to stimulate sustainable economic growth and a high quality of life [16].

For example, transportation is the artery of a city and an important part of smart city construction. Intelligent traffic management applies IoT technologies, such as wireless communication, cloud computing, perception technology, video vehicle surveillance, and GPS. Intelligent transportation employs various IoT devices, such as microcontrollers for connected cars, RFID devices, microchips, video camera equipment, GPS receivers, and navigation systems. By analyzing the real-time traffic information of people, cars, and traffic in the entire area from various perceptions, the platform controls traffic through traffic signals, ramp flow control, and dynamic traffic information signs.

Mohit et al. [17] propose an authentication protocol based on a user ID and password for a vehicular system in WSN to tackle the problem of vehicles running on the road, such as avoidance of traffic jams and other related problems. All of the vehicle sensors are registered through a registration authority. However, there is no additional measure taken to verify the identity of the device.

Despite the advantages IoT offers in a smart city, new security threats are also introduced, especially in transportation, where cyberattacks (such as device hijacking) could lead to devastating consequences.

The issue we are trying to address here is to enhance the device authentication without introducing extra computational burden on the end devices, yet take advantage of distributed reliability from blockchain.

2.2. Related Work

2.2.1. Blockchain and Smart Contract

Blockchain is a distributed shared ledger. In 2008, Satoshi Nakamoto proposed tBitcoin [18], explaining the architectural concept of an electronic cash system based on P2P network, encryption, time stamp, and Merkel tree, etc. As the underlying technology of digital cryptocurrencies such as Bitcoin, blockchain technology was originally designed to solve the long-term double payment problem [19] and the Byzantine generals problem [20].

In 2015, Ethereum [21] and Hyperledger [22] were proposed as a representative of a new generation of blockchain. They provide a decentralized computing platform, which allows a smart contract to be deployed as a manager so that the transaction can be executed with the contractual terms of an agreement [23]. A smart contract can encode any set of rules represented in its programming language. For instance, a contract can execute transfers when certain events happen (e.g., payment of security deposits in an escrow system). Accordingly, smart contracts can be applied to a wide range of applications, including financial instruments (e.g., sub-currencies, financial derivatives, savings wallets, wills) and self-enforcing or autonomous governance applications (e.g., outsourced computation, decentralized gambling) [24].

Since 2017, recent research, for instance, the cross-chain technology [25], sharding [26], and redesigned blockchain structure (e.g., directed acyclic graph (DAG)) [27], has improved the throughput, reduced the delay of transaction confirmation, and expanded the application scenarios of blockchain. These technologies allow the blockchain to be widely used in various fields, indicating a new era of blockchain.

2.2.2. Security Challenges in IoT

Generally, IoT security should address issues such as data authentication, access control, and user privacy. Meanwhile, the lightweight feature and limited computing power of IoT devices should be well considered when designing security models [28,29].

Several representative related studies are listed as follows:

• Mnif et al. [30] propose a new method adapted to resource-constrained wireless sensor networks, where only legitimate users can access node resources, and unauthorized users are denied access.
• Markus et al. [31] propose a system capable of automatically identifying the types of devices being connected to an IoT network and enabling enforcement of rules for constraining the communications of vulnerable devices to minimize damage resulting from their compromise.
• There are some research and development works in the fields of wireless sensor networks and RFID [32,33].

Exploration and implementation of security technologies in IoT is still an open challenge, and the issue of the security architecture of IoT still has room for improvement [34].

In the PKI framework, the single CA model is a commonly used model in an enterprise environment, and a CA is used to issue and manage certificates for all end users in the network. We list the advantages and drawbacks of blockchain and single CA model in

Table 1. Comparison of blockchain-based model and PKI.

Comparison Item	Single CA Model	Blockchain-Based Model
How to Build Trust?	Based on users subjective trust	Based on mathematics
Trust Anchor	Public key of the CA	Cryptography method and Consensus mechanism
Vulnerable to SPOF	Yes	Naturally immune
Vulnerable to Replay Attack?	Additional applications need to be deployed	Each of transactions is verified by timestamp, nonce, transaction ID, etc.

to show the improvements brought by the blockchain [35,36]:

In the existing PKI method, the CA periodically updates and releases Certificate Revocation Lists (CRL). One drawback of this method is that the time granularity of revocation is limited to the CRL release period. During this period, the revoked certificate is still trusted, and malicious attackers can illegally obtain data through revoking delay attacks. In addition, the existing revocation certificate inspection scheme is centralized, which will cause security bottlenecks.

If blockchain is used to manage the operation of certificates, the security bottleneck caused by the existing centralized solution can be effectively eliminated. In addition, the smart contract can make the operation and revocation verification of certificates effective and rapid response.

2.2.3. Convergence of Blockchain and IoT

Blockchain has the following characteristics that meet the needs of IoT [37]:

(1)

Decentralization. Distributed nodes maintain data consistency on the blockchain network through a consensus algorithm without third parties.

(2)

Persistency. In blockchain, invalid transactions will not be identified by miners, so transactions that have been confirmed cannot be deleted.

(3)

Auditability. Each transaction can be easily verified and tracked for every packaged transaction on the blockchain and can point to the transaction packaged in the previous block.

The main goal of the convergence includes: (1) to introduce trust and secure data exchange between IoT devices (systems) by taking advantages of blockchain; (2) to record, identify, and verify IoT transactions using cryptographic mechanisms provided by blockchain technology while balancing the network overhead and device computing capability; (3) to enable the secure P2P interactions between IoT devices without centralized third-party intervention by using blockchain nodes and smart contracts.

In BCoT, IoT data are synchronized to all nodes after reaching a consensus. A consensus mechanism is used to ensure the consistency of the system in Blockchain. There are several common consensus algorithms, such as Proof of Work (PoW) [38] states that generating a piece of data must satisfy certain requirements, which is difficult to produce but easy to verify. Proof of Stake (PoS) [39] states that miners can mine or validate block transactions based on the amount of cryptocurrency coins the miner holds. Practical Byzantine Fault Tolerance (PBFT) [40] is a method to solve the Byzantine Generals Problem that can be used in a real production environment.

In order to optimize the resource consumption of the blockchain and make it suitable for IoT devices, Karlsson et al. [27] propose a permissioned, DAG structured blockchain suitable for power-constrained environments with limited network connections. Liu et al. [41] propose LightChain, which has the characteristic of resource-efficient without affecting the traceability and nonrepudiation of blockchain, and propose a novel consensus mechanism to reduce the consumption of computing power. Prescilla et al. [42] propose a sliding window mechanism that stores only a limited part of the blockchain and maintains the whole blockchain in the private cloud to make the blockchain suitable for IoT devices. Ellul et al. [43] describe a split virtual machine that allows devices to interact with the blockchain system. These studies target blockchain structure optimization in order to incorporate IoT devices as direct blockchain nodes. However, device identity authentication is not fully covered in this research.

Gochhayat et al. [44] design a multi-user model composed of cloud storage servers and group users. Users encrypt files and store them in the district. On the blockchain, the cloud storage of files is done after the data are on the chain. Yakubov et al. [35] and Louise et al. [45] propose a feasible PKI identity authentication scheme in the blockchain. Cruz et al. [46] used blockchain to solve the cross-organizational access control problem in role base access control (RSAC) and realized the cross-organizational authentication of user roles. Bouras et al. [47] propose IoT-CCAC, a decentralized capability-based access control architecture designed for IoT consortium networks where a blockchain-based database is utilized. Cui et al. [48] propose a data management model based on the blockchain platform, where multiple IoT devices are controlled by a management center and the management center obtains access rights through a third party. Bouras et al. [49] propose a lightweight architecture and the associated protocols for consortium blockchain-based identity management to address privacy, security, and scalability issues in a centralized system for IoT. These studies improve the existing methods from the perspectives of cloud, PKI system, and access control. However, the work of identity authentication for IoT devices has room for improvement.

In order to solve the aforementioned identity authentication problem of IoT devices: Omar et al. [50] use function-based tokens based on the ERC721 standard to provide secure identity verification and authorization for IoT devices. Ujjwal et al. [51] propose a verification mechanism based on physical unclonable functions (PUFs), which generates a unique device ID for IoT devices. The registered manufacturer uploads each device ID to a blockchain network. When registering a new device, the end user verifies whether the hash value exists in the blockchain. Alblooshi et al. [52] proposed a traceable medical IoT device management solution to solve the problem of counterfeit devices through two smart contracts.

In the above-surveyed literatures, the authors propose new methodologies and methods for the integration of IoT and blockchain. A few studies focus on identity authentication through global registration on the public chain. These approaches lay out a theoretically feasible solution; however, it is challenging for IoT manufacturers to adopt the idea due to foreseeable cost trade-off. In this research, we intend to explore a practically feasible consortium blockchain solution for IoT device authentication.

3. The BCoT Sentry Methodology

Due to the cost-performance factor, the limited resources of most IoT devices could hardly support complex security models or algorithms. Practically, a security mechanism is implemented in different IoT applications in order to realize various business logic requirements. The cost of modifying existing applications could be extremely high; therefore, our end goal is to propose a new mechanism that could enhance security through a more complex blockchain-based security model without introducing a practically unfeasible cost increase due to the modification of end-device hardware design or the reconstruction of IoT applications.

We propose BCoT Sentry, a system that integrates blockchain with an IoT network and enhances network security by analyzing device traffic flow patterns. In BCoT Sentry, BCoT Gateways are blockchain nodes where an IoT device security module is employed through a smart contract.

Kanhere et al. [53] propose a lightweight blockchain-based architecture for IoT that virtually eliminates the overheads of classic blockchain while maintaining most of its security and privacy benefits. The constituent nodes in a P2P network are grouped in clusters, each cluster selects a Cluster Head (CH), and then CHs maintain a public blockchain. They verify the effectiveness of the proposed architecture against DOS, modification attack, dropping attack, and appending attack. Finally, they evaluate the traffic overhead and processing overhead of the architecture.

Ours work stores device fingerprints in the consortium blockchain through a specially designed BCoT Gateway, which facilitates the recording of authentication transactions in a blockchain network.

3.1. BCoT Sentry Architecture

The BCoT Sentry architecture is depicted in Figure 1, which includes the following components.

(1)

IoT Physic Network: An IoT physic network is a communication network composed of numerous tiny devices with limited capabilities. The IoT physic network can operate in an independent environment, or it can be connected to the Internet through a gateway.

In our proposed framework, IoT devices join the blockchain network through special gateways, and therefore, existing hardware and software applications can be easily integrated without additional cost.

(2)

Blockchain Network: In our framework, the blockchain network is a consortium chain. Nodes communicate with the blockchain through a reserved interface. Transaction logs and device records are maintained on the blockchain by each node and are decentralized and cannot be tampered with.

(3)

Cloud Applications: In a smart city scenario, IoT devices are typically utilized by cloud-based applications, such as smart transportation, smart home, and telemedicine. Our framework should also support the blockchain-based device authentication across the lower layer and upper layer of cloud applications.

(4)

BCoT Gateway: In our framework, the BCoT Gateway is essentially an IoT gateway [54] with blockchain node capability. BCoT Gateway can provide the functionalities of protocol conversion and device management:

The BCoT Gateway manages the sensor node connected to acquire the node’s identification, status and properties, and realizes remote startup, shutdown, control, and analysis.

The BCoT Gateway supports protocol interworking between the traditional network and IoT physic network, which includes Zigbee, Z-Wave, and MQTT.

(5)

Traffic Flow Analyzing: This module monitors the behavior of an individual IoT device and sends a device traffic flow feature to the Smart Contract via blockchain transaction.

(6)

Smart Contract and Interface: The device identity authentication mechanism described in this paper is realized by a single smart contract. The IoT device’s identity information and related operations are defined in smart contracts and triggered by blockchain transactions. The smart contract enforces the access permission policies through defined operations and ensures that only authorized entities could modify or access the device identity information.

Once the smart contract is deployed, it will generate a unique contract address. We specify the contract address and Application Binary Interface (ABI) of the deployed contract in the web3.py interface, so the traffic flow analyzing module can trigger smart contract through blockchain transactions to verify device identity.

3.2. Decentralized Identity Authentication Mechanism

The procedure of the decentralized identity authentication mechanism has three phase:

In the initialization phases, (a) BCoT Gateways join the blockchain network so that each of them will keep a copy of the blockchain. (b) Smart contracts are deployed on the blockchain, and each BCoT Gateway records its contract address and ABI. (c) A blockchain externally owned account (EOA) is created and bounded to each BCoT Gateway.

In the device registration phase, the management entity of the system extracts the traffic flow features of IoT devices and trains the model, then triggers smart contracts through blockchain transactions, and uploads device identity information and weight information to the smart contract. The device identity information will be synchronized to all blockchain nodes when a consensus is reached.

In the device authentication phase, when a device is connected to the network, BCoT Gateway extracts the traffic flow features of the device through a traffic flow analyzing module, then calls the smart contract to identify the types or to detect whether the identity of the device is fraudulently through the web3.py interface.

3.3. Device Authentication Model

In our device authentication model, we define a device fingerprint to discriminate types of IoT devices.

The fingerprint represents the unique network traffic pattern of the device. When an IoT device connects to the gateway, the device traffic will follow a specific process established by the device manufacturer. This process usually consists of a distinguishable communication sequence initiated by an IoT device, and our fingerprint attempts to capture this characteristic sequence.

The IoT Devices reduce the rate of sending data packets, which can be used to determine whether the initialization phase is complete.

In the proposed device authentication mode, let D be an IoT device, let $\mathsf{\Omega }$ be the universal set of devices, let $\mathcal{C}=\{C_1,C_2,\dots ,C_k\}$ be all types the of devices, let $P^D=\{p_1,p_2,\dots ,p_n\}$ be the data packets during the initialization phase, let $\overrightarrow{F{P}^D}$ be the fingerprint of device D, let $\overrightarrow{F{P}_C}$ be the fingerprint of types of device C.

Our device authentication model can be divided into two parts:

Register: Register and identify the types of new devices that are discovered in the network. For an unknown device $D_1$ with fingerprint $F{P}_1$, determine the type of the device $C_1$, which is defined by:

$$J_1(D_1,F{P}_1)=C_1$$

Fraud Detection: Fraud detection verifies and confirms the identity of registered IoT devices. For an IoT device $D_2$ with fingerprint $F{P}_2$ that claims to be type $C_2$, determine whether the identity of the device is correct. This model is defined by:

$$J_2(D_2,F{P}_2,C_2)=\left\{\begin{array}{cc}1,\hfill & \mathrm{if}\mathrm{device}\mathrm{type}\mathrm{matched}\hfill \\ 0,\hfill & \mathrm{else}\hfill \end{array}\right.$$

3.3.1. Device Fingerprint

Features that are used to build a fingerprint are shown in

Table 2. Description of the packet features.

Type	Features	Representation
Link layer protocol (2)	ARP/LLC	packet number
Network layer protocol (3)	IP/ICMP/EAPoL	packet number
Transport layer protocol (2)	TCP/UDP	packet number
Application layer protocol (9)	HTTP/HTTPS/DHCP /BOOTP/SSDP/DNS /MDNS/NTP/TELNET	packet number
–	Packet length	number of packets in a pcap file

.

The feature vector constituted by a packet $p_i$ can be expressed as:

$$f_i=\left\{f_{i,1},f_{i,2},f_{i,3},\cdots ,f_{i,16}\right\},i\in \{1,\cdots ,n\}$$

Hence, the behavior of the device during the initialization phase can be described by a $n\ast 16$ feature matrix:

$$F=\left[\begin{array}{cccc}{f}_{1,1}& f_{1,2}& \cdots & f_{1,16}\\ f_{2,1}& f_{2,2}& \cdots & f_{2,16}\\ ⋮& ⋮& & ⋮\\ f_{n,1}& f_{n,2}& \cdots & f_{n,16}\end{array}\right]$$

Consider that the number of packets sent in the initialization phase of the device, n, is also an important feature, so $\overrightarrow{F{P}^D}$ is given by:

$$\overrightarrow{F{P}^D}=\left\{\sum _j{f}_{j,1},\sum _j{f}_{j,2},\sum _j{f}_{j,3},\cdots ,\sum _j{f}_{j,16},n\right\},j\in \{1,\cdots ,n\}$$

Hence, $\overrightarrow{F{P}_C}$ is given by:

$$\overrightarrow{F{P}_C}=mean\left(\overrightarrow{F{P}^D}\right),D\in {\mathsf{\Omega }}_{C_i}$$

3.3.2. Weight Assignment

The importance of each feature in device fingerprints should be evaluated from three perspectives (as shown in

Table 3. The components of weight.

Components	Description
Discrimination	The association between a feature and corresponding category
Stability	The stability of a feature in the same category
Sensitivity	The sensitivity of the feature to change

):

(1)

Discrimination. Discrimination here refers to the degree of association between a feature and corresponding category.

The maximum information coefficient (MIC), proposed by David [55], is used to measure the discrimination of IoT devices and is widely used for feature selection in machine learning. In our application scenario, devices that have the same type should generate traffic flow with the same features in the same phase. The number of connected IoT devices will keep growing over time, so it conforms to the characteristics of the MIC “big data set”. The MIC is obtained by the following equation:

$$I[x;y]\approx I[X;Y]=\sum _{X,Y}p(X,Y){log}_2\frac{p(X,Y)}{p\left(X\right)p\left(Y\right)}$$

$$MIC[x;y]=\underset{\left|X\right|\left|Y\right|<B}{max}\frac{I[X;Y]}{{log}_2(min(\left|X\right|,\left|Y\right|\left)\right)}$$

where X is the column vector composed of the values of attribute x in all samples, and Y the column vector composed of labels corresponding to each sample. B is the auxiliary variable that is usually set to the 0.6 power of the amount of data sets.

Let $\overrightarrow{dic{s}^C}$ be the discrimination vector and given by:

$$\overrightarrow{dics}=\{MIC[x_1;y],MIC[x_2;y],\dots ,MIC[x_{17};y]\}$$

(2)

Stability. Stability refers to the change of a feature in the same category. A device may be classified into the wrong category due to poor stability of its feature field. Therefore, the stability of each feature needs to be considered.

We use the coefficient of variation ($CV$), a dimensionless quantity, to measure the stability of a feature.

$CV$ is only defined when the average is not 0, but there are several features of which the average is 0. In the IoT scenario, the standard deviation will be 0 if the average of a feature is 0. So a supplementary definition is made to make $CV$ meaningful when the average is 0. For a feature i with average $\mu$ and standard deviation $\sigma$, its $C{V}_i$ is:

$$C{V}_i=\left\{\begin{array}{cc}\frac{\sigma }{\mu }\hfill & \mu \ne 0\hfill \\ 0\hfill & \mu =0\hfill \end{array}\right.$$

The stability of the feature i in device type C can be expressed as:

$$sta{b}_i=\left\{\begin{array}{cc}1-C{V}_i\hfill & C{V}_i<1\hfill \\ 0\hfill & C{V}_i\ge 1\hfill \end{array}\right.$$

Let $\overrightarrow{{stab}^C}$ be the stability vector for device type C and given by:

$$\overrightarrow{{stab}^C}=\{sta{b}_1,sta{b}_2,sta{b}_3\cdots ,sta{b}_{17}\}$$

Hence, the stability of all types of device $\overrightarrow{stab}$ is given by:

$$\overrightarrow{stab}=mean\left(\overrightarrow{{stab}^C}\right),C\in \mathsf{\Omega }$$

(3)

Sensitivity. Sensitivity is defined as a measure of how sensitive the feature is to change. Features with a lower frequency should be sensitive to changes; on the contrary, higher frequency features are relatively insensitive to changes.

For example, when a device is infected by the Mirai virus, numerous Telnet requests will appear on the network. In our scenario, protocols like TELNET should not or rarely appear, so that the infected device may be identified through the TELNET protocol [56].

The proportion of the occurrence times of each protocol in P is given by the following equation:

$$\overrightarrow{{\mathrm{F}}_{occ}}=\left\{\frac{{\sum }_j{f}_{j,1}}{n},\frac{{\sum }_j{f}_{j,2}}{n},\frac{{\sum }_j{f}_{j,3}}{n},\cdots ,\frac{{\sum }_j{f}_{j,17}}{n},1\right\},j\in \{1,\cdots ,17\}$$

Let $\overrightarrow{{sen}^C}$ be the sensitivity vector of types of device C and given by:

$$\overrightarrow{{sen}^C}=\left\{\frac{1}{1+\frac{{\sum }_j{f}_{j,1}}{n}},\frac{1}{1+\frac{{\sum }_j{f}_{j,2}}{n}},\frac{1}{1+\frac{{\sum }_j{f}_{j,3}}{n}},\cdots ,\frac{1}{1+\frac{{\sum }_j{f}_{j,n}}{n}},\frac{1}{2}\right\},j\in \{1,\cdots ,17\}$$

(4)

Weight of Fingerprints. In summary, the weight $\overrightarrow{{weight}^C}$ corresponding to a type of device C is given by:

$$\overrightarrow{{\mathit{W}}^C}=\alpha \ast \overrightarrow{dics}+\beta \ast \overrightarrow{stab}+\gamma \ast \overrightarrow{{sen}^C}(\alpha +\beta +\gamma =1)$$

Here, the values of $\alpha$, $\beta$, $\gamma$ can be freely specified; in this paper, we set $\alpha =0.4$, $\beta =0.3$, $\gamma =0.3$.

3.3.3. Arbitration

(1)

Register: To identify the type of a new device that is discovered in the network, the weighted distance between the devices is needed, and devices of the same type will have a minimum weighted distance. For a newly connected device $D_x$ and a certain type of device $C\in \mathsf{\Omega }$, the distance vector will be:

$$\overrightarrow{\mathit{Dis}}=|F{P}^{D_x}-F{P}^C|$$

The device type of $D_x$ should be C that minimizes the d in the universal set $\mathsf{\Omega }$, the weighted distance of device D and type of device C is:

$$d(D_x,C)=\overrightarrow{\mathit{Dis}}·\overrightarrow{{\mathit{W}}^C}$$

(2)

Fraud Detection: To verify and confirm the identity of registered IoT devices. Let $ind$ be the fraud indicator, which is used to determine whether the identity of a registered device has been fraudulently used.

The standard deviation of device type C is $\overrightarrow{std\left(C\right)}=\{{\sigma }_1,...{\sigma }_{17}\}$, so that $ind$ can be defined by:

$$ind\left(C\right)=\overrightarrow{std\left(C\right)}·\overrightarrow{{\mathit{W}}^C}$$

Therefore, whether device $D_x$ belongs to category C can be derived from:

$$F_2(D_x,F{P}^{D_x},C)=\left\{\begin{array}{cc}1,\hfill & distance(D_x,C)<ind\left(C\right)\hfill \\ 0,\hfill & \mathrm{else}\hfill \end{array}\right.$$

4. Implementation

We develop a prototype of BCoT Sentry for testing and evaluation. The deployment of the system is shown in Figure 2. In this paper, we use an Ubuntu virtual machine to simulate the function of the BCoT Gateway that provides a Python3 environment.

4.1. Device Registration

Scapy [57] is a Python program and library that enables the user to send, sniff, and dissect and forge network packets. This capability allows the construction of tools that can probe, scan, or attack networks.

IoT devices will follow the procedure established by the manufacturer and register themselves to the network. The characteristic network traffic flow will be generated. We use the Scapy tool to collect and analyze traffic flow to get the feature vector of IoT devices and the corresponding weight vector.

4.2. Smart Contract Interface

Web3.py [58] is a Python library for interacting with Ethereum. It is commonly found in decentralized apps (dapps) to help with sending transactions, interacting with smart contracts, reading block data, and a variety of other use cases. The original API was derived from the Web3.js Javascript API but has since evolved toward the needs and creature comforts of Python developers.

The feature vector and weight vector will be uploaded to the blockchain in the form of transactions through the JSON-RPC interface, which is achieved through web3.py in the python3 environment.

4.3. Blockchain Network

The Ethereum Virtual Machine (EVM) used in this paper is Geth with the Golang programming language.

We develop a proof of concept (PoC) implementation of the BCoT Sentry in an Ethereum private chain under a generic genesis block in order to test and evaluate it. In the private blockchain, five BCoT Gateways participate in competitive mining as a full-featured blockchain node. We set the time to generate a new block to about 5 s by adjusting the difficulty of mining. The communication with the blockchain is supported by the API provided based on the HTTP-RPC interface.

4.4. Smart Contract

Solidity [59] is a statically-typed curly-braces programming language designed for developing smart contracts that run on the EVM.

The smart contract in our framework is implemented using Solidity. The device identity information and authentication operations are shown in Figure 3. We assign access rights to the functions in the contract to protect the device’s identity authentication information.

Since Solidity does not support floating-point data types, we need to find alternative representation. We build an IoT device authentication model and also modified the device features and weights by reserving a fixed number of decimal places for float numbers and multiplying them by a factor that always converts them to integers.

5. Evaluation

5.1. Dataset

The public dataset used in our work comes from [31], which includes traffic flow data of 27 types of devices that are representative of the devices commonly seen in the consumer market. In order to enable each tested device to generate enough training data, the setting process is repeated 20 times. The traffic flow data during each initialization process is packaged into a pcap file.

Most of these devices are connected to the network via WiFi or Ethernet, while a few devices use other IoT protocols (such as ZigBee, Z-Wave) to connect to the network indirectly through a HUB.

5.2. Evaluation Setting

All experiments were performed on a server with 36 hyperthreading Intel(R) Xeon(R) Gold 6140 CPU @ 2.30 GHz cores, 128 GB of memory, and VMware ESXi™ 6.7.0 was used to build a computer virtualization platform.

We deployed 5 virtual machines as the baseline environment (as shown in Figure 4), each of them configured with a 2-core CPU, 2 GB RAM, and a hard disk space of 40 GB, running Ubuntu 16.04.2 LTS with GUN/Linux 4.8.0-36-generic kernel. All of them were full nodes (miners) of our private blockchain where a new block was generated in 5 s.

5.3. Result Analysis

First, we extracted the features of the IoT devices and designed the corresponding weights. The discrimination and stability of different protocols are shown in

Table 4. Discrimination and stability of different protocols.

Protocols	Discrimination	Stability
ARP	0.8567	0.5540
LLC	0.5555	0.8068
IP	0.8741	0.3977
ICMP	0.6492	0.8519
EAPoL	0.8516	0.6648
TCP	0.8869	0.5943
UDP	0.8086	0.5039
HTTP	0.8926	0.8501
HTTPS	0.9285	0.8019
DHCP	0.8432	0.5693
BOOTP	0.8432	0.5693
DNS	0.7929	0.6232
NTP	0.7925	0.7318
TELNET	0.0000	1
Packet length	0.9292	0.7661

. It is worth noting that the TELNET protocol does not appear in the data set, which leads to a situation where the discrimination is 0 while the stability is 1.

Gas [21] is used to measure the “workload” of a behavior or a series of behaviors in Ethereum. Figure 5 shows the execution result of the operation that needs to modify the data on the blockchain in proposed model. The Gas consumption is shown in

Table 5. Gas consumption.

Type	Transaction Cost	Execution Cost
Create Contract	1,487,038	1,080,766
Add Device Fingerprint	291,998	262,726
Modify Device Fingerprint	160,963	131,691
Delete Device Fingerprint	33,301	11,261

.

We evaluated the accuracy of our model and the method from [31] on the same data set. We performed a five-fold cross-validation on the data set. The results (as shown in Figure 6) show that in 17 of 27 types of devices, our mechanism achieved parallel results, but in the remaining 10 types, our method achieved a significant lead, although our feature vectors have a lower dimensionality. The reason is that our model uses a better feature extraction method: the features extracted by our model come from all the network traffic packets of the device in the initialization stage, while our counterparties only utilize the first 12 packets of this stage.

Another experiment shows the accuracy of Fraud Detection, which is used to detect fraudulent device identity behavior, and the result is shown in Figure 7.

In this experiment, we first specified the device type C, and then randomly extracted 100 pcap files from the public data set to simulate the traffic flow data in the initialization phase of 100 IoT devices $D=\{D_1,D_2,\cdots ,D_{100}\}$, so that these 100 devices include both normal and fraudulent identities. Finally, we used the model Fraud Detection: $J_2(D_i,featur{e}^{D_i},C),D_i\in D$ to determine whether the device identity is being used fraudulently.

The results in Figure 7 show that for 25 of the 27 types of IoT devices, the accuracy of detecting device identity fraud exceeds 80%, and 21 of which exceed 90%. However, large errors are shown on devices HueSwitch and D-Linkcam. We find that their traffic flow data are extremely unstable, resulting in a large variance in the sample data. As a result, devices that do not originally belong to HueSwitch and D-Linkcam are wrongly classified.

5.4. Time Complexity

When we verify the identity of the IoT device, our model does not modify any data on the blockchain, which means that we can use the call() method to trigger the contract in order to save the transaction fee. The execution results of Register() and Detective() using call() are shown in Figure 8.

In the Ethereum private chain, the throughput of transactions depends on the block size and the time to generate new blocks. The problem of transaction delays due to congestion can usually be solved by increasing transaction fees.

We made 1000 calls to the functions Register() and Detective() on each BCoT Gateway, and obtained the average response time. We calculated the number of requests that each BCoT Gateway can respond to per second, and the result is shown in Figure 9.

Assuming that the type of IoT device is n and there are m IoT devices that require identity authentication, the two parts of our proposed IoT authentication model Register and Fraud Detection have a time complexity of $O(m\ast n)$, and $O\left(m\right)$.

6. Conclusions and Future Works

Blockchain is a promising security solution for IoT. However, the lightweight feature of IoT devices commonly fails to meet computational intensive requirements for a blockchain-based security model. In this paper, we propose BCoT Sentry, which uses BCoT Gateway to facilitate the recording of authentication transactions in a blockchain network. Furthermore, we introduce a novel device recognition model based on device traffic flow.

We implement a prototype to prove our design and validate the device recognition model on a public dataset. In terms of device recognition, accuracy was more than 95%, and 12 of 27 had 100%. In terms of fraudulent identity detection, our model has an accuracy of over 95% in 21 of 27 types of devices. The number of BCoT Gateways that can respond to Register() requests per second is about 215, and to Detective() is about 220. These results demonstrate the effectiveness of the proposed framework.

There is still room to improve the current work. Firstly, we tested our framework only on open datasets, and its effectiveness remains to be tested. Secondly, the identity authentication model we proposed is static in terms of the threshold setting and feature weight setting, which requires regular training to update the threshold and feature weight.

In our future work, we will deploy our framework in a real environment for further testing and study how to dynamically adjust the threshold value and feature weight when new data arrives to improve the performance of the model.