Received 8 December 2023, accepted 21 December 2023, date of publication 28 December 2023,

date of current version 9 January 2024.

Digital Object Identifier 10.1109/ACCESS.2023.3347808

A New Identity Authentication and Key

Agreement Protocol Based on Multi-Layer
Blockchain in Edge Computing
YAO CHEN , QINGQING YANG , XIN ZENG, DENGQI YANG, AND XIAOWEI LI
School of Mathematics and Computer Science, Dali University, Dali 671003, China
Corresponding author: Xiaowei Li ([email protected])
This work was supported by the National Natural Science Foundation of China under Grant 62262001, Grant 61902049, and Grant
32260131.

ABSTRACT In today’s interconnected world, identity authentication and key agreement are important links
in the secure communication process of IoT terminal devices. In the edge computing environment, with
the frequent cross-domain authentication and data sharing of IoT devices in different security domains,
identity authentication faces a series of challenges and security issues. Most of the traditional identity
authentication methods are based on public key infrastructure, which is prone to single point of failure
and is not applicable to the distributed architecture of edge computing. In this article, we apply blockchain
technology to the identity authentication and key agreement process of IoT terminal devices. In order to
meet cross-domain requests from terminal devices in different security domains, a multi-layer blockchain
authentication architecture is designed. The hash value of the digital certificate is stored on the blockchain
and combined with dynamic accumulator technology to enhance the reliability and authentication efficiency
of the digital certificate. Security analysis and experimental results demonstrate that our scheme can achieve
efficient and secure authentication and key agreement.

INDEX TERMS Edge computing, identity authentication, key agreement, multi-layer blockchain.

I. INTRODUCTION heavy burden on cloud center authentication. The traditional

Nowadays, we are witnessing the rapid proliferation of intel- cloud computing environment falls short of meeting the grow-
ligent devices in the digital age, ushering in an era of ing demand. The introduction of edge computing [8] aims to
interconnected everything [1]. The IoT exhibits character- alleviate the computing pressure on the cloud center by divert-
istics such as multi-source heterogeneity and openness, but ing data flow. Edge servers are deployed to take over certain
it also confronts challenges related to cyber threats and pri- functions of the cloud center and handle the computing and
vacy [2]. This makes the protection of the identity information storage tasks of devices in close proximity to the terminals.
of IoT devices of great significance to individuals, fami- The network architecture is illustrated in Fig. 1.
lies, society and even national security. The applications of At present, traditional identity authentication methods are
the Internet of Things span various domains, including the mostly based on Public Key Infrastructure (PKI) imple-
smart grid [3], smart cities [4], intelligent transportation [5], mentation, which belongs to centralized authentication [9],
healthcare [6], and the industrial Internet of Things [7]. With [10], [11]. The centralized authentication process requires the
the advancement of the Internet, a large number of terminal involvement of a trusted third party and is prone to single
devices are being connected to the network. Traditional cloud point of failure issues. The security of this type of authen-
centers suffer from data processing delays, resulting in a tication relies on the stability of the Certificate Authority
(CA) [12]. The authentication process uses digital certifi-
The associate editor coordinating the review of this manuscript and cates issued by CAs to authenticate identities. Once a CA is
approving it for publication was Zijian Zhang . attacked, it will result in identity authentication being unable

2023 The Authors. This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 License.
3274 For more information, see https://creativecommons.org/licenses/by-nc-nd/4.0/ VOLUME 12, 2024
Y. Chen et al.: New Identity Authentication and Key Agreement Protocol

protocol meets security requirements, as demonstrated

by formal security analysis tools and proof of pro-
tocol security under the ROR model. Comparing its
performance with similar cross-domain authentication
protocols shows that this protocol exhibits good com-
putational performance.
The rest of this article is organized as follows. In Section II,
we investigated the work related to cross-domain authentica-
tion. Section III introduces relevant knowledge and system
models. In Section IV, we propose our authentication and
FIGURE 1. Edge computing architecture.
key agreement scheme based on the edge computing environ-
ment. The security analysis and Blockchain impleme-ntation
to proceed. Digital certificate verification in the authentica- are presented in Sections V and VI respectively. Section VII
tion process needs to be completed by public key encryption is the performance analysis of the protocol. Finally, we con-
and digital signature. This leads to complication of certificate clude the paper in Section VIII.
verification process, longer verification times and verifica-
tion time. There are multiple security domains for identity II. RELATED WORK
authentication in the edge computing environment [13], and Traditional cloud centers interact with IoT devices directly
the authentication hierarchy is complex. Massive terminal for authentication and information. In a scenario where a
devices need to cross-domain authentication under different large number of IoT devices are dynamically accessed, this
security domains to request frequent data access. In order to will lead to high operating costs and difficulties in mutual
ensure the consistency and security of the distributed Internet trust between edge servers of different security domains. IoT
of Things system, we provide a distributed authentication application scenarios exhibit greater dynamism, heterogene-
scheme using blockchain technology. Blockchain itself is ity, and scale compared to cloud computing environments.
a distributed network architecture. The binding energy of However, under the network architecture of edge computing,
blockchain and edge computing can well solve the security frequent cross-domain authentication and data sharing among
problems in identity authentication [14], [15]. Due to its terminal devices pose additional requirements for identity
decentralized, tamper proof, open and transparent character- authentication and key agreement protocols. To address var-
istics, blockchain technology can solve the single point of ious security and performance issues, many scholars have
failure problem of public key infrastructure-based authenti- conducted research in this area.
cation [16]. Therefore, the use of blockchain technology can Garba et al. [17] proposed a blockchain based BB-PKI to
establish communication channels for IoT devices in different manage certificates. To avoid single point of failure, multi-
security domains. ple CAs issue certificates and record certificate transactions
The main contributions of this paper can be summarized as on the blockchain through smart contracts. In the work of
follows: Garba et al. [18], a blockchain-based cross-domain authen-
• This paper is primarily based on the distributed archi- tication scheme was proposed. It has privacy-preserving
tecture of edge computing networks. In order to address features for low-performance devices. A set of trusted CAs
the cross-domain requests from IoT devices in differ- associated with a specific region in the blockchain is estab-
ent security domains, we have designed a multi-layer lished and these CAs are responsible for issuing and renewing
blockchain authentication architecture and proposed a certificates. Gu and Chen [19] proposed a cross-domain
protocol scheme for identity authentication and key authentication protocol based on blockchain, which stores
agreement for both single-domain and cross-domain ter- certificate hash values on the blockchain and designs a certifi-
minal devices based on the multi-layer blockchain. cate revocation process. However, there is a problem of low
• The hash value of the digital certificate is stored on authentication efficiency. Wang et al. [20] proposed an anony-
the blockchain, which improves the reliability of the mous authentication model in combination with blockchain
digital certificate. It also simplifies the digital certifi- technology. A decentralized network with the root certifi-
cate reliability verification process, reduces the number cate authority as the authentication node was constructed.
of signature verification and improves authentication Yuan et al. [21] proposed a cross-domain identity authentica-
efficiency. To solve the problem of inefficient on-chain tion scheme between the PKI domain and the IBE domain,
data queries due to the increased size of the blockchain, in which a heterogeneous cross-domain authentication key
the authentication process incorporates dynamic accu- agreement protocol was designed to achieve cross enterprise
mulator technology to improve the efficiency of the communication, but there was a problem of high computa-
authentication process certificate verification. tional complexity. In [22] and [23], an identity authentication
• The protocol designed in this paper was analyzed for protocol with privacy protection was proposed, which intro-
security and performance. The results indicate that the duces group signature verification for users. However, this

VOLUME 12, 2024 3275

 Y. Chen et al.: New Identity Authentication and Key Agreement Protocol

TABLE 1. Main work and limitations.

FIGURE 2. Multi-layer blockchain authentication architecture.

scheme has high computational overhead and is not suitable

for low-performing IoT devices. Wang et al. [24] proposed for low-performing IoT devices, as IoT devices have lim-
a blockchain based on cross-domain authentication scheme ited resources and cannot bear significant computational
for the Internet of Things. The authentication relationship is costs. Therefore, we propose a new cross-domain identity
abstracted into an undirected graph, and the combination of authentication and key agreement protocol based on multi-
accumulator and digital signature formulates the authentica- layer blockchain, which combines dynamic accumulator to
tion problem, which can be well verified the legitimacy of improve identity authentication efficiency and achieve effi-
the authentication. Wang et al. [25] established a multi-CA cient and secure authentication and key agreement.
authentication architecture to achieve cross-domain cer-
tificate information sharing. The cross-domain certificate III. SYSTEM ARCHITECTURE AND DYNAMIC
revocation mechanism was designed to improve the authen- ACCUMUL-ATOR TECHNOLOGY
tication efficiency. Jia et al. [26] proposed a decentralized A. SYSTEM ARCHITECTURE
authentication model using identity-based own authentication Due to the existence of different security domains in the
algorithm instead of PKI. The model is based on blockchain edge computing environment. The same domain terminal
combined with smart contracts and threshold ciphers and has device authentication approach is no longer applicable to
good flexibility. Guo et al. [27] focused on the authentication the authentication environment of multiple security domains.
between different security domains in IoT. A master-slave The local area blockchain in a single security domain cannot
blockchain architecture supporting distributed cross-domain meet the demand of terminal devices to access resources
authentication was designed. An improved Byzantine fault across domains. It also cannot guarantee that the endpoints
tolerance (RIBFT) based on reputation value model was in other security domains can securely access the security
proposed for trusted authentication and data traceability. domain. In order to ensure the consistency and security of
The scheme considers the trustworthiness of the authentica- decentralized IoT systems, we have designed a multi-layer
tion process and the traceability of transaction information. blockchain architecture. In addition, multi-layer blockchains
Cheng et al. [28] proposed a two-way authentication scheme can effectively alleviate the storage pressure of individual
based on blockchain for edge servers and IoT devices. The blockchains, reduce the burden of blockchain queries, and
scheme is mobile and anonymous, and it is suitable for use in meet the cross-domain authentication and key agreement
collaborative edge computing environments. Moni and Mani- between terminal devices in different security domains.
vannan [29] proposed a lightweight identity authentication The system architecture of multi-layer blockchain
protocol for WANET based on the cuckoo filter. Performance designed in this paper is composed of local blockchain
evaluation shows that this protocol has good performance network and public blockchain network. Terminal devices,
overhead and faster authentication efficiency compared to edge server, and local certificate authority CA belonging to
other protocols, but there is a probability of false positives, the same security domain together form the local blockchain
making it difficult to adapt to cross-domain authentication in network. Certificate authorities in different security domains
important situations. A summary of the work of the above form a public blockchain network. When terminal devices
scheme and its limitations are shown in Table 1. belonging to different security domains need to authenticate
However, most Internet of Things authentication protocols communication, they can use the public blockchain network
now have two shortcomings. First, authentication schemes as a communication bridge. The local blockchain and public
based on traditional cloud centers are centralized authen- blockchain are built based on the prototype of the alliance
tication, which essentially relies on trusted third parties. chain, and only approved nodes are allowed to join the
This mode will cause single point of failure and scalability blockchain network. The system architecture is shown in
problems. Secondly, most existing protocols are not suitable Fig. 2.

3276 VOLUME 12, 2024

Y. Chen et al.: New Identity Authentication and Key Agreement Protocol

Local blockchain is responsible for data security of nodes Algorithm 1 Create Accumulator
within the same security domain and identity authentication Input: security parameter 1λ
of the same security domain. Due to the limited comput- Output: accumulator administrator keys (skacc , pkacc )
ing performance of IoT devices, identity authentication and Choose Large prime number p, q
queries are allowed, but they do not participate in the main- Compute N = p ∗ q
tenance of blockchain ledgers. The local blockchain stores Compute Euler function ϕ (n) = (p − 1) ∗ (q − 1)
the certificate hash value of terminal devices within the Select integer g
local domain. Compared to the public blockchain, there are g satisfies gϕ(n) mod n = 1 and g ̸= 1
fewer users and fewer certificates within the local blockchain, acc0 = g ∈ ZN
so lookups are more efficient. When cross domain authen- (skacc , pkacc ) = ((p, q), N ) ← 1λ
tication occurs, local devices cannot access blockchains Return (skacc , pkacc )
from other domains. For this reason, we introduce public
blockchain. The hashes of digital certificates in all secure
domains are stored in the public blockchain, which can satisfy Algorithm 2 Add Element
the verification of digital certificates during cross-domain
Input: cumulative value accx , add element x,element
authentication.
collection X , pkacc
Unlike CA in traditional PKI, each security domain has a
Output: accx ′ , X ′
CA. CA, the certificate issuing authority, is both a node in the
/ X then
if x ∈
local blockchain and a member node of the public blockchain. accx ′ = accX ∪{x} = accxX mod N
CA performs identity verification and certificate issuance for X ′ = X ∪ {x}
IoT devices joining the blockchain in the local blockchain end
network, and it issues cross-domain certificates for cross- returnaccx ′ , X ′
domain authenticated IoT devices in the public blockchain.
CA calculates the certificate hash and cumulative value for
each certificate issued. The dynamic accumulator verifies the Algorithm 3 Del Element
hash of the packaged certificate on the chain, ensuring the Input: cumulative value accx , delete element x,
safe and efficient identity authentication process. element collection X , (skacc , pkacc )
The edge server not only participates in the maintenance of Output: accx ′ , X ′
the local blockchain network, but also assists in completing if Verelement() then
cross-domain authentication of terminal devices in differ- x −1 mod ϕ(n)
accx ′ = accX \{x} = accX mod N
ent security domains. The edge server within each security
X ′ = X \{x}
domain is involved in maintaining the local blockchain. At the end
time of cross-domain access request from terminal devices, return accx ′ , X ′
the edge server and CA are jointly responsible for the infor-
mation interaction for cross-domain authentication.

entered to generate the accumulator administrator’s public

B. DYNAMIC ACCUMLATORS and private key pairs. The initial empty accumulation value
Due to the growing volume of the blockchain, the cost acc0 = g ∈ ZN .
of querying the data on the blockchain is becoming larger The process of adding, deleting, and verifying elements in
and larger. At present, dynamic accumulators are attracting the dynamic accumulator is shown in Algorithm 2-4. After
more and more researchers’ attention. Many accumulators adding element x, the administrator updates the accumulated
with different characteristics have been proposed. In general, value acc and adds the element x to the set X . Deleting
dynamic accumulators are divided into three working direc- element x requires the administrator’s private key skacc . After
tions: RSA accumulators based on strong RSA assumptions, deletion, update the accumulated value and remove element x
bilinear paired accumulators based on q-SDH assumptions, from the collection X . The dynamic accumulator accumulates
and accumulators based on anti-collision hashes and hash a finite set of elements inside into an accumulative value. For
trees [30]. each element in the set, its evidence value W is calculated to
RSA dynamic accumulator allows dynamic addition or prove that the element is inside the accumulator.
deletion of elements from a given accumulator, and real-time
update of existing member witness [31]. The dynamic accu- IV. PROPOSED PROTOCOL
mulator implementation process is shown in the following The authentication scheme is divided into three stages: ter-
algorithm. minal device identity registration, design of authentication
The creation and initialization process of the accumulator and key agreement protocols in the same domain and cross-
is shown in Algorithm 1. Select p, q, and g that meet the domain. The identity registration phase is the same for same
conditions to calculate N and ϕ (n).Security parameter 1λ is domain and cross-domain authenticated IoT devices.

VOLUME 12, 2024 3277

 Y. Chen et al.: New Identity Authentication and Key Agreement Protocol

Algorithm 4 Ver Element

Input: cumulative value accx ,validate elements xi ,
witness value Wi , pkacc
Output: success, false
Compute acc′x = Wixi mod N
if acc′x = accx then
| return success
end
else return false

TABLE 2. Notation description of authentication and key agreement

protocol.

FIGURE 3. Identity registration process.

sends a certificate application to the CA, which requests the

edge server to verify the identity information and issue a
certificate after verification. Take identity registration and
certificate application of terminal device Dx in domain X as
an example, and the specific process is shown in Fig. 3.
Step 1: The terminal device Dx belonging to the domain
X sends a registration request to the edge server ESx .
Step 2: When the edge server ESx receives the registration
request, it decrypts request with its own private key SESx
to obtain the identity of the terminal device Dx . It checks
whether the identity is registered, and if not, stores the identity
information locally.
Step 3: The edge server ESx sends the successful regis-
tration message and the signed identity information to the
Table 2 shows the notation description of IoT devices terminal device Dx .
authentication and key agreement protocol. Step 4: The terminal device Dx signs IDx with its own pri-
vate key and sends Sig(IDx ), IDx and PKDx to CA to request
A. REGISTER a certificate. i.e., Dx sends EPKCA (Sig(IDx ) ∥ IDx ∥ PKDx )
Before the registration and certificate application of same to CA.
domain terminal devices begin, the public key of the edge Step 5: The CAx decrypts the message with the private key
server on the local blockchain has been packaged on the to obtain the identity information of terminal device Dx and
Genesis block. A trusted public key is provided for terminal verify the signature. If the verification is passed, the identity
devices identity registration and certificate acquisition. information has been successfully registered.
This section describes the identity registration process of Step 6: The CAx issues a certificate CertDx to terminal
terminal device D in the local blockchain. At this stage, the device Dx , calculates the hash of certificate h(CertDx ), and
IoT terminal device D of the local blockchain submits a reg- packages the certificate to the chain through the consensus
istration request and encrypts the identity information to the algorithm. The cumulative value a = acc(h(CertDx )) and
edge server ES. The edge server checks whether the identity certificate witness W are generated for the certificate and
information is registered. If it is not registered, it performs the included in the dynamic accumulator.
identity registration operation. If it is registered, the registra- Step 7: The terminal device Dx decrypts to obtain the local
tion fails. After successful registration, the terminal device blockchain digital certificate, certificate cumulative value a

3278 VOLUME 12, 2024

Y. Chen et al.: New Identity Authentication and Key Agreement Protocol

Step 3: D2 sends the information EPKCAx (CertD1 ∥ a1 ||W )

to CA to request certificate verification.
Step 4 Upon receiving the digital certificate from the
device, the CAx first checks if the certificate is within its
validity period. Then it verifies whether the certificate is on
the local blockchain. If the hash of digital certificate value
h(CertD1 ) is on the blockchain, the authentication success
message is returned and sent to D2 . If not, the authentication
fails.
Step 5: The terminal device D2 sends a successful
authentic-cation message to D1 . The secure random number
rD2 is generated, and the S2 · P is calculated with the private
key S2 . Subsequently rD2 · P and S2 · P are encrypted and sent
to D1 , i.e., D2 sends EPKD1 (rD2 · P||S2 · P) to D1 .
Step 6: D1 decrypts to obtain the rD2 · P and S2 · P. The
terminal device D1 with successful authentication generates
the security random number rD1 and calculates the S1 · P with
the private key S1 . Then they are encrypted and sent to the
terminal device D2 , i.e., D1 sends EPKD2 (rD1 · P||S1 · P) to
D2 . Finally the terminal device D1 calculates the session key
K1 = h(rD1 · S2 · P ∥ rD2 · S1 · P ∥ S1 · S2 · P) for subsequent
secure communication with the terminal device D2 .
Step 7: Terminal device D2 decrypts to obtain the secure
random numbers rD1 ·P and S1 ·P, and it calculates the session
key K1 = h(rD1 · S2 · P ∥ rD2 · S1 · P ∥ S1 · S2 · P).
FIGURE 4. Identity authentication and key agreement in the same
domain.
C. AUTHENTICATION AND KEY AGREEMENT
IN CROSS-DOMAIN
and certificate witness W . The information obtained by Dx is The cross-domain authentication and key agreement process
used for subsequent identity authentication. in this section will add new information on the basis of
local digital certificates to generate cross-domain certificates.
B. AUTHENTICATION AND KEY AGREEMENT The cross-domain authentication process will re-issue cross-
IN THE SAME DOMAIN domain certificates as explained below. If the certificate
The terminal device D1 sends the local digital certificate, obtained on the local blockchain continues to be used in the
certificate cumulative value a and certificate witness W cross-domain authentication process, the following problems
to the terminal device D2 through public key encryption. will occur:
As the receiving terminal device D2 uses the private key to 1) It is impossible to distinguish the use scope of the
decrypt to obtain the digital certificate, certificate cumulative certificate across domains. For example, a terminal device
value a and certificate witness W , and then the terminal in domain X wants cross-domain access to both domain Y
device submits it to the CA for review to verify whether and domain Z . If the same certificate is used for cross-
the digital certificate is on the blockchain. If it is on the domain authentication, this will result in confusion about
blockchain, it indicates that the certificate verification is cross-domain resource access and failure to recognize the
passed. After authentication is completed, session key agree- terminal device’s cross-domain access rights across different
ment is performed between terminal devices. This is to ensure security domains.
subsequent secure communication and to improve the speed 2) Cross-domain authentication using certificates on the
of encryption and decryption. Take the identity authentication local blockchain can make cross-domain access less secure.
and key agreement of terminal device D1 and terminal device It makes it possible for terminal devices to access other
D2 in domain X as an example. Describe the process of same cross-domain resources at will as long as they have a local
domain authentication between terminal devices on the local blockchain domain certificate.
blockchain. The authentication process is shown in Fig. 4. Therefore, cross-domain certificates need to be re-issued
Step 1: The terminal device D1 in the same security domain when terminal devices are accessed across domains. so that
sends authentication request EPKD2 (CertD1 ||a||W ) to terminal subsequent terminal devices in different security domains
device D2 . have recognizable access rights.
Step 2: The terminal device D2 decrypts with the private The locally issued certificate is added to the signature of
key to obtain the certificate CertD1 and checks the validity of the cross-domain certificate authority CA.The cross-domain
the certificate. certificate is regenerated, the cross-domain certificate hash

VOLUME 12, 2024 3279

 Y. Chen et al.: New Identity Authentication and Key Agreement Protocol

Step 2: After receiving the cross-domain access request,

the edge server ESy generates a random number r1 and sends
it to the terminal device Dx .
Step 3: After receiving the random number r1 , the terminal
device Dx signs the random number with the private key,
and sends the digital certificate CertDx , certificate cumula-
tive a value and certificate witness W obtained on the local
blockchain to ESy .i.e., Dx sends EPKESy (CertDx ||a||Sig(r1 )||
r1 ||W ) to ESy .
Step 4: After receiving the message, the edge server ESy
decrypts with the private key to obtain the local blockchain
certificate CertDx , cumulative value a and certificate witness
W of the terminal device Dx . It also verifies the validity
of the signature and random number r1 . The edge server
ESy sends the digital certificate CertDx , certificate cumulative
a value and certificate witness W to the CAy to request
certificate verification, i.e., ESy sends EPKCAy (CertDx ||a||W )
to CAy .
Step 5: The CAy obtains the digital certificate, certificate
accumulation value a and certificate witness W of the terminal
device Dx . The CAx first checks if the certificate is within its
validity period. ThenCAy node in the public blockchain trig-
gers the dynamic accumulator to query whether the certificate
exists. If it exists, the verification passes and returns to ESy
for successful authentication; if it does not exist, it returns for
failed authentication.
Step 6: After receiving the successful authentication
FIGURE 5. Identity authentication and key agreement in cross-domain. message, the edge server ESy requests CAy to issue a
cross-domain certificate CertDxy for Dx .
Step 7: The CAy generates a cross-domain certifi-
cate CertDxy to the terminal device Dx .The hash of the
value is calculated, and the smart contract in the public cross-domain certificate is calculated and packaged on the
blockchain network is triggered to generate the cumulative local blockchain. This facilitates subsequent cross-domain
value and certificate witness for the certificate, so that the authentication. And the CAy sends the cross-domain certifi-
certificate can be verified for subsequent cross-domain access cate CertDxy to ESy .
by the terminal device. Step 8: The ESy sends the cross-domain certificate CertDxy
In the process of cross-domain authentication and key to Dx .
agreement, CAs play the role of a bridge. When end device A Step 9: Repeat the above steps to achieve the reverse
in domain X wants to access end device B in domain Y across authentication. Both Dx and Dy have obtained cross-domain
domains, CA in domain X cannot access the local blockchain certificates and completed two-way authentication.
in domain Y , and it queries whether the certificate is on the Step 10: The terminal devices Dx and Dy that complete
chain through the public blockchain. Different CAs in the two-way cross-domain authentication perform key agree-
local blockchain together form the public blockchain. ment. The Dx generates the security random number rx ,
Due to the existence of different security domains for IoT calculates Sx · P with the private key Sx , and sends rx · P and
devices. The terminal device Dx in domain X wants to access Sx ·P to Dy for key agreement, i.e., Dx sendsEPKDy (Sig(rx ·P) ∥
terminal device Dy in domain Y across domains need to rx · P ∥ Sx · P) toDy .
be authenticated. The session key is jointly negotiated for Step 11: The Dy decrypts with private key to obtain Sx ·
subsequent secure communication. Cross-domain authenti- P and rx · P, and verifies the random number rx · P.The Dy
cation and key agreement require certificate authority in the generates the secure random number ry , and uses the private
public blockchain network to act as a communication bridge. key Sy to calculate Sy · P. Dy sends ry · P and Sy · P to Dx , i.e.,
Take the example of terminal device Dx in domain X and Dy sends EPKDx (Sig(ry · P) ∥ ry · P ∥ Sy · P) to Dx . At this
terminal device Dy in domain Y .The process of cross-domain point Dy can calculate the session key K2 = h(Sy · Sx · P ∥
authentication and key agreement is shown in Fig. 5.The ry · Sx · P ∥ rx · Sy · P ∥ ry · rx · P)
specific steps are as follows: Step 12: The Dx decrypts with private key to obtain Sy · P
Step 1: The terminal device Dx requests cross-domain and ry · P, and calculates the session key K2 = h(Sy · Sx · P ∥
access to edge server ESy in domain Y . ry · Sx · P ∥ rx · Sy · P ∥ ry · rx · P).

3280 VOLUME 12, 2024

Y. Chen et al.: New Identity Authentication and Key Agreement Protocol

V. SECURITY ANALYSIS decrypting D2 private key. If there is an attacker, the attacker

In this section, we investigate the security of cross-domain cannot decrypt and obtain secure random number rD1 without
authentication and key agreement protocol and give the secu- the private key, ensuring the security of the session key.
rity analysis from informal security analysis, formal security
proof in the ROR model and formal security analysis with 3) FORWARD SECURITY
protocol analysis tools. Forward security [35] is the inability of an attacker to restore
a session key in the event that the private key used to gener-
A. INFORMAL SECURITY ANALYSIS ate the session key is compromised. That is, the previously
The informal security analysis describes the security of the communicated message remains inaccessible to the attacker.
scheme in terms of five aspects: certificate security, session During cross-domain authentication and key agreement, if the
key security, forward security, DDoS attacks and man-in-the- private key Sx and private key Sy are inadvertently com-
middle attacks. promised, the session key K2 cannot be restored due to the
time-sensitive and fresh nature of the secure random numbers
1) CERTIFICATE SECURITY rx and ry . In addition, the one-way hash function ensures that
the session key cannot be easily tampered with. The hash
The same domain and cross-domain authentication schemes
function is not invertible, making it impossible to derive the
designed in this paper both store the digital certificate hash on
original input to the hash function by obtaining the session
the blockchain, avoiding the drawback of relying entirely on
key hash.
the centralized CA trustworthiness. In addition, if the nodes
on the blockchain want to tamper with data, they will pay a
huge cost of computing power. To tamper with a certain block 4) DDOS ATTACK
data, they must tamper with the entire blockchain, which Distributed Denial of Service Attacks (DDoS Attacks) are
is not feasible in computing. Therefore, the anti-tampering designed to make the target unable to provide services prop-
feature of the blockchain ensures the security of certificates erly by sending a large number of requests to the target. The
stored on the blockchain. The hash value of certificate is goal of a DDoS attack is to overload the target system so
stored on the blockchain, which reduces the storage overhead that it is unable to process normal user requests. Blockchain
and effectively alleviates the problem of insufficient storage has distributed nature. In a blockchain network, each node
capacity of the blockchain. Hash functions are collision- holds complete information about the ledger. Even if less than
resistant, and the probability of a collision on the computation one-third of the total number of nodes in the network fail,
of any two certificate hashes is extremely low. The one-way the normal use of the ledger will not be affected. This means
nature of the hash function makes it impossible to deduce the that even if some of the nodes are not working, the server
original input certificate from the hash function. Therefore, will still be able to obtain authentication information from the
hash functions enable blockchain nodes to store certificates blockchain network and realize cross-domain authentication.
anonymously and securely. During same domain and cross- Once the attacked node is back to normal, it can obtain
domain authentication, the certificate is sent encrypted with complete ledger information from other nodes and become
the receiver’s public key, and the receiver decrypts it with a normal node with cross-domain authentication again.
the private key to obtain the authentication certificate. Under
the public key cryptosystem, the public key is public, but the 5) MAN-IN-THE-MIDDLE ATTACK
private key is confidential. The public key is calculated from A man-in-the-middle attack is when an attacker inserts him-
the private key and it is difficult to deduce the private key from self as a ‘‘middleman’’ between two parties to obtain sensitive
the known public key, so the authentication process ensures information or tamper with the content of the communication.
that the certificate is secure. Suppose the attacker intercepts the random number N sent by
the RA to the device, but the attacker cannot sign the random
2) SESSION KEY SECURITY number due to the lack of the device’s private key. Even if the
In the process of designing session keys in this article, same attacker tries to sign the random number with its own private
domain terminal devices D1 and D2 send secure random key, it needs to send its own certificate to the RA, which will
numbers rD1 and rD2 during the agreement of session keys. not be able to authenticate the attacker’s certificate via the
When a message with a secure random number is received, distributed ledger. The authentication will succeed only if the
the recipient of the message verifies that this timestamp is the device signs the random number with its own private key and
same as the timestamp sent or that it is a duplicate reception. sends the certificate information to the RA.
If the timestamp is repeatedly received, it can be determined
that this behavior is a replay attack, so the secure random B. FORMAL SECURITY ANALYSIS IN ROR MODEL
number can resist replay attacks. In this subsection, we give a formal security proof for the
The session key K1 = h(rD1 · S2 · P ∥ S1 · P · rD2 ∥ S1 · proposed protocol in the ROR model. The ROR model is a
S2 · P) has unforgeability. When terminal device D1 sends rD1 classical security model for proving the security of authenti-
encrypted with D2 public key to D2 , it can only be obtained by cation and key agreement protocols [37], [38].

VOLUME 12, 2024 3281

 Y. Chen et al.: New Identity Authentication and Key Agreement Protocol

In ROR model, the ith protocol instance of U is modeled

as an oracle iU . There is an adversary A who can control the
Q
communication channel and his/her purpose is to break the
authentication or gets the session key. There is a simulator
Q S
simulates the protocol and A interacts with the oracles iU to
gets the information he/she wants. As mentioned in [39],
the attacks of the adversary are simulated as the queries to
the oracles in the protocol in ROR models which Q are Exe- FIGURE 6. The authenticator in BCK.
cute(U1,U2), Send ( iU , m), Corrupt(U), Reveal ( iU ) and
Q

Test( iU ). We do not repeat the definitions here.

Q
Definition 1: Elliptic curve Diffie-Hellman problem Game G3 In this game, we use the authenticator proposed
(ECDH problem). Let G is an elliptic curve additive group in the BCK security model [39] to instead the authentication
over finite field Fp , and P is a generator of G and the order process of the proposed protocol in this paper. Actually, the
of P is q where q is a large prime. aP and bP are two random authentication process of the proposed protocol is similar to
point of G where a and b are unknown. There is no adversary that of the authenticator in BCK model. The authenticator in
A can compute abP in polynomial time. Let SucceedGECDH (A) BCK is as follows:
be the probability that A computes abP mentioned above, From Fig.6 we can see the authentication of the proposed
then we know for every probabilistic polynomial adversary protocol is the same as the authenticator in BCK in essence.
A, SucceedGECDH (A) is negligible. In every authentication process we use a random value and
Theorem 1: Let G is an elliptic curve additive group over the signature of the message which means the authentication
finite field Fp , and P is a generator of G. P is the protocol of the message is secure. If adversary A can break the authen-
proposed in this paper. For any probabilistic polynomial-time tication, then it means an algorithm can break the security of
A with less than qe times Execute query, less than qs times the authenticator in BCK by calling A as a subroutine. How-
Send query and less than qh times Hash query, then the ever, the security proof of the signature-based authenticator
probability that A break the semantic security of P is as was already given in [39]. So we have:
follows:
AdvPG (A) ≤Proof. The security proof of the protocol is Diff3 = Advauthenticator
G (A) ≤ SucceedGECDH (A)
completed by the games between adversary A and the simu-
lator S. S simulates the protocol and answers the queries from Game G4 In this game, we consider an adversary with
the adversary A. Let Gi denotes the ith game between A and strong ability which means he/she can corrupt one of par-
S, Succi denotes the event that A successfully distinguishes a ticipants, then he/she takes a Test query to the simulator S.
random value or the session key returned from the Test query. If the protocol can provide semantic security in this case, then
Let Diffi = Pr[Succi ] − Pr[Succi−1 ] denotes the probability the protocol can also provide semantic security in other cases
difference between ith event and i-1th event. since the adversary has weaker ability. In order to prove the
Game G0 This game simulates the real attack to the real conclusion we choose a random ECDH tuple < P, aP, bP >
protocol, so we have: to instead the public key of Dx and the random parameter
ry P chosen by Dy in the protocol. In such case, we need
AdvPG (A) = |2 Pr[Succ0 ] − 1| to prove the simulation of the protocol is correct after the
Game G1 This game is similar to G_0, the difference is that substitution. Since the public key of Dx is replaced by aPso
S runs the game in the random oracle model which means we do not know the parameter a of aP, then we cannot answer
we answer the Hash query with random value. From the the Reveal query. The reason is that we cannot compute the
definition of the random oracle model, we have: real session key without the parameter a. In this case, we first
check whether there is a record < Sy ·aP ∥ ry ·aP ∥ rx ·Sy ·P ∥
Diff1 = Pr[Succ1 ] − Pr[Succ0 ] = 0 ry · rx · P, hi >in the Hash list, if there is a record, we let hi be
the session key of this session and answer the Reveal query
Game G2 In this game, we exclude the collision between
with hi . Otherwise, we choose a random value h′i and put
different protocol instances, i.e., S or A chooses the same
< Sy · aP · P ∥ ry · aP ∥ rx · Sy · P ∥ ry · rx · P, h′i > in the Hash
random value in different protocol instance. Because if the
list and let h′i be the session key of this session and answer
collision on the protocol instances happens, then A can
the Reveal query with h′i . Now, the simulator S can simulate
successfully guess the answer from the Test query and dis-
the protocol correctly. In such case, if A can distinguish the
tinguish between the session key and the random value(A
difference between the session key of the test session and a
can choose one of the session asks a Reveal query and get
random value, then it means A must have ask a hash query
the session key). We also exclude the collision on the Hash
with < Sy · aP ∥ b · aP ∥ rx · Sy · P ∥ b · rx · P >, then the
functions, so according to the birthday paradox, we have:
simulator S can check the hash record and get the value a·bP.
(qe + qs )2 + q2h So it means the ECDH problem can be broken by using A as
Diff2 =
2p a subroutine. Suppose the probability that the test session that

3282 VOLUME 12, 2024

Y. Chen et al.: New Identity Authentication and Key Agreement Protocol

A chose is exactly the one that the we imbed the ECDH tuple
is 1/(qe + qs ) and the probability that the matching session
of these two session is also the same is 1/(qe + qs ), then we
have:

Diff4 = (qe + qs )2 qh · SucceedGECDH (A)

To sum up, we have:

AdvPG (A) = |2 Pr[Succ0 ] − 1|

= |2 Pr[Succ0 ] − 1 + 2 Pr[Succ4 ] − 2 Pr[Succ4 ]|
= |2 Pr[Succ4 ] − 1 + 2(Pr[Succ0 ] − Pr[Succ4 ])|
X4
≤ |2 Pr[Succ4 ] − 1| + 2 Diffi
i=1

In Game G4 , the protocol is already run in the random

oracle model, so Pr[Succ4 ] = 21 . Now we can conclude the
Theorem 1 as follows:
(qe + qs )2 + q2h
AdvPG (A) ≤ + 2(qe + qs )2 qh
p
· SucceedGECDH (A)

C. FORMAL SECURITY ANALYSIS WITH PROTOCOL

ANALYSIS TOOLS FIGURE 7. Same domain authentication and key agreement security
Scyther is an important tool for verifying protocol security. verification results.
The verification process uses an unlimited number of sessions
and random numbers to verify whether the protocol is secure.
Scyther tool provides graphical operation interface with good 2) CROSS-DOMAIN
human-computer interaction, and can graphically output pro- The Scyther tool analyses the process of cross-domain
tocol attacks. Scyther tool can add adversary models under authentication and key agreement protocols, specifically
strong security models such as long-term key disclosure, involving the four entities Dx , Dy , ESx , and ESy within
session key disclosure, random number disclosure, and state the different security domains. The simulation results show
disclosure by checking [36]. that the declared Secret, Alive, Weakagree, Niagree, and
This section uses the Scyther tool to experiment with secu- Nisynch attributes in Dx and Dy communication are not found
rity analysis of authentication and key agreement protocols in within the limits. The Secret, Alive, Weakagree, Niagree and
the same domain and cross-domain. Nisynch attributes declared by ESx and ESy are not found to
be attacked outside or inside the state space boundaries. The
1) SAME DOMAIN experimental results are shown in Fig. 10.
The scyther tool analyses the process of same domain authen-
tication and key agreement protocols, specifically involving VI. BLOCKCHAIN IMPLEMENTATION
the three entities DA , DB and CA within the same security A. PLATFORM INTRODUCTION
domain. The simulation results show that the declared secret, The FISCO BCOS platform is an open source blockchain
alive, weakagree, niagree, and nisynch attributes have not platform launched by the Financial Blockchain Platform
found attacks outside or inside the state space boundaries. The Consortium of China (FISCO) [40]. It realizes high-
experimental results are shown in Fig. 7. performance transaction processing capability, which can
Description of the same domain authentication protocol: support thousands to tens of thousands of transactions per
defines three entities DA , DB , and CA, and the specific process second. In terms of guaranteeing data security and reliabil-
is shown in Fig.8. ity FISCO BCOS adopts PBFT (Improved Byzantine Fault
Testing key agreement protocol security, as depicted in Tolerance) consensus algorithm, which ensures that more
Fig. 9. The subsequent cross-domain authentication and key than 2/3 of the nodes in the network are honest. It also
agreement protocol experiment process is similar to the secu- provides rich smart contract support and supports alliance
rity analysis experiment of the same domain authentication chain expansion.
and key agreement process. The specific code of the experi- WeCross is a cross-chain solution launched by Tencent’s
ment will not be discussed in detail. blockchain team, aiming to solve the problem of blockchain

VOLUME 12, 2024 3283

 Y. Chen et al.: New Identity Authentication and Key Agreement Protocol

FIGURE 9. Security experiment of key agreement protocol in the same

domain.

FIGURE 10. Cross-domain authentication and key agreement security

verification results.

data transfer between different blockchains. Meanwhile,

WeCross is built on a lightweight cross-chain gate-
way, which makes integration and usage simple and
efficient. It also supports many different blockchain
FIGURE 8. Security experiment of authentication protocol in the same platforms, including FISCO BCOS, Fabric, Ethereum,
domain.
and so on. Its cross-chain interaction protocols and
data formats are compatible with mainstream blockchain
cross-chain interconnection. It is a lightweight cross-chain platforms, facilitating integration with other blockchain
gateway and framework that enables interconnection and systems.

3284 VOLUME 12, 2024

Y. Chen et al.: New Identity Authentication and Key Agreement Protocol

FIGURE 11. Show environment configuration success and login success.

FIGURE 12. Successful contract deployment.

B. IMPLEMENTATION PLAN
In this paper, the platform used to build the blockchain
based on Ubuntu 22.04.1 version of the system is fiscob- 2) IMPORTING SMART CONTRACTS
cos version 2.0. Two blockchains are built on the platform, After successful configuration, you can directly enter the
group1 and group2, where group1 is the public blockchain wecross command console. Enter login to log in to the con-
and group2 is the local blockchain. The consensus algorithm sole for contract deployment operations. Firstly, place the
uses the PBFT algorithm that comes with the platform. written smart contract in the contract file of the console
At the same time, we use the wecross v1.3.0 cross-chain in the directory of/wecross-demo/WeCross-Console/conf/
platform to realize the deployment of smart contracts on contracts/policy.
the blockchain and the interaction between the blockchain
chains. 3) DEPLOYING CONTRACTS ON THE BLOCKCHAIN
Group1, as the public blockchain, is responsible for stor- In the console, first deploy the contract in blockchain 1, and
ing and querying the certificate hash values transmitted the contract deployment command is bcosDeploy. Firstly,
by all local blockchains. Group 2, as a local blockchain, deploy the SetDataInterchain contract, and upon successful
can store and query the hash value locally and upload the deployment, the address of the contract will be returned. Use
local hash value to the public blockchain. At the same the bcosRegister command to register the SetDataInterchain
time, it realizes the querying of other hash values on the contract as a cross chain resource. This way, we can perform
public blockchain through smart contracts (the blockchain cross chain operations through this contract. The contract
1 and blockchain 2 in the following are group1 and address that needs to be filled in when calling the bcosReg-
group2). ister command is the address obtained from the previous
deployment of the contract. If the result returns success,
C. DEPLOYMENT PROCESS it indicates successful registration. Continue deploying the
1) INSTALL AND CONFIGURE THE ENVIROMENT WeCrossHub contract. After the contract deployment is com-
Install wecross and configure the relevant runtime environ- pleted, you need to use the sendTransaction command to call
ment. In this article, we have configured javaJDK version the init function in the SetDataInterchain contract to associate
1.8.0_362, openssl version 3.0.2 and mysql version 8.0.33. the addresses of the WeCrossHub contract. Displaying Block-
You can also sudo apt-get install -y openssl curl expect tree Num indicates that the association was successful, enabling
fontconfig command to configure the environment. After the SetDataInterchain contract to call the cross-chain function
configuring the environment, download the demo from the in the WeCrossHub contract. Next, MDAC, VFS, and TC
wecross website. After the download is complete, run the contracts can be deployed in blockchain 1 using the same
command cd ∼/wecross-demo to enter the download direc- method. Deploy DAC, TCA, WeCrossHub, and SetDataIn-
tory of the demo, and execute bash clear.sh to clean up the old terchain contracts in blockchain 2, and the smart contracts on
installation environment. Run bash build_cross_groups.sh to both blockchains and blockchains are successfully deployed.
deploy the scripts. When all the script files are successfully Fig.12 shows a successful smart contract deployment on the
deployed, a 4-node blockchain with two groups will be built blockchain.
directly from the official configuration file. The consensus
mechanism between the nodes uses the officially config- D. INTRODUCTION TO SMART CONTRACT
ured PBFT (Practical Byzantine Fault Tolerance) consensus FUNCTIONALITIES
algorithm. Fig.11 shows successful environment configura- The relevant smart contracts deployed on the blockchain1
tion and successful login. are MDAC, VFS, TC, WeCrossHub and SetDataInterchain.

VOLUME 12, 2024 3285

 Y. Chen et al.: New Identity Authentication and Key Agreement Protocol

Among them, WeCrossHub and SetDataInterchain are con- by registerCertificateFromTC function and verifyCertificate
tracts shared by the public blockchain and local blockchains, function respectively. In registerCertificate-FromTC func-
which are responsible for cross-chain interactions between tion, it will directly receive the hash value from the TC
the public blockchain and local blockchains. contract as a parameter, and there will be a require to deposit
The SetDataInterchain contract is responsible for the inter- the hash value to determine whether the hash value is in the
action between the child chain and the public blockchain. chain. If the hash value already exists, there will be a corre-
There is a setDataInterchainInvoke function in the contract sponding message. If the hash value is stored successfully, the
which is responsible for inputting information. Five parame- hash value will be stored in the accumulator and added to the
ters need to be filled in, which are the name of the contract on chain. Use verifyCertificate function to query the hash value
the target chain, the name of the function on the contract, the can be directly in the accumulator to query the hash value.
parameters of the function, the contract on the chain where If the certificate exists then return ‘‘certificate in the chain’’,
the callback function is located, and the method name of the otherwise return ‘‘certificate is not in the chain’’. The MDAC
callback function. Then WeCrossHub is called to make the contract part of the code is shown in Algorithm 6.
cross-chain call.
The SetDataInterchain contract part of the code is shown
in Algorithm 5. This function is used to make interchain calls Algorithm 6 RegisterCertificateFromTC
on the blockchain and pass data and callback information. Input: publicKeyHash
Output: whether or not it is stored on the chain
// Get the hash value created by the set function in the
Algorithm 5 SetDataInterchainInvoke
TC
Input: path,method,data, callbackPath, contract
callbackMethod bytes32 publicKeyHash = tcContract.get();
Output: require (publicKeyHash!=bytes32(0), ‘‘No certificate
// This function is used to make cross-chain calls on hash
the found in TC contract’’);
blockchain and pass data and callback information. require(certificates[publicKeyHash].publicKeyHash==
string memory _path, bytes32(0), ‘‘Certificate already registered’’);
string memory _method, // The certificate hash is associated to the certificate
string memory _data, certificates[publicKeyHash]=Certificate(publicKeyHash);
string memory _callbackPath, addToAccumulator(publicKeyHash);
string memory _callbackMethod // Certificate Enrollment event is triggered
// Create a string array ‘args’ with one element to emit CertificateRegistered(publicKeyHash);
store the
parameter data passed to the target smart contract.
public returns (string memory) The relevant smart contracts deployed on the local
string[] memory args = new string[](1); blockchain are DAC, TCA, WeCrossHub and SetDataInter-
args[0] = _data; chain. The DAC contract is responsible for entering and
return hub.interchainInvoke( querying certificates on the local chain. The registerCertifi-
_path, cate function stores the name and hash value of the certificate
_method, into the accumulator. The accumulator is called with verifyC-
args, ertificate function to query the certificate. If the certificate
_callbackPath, exists, it returns ‘‘certificate is in the chain’’, otherwise it
_callbackMethod returns ‘‘certificate is not in the chain’’. The DAC contract
); part of the code is shown in Algorithm 7.

TC contract is responsible for receiving the hash value Algorithm 7 VerifyCertificate

from the SetDataInterchain contract on the local blockchain
Input: publicKeyHash
and storing the hash value for MDAC to call.VFS contract
Output: whether the certificate is on the chain
is responsible for receiving the hash value transmitted from
// Call the function to verify that the hash value of the
the SetDataInterchain contract on the local blockchain and
certificate is in the accumulator
storing the hash value for MDAC to call. And call the
bool exists = checkInAccumulator(publicKeyHash);
query function in the public blockchain through verifyC-
if exists then
ertificateFM function to query whether the hash value is
return certificate is in the chain
in the public blockchain and return the query result. The
else
MDAC contract is responsible for storing and querying the
return certificate is not in the chain
hash value uploaded by the child chain. They are executed

3286 VOLUME 12, 2024

Y. Chen et al.: New Identity Authentication and Key Agreement Protocol

TABLE 3. Algorithm running time.

FIGURE 13. Operation process flow diagram.

Step 7: Blockchain 2 (child chain) calls the get function of

The TAC contract is responsible for getting the results TCA contract summary to check the return result.
returned by the SetDataInterchain contract on the public
blockchain. The result information is queried through the get VII. PERFORMANCE ANALYSIS
function. This section focuses on the performance analysis of the
cross-domain authentication and key agreement protocol for
E. OPERATION PROCESS IoT devices in the previous section, including computing
Fig. 13 illustrates the specific operational process. overhead, communication overhead, experiment comparison
Step 1: Call registerCertificate function in the DAC con- and performance experiment. The desktop computer used in
tract in blockchain 2 (local blockchain) to input the certificate the experiment is configured with an Intel Core i5-10400
name and hash value and register it on the chain. [email protected] processor and 16GB of RAM, and the oper-
Step 2: Check if the certificate is in the chain by verifyCer- ating system is Windows 10 (64bit).
tificate function. If the certificate is in the chain, then return
‘‘certificate is in the chain’’. A. COMPUTING OVERHEAD
Step 3: Call the SetDataInterchain contract to pass the hash This section uses the following notation to indicate the name
value of the certificate stored in the local blockchain to the and running time of each algorithm, as shown in Table 3.
contract TC in the public blockchain. IoT devices use ECDSA (Elliptic Curve Digital Signature
Step 4: The contract TC in blockchain 1 (public Algorithm) signatures, which involve two point multiplica-
blockchain) receives the hash value and stores it, and queries tion operations on the elliptic curve. An average of 2.1ms
whether the hash value has been successfully imported is consumed for a single digital signature operation. This
through the get function in the TC. If the hash value is amount of computation is feasible for ordinary devices.
successfully imported, the encrypted information of the hash The authentication process requires 10 public key encryp-
value will be displayed. tion and decryption operations, which results in a relatively
Step 5: Call the registerCertificateFromTC function in the high computational cost [28]. In [21], the use of multi-
MDAC contract in the public blockchain to register the hash ple bilinear operations further increases the cost compared
value in the TC contract directly on the chain. Call verifyC- to what is presented in this paper. The method of certifi-
ertificate function in MDAC contract of public blockchain to cate verification is carried out by comparing the certificate
check whether the certificate is stored successfully. If suc- hash submitted by the cross-domain user with the certifi-
cessful, it will return ‘‘certificate in chain’’, then the hash cate hash stored on the blockchain. This approach increases
value of the certificate in the local blockchain will be stored the query time when searching on the blockchain, as it
in the public blockchain. necessitates traversing the entire blockchain. In this paper,
Step 6: Blockchain 2 (local blockchain) to blockchain 1 however, we employ a dynamic accumulator in the authenti-
(public blockchain) to launch the hash value query. The Set- cation process to reduce the certificate query time complexity.
DataInterchain cross-chain contract calls the VFS contract While [27] designed a master-slave blockchain architecture,
on blockchain 1 (the public blockchain) to query the hash the computational cost was higher than the cross-domain
value of the certificate stored on the public blockchain. The authentication scheme proposed in this paper. Table 4 illus-
VFS contract calls the verifyCertificateFM function to per- trates the comparative analysis of the computational costs.
form a query on the hash value on blockchain 1 (the public Fig. 14 and Table 4 show the comparison of calculation costs.
blockchain). If the hash value is in blockchain 1 (public Therefore, this scheme has good computational overhead.
blockchain), the return result is passed back through Set- The authentication process information is sent encrypted with
DataInterchain in blockchain 1 (public blockchain) to the the other party’s public key, reducing the chance of malicious
TCA contract in blockchain 2 (child chain). attackers gaining access to identity information. During the

VOLUME 12, 2024 3287

 Y. Chen et al.: New Identity Authentication and Key Agreement Protocol

TABLE 4. Computing overhead comparison.

FIGURE 15. Comparison of bandwidth overhead.

FIGURE 14. Comparison of computing overhead.

TABLE 5. Parameter lengths.

FIGURE 16. Time of cross-domain authentication.

TABLE 6. Comparison of bandwidth consumption.

The test program sent cross-domain authentication requests

in 1s, 10s, 20s and 30s. VMs were configured with two
CPUs, four CPUs, six CPUs and eight CPUs to invoke
to achieve cross-domain authentication. In the experimental
tests, the single authentication time is shown in Fig. 16. The
experimental results show that the single authentication time
is about 18 to 23ms and our cross-domain authentication
authentication process, this scheme improves the query effi- scheme has good stability and high efficiency.
ciency of the certificate through dynamic accumulator. The traditional way of querying data on a blockchain
requires traversing the entire blockchain. As the blockchain
B. COMMUNICATION OVERHEAD grows in size, querying becomes inefficient. In this paper,
In order to better analyze our cross-domain authentication by constructing a dynamic accumulator, the way of traversing
and key agreement protocols, we have listed the bit sizes the data in the blockchain is replaced by proving that the
of different parameters in Table 5. In Table 6 and Fig.15, members are in the accumulator. This enables the time com-
we compared the communication costs of our protocol with plexity of the query to be reduced from O(n) to O(1), reducing
other cross-domain authentication protocols, and it can be query time consumption and improving the efficiency of
seen that our protocol is more efficient than other protocols. cross-domain authentication. As the number of members in
the accumulator increases, the time complexity of adding
C. PERFORMANCE EXPERIMENT or removing members from the dynamic accumulator does
In this section, simulation experiments are conducted to test not increase. It is efficient at adding and removing mem-
the concurrent performance of cross-domain authentication. bers. Although dynamic accumulators are time consuming

3288 VOLUME 12, 2024

Y. Chen et al.: New Identity Authentication and Key Agreement Protocol

node servers in different domains and maintain the trust rela-

tionship between CAs in different domains. The hash value
of the digital certificate is stored in the public blockchain.
It improves the reliability of certificates and reduces the
storage pressure on the public blockchain. The authentication
process is combined with dynamic cryptographic accumu-
lator technology. It solves the problem of low efficiency of
data query on the chain due to the increase of blockchain
volume and improves the efficiency of certificate verifica-
tion of the authentication process. When terminal devices
belonging to different security domains need authentication
communication, the public blockchain network is used as
a communication bridge to ensure the secure sharing of
information across domains. The architecture can effectively
FIGURE 17. Average certificate query time. utilize the computing power of different infrastructures and
enhance the scalability of the system. It can also effectively
relieve the pressure of individual blockchain storage and
to create, the process is a one-off and can be done in the reduce the burden of blockchain queries.
background. But multi-layer blockchain architectures also have limita-
In this paper, the dynamic accumulator uses the strong tions. It does not have a consensus mechanism suitable for
RSA assumption in cryptography to ensure the security of this architecture. Consensus mechanisms are algorithms for
the dynamic accumulator scheme. It is a positive integer reaching distributed consensus on blockchain transactions.
with a length of 1024, which is the product of the sum This architecture is composed of local blockchain and public
generated by two Fermat primality detection algorithms. blockchain. There are respective consensus mechanisms in
First, 3000 blockchain cross-domain certificates are created the blockchain and there is no overall consensus mechanism
in batch as a test data set. It needs to repeat the experiment implemented for the multilayer blockchain architecture yet.
and average the data for five times, which can reduce errors
and avoid contingency. Fig. 17 shows the average time spent
VIII. CONCLUSION
querying 50,100,150,200 certificates.
In the edge computing environment, this scheme proposes
The average query time of [19] grows linearly with the
a cross-domain authentication and key agreement protocol
number of certificates as shown in the Fig. 17. The time
based on a multi-layer blockchain. Cross-domain authen-
consumption of this paper does not fluctuate much with the
tication of IoT devices with different security domains is
number of certificates, so it is suitable for edge comput-
achieved. A multi-layer blockchain architecture is designed,
ing environments with a large number of terminal devices.
consisting of a local blockchain and a public blockchain.
Although the query speed of this paper lags behind that
Dynamic accumulator is introduced to solve the problem
of [29], there is a 3% probability of misjudgment in [29]. If it
of inefficient certificate lookups. Next we conducted perfor-
determines that a certificate exists, it may not actually exist,
mance and security analysis, and the results showed that the
leading to privacy leaks and security issues.
protocol is well feasible and efficient, and more adaptable
with low performance devices. Further in-depth research on
D. SYSTEM ARCHITECTURE ANALYSIS
the underlying blockchain technology is needed in the future
Multi-layer blockchain provides distributed authentication to make blockchain technology an important tool for identity
with the help of blockchain technology. Different security authentication and key agreement.
domains correspond to a local blockchain to establish a local
collaborative trust network. The data processed by a single
device is distributed to multiple edge servers for collabora- REFERENCES
tive processing, which ensures the consistency and security [1] The Mobile Economy 2020, GSMA Assoc., London, U.K., 2019. [Online].
of decentralized IoT systems. The multi-tier blockchain is Available: https://www.gsma.com/
[2] A. Islam and S. Y. Shin, ‘‘A digital twin-based drone-assisted secure data
composed of a public blockchain and a local blockchain. aggregation scheme with federated learning in artificial intelligence of
Both public or local blockchains are based on federated things,’’ IEEE Netw., vol. 37, no. 2, pp. 278–285, Mar. 2023.
chain composition. External nodes can join only after getting [3] P. Mall, R. Amin, A. K. Das, M. T. Leung, and K. R. Choo, ‘‘PUF-based
authentication and key agreement protocols for IoT, WSNs, and smart
approval from the audit to improve the security of the system grids: A comprehensive survey,’’ IEEE Internet Things J., vol. 9, no. 11,
architecture. pp. 8205–8228, Jun. 2022.
In the local blockchain, it supports the authentication of [4] P. Kumar, R. Kumar, G. Srivastava, G. P. Gupta, R. Tripathi,
terminal devices in the same domain, manages each node T. R. Gadekallu, and N. N. Xiong, ‘‘PPSF: A privacy-preserving and
secure framework using blockchain-based machine-learning for IoT-driven
in the IoT, and secures the data in the domain. In the pub- smart cities,’’ IEEE Trans. Netw. Sci. Eng., vol. 8, no. 3, pp. 2326–2341,
lic blockchain, establish communication channels for edge Jul. 2021.

VOLUME 12, 2024 3289

 Y. Chen et al.: New Identity Authentication and Key Agreement Protocol

[5] Y. Lu, X. Huang, K. Zhang, S. Maharjan, and Y. Zhang, ‘‘Blockchain [26] X. Jia, N. Hu, S. Su, S. Yin, Y. Zhao, X. Cheng, and C. Zhang, ‘‘IRBA:
empowered asynchronous federated learning for secure data sharing An identity-based cross-domain authentication scheme for the Internet of
in Internet of Vehicles,’’ IEEE Trans. Veh. Technol., vol. 69, no. 4, Things,’’ Electronics, vol. 9, no. 4, p. 634, Apr. 2020.
pp. 4298–4311, Apr. 2020. [27] S. Guo, F. Wang, N. Zhang, F. Qi, and X. Qiu, ‘‘Master-slave chain based
[6] X. Xiang, M. Wang, and W. Fan, ‘‘A permissioned blockchain-based iden- trusted cross-domain authentication mechanism in IoT,’’ J. Netw. Comput.
tity management and user authentication scheme for E-health systems,’’ Appl., vol. 172, Dec. 2020, Art. no. 102812.
IEEE Access, vol. 8, pp. 171771–171783, 2020. [28] G. Cheng, Y. Chen, S. Deng, H. Gao, and J. Yin, ‘‘A blockchain-
[7] S. He, Z. Li, J. Wang, and N. N. Xiong, ‘‘Intelligent detection for key based mutual authentication scheme for collaborative edge comput-
performance indicators in industrial-based cyber-physical systems,’’ IEEE ing,’’ IEEE Trans. Computat. Social Syst., vol. 9, no. 1, pp. 146–158,
Trans. Ind. Informat., vol. 17, no. 8, pp. 5799–5809, Aug. 2021. Feb. 2022.
[8] W. Shi, J. Cao, Q. Zhang, Y. Li, and L. Xu, ‘‘Edge computing: Vision and [29] S. Showkat Moni and D. Manivannan, ‘‘A lightweight privacy-preserving
challenges,’’ IEEE Internet Things J., vol. 3, no. 5, pp. 637–646, Oct. 2016. V2I mutual authentication scheme using cuckoo filter in VANETs,’’ in
[9] J. B. Xue and Z. M. Bai, ‘‘Security and efficient authentication scheme Proc. IEEE 19th Annu. Consum. Commun. Netw. Conf. (CCNC), Las
for mobile edge computing,’’ J. Beijing Univ. Posts Telecommun., vol. 44, Vegas, NV, USA, Jan. 2022, pp. 815–820.
no. 1, pp. 110–116, Jan. 2021. [30] J. Qi, ‘‘Research on the application of accumulator in blockchain,’’
[10] O. Salman, S. Abdallah, I. H. Elhajj, A. Chehab, and A. Kayssi, M.S. thesis, Nanjing Univ. Inf. Eng., Nanjing, China, 2020.
‘‘Identity-based authentication scheme for the Internet of Things,’’ in [31] M. X. Miao, P. R. Wu, and Y. L. Wang, ‘‘Research progress and application
Proc. IEEE Symp. Comput. Commun. (ISCC), Messina, Italy, Jun. 2016, of password accumulator,’’ J. Xidian Univ., vol. 49, no. 1, pp. 79–91,
pp. 1109–1111. Sep. 2022.
[11] K. Xue, P. He, X. Zhang, Q. Xia, D. S. L. Wei, H. Yue, and F. Wu, [32] J. Lin, W. Yu, N. Zhang, X. Yang, H. Zhang, and W. Zhao, ‘‘A sur-
‘‘A secure, efficient, and accountable edge-based access control framework vey on Internet of Things: Architecture, enabling technologies, security
for information centric networks,’’ IEEE/ACM Trans. Netw., vol. 27, no. 3, and privacy, and applications,’’ IEEE Internet Things J., vol. 4, no. 5,
pp. 1220–1233, Jun. 2019. pp. 1125–1142, Oct. 2017.
[12] P. Black and R. Layton, ‘‘Be careful who you trust: Issues with the public [33] V. Hassija, V. Chamola, V. Saxena, D. Jain, P. Goyal, and B. Sik-
key infrastructure,’’ in Proc. 5th Cybercrime Trustworthy Comput. Conf., dar, ‘‘A survey on IoT security: Application areas, security threats,
Auckland, New Zealand, Nov. 2014, pp. 12–21. and solution architectures,’’ IEEE Access, vol. 7, pp. 82721–82743,
[13] J. Ni, K. Zhang, X. Lin, and X. Shen, ‘‘Securing fog computing for Internet 2019.
of Things applications: Challenges and solutions,’’ IEEE Commun. Surveys [34] Z. Liao, X. Pang, J. Zhang, B. Xiong, and J. Wang, ‘‘Blockchain on
Tuts., vol. 20, no. 1, pp. 601–628, 1st Quart., 2018. security and forensics management in edge computing for IoT: A com-
[14] T. Salman, M. Zolanvari, A. Erbad, R. Jain, and M. Samaka, ‘‘Security prehensive survey,’’ IEEE Trans. Netw. Service Manage., vol. 19, no. 2,
services using blockchains: A state of the art survey,’’ IEEE Commun. pp. 1159–1175, Jun. 2022.
Surveys Tuts., vol. 21, no. 1, pp. 858–880, 1st Quart., 2019. [35] H. K. Jiang et al., ‘‘Improved certificateless proxy blind signature scheme
[15] B. Cao, Y. Li, L. Zhang, L. Zhang, S. Mumtaz, Z. Zhou, and M. Peng, with forward security,’’ Comput. Sci., vol. 48, no. 6A, pp. 529–532,
‘‘When Internet of Things meets blockchain: Challenges in distributed Jun. 2021.
consensus,’’ IEEE Netw., vol. 33, no. 6, pp. 133–139, Nov. 2019. [36] N. Kahya, N. Ghoualmi, and P. Lafourcade, ‘‘Formal analysis of PKM
[16] S. Matsumoto and R. M. Reischuk, ‘‘IKP: Turning a PKI around with using scyther tool,’’ in Proc. Int. Conf. Inf. Technol. e-Services, Sousse,
decentralized automated incentives,’’ in Proc. IEEE Symp. Secur. Privacy Tunisia, Mar. 2012, pp. 1–6.
(SP), San Jose, CA, USA, May 2017, pp. 410–426. [37] G. Thakur, P. Kumar, Deepika, S. Jangirala, A. K. Das, and Y. Park,
[17] A. Garba, Q. Hu, Z. Chen, and M. R. Asghar, ‘‘BB-PKI: Blockchain-based ‘‘An effective privacy-preserving blockchain-assisted security proto-
public key infrastructure certificate management,’’ in Proc. IEEE 22nd Int. col for cloud-based digital twin environment,’’ IEEE Access, vol. 11,
Conf. High Perform. Comput. Commun.; IEEE 18th Int. Conf. Smart City; pp. 26877–26892, 2023.
IEEE 6th Int. Conf. Data Sci. Syst. (HPCC/SmartCity/DSS), Yanuca Island, [38] J. Ryu, S. Son, J. Lee, Y. Park, and Y. Park, ‘‘Design of secure mutual
Fiji, Dec. 2020, pp. 824–829. authentication scheme for metaverse environments using blockchain,’’
[18] A. Garba, Z. Chen, Z. Guan, and G. Srivastava, ‘‘LightLedger: A novel IEEE Access, vol. 10, pp. 98944–98958, 2022.
blockchain-based domain certificate authentication and validation [39] M. Bellare, R. Canetti and H. Krawczyk, ‘‘A modular approach to the
scheme,’’ IEEE Trans. Netw. Sci. Eng., vol. 8, no. 2, pp. 1698–1710, design and analysis of authentication and key-exchange protocols,’’ in
Apr. 2021. Proc. 30th Annu. ACM Symp. Theory Comput. (STOC), May 1998,
[19] P. Gu and L. Chen, ‘‘An efficient blockchain-based cross-domain authen- pp. 419–428.
tication and secure certificate revocation scheme,’’ in Proc. IEEE 6th [40] FISCO-BCOS. Accessed: Oct. 2020. [Online]. Available: http://wwwfisco-
Int. Conf. Comput. Commun. (ICCC), Chengdu, China, Dec. 2020, bcos.org
pp. 1776–1782.
[20] W. Wang, N. Hu, and X. Liu, ‘‘BlockCAM: A blockchain-based cross-
domain authentication model,’’ in Proc. IEEE 3rd Int. Conf. Data Sci.
Cyberspace (DSC), Guangzhou, China, Jun. 2018, pp. 896–901.
[21] C. Yuan, W. Zhang, and X. Wang, ‘‘EIMAKP: Heterogeneous cross-
domain authenticated key agreement protocols in the EIM system,’’
Arabian J. Sci. Eng., vol. 42, no. 8, pp. 3275–3287, Aug. 2017.
[22] D. He, S. Chan, and M. Guizani, ‘‘An accountable, privacy-preserving, and
efficient authentication framework for wireless access networks,’’ IEEE
Trans. Veh. Technol., vol. 65, no. 3, pp. 1605–1614, Mar. 2016.
[23] D. He, J. Bu, S. Chan, C. Chen, and M. Yin, ‘‘Privacy-preserving universal YAO CHEN received the B.S. degree from the
authentication protocol for wireless communications,’’ IEEE Trans. Wire- School of Electronic and Information Engineering,
less Commun., vol. 10, no. 2, pp. 431–436, Feb. 2011. Weifang Institute of Technology, in 2015. She is
[24] L. Wang, Y. Tian, and D. Zhang, ‘‘Toward cross-domain dynamic accu- currently pursuing the M.S. degree with the School
mulator authentication based on blockchain in Internet of Things,’’ IEEE of Mathematics and Computer Science, Dali Uni-
Trans. Ind. Informat., vol. 18, no. 4, pp. 2858–2867, Apr. 2022. versity. Her research interests include blockchain
[25] M. Wang, L. Rui, Y. Yang, Z. Gao, and X. Chen, ‘‘A blockchain- technology and the IoT security.
based multi-CA cross-domain authentication scheme in decentralized
autonomous network,’’ IEEE Trans. Netw. Service Manage., vol. 19, no. 3,
pp. 2664–2676, Sep. 2022.

3290 VOLUME 12, 2024

Y. Chen et al.: New Identity Authentication and Key Agreement Protocol

QINGQING YANG received the M.S. degree from DENGQI YANG received the B.S. and M.S.
the School of Mathematics and Computer Science, degrees in computational mathematics from Yun-
Dali University, in 2022. Her research interests nan University, Kunming, China, in 2003 and
include blockchain security and cloud computing 2006, respectively, and the Ph.D. degree in com-
security. puter science from Sichuan University, Chengdu,
China, in 2012. He is currently a Professor of
computer science with the College of Math-
ematics and Computer, Dali University, Dali,
China. His main research interests include digital
signatures, identity authentication, and artificial
intelligence.

XIN ZENG received the M.S. degree from the XIAOWEI LI received the B.S. degree in math-
School of Information Science, Yunnan Univer- ematics and applied mathematics and the Ph.D.
sity, in 2013. He is currently a Lecturer with degree in information security from Xidian Uni-
the School of Mathematics and Computer Sci- versity, China, in 2008 and 2013, respectively.
ence, Dali University. His main research interests He is currently an Associate Professor with
include spatial juxtaposition, pattern mining, and the School of Mathematics and Computer Sci-
association rule mining. ence, Dali University. His main research interests
include cybersecurity protocols, cloud computing
security, and blockchain technology.

VOLUME 12, 2024 3291