# Certificateless Authentication Scheme Based on Blockchain in Smart Home Network

Authors: Xingang Zhang; He Li; Xiao Tian; Rui Zhang; Qinglei Qi
Journal: Mathematical Problems in Engineering
 (2022)

---

## Abstract

The traditional centralized intelligent home network security authentication schemes have security problems such as integrity and confidentiality, while the distributed schemes have the problem of delayed authentication. These schemes are not suitable for the intelligent home environment of edge computing. To solve these problems, a certificateless smart home network authentication scheme based on blockchain and certificateless cryptosystem is proposed to realize mutual authentication among users, intelligent terminals (ITs), and intelligent gateways (IGs). The aggregation signature scheme of certificateless identity is introduced into the authentication of intelligent terminals in smart home network. The IG only needs to generate a signature to complete the identity authentication of multiple ITs. Compared with other authentication schemes, the security verification and performance analysis show that the proposed scheme uses less computation overhead and achieves more security features.


---

## Body

## 1. Introduction

Smart home is an important application of the Internet of Things (IoT) under the development of mobile Internet [1]. Smart home network is a network that interconnects all types of intelligent terminals in the home through IoT technology. In recent years, with the development of artificial intelligence and big data technology, it has made home networks increasingly intelligent. However, due to the limitation of hardware resources of home smart terminal devices, cloud computing is usually required to meet personalized smart services in the home [2]. The characteristics of strong real-time interactivity and low latency of edge computing will become the standard for home network intelligent services [3]. However, the wireless local area network used in smart homes has serious security risks and is easily attacked by hackers. The interception of wireless information also makes the wireless communication of smart terminals useless [4], which brings many security threats to the access and transmission of home data. Therefore, new requirements and challenges are put forward for the identity authentication scheme of the smart home network. At present, IoT authentication technology is mainly based on cryptographic systems and is divided into two main methods: symmetric and public key. Symmetric key authentication is computationally small and fast, but there are security issues arising from key management and distribution [5]. Therefore, it is necessary to design an authentication scheme that not only meets the needs of the future smart home network architecture but also is safe and efficient.In recent years, there has been a lot of research in the field of smart home network authentication. In order to deal with the malicious attacks of radio frequency identification (RFID) in radio communication, a new trust-based authentication scheme is proposed in the literature [6] for smart home systems. The evaluation results of the scheme show that interference attacks and cloning attacks can be effectively countered. Fog computing smart home system, the literature [7] proposes an authentication model in a fog environment (SecFHome) that includes an edge negotiation phase and an identity verification phase. SecFHome adds updated information to the authentication side and can verify the synchronization of messages while authenticating, improving the efficiency of authentication. To protect smart home data security, a new secure privacy protection scheme is proposed in the literature [8] to resist ephemeral secret leakage (ESL) simulation attacks. The security of the scheme against different known attacks is demonstrated using the stochastic model. To reduce smart home network security threats, literature [9] proposes a smart card-based secure addressing and authentication scheme by modifying the IPv6 protocol. This scheme uses a secret session key to prevent unauthorized access to the network. However, this solution is less versatile and more difficult to apply in practice. Considering the limited resources of smart home devices, literature [10] proposes a lightweight short token authentication scheme. However, the scheme has security loopholes, which cannot resist Dos attacks, communication between devices is limited, and the registration process is complicated. The literature [11] designs a permission access control method based on risk. It uses groups (grouped according to risk similarity) for setting permissions and authorizing access. The method is similar to the above methods, in that they all use a centralized architecture and suffer from a single point of failure.To solve the problems in the traditional centralized authentication architecture, the literature [12, 13] introduces blockchain technology to smart home network authentication based on cloud computing to achieve decentralized network authentication. But this scheme uploads data to the cloud, which has the problems of data leakage, high computational effort, and communication overhead. In order to solve these problems, the literature [14] introduced edge computing to realize the authentication and control of the smart home network based on the blockchain technology. Therefore, to solve this problem, this paper combines a certificateless cryptosystem with blockchain and proposes a blockchain-based certificateless authentication scheme (BCAS), which realises mutual authentication of users, smart terminals, and smart gateways. At the same time, to cope with the growth in the number of smart terminals in a smart home network, one-to-one smart terminal authentication may lead to system resource consumption and signalling congestion problems [15]. This paper also introduces a secure and efficient aggregated signature scheme for certificate-free identities to the authentication of smart terminals in smart home networks. Realizing the authentication of multiple smart terminals can be completed with a single signature authentication. The security and performance analysis illustrates that the proposed solution uses less computational overhead while ensuring security. Compared with existing certificateless authentication Scheme of smart home network, our proposed algorithm contributes the following improvements:The smart home authentication network is constructed based on blockchain that includes the IT, intelligent app, user, IG, and ES.A user authentication scheme based on blockchain and tripartite key negotiation is designed to improve the authentication security among users, IG, and ITs.A single authentication scheme based on blockchain and public key signature is proposed to achieve secure and efficient authentication among IT, IG, and ES.To improve the authentication performance of multiple ITs, the aggregation signature scheme of certificateless identity is introduced into the authentication of intelligent terminals in smart home network.This paper is organized as follows. Section2 presents preliminary knowledge of smart home security authentication. Section 3 introduces blockchain-based authentication scheme. Section 4 describes the security analysis of blockchain-based authentication scheme. Simulation results and performance analyses of the scheme are presented in Section 5. Finally, the conclusions are drawn in Section 6.


## 2. Preliminary Knowledge

### 2.1. Blockchain

Blockchain is a distributed ledger technology, proposed by selfproclaimed Satoshi Nakamoto in 2008. It is the core technology of Bitcoin. Different from the traditional banking transaction system, the blockchain can realize the verification and storage of transactions through distributed nodes without any trusted central authority [16]. Each node on the blockchain has a high degree of autonomy, and transactions on the blockchain network require consensus among all participants. Therefore, the blockchain has the characteristics of decentralization, data are difficult to tamper with, and traceable. It has these properties because the blockchain stores data through a chain structure, specifically as shown in Figure 1.Figure 1
Blockchain structure.Each block is divided into a block header and a block body. Where the block header includes information such as version number, parent block hash, timestamp, and Merkle tree root value. The block body is used to store all types of transaction information. Where each transaction is permanently stored in the block body and requires a digital signature from the parties to the transaction; thus, ensuring that the data cannot be forged. Therefore, the data information recorded in the blockchain is extremely reliable and can solve the problem of entities not trusting each other in information systems.


### 2.2. Certificateless Trilateral Key Negotiation

Diffie and Hellman proposed the first two-party single-round key agreement protocol in 1976, which allows participating users to calculate a shared session key through public information. The shared session key is calculated from the secret value chosen by each of the participants. The literature [17] proposes a first tripartite key negotiation protocol in communication systems to enable three entities to construct a shared session key. The efficient certificateless tripartite key negotiation protocol proposed above is used here, and the specific tripartite key negotiation process is shown in Figure 2.Figure 2
Tripartite key agreement negotiation process.IDA, IDB, and IDC are the respective identities of users A, B, and C. They submit their identities to the key generation center to generate their respective partial private keys, DA, DB, and DC. PKA, PKB, and PKC are the respective private keys of users A, B, and C. TA, TB, and TC are the random numbers secretly chosen by each of users A, B, and C. TA=ga, TB=gb, and TC=gc. <hC, sC> is the signature generated by user C, where hC is the hash value of user identity information, random number, and information to be signed. The sC is part of the private key output by user C. After the tripartite has completed the exchange of information and authentication in compliance with the rules of the protocol, they can each obtain a common key K by calculation and use this key K for secure communication in future communications.


### 2.3. Certificateless Aggregate Signature

The first identity-based aggregated signature scheme using fork priming was proposed by Cheon et al. in 2004. It is proposed to facilitate the one-time verification of multiple signatures of multiple users. The signed message can only be known by the signer and the key generation center, and the signature private key is associated with the identity information. The so-called aggregated signature is to aggregate the signatures ofn signers to n different messages into one signature, so that the verification equation of n signatures can be reduced to one verification equation. Therefore, the aggregated signature greatly improves the efficiency of signature verification and transmission.


### 2.4. Difficult Questions and Hypothesis

Definition 1.
Diffie–Hellman (CDH) problem.
Letp and q be two prime numbers and satisfy q|(p − 1), let g be a generating element of order q in Zp∗, a, b∈Zp∗, given definite g,ga,gb∈Zp∗, and calculate gab∈Zp∗. The probability of the CDH problem being successfully calculated by algorithm A is(1)SuccZp∗,ACDH=Prgab←Ag,ga,gb,where the calculated probabilities are based on the random selection of algorithm A and the random selection of a and b on Zp∗.Hypothesis 1.
CDH probability hypothesis:SuccZp,A∗CDH is negligible under any polynomial algorithm A.Definition 2.
Discrete logarithm (DL) problems: letp and q be two prime numbers and satisfy q|(p − 1), let g be a generating element of order q in Zp∗, a, b∈Zp∗, given definite g,ga∈Zp∗, and calculate a∈Zp∗. The probability of the DL problem being successfully calculated by algorithm A is(2)SuccZp∗,ADL=Pra←Ag,ga,where the calculated probabilities are based on the random selection of algorithm A and the random selection of a on Zp∗.Hypothesis 2.
DL probability hypothesis:SuccZp,A∗CDH is negligible under any polynomial algorithm A.


## 2.1. Blockchain

Blockchain is a distributed ledger technology, proposed by selfproclaimed Satoshi Nakamoto in 2008. It is the core technology of Bitcoin. Different from the traditional banking transaction system, the blockchain can realize the verification and storage of transactions through distributed nodes without any trusted central authority [16]. Each node on the blockchain has a high degree of autonomy, and transactions on the blockchain network require consensus among all participants. Therefore, the blockchain has the characteristics of decentralization, data are difficult to tamper with, and traceable. It has these properties because the blockchain stores data through a chain structure, specifically as shown in Figure 1.Figure 1
Blockchain structure.Each block is divided into a block header and a block body. Where the block header includes information such as version number, parent block hash, timestamp, and Merkle tree root value. The block body is used to store all types of transaction information. Where each transaction is permanently stored in the block body and requires a digital signature from the parties to the transaction; thus, ensuring that the data cannot be forged. Therefore, the data information recorded in the blockchain is extremely reliable and can solve the problem of entities not trusting each other in information systems.


## 2.2. Certificateless Trilateral Key Negotiation

Diffie and Hellman proposed the first two-party single-round key agreement protocol in 1976, which allows participating users to calculate a shared session key through public information. The shared session key is calculated from the secret value chosen by each of the participants. The literature [17] proposes a first tripartite key negotiation protocol in communication systems to enable three entities to construct a shared session key. The efficient certificateless tripartite key negotiation protocol proposed above is used here, and the specific tripartite key negotiation process is shown in Figure 2.Figure 2
Tripartite key agreement negotiation process.IDA, IDB, and IDC are the respective identities of users A, B, and C. They submit their identities to the key generation center to generate their respective partial private keys, DA, DB, and DC. PKA, PKB, and PKC are the respective private keys of users A, B, and C. TA, TB, and TC are the random numbers secretly chosen by each of users A, B, and C. TA=ga, TB=gb, and TC=gc. <hC, sC> is the signature generated by user C, where hC is the hash value of user identity information, random number, and information to be signed. The sC is part of the private key output by user C. After the tripartite has completed the exchange of information and authentication in compliance with the rules of the protocol, they can each obtain a common key K by calculation and use this key K for secure communication in future communications.


## 2.3. Certificateless Aggregate Signature

The first identity-based aggregated signature scheme using fork priming was proposed by Cheon et al. in 2004. It is proposed to facilitate the one-time verification of multiple signatures of multiple users. The signed message can only be known by the signer and the key generation center, and the signature private key is associated with the identity information. The so-called aggregated signature is to aggregate the signatures ofn signers to n different messages into one signature, so that the verification equation of n signatures can be reduced to one verification equation. Therefore, the aggregated signature greatly improves the efficiency of signature verification and transmission.


## 2.4. Difficult Questions and Hypothesis

Definition 1.
Diffie–Hellman (CDH) problem.
Letp and q be two prime numbers and satisfy q|(p − 1), let g be a generating element of order q in Zp∗, a, b∈Zp∗, given definite g,ga,gb∈Zp∗, and calculate gab∈Zp∗. The probability of the CDH problem being successfully calculated by algorithm A is(1)SuccZp∗,ACDH=Prgab←Ag,ga,gb,where the calculated probabilities are based on the random selection of algorithm A and the random selection of a and b on Zp∗.Hypothesis 1.
CDH probability hypothesis:SuccZp,A∗CDH is negligible under any polynomial algorithm A.Definition 2.
Discrete logarithm (DL) problems: letp and q be two prime numbers and satisfy q|(p − 1), let g be a generating element of order q in Zp∗, a, b∈Zp∗, given definite g,ga∈Zp∗, and calculate a∈Zp∗. The probability of the DL problem being successfully calculated by algorithm A is(2)SuccZp∗,ADL=Pra←Ag,ga,where the calculated probabilities are based on the random selection of algorithm A and the random selection of a on Zp∗.Hypothesis 2.
DL probability hypothesis:SuccZp,A∗CDH is negligible under any polynomial algorithm A.


## 3. Blockchain-Based Authentication Scheme

### 3.1. Network Authentication Model

The smart home network built in this paper includes intelligent terminal (IT), intelligent application, user, intelligent gateway (IG), and edge server (ES), as shown in Figure3. The IT mainly includes smart lights, smart audio, smart access control, smart air conditioning, home security systems, and various sensor devices. These terminal devices form a heterogeneous Internet of Things that collects and monitors various types of data in the home environment. The IG is an important communication device in the home network, with functions such as computing and storage, and acts as a full node of the blockchain, enabling all types of transaction operations (such as creation, validation, and query). The IG stores various types of data collected by IT, and the user (family members in the smart home) can query and manipulate these data as required. Edge computing refers to a new model of performing distributed computing at the edge of the network [18], with ES acting as an edge cloud responsible for smart home big data processing.Figure 3
Smart home network structure.First, the network system initialization is performed by the ES, and the initialization generates the public parameters required for network authentication. Secondly, IT can collect environmental information in the family and use its own ID to complete registration and exchange information with IG. Among other things, IT should also create and store blockchain power tokens and smart contracts (smart contracts define permissions, policies, and constraints associated with the service) on the blockchain. Then, the smart application authenticates the user by verifying the information entered by the user. Finally, after passing the identity verification, users can request blockchain power tokens and smart contracts from IT and then request access to relevant services from IG, and only after the access service request is approved, they can operate on IT with corresponding rights.The detailed description of the proposed blockchain-based authentication scheme is as follows. The scheme includes system initialization, tripartite key negotiation, IT identity binding, and user identity binding.


### 3.2. System Initialization

System initialization is performed by ES, and a public key cryptosystem is constructed using the Elliptic Curve Integrated Encryption Scheme (ECIES) [13] with the following key generation process:


#### 3.2.1. System Creation

Enter the security parameterk, and ES produces two large prime numbers p and q and satisfies q|(p − 1). Randomly choose a generating element g of order q of Zp∗, the subgroup generated by is G. ES arbitrarily choose x∈ Zp∗, and calculate y=gx. Select hash function:(3)H1:0,1∗×Zp∗⟶Zq∗,H2:0,1∗×Zp∗×Zp∗⟶Zq∗,H3:0,1∗×Zp∗4×Zp∗×Zp∗⟶Zq∗.System public parameters = {p, q, g, y, H1, H2, H3}, Master Key (msk) = x, and x ∈ Zp∗.


#### 3.2.2. Partial Private Key Generation

After entering the user’s identity IDi, the KGC first randomly selectsxi ∈ Zq∗, then calculate Ri=gri, Q1=H1IDi,Ri, Di=xH1IDi,Ri=xQi, return Di to user i through a secure channel, and use Di as part of user i’s private key.


#### 3.2.3. Secret Value Setting

UserIDi randomly selects xi ∈ Zq∗ as the long-term private key.


#### 3.2.4. Private Key Setting

UserIDi enters the parameters params, a partial private key and Di, output the Si of the private key at the client, where Si=xiQi, and generates the full private key SKi=<Si,Di>.


#### 3.2.5. Public Key Setting

The user selects a random secret valuexi, Xi=gxi, to generate the public key PKi=<Xi,Ri>.


### 3.3. Tripartite Key Negotiation

In the first use of IT, the user’s participation is required, and the key negotiation between the three is completed through the interaction of IG. Here, IDIT, IDIG, and IDU are the respective identities of IT, IG, and user U. They submit their identities to ES, which completes the system initialization and generates their respective partial private keys, SKIT, SKIG, and SKU.PKIT, PKIG, and PKU are the respective public keys of IT, IG, and user U. NIT, NIG, and NU are random numbers a, b, c, chosen secretly by each of IT, IG, and user U, then calculate NIT = ga, NIG = gb, and NU = gc, and <hU, sU > is the signature generated by user U:(1)
IG sends < IDIG, NIG, PKIG > to IT and U.(2)
UserU receives a message from the IG and generates a key negotiation response message < IDU, NU, PKU>, which is also sent to the IG. IT receives a message from IG and generates a key negotiation response message < IDIT, NIT, PKIT,>, at the same time sending the message to IG.(3)
After IG receives messages from userU and IT, calculate KIG=gcx+xcNUPKUNITPKIT, hIG=H2TIG,IDIG,m, sIG=c+HIG+xIG, generate signature <hIG, sIG>, and send message <IDIG, NIG, PKIG, hIG, sIG > to users U and IT.(4)
As in Figure4, after receiving the identity information <IDIG, NIG, PKIG, hIG, sIG > from the IG, the user U and IT verify the signature of the IG, respectively. If user U and IT pass the authentication to the IG, then user U and IT send their identity information <IDU, NU, PKU, hU, sU>, <IDIT, NIT, PKIT, hIT, sIT>, respectively, to the IG.(5)
If the IG passes the authentication of userU and IT, it first forwards <IDIT, NIT, PKIT, hIT, sIT> to user U and <IDU, NU, PKU, hU, sU> to IT. Then, the user U and IT authenticate each other. Finally, after authentication, user U and IT can each obtain a common session key KS = KIG = KIT = KU by calculation and use this key KS for secure communication in future communications. If the identity information cannot be authenticated, key negotiation needs to be performed again.Figure 4
Tripartite key negotiation between IT, IG, and userU.


### 3.4. Intelligent Terminal Identity Binding

IT needs to initiate the binding of its own ID to IG to generate a unique ITID and store it on the blockchain, and the specific IT binding process is shown in Figure5:(1)
IT first hashes its identity IDIT with SHA256 function to get H(IDIT), then encrypts it with the common session key KS to get E(KS, H(IDIT)), and finally sends it to IG.(2)
The IG receives the message, decrypts it with the common session keyKS to get D(KS, H(IDIT)), and queries whether the device is in the device list.(3)
If present, a device unique identification ITID(i) is generated for it and stored on the blockchain. If it does not exist, it indicates that the device does not exist or is illegal and the identity binding is rejected.Figure 5
IT identity binding process.


### 3.5. User Identity Binding

As with IT, users need to be bound to the ES to ensure their legitimacy. The specific user binding process is shown in Figure6:(1)
UserU sends <IDU, NU, PKU, hU, sU> to ES for key negotiation.(2)
After receiving the message fromU, ES verifies the user’s signature and calculates KES−U=gbx+xbNUPKU, hES=H2TIG,m, and sES=c+HES+xES; m is the message to be signed. ES generates signatures <hES, sES> and send the information <IDES,NES, PKES, hES, sES> to U.(3)
After receiving the signature information <NES, PKES, hES, sES> of the ES, U verifies the signature of the ES, and if user U passes the authentication of the signature of the ES, user U computes KU−ES=gcx+xcNESPKES. Finally, after authentication, the users U and ES can each obtain a common session key KUE = KES − U = KU − ES by calculation to use this key KUE for secure communication in future communications.(4)
The user chooses their identity IDj to be hashed using the SHA256 function to obtain H(IDj). Next, the encryption E(KUE, H(IDj)) is performed with the common session key KUE, and finally, this encrypted message is sent to the ES.(5)
After receiving the message, the ES decryptsD(KUE, H(IDj)) with the common session key KUE and queries whether the user is a legitimate smart home family member.(6)
If legitimate, a user unique identifier UUID(j) is generated for it and added to the blockchain. If it is not legal, the user does not exist or is illegal and the identity binding is rejected.Figure 6
User identity binding process.


### 3.6. User Authentication Access Mechanism

When a user needs to access an IT or access a specific service, user authentication needs to be completed. As shown in Figure7, the specific authentication process is as follows:(1)
the user uses the APP inputU(j) to generate the user authentication request message rU, which consists of an encrypted random number and signature generated by IT(i). That is, KU(RU(j),SigU), where RU(j) is a random number, SigU is its own signature, and KU is the key negotiated by U(j) with ES or IG.(2)
After IG or ES receives the message, it verifies the signature and establishes a connection with the blockchain network, requesting to obtain its unique identifier UUID(j). The ES or IG verifies the existence of the user by decoding the function f(UUID(j)) = H(U′(j)), if H(U′(j)) = H(U(j)), then the user is authenticated; otherwise, the authentication is denied.(3)
After the user establishes the initial trust relationship with the IG or ES, the user sends an access request message to the IT.(4)
IT(i) verifies the user’s signature after receiving the access request message and generates a response message and sends it to the IG. After the IG receives the message, it verifies the validity of IT(i); if it is valid, it forwards the message; otherwise, it rejects the request.(5)
After receiving the response message from IT(i), the user verifies the legitimacy of IT(i) and generates control information and sends it to IT(i). Users can perform control operations on IT(i) or encrypt data interactions.Figure 7
User authentication access process.


### 3.7. IT Authentication Mechanism

#### 3.7.1. Single Intelligent Terminal Authentication

In order to avoid illegal intrusion into the smart home network via IT devices, when a single IT device needs to upload data to the ES via IG, the legitimacy of the end device needs to be authenticated. As shown in Figure8, the specific authentication process is as follows:(1)
IT(i) sends the authentication request message rIT to the IG, which consists of an encrypted random number and signature generated by IT(i). That is, KIT-IG (RIT(i), SigIT), where RIT(i) is a random number, SigIT is its own signature, and KIT-IG is the key negotiated between IT(i) and IG.(2)
The IG receives the message, verifies the signature, and establishes a connection to the blockchain network, requesting its unique identification ITID(i). Verify the existence of IT(i) by decoding function f(ITID(i)) = H(IDIT′ (i)), if H(IDIT′ (i)) = H(IDIT(i)), then IG passes the consent authentication and sends an authentication response message to IT(i); otherwise, IG rejects authentication.(3)
The IG encrypts its own signature with the public key of the ES and sends it to the ES together with the authentication request of IT(i).(4)
After receiving the signature and authentication request from the IG, ES first verifies the IG signature. After the ES verifies the IG, it will generate its own signature and sends an IG authentication pass message to the IG; otherwise, authentication is denied. Then, the ES establishes a connection with the blockchain network and requests for the unique identification ITID(i) of that IT(i). ES obtains its unique identifier ITID(i) and then verifies the existence of IT(i) by decoding the function f(ITID(i)) = H(IDIT′ (i)). If H(IDIT′ (i)) = H(IDIT(i)), then IT(i) is authenticated by the ES, which generates an IT(i) authentication pass message and sends it to the IG; otherwise, authentication is denied.(5)
After receiving the signature and authentication pass message from the ES, IG verifies the legitimacy of the ES. If the ES is legitimate, IG will generate its own signature and sends it to IT(i) together with the signature of ES. Otherwise, authentication is rejected.(6)
After receiving the signature and authentication pass message from the IG, IT(i) verifies the legitimacy of the IG and ES. If the IG and ES are legitimate, and the IT(i) receives the ES authentication pass message forwarded by IG, the authentication is passed and data can be sent to the ES via the IG. Otherwise, authentication is rejected.Figure 8
Single intelligent terminal authentication access process.


#### 3.7.2. Multiple Intelligent Terminal Authentications

In multiple IT concurrent authentications, identity-based aggregated signatures are introduced to smart home network authentication. Compressing the signatures of any number of entities into one signature reduces the storage space of the signature and at the same time simplifies the authentication of multiple entities to the verification of one signature. In multiple IT concurrent authentications, identity-based aggregated signatures are introduced to smart home network authentication. Compressing the signatures of any number of entities into one signature reduces the storage space of the signatures and simultaneously simplifies the authentication of multiple entities to the verification of one signature. Compared with other authentication schemes, this scheme reduces the burden of data storage space under the premise of ensuring security. The data traffic of interactive messages and signalling is reduced, and the computational workload of verifying the signature is also reduced. It can improve the efficiency of smart home network certification when multiple IT certifications are concurrent. As shown in Figure9, the specific authentication process is as follows:(1)
the IG sends an aggregated signature authentication request to all ITs in the smart home network. This group of endpoints generates their own signatureσ(i) using their own private keys and sends an aggregated signature authentication response message including this signature to the IG.(2)
After IG receives these aggregate signature authentication response messages, it queries whether these IT devices exist. If they exist, the unique identification ASID(s) of the multiterminal is generated and stored in the blockchain. If one or more terminals do not exist, the authentication will be refused, and only the unique identification ASID(s) of the legitimate terminal will be generated and stored in the blockchain.(3)
The IG generates the aggregated signature of the legitimate endpoint and encrypts it with the public key of the ES and sends it to the ES together with the IGs aggregated authentication request.(4)
After the ES receives the aggregated signature and authentication request sent by the IG, it first verifies the aggregated signature of the IG. After the verification is passed, the ES establishes a connection with the blockchain network and requests to obtain the unique identification ASID(s) of multiple ITs.(5)
The ES obtains its unique identification ASID(s) and verifies the existence of IT(s) by decoding the function f(ASID(s)) = H(IDIT′ (s)). If H(IDIT′(s)) = H(IDIT(s)), then IT(s) is authenticated by the ES, which generates its own signature and sends an authentication pass message to the IG. Otherwise, the authentication is rejected.(6)
After receiving the signature and authentication pass message from the ES, the IG verifies the legitimacy of the ES. If the ES is legitimate, it generates its own signature and forwards the authentication pass message; otherwise, it rejects the authentication.(7)
After receiving the signature and authentication pass message from the IG, IT(s) verifies the legitimacy of the IG and ES. If the IG and ES are legitimate, then the authentication is passed and data can be sent to the ES via the IG; otherwise, the authentication is rejected.Figure 9
Multiple Intelligent terminal authentication access processes.


## 3.1. Network Authentication Model

The smart home network built in this paper includes intelligent terminal (IT), intelligent application, user, intelligent gateway (IG), and edge server (ES), as shown in Figure3. The IT mainly includes smart lights, smart audio, smart access control, smart air conditioning, home security systems, and various sensor devices. These terminal devices form a heterogeneous Internet of Things that collects and monitors various types of data in the home environment. The IG is an important communication device in the home network, with functions such as computing and storage, and acts as a full node of the blockchain, enabling all types of transaction operations (such as creation, validation, and query). The IG stores various types of data collected by IT, and the user (family members in the smart home) can query and manipulate these data as required. Edge computing refers to a new model of performing distributed computing at the edge of the network [18], with ES acting as an edge cloud responsible for smart home big data processing.Figure 3
Smart home network structure.First, the network system initialization is performed by the ES, and the initialization generates the public parameters required for network authentication. Secondly, IT can collect environmental information in the family and use its own ID to complete registration and exchange information with IG. Among other things, IT should also create and store blockchain power tokens and smart contracts (smart contracts define permissions, policies, and constraints associated with the service) on the blockchain. Then, the smart application authenticates the user by verifying the information entered by the user. Finally, after passing the identity verification, users can request blockchain power tokens and smart contracts from IT and then request access to relevant services from IG, and only after the access service request is approved, they can operate on IT with corresponding rights.The detailed description of the proposed blockchain-based authentication scheme is as follows. The scheme includes system initialization, tripartite key negotiation, IT identity binding, and user identity binding.


## 3.2. System Initialization

System initialization is performed by ES, and a public key cryptosystem is constructed using the Elliptic Curve Integrated Encryption Scheme (ECIES) [13] with the following key generation process:


### 3.2.1. System Creation

Enter the security parameterk, and ES produces two large prime numbers p and q and satisfies q|(p − 1). Randomly choose a generating element g of order q of Zp∗, the subgroup generated by is G. ES arbitrarily choose x∈ Zp∗, and calculate y=gx. Select hash function:(3)H1:0,1∗×Zp∗⟶Zq∗,H2:0,1∗×Zp∗×Zp∗⟶Zq∗,H3:0,1∗×Zp∗4×Zp∗×Zp∗⟶Zq∗.System public parameters = {p, q, g, y, H1, H2, H3}, Master Key (msk) = x, and x ∈ Zp∗.


### 3.2.2. Partial Private Key Generation

After entering the user’s identity IDi, the KGC first randomly selectsxi ∈ Zq∗, then calculate Ri=gri, Q1=H1IDi,Ri, Di=xH1IDi,Ri=xQi, return Di to user i through a secure channel, and use Di as part of user i’s private key.


### 3.2.3. Secret Value Setting

UserIDi randomly selects xi ∈ Zq∗ as the long-term private key.


### 3.2.4. Private Key Setting

UserIDi enters the parameters params, a partial private key and Di, output the Si of the private key at the client, where Si=xiQi, and generates the full private key SKi=<Si,Di>.


### 3.2.5. Public Key Setting

The user selects a random secret valuexi, Xi=gxi, to generate the public key PKi=<Xi,Ri>.


## 3.2.1. System Creation

Enter the security parameterk, and ES produces two large prime numbers p and q and satisfies q|(p − 1). Randomly choose a generating element g of order q of Zp∗, the subgroup generated by is G. ES arbitrarily choose x∈ Zp∗, and calculate y=gx. Select hash function:(3)H1:0,1∗×Zp∗⟶Zq∗,H2:0,1∗×Zp∗×Zp∗⟶Zq∗,H3:0,1∗×Zp∗4×Zp∗×Zp∗⟶Zq∗.System public parameters = {p, q, g, y, H1, H2, H3}, Master Key (msk) = x, and x ∈ Zp∗.


## 3.2.2. Partial Private Key Generation

After entering the user’s identity IDi, the KGC first randomly selectsxi ∈ Zq∗, then calculate Ri=gri, Q1=H1IDi,Ri, Di=xH1IDi,Ri=xQi, return Di to user i through a secure channel, and use Di as part of user i’s private key.


## 3.2.3. Secret Value Setting

UserIDi randomly selects xi ∈ Zq∗ as the long-term private key.


## 3.2.4. Private Key Setting

UserIDi enters the parameters params, a partial private key and Di, output the Si of the private key at the client, where Si=xiQi, and generates the full private key SKi=<Si,Di>.


## 3.2.5. Public Key Setting

The user selects a random secret valuexi, Xi=gxi, to generate the public key PKi=<Xi,Ri>.


## 3.3. Tripartite Key Negotiation

In the first use of IT, the user’s participation is required, and the key negotiation between the three is completed through the interaction of IG. Here, IDIT, IDIG, and IDU are the respective identities of IT, IG, and user U. They submit their identities to ES, which completes the system initialization and generates their respective partial private keys, SKIT, SKIG, and SKU.PKIT, PKIG, and PKU are the respective public keys of IT, IG, and user U. NIT, NIG, and NU are random numbers a, b, c, chosen secretly by each of IT, IG, and user U, then calculate NIT = ga, NIG = gb, and NU = gc, and <hU, sU > is the signature generated by user U:(1)
IG sends < IDIG, NIG, PKIG > to IT and U.(2)
UserU receives a message from the IG and generates a key negotiation response message < IDU, NU, PKU>, which is also sent to the IG. IT receives a message from IG and generates a key negotiation response message < IDIT, NIT, PKIT,>, at the same time sending the message to IG.(3)
After IG receives messages from userU and IT, calculate KIG=gcx+xcNUPKUNITPKIT, hIG=H2TIG,IDIG,m, sIG=c+HIG+xIG, generate signature <hIG, sIG>, and send message <IDIG, NIG, PKIG, hIG, sIG > to users U and IT.(4)
As in Figure4, after receiving the identity information <IDIG, NIG, PKIG, hIG, sIG > from the IG, the user U and IT verify the signature of the IG, respectively. If user U and IT pass the authentication to the IG, then user U and IT send their identity information <IDU, NU, PKU, hU, sU>, <IDIT, NIT, PKIT, hIT, sIT>, respectively, to the IG.(5)
If the IG passes the authentication of userU and IT, it first forwards <IDIT, NIT, PKIT, hIT, sIT> to user U and <IDU, NU, PKU, hU, sU> to IT. Then, the user U and IT authenticate each other. Finally, after authentication, user U and IT can each obtain a common session key KS = KIG = KIT = KU by calculation and use this key KS for secure communication in future communications. If the identity information cannot be authenticated, key negotiation needs to be performed again.Figure 4
Tripartite key negotiation between IT, IG, and userU.


## 3.4. Intelligent Terminal Identity Binding

IT needs to initiate the binding of its own ID to IG to generate a unique ITID and store it on the blockchain, and the specific IT binding process is shown in Figure5:(1)
IT first hashes its identity IDIT with SHA256 function to get H(IDIT), then encrypts it with the common session key KS to get E(KS, H(IDIT)), and finally sends it to IG.(2)
The IG receives the message, decrypts it with the common session keyKS to get D(KS, H(IDIT)), and queries whether the device is in the device list.(3)
If present, a device unique identification ITID(i) is generated for it and stored on the blockchain. If it does not exist, it indicates that the device does not exist or is illegal and the identity binding is rejected.Figure 5
IT identity binding process.


## 3.5. User Identity Binding

As with IT, users need to be bound to the ES to ensure their legitimacy. The specific user binding process is shown in Figure6:(1)
UserU sends <IDU, NU, PKU, hU, sU> to ES for key negotiation.(2)
After receiving the message fromU, ES verifies the user’s signature and calculates KES−U=gbx+xbNUPKU, hES=H2TIG,m, and sES=c+HES+xES; m is the message to be signed. ES generates signatures <hES, sES> and send the information <IDES,NES, PKES, hES, sES> to U.(3)
After receiving the signature information <NES, PKES, hES, sES> of the ES, U verifies the signature of the ES, and if user U passes the authentication of the signature of the ES, user U computes KU−ES=gcx+xcNESPKES. Finally, after authentication, the users U and ES can each obtain a common session key KUE = KES − U = KU − ES by calculation to use this key KUE for secure communication in future communications.(4)
The user chooses their identity IDj to be hashed using the SHA256 function to obtain H(IDj). Next, the encryption E(KUE, H(IDj)) is performed with the common session key KUE, and finally, this encrypted message is sent to the ES.(5)
After receiving the message, the ES decryptsD(KUE, H(IDj)) with the common session key KUE and queries whether the user is a legitimate smart home family member.(6)
If legitimate, a user unique identifier UUID(j) is generated for it and added to the blockchain. If it is not legal, the user does not exist or is illegal and the identity binding is rejected.Figure 6
User identity binding process.


## 3.6. User Authentication Access Mechanism

When a user needs to access an IT or access a specific service, user authentication needs to be completed. As shown in Figure7, the specific authentication process is as follows:(1)
the user uses the APP inputU(j) to generate the user authentication request message rU, which consists of an encrypted random number and signature generated by IT(i). That is, KU(RU(j),SigU), where RU(j) is a random number, SigU is its own signature, and KU is the key negotiated by U(j) with ES or IG.(2)
After IG or ES receives the message, it verifies the signature and establishes a connection with the blockchain network, requesting to obtain its unique identifier UUID(j). The ES or IG verifies the existence of the user by decoding the function f(UUID(j)) = H(U′(j)), if H(U′(j)) = H(U(j)), then the user is authenticated; otherwise, the authentication is denied.(3)
After the user establishes the initial trust relationship with the IG or ES, the user sends an access request message to the IT.(4)
IT(i) verifies the user’s signature after receiving the access request message and generates a response message and sends it to the IG. After the IG receives the message, it verifies the validity of IT(i); if it is valid, it forwards the message; otherwise, it rejects the request.(5)
After receiving the response message from IT(i), the user verifies the legitimacy of IT(i) and generates control information and sends it to IT(i). Users can perform control operations on IT(i) or encrypt data interactions.Figure 7
User authentication access process.


## 3.7. IT Authentication Mechanism

### 3.7.1. Single Intelligent Terminal Authentication

In order to avoid illegal intrusion into the smart home network via IT devices, when a single IT device needs to upload data to the ES via IG, the legitimacy of the end device needs to be authenticated. As shown in Figure8, the specific authentication process is as follows:(1)
IT(i) sends the authentication request message rIT to the IG, which consists of an encrypted random number and signature generated by IT(i). That is, KIT-IG (RIT(i), SigIT), where RIT(i) is a random number, SigIT is its own signature, and KIT-IG is the key negotiated between IT(i) and IG.(2)
The IG receives the message, verifies the signature, and establishes a connection to the blockchain network, requesting its unique identification ITID(i). Verify the existence of IT(i) by decoding function f(ITID(i)) = H(IDIT′ (i)), if H(IDIT′ (i)) = H(IDIT(i)), then IG passes the consent authentication and sends an authentication response message to IT(i); otherwise, IG rejects authentication.(3)
The IG encrypts its own signature with the public key of the ES and sends it to the ES together with the authentication request of IT(i).(4)
After receiving the signature and authentication request from the IG, ES first verifies the IG signature. After the ES verifies the IG, it will generate its own signature and sends an IG authentication pass message to the IG; otherwise, authentication is denied. Then, the ES establishes a connection with the blockchain network and requests for the unique identification ITID(i) of that IT(i). ES obtains its unique identifier ITID(i) and then verifies the existence of IT(i) by decoding the function f(ITID(i)) = H(IDIT′ (i)). If H(IDIT′ (i)) = H(IDIT(i)), then IT(i) is authenticated by the ES, which generates an IT(i) authentication pass message and sends it to the IG; otherwise, authentication is denied.(5)
After receiving the signature and authentication pass message from the ES, IG verifies the legitimacy of the ES. If the ES is legitimate, IG will generate its own signature and sends it to IT(i) together with the signature of ES. Otherwise, authentication is rejected.(6)
After receiving the signature and authentication pass message from the IG, IT(i) verifies the legitimacy of the IG and ES. If the IG and ES are legitimate, and the IT(i) receives the ES authentication pass message forwarded by IG, the authentication is passed and data can be sent to the ES via the IG. Otherwise, authentication is rejected.Figure 8
Single intelligent terminal authentication access process.


### 3.7.2. Multiple Intelligent Terminal Authentications

In multiple IT concurrent authentications, identity-based aggregated signatures are introduced to smart home network authentication. Compressing the signatures of any number of entities into one signature reduces the storage space of the signature and at the same time simplifies the authentication of multiple entities to the verification of one signature. In multiple IT concurrent authentications, identity-based aggregated signatures are introduced to smart home network authentication. Compressing the signatures of any number of entities into one signature reduces the storage space of the signatures and simultaneously simplifies the authentication of multiple entities to the verification of one signature. Compared with other authentication schemes, this scheme reduces the burden of data storage space under the premise of ensuring security. The data traffic of interactive messages and signalling is reduced, and the computational workload of verifying the signature is also reduced. It can improve the efficiency of smart home network certification when multiple IT certifications are concurrent. As shown in Figure9, the specific authentication process is as follows:(1)
the IG sends an aggregated signature authentication request to all ITs in the smart home network. This group of endpoints generates their own signatureσ(i) using their own private keys and sends an aggregated signature authentication response message including this signature to the IG.(2)
After IG receives these aggregate signature authentication response messages, it queries whether these IT devices exist. If they exist, the unique identification ASID(s) of the multiterminal is generated and stored in the blockchain. If one or more terminals do not exist, the authentication will be refused, and only the unique identification ASID(s) of the legitimate terminal will be generated and stored in the blockchain.(3)
The IG generates the aggregated signature of the legitimate endpoint and encrypts it with the public key of the ES and sends it to the ES together with the IGs aggregated authentication request.(4)
After the ES receives the aggregated signature and authentication request sent by the IG, it first verifies the aggregated signature of the IG. After the verification is passed, the ES establishes a connection with the blockchain network and requests to obtain the unique identification ASID(s) of multiple ITs.(5)
The ES obtains its unique identification ASID(s) and verifies the existence of IT(s) by decoding the function f(ASID(s)) = H(IDIT′ (s)). If H(IDIT′(s)) = H(IDIT(s)), then IT(s) is authenticated by the ES, which generates its own signature and sends an authentication pass message to the IG. Otherwise, the authentication is rejected.(6)
After receiving the signature and authentication pass message from the ES, the IG verifies the legitimacy of the ES. If the ES is legitimate, it generates its own signature and forwards the authentication pass message; otherwise, it rejects the authentication.(7)
After receiving the signature and authentication pass message from the IG, IT(s) verifies the legitimacy of the IG and ES. If the IG and ES are legitimate, then the authentication is passed and data can be sent to the ES via the IG; otherwise, the authentication is rejected.Figure 9
Multiple Intelligent terminal authentication access processes.


## 3.7.1. Single Intelligent Terminal Authentication

In order to avoid illegal intrusion into the smart home network via IT devices, when a single IT device needs to upload data to the ES via IG, the legitimacy of the end device needs to be authenticated. As shown in Figure8, the specific authentication process is as follows:(1)
IT(i) sends the authentication request message rIT to the IG, which consists of an encrypted random number and signature generated by IT(i). That is, KIT-IG (RIT(i), SigIT), where RIT(i) is a random number, SigIT is its own signature, and KIT-IG is the key negotiated between IT(i) and IG.(2)
The IG receives the message, verifies the signature, and establishes a connection to the blockchain network, requesting its unique identification ITID(i). Verify the existence of IT(i) by decoding function f(ITID(i)) = H(IDIT′ (i)), if H(IDIT′ (i)) = H(IDIT(i)), then IG passes the consent authentication and sends an authentication response message to IT(i); otherwise, IG rejects authentication.(3)
The IG encrypts its own signature with the public key of the ES and sends it to the ES together with the authentication request of IT(i).(4)
After receiving the signature and authentication request from the IG, ES first verifies the IG signature. After the ES verifies the IG, it will generate its own signature and sends an IG authentication pass message to the IG; otherwise, authentication is denied. Then, the ES establishes a connection with the blockchain network and requests for the unique identification ITID(i) of that IT(i). ES obtains its unique identifier ITID(i) and then verifies the existence of IT(i) by decoding the function f(ITID(i)) = H(IDIT′ (i)). If H(IDIT′ (i)) = H(IDIT(i)), then IT(i) is authenticated by the ES, which generates an IT(i) authentication pass message and sends it to the IG; otherwise, authentication is denied.(5)
After receiving the signature and authentication pass message from the ES, IG verifies the legitimacy of the ES. If the ES is legitimate, IG will generate its own signature and sends it to IT(i) together with the signature of ES. Otherwise, authentication is rejected.(6)
After receiving the signature and authentication pass message from the IG, IT(i) verifies the legitimacy of the IG and ES. If the IG and ES are legitimate, and the IT(i) receives the ES authentication pass message forwarded by IG, the authentication is passed and data can be sent to the ES via the IG. Otherwise, authentication is rejected.Figure 8
Single intelligent terminal authentication access process.


## 3.7.2. Multiple Intelligent Terminal Authentications

In multiple IT concurrent authentications, identity-based aggregated signatures are introduced to smart home network authentication. Compressing the signatures of any number of entities into one signature reduces the storage space of the signature and at the same time simplifies the authentication of multiple entities to the verification of one signature. In multiple IT concurrent authentications, identity-based aggregated signatures are introduced to smart home network authentication. Compressing the signatures of any number of entities into one signature reduces the storage space of the signatures and simultaneously simplifies the authentication of multiple entities to the verification of one signature. Compared with other authentication schemes, this scheme reduces the burden of data storage space under the premise of ensuring security. The data traffic of interactive messages and signalling is reduced, and the computational workload of verifying the signature is also reduced. It can improve the efficiency of smart home network certification when multiple IT certifications are concurrent. As shown in Figure9, the specific authentication process is as follows:(1)
the IG sends an aggregated signature authentication request to all ITs in the smart home network. This group of endpoints generates their own signatureσ(i) using their own private keys and sends an aggregated signature authentication response message including this signature to the IG.(2)
After IG receives these aggregate signature authentication response messages, it queries whether these IT devices exist. If they exist, the unique identification ASID(s) of the multiterminal is generated and stored in the blockchain. If one or more terminals do not exist, the authentication will be refused, and only the unique identification ASID(s) of the legitimate terminal will be generated and stored in the blockchain.(3)
The IG generates the aggregated signature of the legitimate endpoint and encrypts it with the public key of the ES and sends it to the ES together with the IGs aggregated authentication request.(4)
After the ES receives the aggregated signature and authentication request sent by the IG, it first verifies the aggregated signature of the IG. After the verification is passed, the ES establishes a connection with the blockchain network and requests to obtain the unique identification ASID(s) of multiple ITs.(5)
The ES obtains its unique identification ASID(s) and verifies the existence of IT(s) by decoding the function f(ASID(s)) = H(IDIT′ (s)). If H(IDIT′(s)) = H(IDIT(s)), then IT(s) is authenticated by the ES, which generates its own signature and sends an authentication pass message to the IG. Otherwise, the authentication is rejected.(6)
After receiving the signature and authentication pass message from the ES, the IG verifies the legitimacy of the ES. If the ES is legitimate, it generates its own signature and forwards the authentication pass message; otherwise, it rejects the authentication.(7)
After receiving the signature and authentication pass message from the IG, IT(s) verifies the legitimacy of the IG and ES. If the IG and ES are legitimate, then the authentication is passed and data can be sent to the ES via the IG; otherwise, the authentication is rejected.Figure 9
Multiple Intelligent terminal authentication access processes.


## 4. Security Analysis

Lemma 1.
Assume that the cryptographic problem of the elliptic curve used in the scheme is secure, and the single-item security is that the adversary cannot obtain the corresponding plaintext from the ciphertext when he does not know the user’s private key, that is, the adversaryu can obtain the inverse from the ciphertext. The probability is negligible under any polynomial algorithm A (Hypotheses 1 and 2).(4)SuccZp∗,ADL=Prxi←Ag,gxi,(5)SuccZp∗,ADL=Prri←Ag,gri.
It follows from Hypothesis2 and the Lemma that (4) and (5) successfully solved are negligible under any polynomial algorithm A.
In theory, hackers can simultaneously intercept the public keys PKa, PKb, and PKc and the random numbers Ra, Rb, and Rc of users A, B, and C in the channel.” If an attacker wants to obtain the shared key K, he must obtain the master key x and any one of the random numbers ra, rb, and rc at the same time. Taking user A as an example, the attacker wants to obtain the shared key, and other information can be obtained by intercepting the information, but he must also obtain the master key x and the random number ra at the same time. The formula is as follows:(6)SuccZp∗,ACDH=Prgrax←Ag,gra,gx.
It follows from Hypothesis1 and the Lemma that (6) successfully solved under any polynomial algorithm A is negligible. Therefore, the solution is monomial secure and the proof is over.
In addition to one-way security, the scheme also has security features such as antireplay attack, man-in-the-middle attack, denial of service attack, active attack, and passive eavesdropping.


### 4.1. Confidentiality

The user and IT use the shared key to encrypt the authentication request message to the IG or ES. When the IG or ES receives the authentication request, the shared key is used for decryption. Other communication entities cannot obtain the authentication because they do not have the decrypted shared key.


### 4.2. Freshness

The freshness of messages transmitted between usersU, IG, and ES is guaranteed by random numbers. User U attaches a random number when sending an authentication data request, and IG and ES also attach a random number when sending an authentication response. By checking whether the received random number is the same as the one sent by itself, if it is different, the authentication fails. Therefore, it can be guaranteed that every authentication message sent has a freshness guarantee.


### 4.3. Unforgeability

When a forger pretends to be a signeru to forge a single signature σu=(Uu, Vu), although Uu can be calculated from the public key and random number, Vu cannot be calculated correctly because Vu=(hu, Ru)QIDu, and the forger does not know Ru, QIdu, and hu, so it is impossible to forge σu to pass the signature authentication. According to the unforgeability of a single signature, while a forger can forge U, it cannot forge V so that it passes verification. Since the aggregated signature is jointly determined by multiple users, the counterfeiter needs to obtain the private key SK of all the signers to obtain the signature, which is obviously unrealistic. Even if the attacker obtains one or more private keys, it also cannot generate the correct aggregate signature without knowing the other private keys.


### 4.4. Antireplay Attack

When an attacker is replaying an old authentication data request message from a user or terminal, the IG or ES receives the message and verifies that the random number it contains is the same as its own current random number. If it is different, the authentication data request message is rejected. Similarly, when an attacker replayed an old authentication response message from IG or ES, it would be rejected by the user or endpoint.


### 4.5. Anti-Man-in-the-Middle Attack

When an attacker impersonates IG to eavesdrop and tamper with the authentication message between ES, IT, and users, it cannot be successful. Because the attacker does not know the private key of the ES, and there is signature authentication between the ES, the user, and the IG. If it cannot pass the signature authentication, the ES will reject the request when it receives the authentication data request message, and the user will also reject the request when it receives the authentication response message from the IG. Therefore, it can defend against man-in-the-middle attacks.


### 4.6. Resisting Distributed Denial of Service Attacks (DDos)

The smart home authentication network is based on blockchain, which uses a distributed network. When a network communication node (such as IG) is attacked and the user cannot log in normally, the normal communication of other IGs is not affected. Therefore, it can effectively resist DDos.Table1 analyzes the authentication comparison between the three existing schemes and the newly proposed scheme. The scheme’s authentication includes the following: ① ES to user authentication (ES-U): ② ES to IT authentication (ES-IT); ③ user to ES authentication (U-ES); ④ user to IT authentication (U-ES); and ⑤ IT to user authentication (IT-U).Table 1
Comparison of authentication schemes.
ProtocolES-UES-ITU-ESU-ITIT-UTyche [11]YNYNNLiterature [12]YNNYNLiterature [13]YYNNNBCASYYYYYFrom the above security analysis and the comparison of Tables1 and 2, it can be concluded that the proposed solution has a higher level of security than these three existing solutions.Table 2
Types of attacks that each of the compared schemes can resist.
ProtocolReplayDDosMan-in-the-middleConfidentialityTyche [11]YNYNLiterature [12]YNNYLiterature [13]YYNYBCASYYYY


## 4.1. Confidentiality

The user and IT use the shared key to encrypt the authentication request message to the IG or ES. When the IG or ES receives the authentication request, the shared key is used for decryption. Other communication entities cannot obtain the authentication because they do not have the decrypted shared key.


## 4.2. Freshness

The freshness of messages transmitted between usersU, IG, and ES is guaranteed by random numbers. User U attaches a random number when sending an authentication data request, and IG and ES also attach a random number when sending an authentication response. By checking whether the received random number is the same as the one sent by itself, if it is different, the authentication fails. Therefore, it can be guaranteed that every authentication message sent has a freshness guarantee.


## 4.3. Unforgeability

When a forger pretends to be a signeru to forge a single signature σu=(Uu, Vu), although Uu can be calculated from the public key and random number, Vu cannot be calculated correctly because Vu=(hu, Ru)QIDu, and the forger does not know Ru, QIdu, and hu, so it is impossible to forge σu to pass the signature authentication. According to the unforgeability of a single signature, while a forger can forge U, it cannot forge V so that it passes verification. Since the aggregated signature is jointly determined by multiple users, the counterfeiter needs to obtain the private key SK of all the signers to obtain the signature, which is obviously unrealistic. Even if the attacker obtains one or more private keys, it also cannot generate the correct aggregate signature without knowing the other private keys.


## 4.4. Antireplay Attack

When an attacker is replaying an old authentication data request message from a user or terminal, the IG or ES receives the message and verifies that the random number it contains is the same as its own current random number. If it is different, the authentication data request message is rejected. Similarly, when an attacker replayed an old authentication response message from IG or ES, it would be rejected by the user or endpoint.


## 4.5. Anti-Man-in-the-Middle Attack

When an attacker impersonates IG to eavesdrop and tamper with the authentication message between ES, IT, and users, it cannot be successful. Because the attacker does not know the private key of the ES, and there is signature authentication between the ES, the user, and the IG. If it cannot pass the signature authentication, the ES will reject the request when it receives the authentication data request message, and the user will also reject the request when it receives the authentication response message from the IG. Therefore, it can defend against man-in-the-middle attacks.


## 4.6. Resisting Distributed Denial of Service Attacks (DDos)

The smart home authentication network is based on blockchain, which uses a distributed network. When a network communication node (such as IG) is attacked and the user cannot log in normally, the normal communication of other IGs is not affected. Therefore, it can effectively resist DDos.Table1 analyzes the authentication comparison between the three existing schemes and the newly proposed scheme. The scheme’s authentication includes the following: ① ES to user authentication (ES-U): ② ES to IT authentication (ES-IT); ③ user to ES authentication (U-ES); ④ user to IT authentication (U-ES); and ⑤ IT to user authentication (IT-U).Table 1
Comparison of authentication schemes.
ProtocolES-UES-ITU-ESU-ITIT-UTyche [11]YNYNNLiterature [12]YNNYNLiterature [13]YYNNNBCASYYYYYFrom the above security analysis and the comparison of Tables1 and 2, it can be concluded that the proposed solution has a higher level of security than these three existing solutions.Table 2
Types of attacks that each of the compared schemes can resist.
ProtocolReplayDDosMan-in-the-middleConfidentialityTyche [11]YNYNLiterature [12]YNNYLiterature [13]YYNYBCASYYYY


## 5. Performance Analysis

The smart home network architecture in this paper is built on the Ethernet platform. In the simulation testing and evaluation experiments, ES and IG were used as full nodes, and IT and users consisting of various sensors were used as light nodes. The Lenovo Yangtze P880 workstation was used as the Linux server. The configuration used for the ES was the Raspberry Pi 2020-02-05. IG uses a standalone virtual machine running the SDN controller in a Linux server. Smart contracts were coded using Solidity v0.5.0. The experimental environment is shown in Table3.Table 3
Experimental environment parameters.
Software/hardwareParameterOperating systemUbuntu Linux 20.04LTSCPUIntel i7 10700 2.9 GHzProgramming languagesSolidityMemory16GRaspberry Pi4B+


### 5.1. Analysis of User Authentication

In the simulation evaluation, the proposed scheme is compared with the risk-based access control architecture Tyche from literature [11], the cloud and blockchain-based approach to smart home access control from literature [12], and the IoT authentication and access control approach from literature [13]. Tyche is a system that leverages the risk-asymmetry in physical device operations to limit the risk that apps pose to smart home users [11]. The risk-based groupings of device operations are defined in this system and applied to existing SmartThings apps. To counter the possible attacks on the gateway of smart homes, a blockchain-based smart home gateway network is proposed in literature [12]. To support decentralization and overcome the problem from traditional centralized architecture, this smart home network includes device, gateway, and cloud layers. The blockchain technology is employed at the gateway layer wherein data are stored and exchanged in the form blocks of blockchain. To monitor the activities that take place on particular data evidence, a novel Cloud framework based on Software Defined Network (SDN) is proposed in literature [13]. This framework includes IoT devices (100-mobile nodes), open flow switch, and blockchain-based controllers, cloud server, authentication server (AS), and investigator. In the mobile nodes, the packets are encrypted by using the ECIES algorithm and transferred to the cloud server.The computational overhead mainly includes the encryption and decryption algorithms used for user registration and user authentication, signature authentication, hash functions, and decoding functions. The overhead calculated in the simulation experiments in this paper is the total time required for a user to initiate a registration and for the authentication to complete, as shown in Figure10, and the simulation results are the average of 20 tests. It can be seen that the time spent in this scheme is less than in literature [11, 12] due to the shorter length of the ECIES key used and therefore less computational overhead. However, compared with the literature [13], the computational cost is slightly longer because the user authentications to IT and IT to user authentication are added to the user authentication scheme, which increases the computational cost but improves the security of authentication.Figure 10
Comparison of user authentication calculation overheads.


### 5.2. Analysis of IT Authentication

Intelligent terminal authentication simulation experiments use response time for performance analysis. The response time is the time taken from the initiation of an authentication request message to the receipt of an authentication pass message. Firstly, the response time in the case of a small number of concurrent authentication requests using a single intelligent terminal authentication method. As shown in Figure11, the response time of schemes is increased as the number of IT increases. This is because as the number of nodes increases, the number of signatures to be verified increases and the computation delay becomes longer. Compared to other schemes, BCAS scheme has the shortest response time. This is because that the single IT authentication process is optimized in this paper. After the ES completes the IG authentication, it sends its own signature to the IG. Then, while the ES verifies the blockchain identity of the IT, the IG authenticates the effectiveness of the ES. This reduces the computational latency, which improves the response time. However, in Figure 11, the advantage of scheme BCAS is not obvious when the number of ITs is small, due to the fact that the computation time for signatures is a smaller proportion of the response time.Figure 11
Comparison of response times when the number of IT concurrent is low.Figure12 shows a comparison of the response time with different numbers of sensor nodes using the Tyche and BACS Literature [12, 13] schemes.Figure 12
Comparison of response times when the number of IT concurrent is high.The response time of all schemes becomes longer as the number of sensor nodes increases. This is because as the number of nodes increases, the number of signatures to be verified increases and the computation delay becomes longer. In Figure12, as the number of IT concurrent increases, the response time increases for all schemes. However, the BCAS method increases less quickly than the other methods. This is due to the fact that the BCAS scenario reduces the number of verification signatures when handling multiple IT certifications. With the increase of concurrent ITs authentication, BCAS has obvious advantages. It is due to the fact that the computation time of the signature occupies a large proportion of the response time. The average response time of BCAS is 12.03% lower than that of literature [13], 48.53% lower than that of Tyche, and 52.23% lower than that of literature [12]. Therefore, the proposed solution has greater advantages when the number of IT certifications increases dramatically (such as smart home network power outage restarts and IG disconnections).


## 5.1. Analysis of User Authentication

In the simulation evaluation, the proposed scheme is compared with the risk-based access control architecture Tyche from literature [11], the cloud and blockchain-based approach to smart home access control from literature [12], and the IoT authentication and access control approach from literature [13]. Tyche is a system that leverages the risk-asymmetry in physical device operations to limit the risk that apps pose to smart home users [11]. The risk-based groupings of device operations are defined in this system and applied to existing SmartThings apps. To counter the possible attacks on the gateway of smart homes, a blockchain-based smart home gateway network is proposed in literature [12]. To support decentralization and overcome the problem from traditional centralized architecture, this smart home network includes device, gateway, and cloud layers. The blockchain technology is employed at the gateway layer wherein data are stored and exchanged in the form blocks of blockchain. To monitor the activities that take place on particular data evidence, a novel Cloud framework based on Software Defined Network (SDN) is proposed in literature [13]. This framework includes IoT devices (100-mobile nodes), open flow switch, and blockchain-based controllers, cloud server, authentication server (AS), and investigator. In the mobile nodes, the packets are encrypted by using the ECIES algorithm and transferred to the cloud server.The computational overhead mainly includes the encryption and decryption algorithms used for user registration and user authentication, signature authentication, hash functions, and decoding functions. The overhead calculated in the simulation experiments in this paper is the total time required for a user to initiate a registration and for the authentication to complete, as shown in Figure10, and the simulation results are the average of 20 tests. It can be seen that the time spent in this scheme is less than in literature [11, 12] due to the shorter length of the ECIES key used and therefore less computational overhead. However, compared with the literature [13], the computational cost is slightly longer because the user authentications to IT and IT to user authentication are added to the user authentication scheme, which increases the computational cost but improves the security of authentication.Figure 10
Comparison of user authentication calculation overheads.


## 5.2. Analysis of IT Authentication

Intelligent terminal authentication simulation experiments use response time for performance analysis. The response time is the time taken from the initiation of an authentication request message to the receipt of an authentication pass message. Firstly, the response time in the case of a small number of concurrent authentication requests using a single intelligent terminal authentication method. As shown in Figure11, the response time of schemes is increased as the number of IT increases. This is because as the number of nodes increases, the number of signatures to be verified increases and the computation delay becomes longer. Compared to other schemes, BCAS scheme has the shortest response time. This is because that the single IT authentication process is optimized in this paper. After the ES completes the IG authentication, it sends its own signature to the IG. Then, while the ES verifies the blockchain identity of the IT, the IG authenticates the effectiveness of the ES. This reduces the computational latency, which improves the response time. However, in Figure 11, the advantage of scheme BCAS is not obvious when the number of ITs is small, due to the fact that the computation time for signatures is a smaller proportion of the response time.Figure 11
Comparison of response times when the number of IT concurrent is low.Figure12 shows a comparison of the response time with different numbers of sensor nodes using the Tyche and BACS Literature [12, 13] schemes.Figure 12
Comparison of response times when the number of IT concurrent is high.The response time of all schemes becomes longer as the number of sensor nodes increases. This is because as the number of nodes increases, the number of signatures to be verified increases and the computation delay becomes longer. In Figure12, as the number of IT concurrent increases, the response time increases for all schemes. However, the BCAS method increases less quickly than the other methods. This is due to the fact that the BCAS scenario reduces the number of verification signatures when handling multiple IT certifications. With the increase of concurrent ITs authentication, BCAS has obvious advantages. It is due to the fact that the computation time of the signature occupies a large proportion of the response time. The average response time of BCAS is 12.03% lower than that of literature [13], 48.53% lower than that of Tyche, and 52.23% lower than that of literature [12]. Therefore, the proposed solution has greater advantages when the number of IT certifications increases dramatically (such as smart home network power outage restarts and IG disconnections).


## 6. Conclusions

As an important part of IoT applications, smart home networks can bring great convenience to family life. However, as remote users and the smart home network communicate through insecure channels, there are important security risks for sensitive information of users and intelligent devices. It is therefore necessary to design a secure and efficient authentication scheme to secure the communication. This paper proposes a certificateless authentication scheme for edge computing based on blockchain. The scheme has security features such as decentralization, unforgeability, resistance to replay attacks, and resistance to man-in-the-middle attacks. Performance simulation experiments show that this scheme has less computational overhead and shorter response time, especially in the case of high IT concurrent certification. At the same time, smart home data are stored in ES to reduce data security problems caused by IG being attacked. However, the proposed authentication scheme needs more control information. The computational cost of the BCAS method is still high for the ITs and users. In future research, the efficient and secure cryptographic signature methods will be considered to improve computational cost and optimize the authentication process. To reduce the response time, the offline computing will be introduced into the smart home authentication.



---

*Source: 6458461-2022-08-26.xml*