Journal of Parallel and Distributed Computing 143 (2020) 1–16

Contents lists available at ScienceDirect

J. Parallel Distrib. Comput.

journal homepage: www.elsevier.com/locate/jpdc

BTNC: A blockchain based trusted network connection protocol in IoT

∗ ∗
Junwei Zhang a , Zhuzhu Wang a , , Lei Shang a , , Di Lu b , Jianfeng Ma a
a
School of Cyber Engineering, Xidian University, Xi’an 710071, China
b
School of Computer Science and Technology, Xidian University, Xi’an 710071, China

article info a b s t r a c t

Article history: Along with the rapid growth of the size and complexity of Internet of Things (IoT), the security of
Received 1 December 2019 terminal devices has increasingly become a focus. In order to ensure the security of terminals, the
Received in revised form 7 April 2020 trusted network connect (TNC) could realize not only the user authentication but also the platform
Accepted 14 April 2020
attestation during the network access process. However, the existing TNC infrastructure is based on
Available online 21 April 2020
a centralized architecture, which is not suitable for distributed services. To address this problem, we
Keywords: present a blockchain-based TNC protocol named BTNC to ensure the reliability of terminals in IoT.
Blockchain Due to the decentralization, trustlessness, trackability, and immutability features of blockchain, BTNC
IoT is able to verify the security of terminal devices in IoT networks. First, we come up with some threats,
Key exchange including unauthorized user, illegal platform and platform replacement attack, then correspondingly
Platform measurement define the security goals of our scheme. Second, combining key exchange protocol based on blockchain
Trusted network connection and D–H PN protocol included in TNC specification, we propose a blockchain-based trusted network
connection protocol, which realizes mutual user authentication, platform attestation and trust network
access by cryptography among terminals in IoT. Third, we make a security analysis in the PCL mode
and conclude that our protocol can resist the attacks above. Finally, the performance overheads caused
by our scheme are evaluated and the experiments show that it is efficient and feasible for different
kinds of terminals in IoT.
© 2020 Elsevier Inc. All rights reserved.

1. Introduction due to its decentralization. Meanwhile, some existing manage-

ment schemes [19,25] based on centralization mode are not able
With the rapid development of the Internet of Things (IoT) to provide distributed architecture to realize verification among
technology [6], we have witnessed the wide adoption of IoT terminals without trusted third parties.
applications across varieties of industry sectors, including home To address these problems, the emerging blockchain tech-
automation, transportation, medicine and manufacturing [4,39]. nology can serve as a promising candidate to provide verifiable
However, some security issues of IoT are still unsolved and some services [14,35]. Blockchain is an intelligent peer-to-peer net-
typical attacks still threaten applications in IoT [13]. There has work [38] that uses distributed ledger to identify, disseminate
been an increasing awareness of the necessary to insure the and record information, which is based on cryptography princi-
ples to implement distributed data storage. Because of its decen-
security of terminal devices in the large-scale distributed deploy-
tralization, trustlessness, traceability, and immutability features,
ment [18]. In other words, in order to guarantee the security of
blockchain has the potential to achieve the management and ver-
the IoT environment, not only the users of the device but also the
ification among terminals without centralized architecture [45].
integrity of the platform is required to be verified.
Nowadays, there have been several ways [22,37,43] to im-
Nowadays, TCG (Trusted Computing Group) [20,34] has ex-
plement terminals access control based on blockchain. However,
tended its efforts in trusted computing to the development and
scheme ChainAnchor [22] essentially adopts the centralized man-
promotion of the TNC specification [40,41]. Therefore we adopt agement model, i.e. its security needs to rely on trust authority.
TNC architecture to verify the legitimacy of the users’ identities Scheme RSU [43] just guarantees the security of the devices
and the integrity of devices in IoT system. However, tradition TNC through the pattern of trust management, i.e. it evaluates the
architecture based on client/server(C/S) structure is centralized security of a device by assessing its trust threshold. Scheme TM-
to manage terminals, which is not adaptable to the IoT system coin [37] realizes the verification process of terminals based on
trusted computing theory without TNC framework, i.e it utilizes
∗ Corresponding authors. remote attestation mechanism to verify the integrity of devices.
E-mail addresses: [email protected] (Z. Wang), In conclusion, the related schemes have following drawbacks:
[email protected] (L. Shang). (1) some schemes [22,44] could not provide a distributed network

https://doi.org/10.1016/j.jpdc.2020.04.004
0743-7315/© 2020 Elsevier Inc. All rights reserved.
2 J. Zhang, Z. Wang, L. Shang et al. / Journal of Parallel and Distributed Computing 143 (2020) 1–16

access control architecture without trust authority; (2) some 2. Related work
schemes [5,43] do not attest the integrity of the device platform;
(3) the others [1,37] do not realize the trusted network connect In 2003, the emergence of TCG marked the further maturity
among terminals in the distributed environment. of trusted computing technology along with a series of technical
Therefore, we are supposed to consider following challenges:
specifications including TNC framework [40,41]. Under the guid-
(1) Realize distributed integrity measurement storage and
ance of these specifications, many network enterprises utilized
platform attestation.
TNC architecture to support and manage their products, which
Due to the decentralized characteristic of blockchain, it is
difficulty to verify the integrity of the terminals without a trusted had been applied in practice. Cisco NAC utilized TNC infrastruc-
party. We should design a blockchain based protocol to realize ture to perform security policy and check whether the illegal
integrity measurement storage and platform attestation without terminal device attempted to access network so as to prevent
trust authority. adversaries such as viruses, worms and spyware [23]. Microsoft
(2) Achieve user authentication and key agreement protocol NAP leveraged the client application named Quarantine Agent
based on blockchain. to transmit system information to Network Policy Server which
Because the key exchange process in D–H PN protocol of TNC cooperated with trusted third party to ensure that all equip-
is based on C/S mode, we are supposed to extend and modify the ment can be verified before accessing the network [2]. At the
key agreement protocol based on blockchain so as to achieve user same time, some protocols based on TNC framework were also
authentication among users in IoT environment. proposed gradually. Zhang et al. [44] made a comprehensive
(3) Design a secure blockchain-based trusted network connect and reasonable analysis on TNC and proposed a new protocol
protocol to resist platform replacement attack. Twin-DH to resist platform replacement attack and realize trust
Because the TNC framework cannot resist the platform re- network connection. However, the system architecture proposed
placement attack, we are supposed to design a secure blockchain-
above are all based on C/S structure, which is not suitable for
based trusted network connect protocol. Not only does it realize
decentralized and distributed environments.
user authentication and platform attestation among terminals
in the distributed environment, but also it can resist platform From the perspective of the distributed environment,
replacement attack based on security analysis. M. Dorodchi et al. [9] proposed a scheme to manage devices
Facing these challenges above, the research on the implemen- in IoT system securely by combining a trust policy and a trust
tation of point-to-point mutual verification between terminals framework. F. Bao et al. [5] analyzed whether the equipment
based on blockchain appears to be particularly important. in IoT system was credible by utilizing the technical approach
Our contributions. In this study, we propose a blockchain- of trust management to guarantee the security of the whole
based scheme BTNC, which combines the blockchain technology system. Gao et al. [19] came up with a secure logistics infor-
and TNC framework. Not only does this scheme suit decentralized mation scheme to provide privacy protection of both personal
network, but also it realizes user authentication and platform information and logistics information in IoT environment. Rwan
attestation among terminal devices in IoT environment. We put et al. [32] described the challenges and solutions of current IoT
forward some threats caused by TNC in the distributed envi- security. Ma et al. [31] propose a privacy-preserving mechanism
ronment without trusted third party and propose a PCL-secure with differential privacy for vehicle networks. Gai et al. propose a
scheme based on blockchain, which ensures terminal devices to tensor-based fully homomorphic encryption [12] and establish a
access network credibly. Then we analyze the security of the
dynamic privacy protection model [10] for IoT. At the same time,
proposed protocol in PCL mode and evaluate the performance of
some biometric security solutions are also proposed based on fea-
scheme through simulations.
Our contributions in this paper are threefold. ture recognition [27]. Ma et al. investigate voice recognition [28],
face recognition [29] and eye-movement recognition [30] which
1. Decentralized integrity measurement. can be used to realize biometric authentication. However, the
We propose a novel blockchain-based network connection researches direction mentioned above do not involve trusted
scheme in the distributed environment. The platform mea- computing, which lacks the evaluation of platform integrity of
surements could be stored and included in the blockchain terminal devices in IoT environment.
in a decentralized mode and the verifiers are able to ob- As for blockchain system, S. Nakamoto [35] proposed Bitcoin
tain these information by querying and downloading the as a cryptocurrency and worldwide payment system in 2008.
blockchain so as to realize the platform attestation.
After Bitcoin, lots of systems [36] based on blockchain had being
2. Authenticated key exchange based on blockchain.
increasingly developed and widely used to realize secure man-
Our scheme combines Diffie–Hellman over bitcoin with
agement in IoT [15,17]. Ji et al. [24] investigated the location shar-
TNC framework, which conducts key agreement protocol
based on blockchain among users so as to achieve the user ing based on blockchains, which realized privacy-preserving loca-
authentication in the distributed environment. tion sharing for telecare medical information systems. Gai et al.
3. Security in protocol composition logic. propose a conceptual model for fusing blockchains and cloud
We theoretically analyze the security of our scheme by computing [11], and propose a model permissioned blockchain
protocol composition logic (PCL) method and further prove edge model for smart grid network satisfying privacy protections
that BTNC could resist platform replacement attack. and energy security [16]. Siamak et al. [33] proposed an authen-
ticated key exchange (AKE) protocol over Bitcoin, which realized
Organization. The remainder of this paper is organized as fol-
end-to-end secure communication among Bitcoin users in a post-
lows: Section 2 presents the related work of our protocol while
transaction scenario without requiring any trusted third party.
Section 3 presents some preliminary backgrounds, including
trusted network connect, blockchain, Diffie–Hellman over Bit- However, these papers do not deal with trusted computing and
coin and platform replacement attack. Section 4 presents system therefore the platform of terminal devices in distributed environ-
model, threat models and design goals. Section 5 presents the ment cannot be verified. Jaemin et al. [37] combined blockchain
detailed description of the proposed scheme. In Section 6, we and trusted computing in a distributed system to achieve remote
make a security analysis of our scheme and the performance attestation. However, the assumptions of the protocol are un-
analysis of the proposed scheme is presented in Section 7. At last, reasonable and they do not consider the verification of terminal
we conclude this paper in Section 8. devices in distributed systems from the perspective of TNC.
 J. Zhang, Z. Wang, L. Shang et al. / Journal of Parallel and Distributed Computing 143 (2020) 1–16 3

3. Preliminaries 3.3. Diffie–Hellman over Bitcoin

3.1. Trusted network connect Due to the utilization of blockchain to achieve desirable de-
centralization, we need to extend the content of D–H PN protocol
TNC architecture. The architecture consists of three entities: of TNC specification based on distributed environment. In order
the access requester (AR), the policy enforcement point (PEP) to guarantee the privacy and integrity of key exchange process,
and the policy decision point (PDP). Briefly, AR collects the in- we include the Diffie–Hellman over Bitcoin (DHOB) scheme, pro-
formation of platform and sends the message to PDP in order posed by Siamak F. Shahandashti into our protocol [33], which
to apply for connection. When receiving AR’s access request, combines the blockchain and key agreement protocol based on el-
PDP compares the AR’s credentials based on local security policy liptic curve digital signature algorithm (ECDSA) and elliptic curve
and makes a decision whether the access request should be Diffie–Hellman (ECDH) [23,26], aiming to achieve transaction-
granted. PEP controls access to protect network and performs the level authentication by taking advantage of a secret that only
decisions made by PDP. exists due to the creation of transactions that are stored in the
AR consists of three modules: network access requestor (NAR), blockchain. This kind of key agreement protocol establishes a
TNC client (TNCC) and integrity measurement collector (IMC) secure end-to-end communication channel between users, which
while PDP consists of network access authority (NAA), trusted takes advantage of leveraging the transaction-specific secrets in
network connection server (TNCS) and integrity measurement the confirmed transactions published in the blockchain. The do-
verifier (IMV). main parameters of the DHOB can be found in [36].
Moreover, there are multiple interfaces in this architecture,
including IF-T, IF-TNCCS, IF-IMC, IF-IMV, IF-M and so on. Among 3.4. Platform replacement attack
them, IF-T maintains the transportation of messages between
NAR and NAA. IF-TNCCS relates to interaction between the TNCC In TNC’s specification, D–H PN is used as an EAP-TNC protocol
and the TNCS as it pertains to the exchange of integrity measure- and the established key should be exported and mixed into the
ment data. IF-M defines the protocol for messaging between IMC tunneled EAP method’s session keys. However, the D–H exchange
and IMV [40,41]. in protocol D–H PN could not provide a strong cryptographic
IF-T: Protocol bindings for tunneled extensible authentica- binding between the authenticating user and the TPM-based In-
tion protocol (EAP) methods. NAR and NAA communicate with tegrity Report making D–H PN could not resist platform replace-
ment attack, which will compromise the security of terminals in
each other via four protocol layers including EAP-TNC, Tunnel
IoT environment. Against this kind of attack, Zhang et al. make a
EAP, EAP and access protocol, which are combined to form the
comprehensive and reasonable analysis on TNC and the platform
IF-T protocol binding for tunneled EAP methods [42]. EAP-TNC is
replacement attack is described in detail in [44] including threat
designed to encapsulate IF-TNCCS messages in a very simple EAP
models and adversary description.
method, which can be carried over tunneled EAP methods using
standard attribute value pairs. This allows IF-TNCCS messages
4. Problem formulations
to be carried within tunneled EAP methods while the method
creates a cryptographically protected tunnel over EAP.
4.1. System model

3.2. Blockchain Our scheme is designed under the IF-T interface in TNC ar-
chitecture and we assume that each terminal device is initially
The blockchain is a growing list of records, called blocks, which equipped with a trusted platform module (TPM). TPM is a trust
are linked using cryptography. By design, blockchain is a public root of a trusted computing platform, which has the ability of
ledger of all transactions that have ever been executed. It is cryptographic operation and storage. The integrity information of
constantly growing as miners add new blocks to it to record the entire platform can be obtained within the TPM by invoking
the most recent transactions. Once recorded, the data in any relevant interfaces.
given block cannot be altered retroactively without alteration of Here, we let terminal A and terminal B respectively represent
all subsequent blocks. Each node in blockchain has a copy of a requester and a responder in IoT environment. The system
recorded transactions, which is downloaded automatically when model is shown in Fig. 1, which consists of three entities: ter-
the miner joins the network. The blockchain has complete in- minal A(TDA ), terminal B(TDB ) and blockchain. Regularly, TDA
formation about addresses and balances from the genesis block includes user A(UserA ) and device A(DeviceA ) while TDB includes
to the most recently completed block. As a public ledger, it is user B(UserB ) and device B(DeviceB ). Note that, user and de-
convenient to query any block for transactions associated with vice are integrated into one entity named terminal. Here, TDA
a particular address with help of public-key cryptography. and TDB respectively measure their platform integrity and reg-
The blockchain is seen as the main technology innovation of ister themselves in the initialization phase. Then, during the
Bitcoin because it stands as a ‘‘trustless’’ proof mechanism of all trusted network connect phase, UserA and DeviceA perform mu-
the transactions on the network. Users can trust the system of tual verification with UserB and DeviceB in order to guarantee
the public ledger stored on many decentralized nodes, as opposed the security and credibility of the distributed network. More-
to having to maintain trust with a third party. It allows the over, blockchain is responsible for maintaining and updating the
disintermediation and decentralization of all transactions of any transactions which it receives during the whole process.
type between all parties on a global basis [35]. Terminal A. As a requester, TDA can initiate a request and
The blockchain is like another application layer to run on the establish a connection with TDB . Then it can obtain TDB ’s cur-
existing stack of Internet protocols, adding an entire new tier rent platform integrity through the delivery of messages. With
to the Internet to enable economic transactions, both immedi- the help of obtaining the TDB ’s latest transaction included in
ate digital currency payments and more complicated financial the blockchain, TDA can detect the trustworthiness of the other
contracts. Further, the blockchain may be used not just for trans- party. Here, UserA and DeviceA are responsible for performing
actions, but also as a inventory system for the recording, tracking, mutual verification with UserB and DeviceB in the trusted network
monitoring of all assets [36]. connect phase.
4 J. Zhang, Z. Wang, L. Shang et al. / Journal of Parallel and Distributed Computing 143 (2020) 1–16

Fig. 1. System model.

Fig. 2. The BTNC framework.

Terminal B. As a responder, TDB can establish connection device to impersonate the legal device. As a result, it may have
with TDA when receiving a request from TDA . Then TDB is able the following aggressive behaviors. For example, (1) the adversary
to compare TDA ’s platform integrity with its latest transaction could be considered as a trusted terminal and therefore access
included in the blockchain and verify whether the other party the network; (2) the trusted terminal devices’ private information
is compromised. Here, UserB and DeviceB are responsible for could be obtained by the adversary.
performing mutual verification with UserA and DeviceA in the
trusted network connect phase. 4.3. Design goals
Blockchain. Blockchain is used to store and update transac-
tions when receiving transactions from the miners. Our proposed scheme is supposed to satisfy the following
requirements:
4.2. Threat model 1. User authentication. Our scheme is able to verify the au-
thorization of the users’ identities and discern the unau-
As a member of the distributed network, the terminals may thorized users.
have the following dishonest behaviors: 2. Platform attestation. Our scheme has ability to detect the
Unauthorized user. As a user of the terminal, if the user is integrity of terminal platforms and prevent illegal devices
unauthorized that he does not perform the registration process from accessing protected network.
with the trusted third party in the initialization phase, he may 3. Resist platform replacement attack. Our scheme is capable
engage in the following aggressive behaviors. For example, (1) he of resisting the platform replacement attack.
may make connection with other authorized users and therefore
steal their private data; (2) he may access the network without 5. The proposed scheme
initialization phase. As a result, unauthorized users may invade
and attack the protected distributed network. Overview of scheme BTNC. As shown in Fig. 2, BTNC con-
Illegal platform. As a platform of the terminal device, if the sists of two phases including initialization phase and trusted
platform is illegal that its integrity could not satisfy the network network connect phase. With the help of TPM chip, the plat-
access policy, it may have the following dishonest behaviors. form measurements of a terminal can be obtained by invoking
For example, (1) it may transmit fake platform measurements to TPM_Quote() function [3]. In our scheme, base and update trans-
other trusted devices during mutual verification; (2) it may forge actions generated by terminals are uniformly considered as extra
a transaction to deceive other trusted terminals. As a result, illegal information which are embedded in the final transaction records
platform may be considered as a trusted terminal device so as to and therefore be included in the blockchain.
access the protected network. In the initialization phase, a terminal in IoT will generate a
Platform replacement attack. If a certificated terminal device final registration message including its identity, measurement
is illegal, the adversary could instruct any other unauthorized report and ECDSA signature. Then, the trusted third party will
 J. Zhang, Z. Wang, L. Shang et al. / Journal of Parallel and Distributed Computing 143 (2020) 1–16 5

Fig. 3. Initialization phase.

verify the validity of its platform measurement and the cor- (rA , sA ). IDA denotes the device identification number, PCRA0 de-
rectness of relevant signatures. Subsequently, the trusted third notes the initial platform measurement, digestA denotes the plat-
party will sign the final registration information if the platform form measurement value of terminal A each time and CTA0 de-
measurements comply with the local network access policy. As a notes a counter which is set to 0 in the initialization phase.
result, a base transaction will be generated by the terminal and (rA , sA ) is derived by KpriA and registration information Mregis ,
eventually be included in the blockchain. where Mregis = (IDA , MTQI ), K P = (x1 , y1 ), rA = x1 mod n, sA =
In the trusted network connect phase, the terminals in IoT K −1 (hash(Mregis ) + KpriA ·rA ). σAIK is derived by TPM_QUOTE_INFO,
will perform mutual user authentication and platform attestation where σAIK = SignAIK (TPM_QUOTE_INFO). EAP method is used to
based on blockchain with each other. As a result, each of them is provide a cryptographically protected tunnel between TDA and T .
able to verify the security of others. Then, the update transactions (3) When T receives the EAP-Request message from TDA , it
will be generated and eventually be included in the blockchain. utilizes TDA ’s public AIK to verify the signature. Then, T will
validate whether the PCRA0 value complies with the requirements
of the network policy.
5.1. Initialization phase (4) If the PCRA0 value satisfies the policy, T will send veri-
fication message (Mv erT ) to TDA , which is encapsulated by EAP
The domain parameters is public, which includes group order method named EAP-Response. Here, Mv erT = (PCRA0 , IDA , CTA0 ,
n, generator P, prime number q and curve E. Each terminal digestA , (rA , sA ), σT ) and σT = SignT (Mv erT ), in which SignT (.) is
must be registered so as to have certified public/private key pair defined to sign the message using the private key of T . On the
(Kpub/Kpri) before initialization phase. In this section, we let contrary, if the PCRA0 value does not meet the requirements of
terminal A (TDA ) represent any of terminals in IoT. The process the policy, T will interrupt the connection immediately.
of the initialization phase is shown in Fig. 3. (5) When receiving the EAP-Response message from T , TDA
(1) First of all, TDA is supposed to measure its platform re- will generate a base transaction message (MbtA ) and broadcast
source when launching system with the help of TPM chip. The it to the network. When a valid block, including the base trans-
measurements of platform are presented by a hash value stored action of TDA , is generated and uploaded in the blockchain, the
in the platform configuration registers (PCR). Then, through the initialization phase is over.
iterative calculation and hash chain technology, the integrity Next, we introduce the structure of the base transaction which
measurements PCRA of TDA are generated [3], where PCRAi = is used to register the platform measurement.
hash(PCRAi−1 ∥digestA ). Here, digest denotes a variable number of Base transaction. This transaction consists of transaction ID,
octets of each measurement that to be hashed and hash(.) repre- device ID, PCR measurement, counter value, ECDSA signature
sents a collision-resistant hash function which is used to provide (r , s), digest and T ’s signature. More specifically, the transaction
ID is the hashed value of initial public key of the sender and
integrity checking and authentication as well as one-way func-
the device ID is a unique identification of the terminal device
tions. New PCRAi values are derived from old PCRAi−1 values in
which is verified. ECDSA signature (r , s) is used for key agreement
every measurement while i → {1, 2...n}.
process. The counter value is used to solve the synchronization
(2) In order to complete the registration of identity and plat-
problem while the PCR measurement and digest are used to
form information, TDA will select a random number K ∈ [1,n-1]
attest platform. Then, T signs digitally over the aforementioned
and establish a secure connection with a trusted third party T
data using private key. Moreover, miners are able to verify the
using EAP method named EAP-Request to encapsulate its final correctness of base transactions by following conditions: (1) the
registration message (MregisFin ) where MregisFin = (IDA ,TPM_QUOTE integrity of the data; (2) the correctness of the signature signed
_INFO, (rA , sA ), σAIKA ). Here, TPM_QUOTE_INFO (MTQI ), including digitally by T .
(PCRA0 , digestA , CTA0 ), is a measurement report which can be used
to determine the integrity of the terminal platform. 5.2. Trusted network connect phase
In our protocol, SignAIK (.) is defined to sign the message us-
ing the private attestation identity key (AIK) inside the TPM In this phase, the platform measurements of terminal devices
chip. Note that, the private AIK is used specifically for sign- can be detected and verified without the trusted third party T and
ing platform measurements due to the security concerns. Next, the process of trusted network connect phase is shown in Fig. 4.
we make a brief introduction about the final registration mes- Here, we let terminal A (TDA ) and terminal B (TDB ) represent a
sage MregisFin which includes IDA , PCRA0 , CTA0 , digestA , σAIKA and requester and a responder, respectively.
6 J. Zhang, Z. Wang, L. Shang et al. / Journal of Parallel and Distributed Computing 143 (2020) 1–16

Fig. 4. Trusted network connect phase.

(1) TDA sends an EAP-Request message to TDB , including following messages transmitting between TDA and TDB , where
(TDA , IDA , TDB , NA ), to indicate the beginning of the session. NA UV − 2 = hash(2∥RN ∥KssAB ).
denotes a random number that TDA chooses. This cryptographically binds the PCR values quoted to the ses-
(2) When TDB receives the EAP-Request message, it will gen- sion key KssAB during the verification, which effectively combines
erate an EAP-Response message, including (TDA , IDB , TDB , NB ), to user authentication with platform attestation.
indicate the continuation of the session and therefore send EAP- (5-b) TDB will calculate KssAB , Unique-Value-1 and Unique-
Response message to TDA . NB denotes a random number that TDB Value-2 in a same way as TDA in ‘‘(5-a)’’.
chooses. (6) TDA sends an EAP-TNC Request message to TDB includ-
(3-a) Then, TDB will derive a transaction-specific private key ing IDA , TDA , TDB , which indicates a willingness to verify TDB ’s
KpritsB from its own signature pair (rB , sB ) and transaction ID(TB ), platform measurements.
1
where KpritsB = (hash(TB ) + KpriB · rB )s− B . Here, TB denotes TDB ’s
(7) When TDB receives the EAP-TNC Request message and
latest transaction included in the blockchain. is asked to produce an integrity report, UV-1 is passed to the
(3-b) When receiving the EAP-Response message, TDA will also TPM_Quote operation along with the desired PCRBi set so that
derive a transaction-specific private key KpritsA as TDB in ‘‘(3-a)’’. the resulting KpriAIKB signed TPM_INTEG_INFO (MTII ) contains a
(4-a) TDA will query the blockchain, extract TDB ’s ECDSA signa- binding of the system state to the session state. Note that MTII
ture pair (rB , sB ) from its transaction and attempt to derive TDB ’s = (MTQI , UV − 1). As a result, TDB sends EAP-TNC Response
transaction-specific public key, where KpubtsB = (xB , yB ). (x, y) message to TDA which includes (IDB , TDB , TDA ,TPM_INTEG_IN-FO,
represents a point on the elliptic curve. (rB , sB ), σAIKB )UV −2 . Here, we let CTB + 1 when the PCRB is mea-
(4-b) TDB will also derive TDA ’s transaction-specific public sured once.
key KpubtsA = (xA , yA ) by extracting TDA ’s ECDSA signature pair (8) Then, TDB will compute UV − 2 iteratively, where UV −
(rA , sA ) from its transaction as well. Here Cre(.) is defined to derive 2 = hash(2∥RN ∥KssAB ∥hash(EAP-TNC Response)). Here, we utilize
transaction-specific private keys and transaction-specific public UV − 2 to be the secret session key of the subsequent sessions.
keys in a trusted network connect phase. (9) When receiving the EAP-TNC Response message, TDA will
(5-a) Following the Elliptic Curve Diffie–Hellman (ECDH) ap- decrypt the message with the help of UV − 2. If it recovers the
proach [21], TDA is able to calculate the shared secret (xAB , yAB ), plaintext, TDA is responsible to do the following steps. First, TDA
where (xAB , yAB ) = KpritsA · KpubtsB . Then, the xAB coordinate will will verify the authenticity of the signature signed by TDB using
be used to derive the shared secret key KssAB refer to KDF (.) KpubAIKB . Then, it verifies the consistency of UV − 1, which means
function, where KssAB = KDF (xAB ). Here, KDF (.) is defined as a whether the value of UV − 1 is as same as the value it computes.
kind of key derivation function which is used to create secure Next, TDA will verify the value of PCRBi by obtaining the PCR value
session key [33]. In order to achieve platform attestation, we PCRBi−1 of the TDB ’s latest transaction from the blockchain, where
utilize one byproduct Unique-Value-1 (UV − 1) of the secret CTBi−1 = CTBi −1 and PCRBi = hash(PCRBi−1 ∥digestB ). Then, TDA will
key and both random numbers NA , NB as the ExternalData RN compute UV − 2 as TDB in ‘‘(8)’’. Here, CheckHashPCR (.) is defined
parameter to the subsequent TPM_Quote operation which is used to verify the PCR values based on the blockchain.
to invoke PCR values and produce MTQI . Then, TDA will compute (10) TDB sends an EAP-TNC Request message to TDA includ-
the UV − 1, where UV − 1 = hash(1∥RN ∥KssAB ). Moreover, we ing IDB , TDB , TDA , which indicates a willingness to verify TDA ’s
utilize another byproduct Unique-Value-2 (UV − 2) to encrypt platform measurements.
 J. Zhang, Z. Wang, L. Shang et al. / Journal of Parallel and Distributed Computing 143 (2020) 1–16 7

Fig. 5. Generation of transactions.

(11) TDA sends an EAP-TNC Response message to TDB , in- 6. Analysis of scheme BTNC
cluding TPM_INTEG_INFO, IDA , TDA , TDB , (rA , sA ), and σAIKA , where
EAP-TNC Response = (TPM_INTEG_INFO, IDA , TDA , TDB , (rA , sA ), In this section, we use PCL to prove the correctness of the
σAIKA )UV −2 . proposed protocol, including authentication and secrecy prop-
(12) When receiving EAP-TNC Response message, TDB will erties, and the detailed information on the PCL proof system
decrypt the message by secret key UV − 2 and verify following can be found in [7,8]. In general, we will conduct the PCL proof
data. First, TDB will verify the signature signed by using KpubAIKA . method to analyze the proposed scheme BTNC, which includes
Then TDB will verify the consistency of UV − 1 and the correctness the initialization phase (Ini) and the trusted network connect
of PCRBi as TDA does in ‘‘(9)’’. phase (Tnc). Particularly, we will describe the DHOB axioms based
(13-a) If validation passes above, TDA will sign the EAP-TNC on the PCL grammar firstly. Then we will give the precondition
Response message sent from TDB and generate a new update of the sub-protocol BTNC.Ini and sub-protocol BTNC.Tnc, as well
transaction MutB of TDB , where MutB = (IDB , σA , σAIKA , TPM_QUOTE as their security properties, invariants and security proof. Next,
_INFO). Then, TDA broadcast it to the network. After the miners we will use the proved theorems and the sequential composition
generate a valid block including the update transaction of TDB , theorem to further analyze the security of the proposed goals.
the trusted network connect phase is over. Here, precondition, security properties, invariants and sequential
(13-b) TDB will conduct the same process as TDA in ‘‘(13-a)’’. composition are the related syntax and semantics of PCL proof
Next, we will introduce the structure of the update transac- system. PCL defines sequential and parallel composition of pro-
tocols as syntactic operations on cord and present associated
tions which are leveraged to update the platform measurements
methods for proving protocol properties compositionally.
and the process of the generation of the transactions will be
depicted in Fig. 5.
6.1. DHOB axioms
Update transaction. This transaction consists of transaction
ID, device ID, PCR measurement, counter value, digest value,
Since the key agreement process of the Diffie–Hellman over
ECDSA (r , s), AIK signature and other terminal device’s signature.
bitcoin (DHOB) protocol is used in the trusted network connect
Here, AIK signature and other terminal device’s signature are used
phase, we are able to extend protocol composition logic content
to guarantee the validity of the update transactions. Moreover,
and describe the DHOB axioms based on the PCL grammar.
miners are able to verify the correctness of update transactions by
DHOB1: Compute(X , KssAB ) ⊃ Has(X , KssAB )
following conditions: (1) messages’ integrity; (2) signed digitally
DHOB2: Has(X , KssAB ) ⊃ (Has(X , {KpritsA , KpubtsB })) ∨ (Has(X ,
by private key AIK ; (3) signed digitally by the other terminal’s {KpritsB , KpubtsA }))
private key, which means that each terminal could not publish DHOB3: (Has(X , {KpritsA , KpubtsB })) ∨ (Has(X , {KpritsB , KpubtsA })) ⊃
their own update transactions to the miners; (4) counter value (Compute(X , {KpritsA , KpubtsB }) ∧ ∃M .(⋄Has(X , KpriA ) ∧ Receiv e
is not repetitive compared with the previous transactions, which (X , M) ∧ Contains(M , {TA , rB , sB }))) ∨ (Compute(X , {KpritsB , KpubtsA })
means that a terminal could not simultaneously perform trusted ∧∃M ′ .(⋄Has(X , KpriB ) ∧ Receiv e(X , M ′ ) ∧ Contains(M ′ , {TB , rA , sA })))
network connect phase with any other two terminals so as to DHOB4: (⋄Receiv e(X , M)∧Contains(M , {TA , rB , sB }))∨(⋄Receiv e(X ,
solve the problem of synchronization. M) ∧ Contains(M , {TA , rB , sB })) ⊃ ∃Y , M , M ′ Send(Y , {TA , rB , sB }) ∨
Here we adopt blockchain to store the platform measurement Send(Y , {TB , rA , sA })
information of each terminal in the distributed network, which DHOB5: (Receiv e(X , {TA , rB , sB }) ∧ ⋄Has(X , KpriA )) ∨ (Receiv e(X ,
greatly eliminates the risk of being managed centrally with the {TB , rA , sA }) ∧ ⋄Has(X , KpriB )) ⊃ Compute(X , {KpritsA , KpubtsB }) ∨
help of the trusted third party. Every terminal in the distributed Compute(X , {KpritsB , KpubtsA })
system can directly establish connection with other terminals Particularly, DHOB1 states that if terminal X can compute the
and request their PCR values in order to verify the integrity of session key, it also owns the session key; DHOB2 states that if
their platforms based on blockchain without trusted third party. terminal X has a session key, it also has a specific transaction key
Through the technology of the blockchain, terminals’ base and pair for that session key; DHOB3 indicates that terminal X , which
update transactions can be stored integrally so that our scheme has a specific transaction key pair, can obtain the secret material
can achieve the property of decentralization. used to calculate the specific transaction key pair from an entity;
8 J. Zhang, Z. Wang, L. Shang et al. / Journal of Parallel and Distributed Computing 143 (2020) 1–16

DHOB4 states that there is an entity Y who can send the relevant ΓBTNC .Ini.2 := Honest(T̂ ) ⊃ (Send(T , MverT ) ∧ Contains(MverT ,
material information to terminal X before terminal X receives {MregisFin , σT }) ∧ Has(T , KpriT ) ∧ ⋄Has(T , KpubA )) ⊃ (MverT =
the secret material used to calculate a specific transaction key {T̂ , Â, {{|MregisFin |}KpriT , {MregisFin }}} ∧ After(Receiv e(T , {Â, T̂ ,
pair; DHOB5 indicates that terminal X can calculate the relevant
{|MregisFin |}KpubT })) ∧ Send(T , {T̂ , Â, {|MverT |}KpubA })).
specific transaction key pair with its own private key, transaction
ΓBTNC .Ini.3 := Honest(Ĉ ) ⊃ ( After(Receiv e(C , {Â, Ĉ , {MverT }}) ∧
number and ECDSA signature information.
New (C , MbtA ) ∧ Contains(MbtA , {Mv erT , TDA , })).
6.2. BTNC.Ini sub-protocol
ΓBTNC .Ini = ΓBTNC .Ini.1 ∧ ΓBTNC .Ini.2 ∧ ΓBTNC .Ini.3 .
Invariants ΓBTNC .Ini.1 , ΓBTNC .Ini.2 and ΓBTNC .Ini.3 are generally
proved by induction over programs using the Honesty Rule. The
Since each terminal in the distributed environment is embed-
proof of the theory 1 is described formally using the programming
ded with TPM trusted platform modules with different identities
language, which appears in Appendix A.
in order to measure and report platform status before the ini-
Here, with the combination of Theorem 1, DHOB axioms and
tialization phase. Each terminal has its own attestation identity
key AIK , trusted counter and configuration register. Before each proof process in Appendix A, we further analyze the user au-
terminal sends registration information to a trusted third party, thentication of the BTNC. We denote an adversary A who is an
it will conduct a process of platform measurement and storage of unauthorized user aiming to pass user authentication. When the
its own, so the corresponding PCR value, digest value and counter adversary A could access network, there are two possible cases.
value will be generated. Here, we let terminal A (TDA ), TPM chip Case 1: Adversary A could utilize an unregistered terminal TDA
P, trusted third party T and blockchain C be the roles to execute to access the protected network.
the BTNC.Ini sub-protocol. Case 2: Adversary A could utilize a registered terminal TDA to
PRECONDITION: BTNC.Ini starts from a state in which the access the protected network.
precondition θBTNC .Ini holds, where Case 1. Formulas (1)–(4) in Appendix A assert that before T
send Mv erT , it must have received a final registration message
θBTNC .Ini = Has(P̂ , KpriAIKA ) ∧ Fresh(P̂ , PCRA0 ) ∧ Fresh(P̂ , digestA ) ∧
from TDA , where ActionsInOrder (Receiv e(T , {Â, T̂ , {|MregisFin |}
Fresh(P̂ , CTA0 ) ∧ Contains(MTQI , {PCRA0 , digestA , CTA0 }) ∧ Fresh(MTQI ,
KpubT }), Send(T , {T̂ , Â, {|σT , MregisFin |}KpubA })). Due to the Honesty
{rA , sA }) ∧ Contains(MregisFin , {MTQI , rA , sA }) ∧ Has(Â, MregisFin ) ∧ Has
rule, the trusted T could not conduct its action sequences and
(Â, KpriA ) ∧ Has(T̂ , KpriT ). so as not to send message Mv erT signed by private key KpriT if
Here, the precondition of the BTNC.Ini is that any TPM chip TDA does not send MregisFin to T . At the same time, due to the
of a terminal could generate a measurement report MTQI which unforgeable of the signature σ T , adversary A could not forge T ’s
includes PCR value PCR, measurement value digest and counter signature.
value CT . As a result, the terminal could have final registration Formulas (12)–(13) in Appendix A assert that before
message MregisFin which consists of ECDSA signature (r , s) and the blockchain C generates the base transaction MbtA of TDA , it must
measurement report MTQI . At the same time, each terminal has have received the message Mv erT , including σT and MregisFin , from
their own private key while the trusted third party has its own
TDA where ActionsInOrder (Send(A{Â, Ĉ , {MbtA }}), Receiv e(C {Â, Ĉ ,
private key KpriT .
{MbtA }})).
AUTHENTICATION: BTNC.Ini is said to provide authentication
According to the formula (14), before TDA generates and sends
if phiBTNC .Iniauth holds, where
the base transaction to the blockchain C , it must have received
φBTNC .Iniauth = Honest(P̂) ∧ Honest(T̂ ) ∧ Honest(Ĉ ) ∧ Honest(Â) ⊃ the message Mv erT from T , where ActionsInOrder (Receiv e(A, {T̂ ,
∀A.ActionsInorder(
Â, {|σT , MregisFin |}KpubA }), Send(A{Â, Ĉ , {MbtA }})). Because TDA is an
Send(P , {P̂ , Â, {MTQI , σAIKA }}),
unregistered terminal, adversary A could not receive the message
Receiv e(A, {P̂ , Â, {MTQI , σAIKA }}), Mv erT including σT from honest T .
Send(A, {Â, T̂ , {|MregisFin |}KpubT }), Due to the Honesty rule, the blockchain C could not generate a
Receiv e(T , {Â, T̂ , {|MregisFin |}KpubT }), block including TDA ’s base transaction MbtA . As a result, adversary
Send(T , {T̂ , Â, {|σT , MregisFin |}KpubA }), A could not pass the user authentication.
Receiv e(A, {T̂ , Â, {|σT , MregisFin |}KpubA }), Note that, ActionsInOrder is a kind of rule for temporal or-
Send(A{Â, Ĉ , {MbtA }}), dering, where ActionsInOrder(a1 , . . . ,an ) ≡ After(a1 ,a2 )∧ · · · ∧
After(an−1 ,an ).
Receiv e(C {Â, Ĉ , {MbtA }})).
Case 2. According to the DHOB5 axiom, the specific transaction
Here, the authentication property of the BTNC.Ini is that any
private key KpritsA is derived by the private key KpriA . Therefore,
measurement report MTQI received by the TDA is sent by the TPM
although adversary A could utilize a registered terminal TDA
chip P and any final registration message received by the trusted
whose base transaction has been included in the blockchain, it
third party T is sent by the TDA . Moreover, any message including
is impossible for A to forge the private key of the TDA , which
σT , MregisFin received by the TDA is sent by the trusted third party
leads to the difficulty in calculating elliptic discrete logarithms.
T and any base transaction received by the blockchain is sent by
As a result, adversary A could not derive the secret session key
the TDA . At the same time, both TDA and T could confirm the
in terms of DHOB2 axiom and therefore could not pass the user
existence of their own secret keys KpriA and KpriT , respectively.
authentication.
Theorem 1. If θBTNC .Ini is true, BTNC.Ini will guarantee the authenti-
6.3. BTNC.Tnc sub-protocol
cation property, where
BTNC.Ini⊢ θBTNC .Ini [BTNC .Ini]φBTNC .Iniauth .
Here, we let terminal A (TDA ), terminal B (TDB ) and blockchain
INVARIANTS: In the case of BTNC.Ini, the expected behaviors C be the roles to execute the BTNC.Tnc sub-protocol.
of three honest principals are captured by ΓBTNC .Ini , where PREDICTION: BTNC.Tnc starts from a state in which the pre-
ΓBTNC .Ini.1 := Honest(P̂) ⊃ (Send(P , MTQI ) ∧ Contains(MTQI , condition θBTNC .Tnc holds, where
{PCRA0 , digestA , CTA0 })) ⊃ (MTQI = {P̂ , Â, {KpriAIKA , {PCRA0 , digestA , θBTNC .Tnc = Has(Â, NA ) ∧ Has(B̂, NB ) ∧ Has(Â, KpriAIKA ) ∧ Has(Â,
CTA0 }}} ∧ ⋄Fresh(P , KpriAIKA )) ∧ After(Start(P)) ∧ Send(P , {P̂ , Â, PCRAi ) ∧ Has(Â, digestA ) ∧ Has(Â, CTAi ) ∧ Contains(MTQI , {PCRAi ,
{PCRA0 , digestA , CTA0 , σAIKA }}). digestA , CTAi }) ∧ Has(Â, KpriA ) ∧ Has(B̂, KpriAIKB ) ∧ Has(B̂, PCRBi )
 J. Zhang, Z. Wang, L. Shang et al. / Journal of Parallel and Distributed Computing 143 (2020) 1–16 9

∧ Has(B̂, digestB ) ∧ Has(B̂, CTBi ) ∧ Contains(MTQI , {PCRBi , digestB , key KpriAIKD in order to pass platform attestation. Due to the
CTBi }) ∧ Has(B̂, KpriB ) ∧ Has(Ĉ , TA ) ∧ Has(Ĉ , TB ) ∧ Has(Ĉ , rA ) ∧ Honesty rule of TPM chip P in Appendix A, only honest P could
Has(Ĉ , rB ) ∧ Has(Ĉ , PCRAi−1 ) ∧ Has(Ĉ , PCRBi−1 ) ∧ Has(Ĉ , digestA ) ∧ possess the private key KpriAIKD and generate the signature σAIKD
of the integrity report MTQI . At the same time, non-TPM data could
Has(Ĉ , CTAi−1 ) ∧ Has(Ĉ , digestB ) ∧ Has(Ĉ , CTBi−1 ).
not be signed by AIK , which prevents TDD from fabricating illegal
Here, the precondition of BTNC.Tnc is that the TDA and the PCR values to be signed. As a result, the adversary TDD could not
TDB have their own measurement reports MTQI , private keys and generate and transmit a fake measurement report MTQI signed by
attestation identity keys KpriAIK because of being embedded the private key KpriAIKD to other trusted terminals and therefore pass
TPM chips. Moreover, the latest transactions of the TDA and the platform attestation.
TDB have been included in the blockchain C . As a result, the
blockchain C has their last integrity report including PCRAi−1 and 6.4. The compositional proof of BTNC
PCRBi−1 .
SECRECY: BTNC.Tnc is said to provide secrecy if phiBTNC .Inisec As illustrated above, the BTNC protocol is constructed by a
holds, where sequential composition of BTNC.Ini and BTNC.Tnc. Here, we prove
φBTNC .Tncsec = Honest(Â ∧ Honest(B̂)) ⊃ Has(Ẑ , UV − 1) ∧ the authentication and secrecy properties of BTNC with the help
Has(Z , UV −2) ⊃ Ẑ = Â∨Ẑ = B̂∧Has(A, KpriAIKA ) ∧ Has(A, KpriA ) ∧ of sequential composition proof method.
Has(B, KpriAIKB ) ∧ Has(B, KpriB ).
Here, the secrecy property of BTNC.Tnc is that both TDA and Theorem 3. According to the process of trusted network connec-
TDB should confirm the existence of the secret key including tion, the security properties of protocol BTNC can be guaranteed by
KssAB , UV − 1, UV − 2, and the fresh secret keys should not combining BTNC.Ini and BTNC.Tnc, where
be known to any other principal other than two participants. BTNC ⊢ θBTNC [BTNC .Ini, BTNC .Tnc ]φBTNC .Ini ∧ φBTNC .Tnc
Moreover, both TDA and TDB should confirm the existence of their φBTNC .Ini = φBTNC .Iniauth
private AIK . φBTNC .Tnc = φBTNC .Tncsec

Theorem 2. If θBTNC .Tnc is true, BTNC.Tnc will guarantee the secrecy Proof. (1) According to the proof of these two sub-protocols,
property, where BTNC.Ini and BTNC.Tnc can satisfy the security properties.
BTNC.Tnc⊢ θBTNC .Tnc [BTNC .Tnc ]φBTNC .Tncsec . BTNC .Ini ⊢ ΓBTNC .Ini ΓBTNC .Ini ⊢ [BTNC .Ini]T φBTNC .Iniauth
BTNC .Tnc ⊢ ΓBTNC .Tnc ΓBTNC .Tnc ⊢ [BTNC .Tnc ]B φBTNC .Tncsec
INVARIANTS: In the case of BTNC.Tnc, the expected behaviors (2) Under the weaker prediction, the security properties of
of two honest principals are captured by ΓBTNC .Tnc , where protocol BTNC can still be guaranteed.
ΓBTNC .Tnc .1 := Honest(B̂) ⊃ ( After(Receiv e(B, {Â, B̂, {TDA , TDB , BTNC .Ini ⊢ ΓBTNC .Ini ∧ ΓBTNC .Tnc BTNC .Tnc ⊢ ΓBTNC .Ini ∧ ΓBTNC .Tnc
IDA , NA }})) ∧ Fresh(B, NB ) ∧ Send(B, {B̂, Â, {TDB , TDA , IDA }}) ∧ After (3) Since the postcondition of θBTNC .Ini satisfies the precondition
(Receiv e(B, {Ĉ , B̂, {TB , rA , sA }})) ∧ Compute(B, {UV − 1, UV − 2}) ∧ of θBTNC .Tnc , where θBTNC .Ini ⊃ θBTNC .Tnc
Send(B, {B̂, Â, {|TDB , TDA , IDB |}UV −2 }) ∧ After(Receiv e(B, {Â, B̂, (4) Invariant ΓBTNC .Ini ∪ ΓBTNC .Tnc satisfies both BTNC.Ini and
MTII }))∧Contains(MTII , {|MTQI , rA , sA , UV − 1, σAIKA |}UV −2 )∧Verify(B, BTNC.Tnc.
BTNC .Ini ⊢ ΓBTNC .Ini ∪ ΓBTNC .Tnc
MTII ) ∧ Send(B, {B̂, Ĉ , {{MutA , σB }}}).
i BTNC .Tnc ⊢ ΓBTNC .Ini ∪ ΓBTNC .Tnc
ΓBTNC .Tnc .2 := Honest(Ĉ ) ⊃ ( ⋄Has(C , {TA , TB , rA , sA , rB , sB , BTNC ⊢ ΓBTNC .Ini ∪ ΓBTNC .Tnc
PCRAi−1 , digestA , CTAi−1 , PCRBi−1 , digestB , CTBi−1 }) ∧ After(Receiv e(C , (5) The steps above indicate that the security of BTNC.Ini and
{Â, Ĉ , {MutBi }})) ∧ New(C , MutBi ) ∧ After(Receiv e(C , {B̂, Ĉ , {MutAi }})) BTNC.Tnc can still be guaranteed after sequential combination,
∧ New(C , MutAi ). where
ΓBTNC .Tnc = ΓBTNC .Tnc .1 ∧ ΓBTNC .Tnc .2 BTNC ⊢ θBTNC [BTNC .Ini, BTNC .Tnc ]φBTNC .Ini ∧ φBTNC .Tnc
The proof of the theory 2 is described formally using the pro- Therefore, the protocol is secure under the sequential com-
gramming language, which appears in Appendix B. Here, with the position. From the proof of Theorem 3, we conclude that the
combination of Theorem 2 and proof process in Appendix B, we protocol is proved to be secure. Here, we further analyze the
security attribute of resisting platform replacement attack. We
further analyze the platform attestation of the BTNC. We denote a
consider an attack (platform replacement attack) that terminal E
compromised terminal D(TDD ) which is authorized but has illegal
(TDE ) is an authorized device with illegal platform and terminal
platform and attempts to access the distributed network. Under
F (TDF ) is an unauthorized device with trusted platform. Then,
this circumstance, there are two possible cases.
TDE instruct invalid TDF to impersonate a trusted terminal, which
Case 1: Adversary TDD could forge Unique-Value-1(or Unique-
forms a kind of collusion relationship. Then TDE starts perform-
Value-2) and therefore conduct the man-in-the-middle attack ing mutual authentication with a trusted terminal A (TDA ) and
between trusted terminal A and terminal B in practice. thereby leaking their session key, UV − 1 and UV − 2 to TDF . As a
Case 2: Adversary TDD could generate and transmit a fake result, the validity of mutual verification could not be guaranteed
measurement report MTQI signed by private key KpriAIKD to other and terminal TDE will be considered as an authorized user with
trusted terminals. trusted platform.
Case 1. Formulas (16)–(17) in Appendix B assert that only Since the postcondition of θBTNC .Ini satisfies the precondition
TDA and TDB could confirm the existence of the secret key KssAB , of θBTNC .Tnc , where θBTNC .Ini ⊃ θBTNC .Tnc and BTNC ⊢ ΓBTNC .Ini ∪
UV − 1, UV − 2; The fresh secret keys UV − 1, UV − 2, KssAB could ΓBTNC .Tnc , the security of BTNC.Ini and BTNC.Tnc can still be guar-
not be known to any other principal other than TDA and TDB . At anteed after sequential combination. As a result, TDE and TDF
the same time, UV − 1 and UV − 2 are pseudorandom numbers, could not obtain the private key KpriAIKF and due to the un-
the probability that adversary TDD could forge UV − 1(or UV − 2) forgeable of the signature σAIKF and the randomness of the value
is the probability of breaking the computational Diffie–Hellman UV − 1, UV − 2, TDE could not impersonate a trusted terminal
(CDH) assumption. In other words, assuming the probability that and therefore transmit legal platform measurement. At the same
case 1 happens is negligible. As a result, adversary TDD is unable time, TDF could not attain the private key KpriE of the TDE and
to forge UV − 1 and UV − 2 in practice. therefore derive secret keys including KssAE , UV − 1 and UV − 2.
Case 2. Formula (22)–(24) in Appendix B assert that the adver- In the end, the platform replacement attack has no influence on
sary TDD needs to send integrity report MTQI signed by the private the security of the scheme BTNC.
10 J. Zhang, Z. Wang, L. Shang et al. / Journal of Parallel and Distributed Computing 143 (2020) 1–16

Fig. 6. Computation overhead of initialization phase in different encryption algorithms.

Table 1 to evaluate the performance overhead of one terminal during

Comparison with related works. the registration process. Because the current TPM uses 1024-
Schemes D–H PN [41] Twin D–H [44] BTNC bit RSA, 2048-bit RSA or 256-bit ECC to achieve encryption and
√
Decentralization ×
√ ×
√ √ signature, here we simulate encryption overhead under three
User authentication √ √ √ different encryption algorithms. In our parameter settings, the
Platform attestation √ √
Resist platform replacement attack × key length is respectively 128 bytes in RSA-1024, 256 bytes in
RSA-2048 and 256 bits in ECC-256. The exponent value e of public
key in RSA is 0x10001. Moreover, For reference, E, G, a, b, q and
n are defined below:
7. Performance evaluation
• E = secp256k1 elliptic curve
In this section, we first compare our scheme with related • G = (0x79BE 667EF9 DCBBAC 55A062 95CE87 0B0702
schemes and then we evaluate the performance overheads of 9BFCDB 2DCE28 D959F2 815B16 F81798, 0x483a da7726
BTNC including the initialization phase and the trusted network a3c465 5da4fb fc0e11 08a8fd 17b448 a68554 199c47 d08ffb
connect phase. 10d4b8)
• a = 00000000 00000000 00000000 00000000 00000000
7.1. Comparison 00000000 00000000 00000000
• b = 00000000 00000000 00000000 00000000 00000000
We compare our scheme with D–H PN [41] and 00000000 00000000 00000007
√ Twin D–H [44]. • q = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
Table 1 shows the comparison results, where ‘‘ ’’ means satisfied
and ‘‘×’’ means dissatisfied. FFFFFFFE FFFFFC2F
From Table 1, it is obvious that D–H PN protocol and Twin D– • n = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6
H protocol cannot provide distributed network access framework AF48A03B BFD25E8C D0364141
and D–H PN protocol is unable to resist platform replacement In our experiment, OpenSSL 1.0.1i is ported to perform the
attack. Our scheme BTNC, which satisfies all the required proper- cryptographic operations such as encryption and signature based
ties, can be applied to provide user authentication, platform attes- on the elliptic curve, secp256k1. From the result, we find that
tation and resist platform replacement attack in the distributed the elapsed time of the registration process using RSA-1024 and
environment. ECC-256 encryption algorithms are obviously less than that us-
ing RSA-2048 encryption algorithm, but the difference between
7.2. Evaluation RSA-1024 and ECC-256 encryption algorithms is inconspicuous.
In order to select a more efficient encryption algorithm based
In this section, we mainly focus on the evaluation of computa- on IoT system, we decide to increase terminals to simulate the
tion overheads of our proposed scheme. The performance evalu- registration process of multi-devices under the IoT scenario.
ation consists of two parts including the initialization phase and From Fig. 7, with the increase of terminal devices in IoT, ECC-
the trusted network connect phase. The experiments are imple- 256 algorithm is more efficient, which takes less time compared
mented on a PC(CPU:Intel(R)Core(TM) i5-5300U CPU @ 2.30 GHz with RSA-1048 algorithm. As a result, ECC-256 is selected as
2.30 GHz, RAM:8G, OS:Windows 7) using Java SE 9 and Ubuntu the encryption algorithm for the initialization phase under IoT
18.04. environment.
Initialization phase. In the initialization phase of our scheme, As for ECDSA, the secp256k1 curve is used and all domain
a trusted terminal who wants to access network must make parameters over the finite field including group order n, gener-
connection with the trusted third party to register itself in the ator P and modulus q can be found above. The elapsed time is
blockchain. In this process, the trusted terminal should gener- measured by utilizing the System.currentTimeMillis() function of
ate the key pair, the final registration message and encrypt the Java. Fig. 8 shows the performance overhead caused by the key
messages. In Fig. 6, we adopt different encryption algorithms pair generation and the final registration message generation. The
 J. Zhang, Z. Wang, L. Shang et al. / Journal of Parallel and Distributed Computing 143 (2020) 1–16 11

Fig. 7. Computation overhead of multi-devices in different encryption algorithms.

Fig. 8. Performance overhead caused by the initialization phase.

average elapsed time of key pair generation is 6.26 ms while the xAB of a point on an elliptic curve, which is generated by ECDH
final registration message generation is 11.37 ms. process. And then it outputs the session key KssAB which is used
Trusted network connect phase. In the trusted network con- to encrypt messages. The input parameters of CheckHashPCR (.)
nect phase, preliminary steps of BTNC involve obtaining the trans- are terminal B’s last PCR value PCRBi−1 , terminal B’s current PCR
actions from the blockchain 0.04 ms and retrieving the ECDSA value PCRBi and its platform measurement value digestB while
signatures (r , s) stored in the transaction 0.08 ms. Overall, these the output is a boolean variable which is used to verify the
steps on average require 0.12 ms, which can be negligible for integrity of the terminal B’s platform. As for SignAIK (.) function,
the entire verification process. Then we evaluate the performance the input parameters are private attestation identity key KpriAIKA
overhead of the functions in the trusted network connect phase and measurement report MTQI , then it outputs a signature σAIKA
signed by KpriAIKA .
including Cre(.), KDF (.), SignAIK (.) and CheckHashPCR (.), which are
Fig. 9 shows the performance overhead caused by the func-
based on SHA256 hash function, secp256k1 curve and ECC-256
tions above. The generation of session key Kss is non-interactive
encryption algorithm.
as participants are not required to exchange information before
Here, function Cre(KpriA , TA , rB , sB ) → (KpritsA , KpubtsB ), func- deriving the shared secret, which takes a little time to perform
tion KDF (xAB ) → KssAB , function CheckHashPCR (PCRBi−1 , PCRBi , Cre(.) and KDF (.). The average elapsed time of Cre(.), KDF (.),
digestB ) → 0/1 and function SignAIK (KpriAIKA , MTQI ) → σAIK . SignAIK (.) and CheckHashPCR (.) respectively are 1.26 ms, 3.47 ms,
Particularly, we take terminal A as an example to introduce 28.36 ms and 17.64 ms. Here, because TPM_QUOTE_INFO that
the parameters of each function. As for Cre(.) function, the input contains platform measurement can only be signed inside the
parameters are private key KpriA , transaction ID number TA , ter- TPM by AIK , which takes much more time to invoke TPM_Quote()
minal B’s ECDSA signature (rB , sB ), Then Cre(.) function outputs compared with other functions. Aside from the security con-
transaction-specific private key KpritsA and transaction-specific siderations of TPM by utilizing AIK , our protocol is relatively
public key KpubtsB . As for KDF (.) function, it inputs the abscissa efficient.
12 J. Zhang, Z. Wang, L. Shang et al. / Journal of Parallel and Distributed Computing 143 (2020) 1–16

Fig. 9. Performance overhead caused by functions in our scheme.

Fig. 10. Performance overhead caused by the upload and download processes of the base/update transaction.

Fig. 11. Comparison between D–H PN and BTNC under authentication delay.
 J. Zhang, Z. Wang, L. Shang et al. / Journal of Parallel and Distributed Computing 143 (2020) 1–16 13

Table A.1

AA1, ARP, AA4 θBTNC .Ini [BTNC .Ini]T Receiv e(T , {Â, T̂ , {|MregisFin |}KpubT });
Send(T , {T̂ , Â, {|σT , MregisFin |}KpubA }). (1)

VER Honest(T̂ ) ∧ Verify(T , {MTQI } ∧ T̂ ̸ = Xˆ1 )

⊃ ∃X 1 .∃M .(Send(X 1 , M) ∧ Contains(M , {MregisFin , σAIKX 1 })
∧Contains(MregisFin , {|MTQI , rX 1 , sX 1 |}KpubAIK 1 ))
X
⊃ Has(X 1 , MregisFin ) ∧ Has(X 1 , KpubAIKX 1 ) ∧ Has(X 1 , KpubT ). (2)

ΓBTNC .Ini , (2) Has(X , MregisFin ) ∧ Has(X , KpubAIK 1 ) ∧ Has(X , KpubT ) ∧ ΓBTNC .Ini
1 1 1
X
⊃ X 1 = T ∨ X 1 = A. (3)

HON, (3) Honest(T̂ ) ∧ ΓBTNC .Ini ∧ ⋄Send(X , MregisFin )

1

∧Contains(MregisFin , {MTQI , σAIKX 1 , rX 1 , sX 1 })

⊃ Contains(MTQI , {|PCRX 1 , digestX , CTX 1 |}KpriAIK )
0 0 X1
⊃ Has(X 1 , MTQI ) ∧ Has(X , KpriAIKX 1 )
⊃ Has(X 1 , MregisFin ) ∧ HasAlone(A, KpriAIKA )
⊃ X 1 ̸= T ∧ X 1 = A. (4)

ΓBTNC .Ini , (4) Honest(T̂ ) ∧ ΓBTNC .Ini ∧ ⋄Has(A, KpriAIKA )

⊃ After(Send(A, {Â, T̂ , {|MregisFin |}KpubT })),
Receiv e(T , {Â, T̂ , {|MregisFin |}KpubT }). (5)

AA1, APR θBTNC .Ini [BTNC .Ini]P Send(P , {P̂ , Â, {MTQI , σAIKA }}). (6)

ΓBTNC .Ini Honest(P̂) ∧ ⋄Send(P , {P̂ , Â, {MTQI , σAIKA }}) ∧ Has(P , KpriAIKA )
⊃ ∃X 2 .∃M .Receiv e(X 2 , M) ∧ Contains(M , {MTQI , {|MTQI |}KpriAIK })
X2
⊃ Has(X 2 , σAIKX 2 ) ∧ Has(X 2 , MTQI ). (7)

θBTNC .Ini , (7) θBTNC .Ini ∧ Has(X 2 , σAIKX 2 ) ∧ Has(X 2 , MTQI ) ⊃ X 2 = P ∨ X 2 = A. (8)

θBTNC .Ini , (8) Honest(P̂) ∧ θBTNC .Ini ∧ Receiv e(X 2 , {MTQI , σAIK 2 })
X
⊃ Has(X 2 , MTQI ) ∧ ¬Has(X 2 , KpriAIKX 2 )
⊃ ¬HasAlone(X 2 , KpriAIKA )
⊃ X 2 ̸= T ∧ X 2 = A. (9)

ΓBTNC .Ini , (9) Honest(P̂) ∧ ΓBTNC .Ini ∧ ⋄Has(P , KpriAIKA ) ∧ Send(P , {P̂ , Â, {MTQI , σAIKA }})
⊃ After(Send(P , {P̂ , Â, {MTQI , σAIKA }})),
Receiv e(A, {P̂ , Â, {MTQI , σAIKA }}). (10)

(5), (10), ARP Fresh(A, KpriA )[BTNC .Ini]A Honest(T ) ∧ Honest(P)∃A.ActionsInOrder

Receiv e(A, {P̂ , Â, {MTQI , σAIKA }}),
Send(A, {Â, T̂ , {|MregisFin |}KpubT }). (11)
AA1, ARP θBTNC .Ini [BTNC .Ini]C Receiv e(C , {Â, Ĉ , {σT , MregisFin }}). (12)
HON, (12) Honest(Ĉ ) ∧ Receiv e(C , {Â, Ĉ , {MbtA }})
⊃ ∃X 3 .∃M .Send(X 3 , M) ∧ Contains(M , {MbtX 3 })
⊃ Has(X 3 , MbtX 3 ) ∧ Contains(MbtX 3 , MregisFin ) ∧ Contains(MregisFin , σT ) ∧ X 3 ̸= C
⊃ X 3 = A ∧ ⋄Has(A, MregisFin ) ∧ Contains(MregisFin , σT )
⊃ After(Receiv e(C , {Â, Ĉ , {MbtA }})), Send(A, {Â, Ĉ , {MbtA }}). (13)
θBTNC .Ini , (13) Has(A, KpriA ) ∧ Has(T , KpriT ) ∧ Honest(T )
⊃ After(Receiv e(A, {T̂ , Â, {|σT , MregisFin |}KpubA }))
⋄Send(T , {T̂ , Â, {|σT , MregisFin |}KpubA }). (14)

(11), (14) θBTNC .Ini [BTNC .Ini]T (ν KprT ) ⋄ Receiv e(T , {Â, T̂ , {|MregisFin |}KpubT })
⊃ Send(T , {T̂ , Â, {|σT , MregisFin |}KpubA }). (15)

(11), (13), (14), (15) φBTNC .Iniauth = Honest(P̂) ∧ Honest(T̂ ) ∧ Honest(Ĉ )Honest(Â) ⊃ ∃A.ActionsInorder(
Send(P , {P̂ , Â, {MTQI , σAIKA }}),
Receiv e(A, {P̂ , Â, {MTQI , σAIKA }}),
Send(A, {Â, T̂ , {|MregisFin |}KpubT }),
Receiv e(T , {Â, T̂ , {|MregisFin |}KpubT }),
Send(T , {T̂ , Â, {|σT , MregisFin |}KpubA }),
Receiv e(A, {T̂ , Â, {|σT , MregisFin |}KpubA }),
Send(A{Â, Ĉ , {MbtA }}),
Receiv e(C {Â, Ĉ , {MbtA }})).

Regarding the relevant operation of blockchain in practical and the gasPrice was set to 1 Gwei. In the practical application
application, we utilize the Ethereum official client software Geth scenario, not only the verification time of the block is critical,
but also the minimum gas value cost is reasonable. Here, the size
to operate a private network. Particularly, we calculate the com-
of the base transaction is 238 bytes while the size of the update
putational overhead of the upload and download processes of the
transaction is 494 bytes. Fig. 10 shows the performance overhead
base transaction and the update transaction. When we conducted caused by the upload and download processes of the base/update
the experiment on January 4th 2019, 1 ether = 134.33 USD transaction.
14 J. Zhang, Z. Wang, L. Shang et al. / Journal of Parallel and Distributed Computing 143 (2020) 1–16

Table B.1

DHOB1, DHOB2 ∃Z .Has(Z , UV − 1) ∧ Has(Z , UV − 2) ≡ Compute(Z , {UV − 1, UV − 2})

⊃ Has(Z , Hash(KssAB , NA , NB )) ≡ Compute(Z , Hash(KssAB , NA , NB ))
⊃ Has(Z , KssAB ) ∧ Has(Z , NA ) ∧ Has(Z , NB ) ≡ Compute(Z , KssAB )
⊃ Has(Z , {KpritsA , KpubtsB }) ∨ Has(Z , {KpritsB , KpubtsA })
≡ Compute(Z , {KpritsA , KpubtsB }) ∧ Compute(Z , {KpritsB , KpubtsA })
⊃ Has(Z , {KpriA , TA , rB , sB }) ∨ Has(Z , {KpriB , TB , rA , sA }). (16)

ΓBTNC .Tnc , (16) Honest(Â) ∧ Honest(B̂)

⊃ Has(Z , {KpriA , TA , rB , sB }) ∧ HasAlone(A, KpriA )
∨Has(Z , {KpriB , TB , rA , sA }) ∧ HasAlone(B, KpriB )
⊃ Z = A ∨ Z = B. (17)
REC, ARP, DHOB3 [(Ĉ , B̂, TB , rA , sA )]B Receiv e(B, {Ĉ , Â, {TA , rB , sB }})
⊃ Honest(Ĉ ) ∧ Has(B, {TB , rA , sA }). (18)

REC, ARP [(Â, B̂, TDA , IDA , IDB , NA )]B Receiv e(B, {Â, B̂, {TDA , TDB , IDA , NA }})
⊃ Has(B, NA ). (19)

ORIG, AA1 [(ν NB )]B Send(B, {B̂, Â, {TDB , TDA , IDB , NB }}) ∧ ⋄New(B, NB )
⊃ Has(B, NB ). (20)
DHOB4, (18), (19), (20) [(Â, B̂, TDA , IDA , IDB , NA ), (ν NB ), (Ĉ , B̂, TB , rA , sA )]B
Has(B, NA ) ∧ Has(B, NB ) ∧ Has(B, {TB , rA , sA })
≡ Compute(B, KpritsB ) ∧ Compute(B, KpubtsA )
supsetHas(B, KssAB ) ≡ Compute(B, Hash(KssAB,NA ,NB ,1 ))
∧Compute(B, Hash(KssAB,NA ,NB ,2 )) (21)

ARP, AA2 [< B̂, Â, {|TDB , TDA , IDB |}UV −2 >
(Â, B̂, {|TDA , TDB , IDA , {|MTQI |}KpriAIK , UV − 1, rA , sA |}UV −2 )
A
(Â, B̂, z)(z /{|TDA , TDB , IDA |}UV −2 )
< B̂, Â, {|TDB , TDA , IDB , {|MTQI |}KpriAIK , UV − 1, rB , sB |}UV −2 >]B
B
Send(B, {B̂, Â, {|TDB , TDA , IDB |}UV −2 })
Receiv e(B, {Â, B̂, {|MTQI , rA , sA , UV − 1, σAIKA |}UV −2 })
Receiv e(B, {Â, B̂, {|TDA , TDB , IDA |}UV −2 })
Send(B, {B̂, Â, {|MTQI , rB , sB , UV − 1, σAIKB |}UV −2 })
⊃ ∃Z .Receiv e(Z , {|TDB , TDA , IDB |}UV −2 )∧
Receiv e(Z , {|MTQI , rB , sB , UV − 1, σAIKB |}UV −2 )
⊃ Compute(Z , UV − 2) ∧ Compute(Z , UV − 1)∧
Send(Z , {|MTQI , rA , sA , UV − 1, σAIKA |}UV −2 )∧
Send(Z , {|TDB , TDA , IDB |}UV −2 ). (22)

DHOB5, (22) Compute(Z , {UV − 1, UV − 2}) ∧ Compute(Z , {KssAB , NA , NB , 1})

∧Compute(Z , {KssAB , NA , NB , 1})
⊃ Has(Z , KssAB ) ∧ Has(Z , NA ) ∧ Has(Z , NB )
⊃ Has(Z , {KpritsA , KpubtsB }) ∨ Has(Z , {KpritsB , KpubtsA }). (23)
ΓBTNC .Tnc , (23) Honest(B̂) ∧ Honest(Â)∧
Receiv e(B, {Â, B̂, {|MTQI , rA , sA , UV − 1, σAIKA |}UV −2 })
∧Send(B, {B̂, Â, {|MTQI , rB , sB , UV − 1, σAIKB |}UV −2 })
⊃ Z ̸= B ∧ Z = A. (24)

DHOB5, (23), (24) Honest(B̂) ∧ Honest(Â)

⊃ Has(A, {KpritsA , KpubtsB }) ∧ Has(A, NA ) ∧ Compute(A, Hash(KssAB , NA , NB ))
⊃ Has(A, UV − 1) ∧ Has(A, UV − 2) ∧ Has(A, KpriA ). (25)

(17), (20), (25) φBTNC .Tncsec = Honest(Â ∧ Honest(B̂)) ⊃ Has(Ẑ , UV − 1)∧

Has(Z , UV − 2) ⊃ Ẑ = Â ∨ Ẑ = B̂ ∧ Has(A, KpriA ) ∧ Has(B, KpriB ).

From Fig. 10, the average upload and download overhead cost Our scheme seems somehow less efficient than D–H PN, but only
of a base transaction are 0.05337 s and 0.00725 s respectively. our scheme achieves a much stronger requirement of decentral-
The average upload and download overhead cost of a update ization, which is fundamental for the verification of terminals
transaction is 0.05641 s and 0.01324 s respectively. The average in IoT. All these experiments imply that our scheme is efficient
gas consumption value of the base transaction and the update and can be used for real-world user authentication and platform
transaction are 137132.8 Gwei and 154453.76 Gwei respectively. attestation in IoT environment.
The results show that the upload and download processes of
8. Conclusion
transactions are efficient and the actual cost is acceptable in
practice, which has little influence on the process of BTNC.
In this paper, we have proposed BTNC, a novel trusted network
For further analysis of the performance, Fig. 11 shows a com- connection protocol based on blockchain in IoT. In our scheme,
parison of verification time between D–H PN and BTNC while the the terminals in the distributed system can complete mutual ver-
frequency of CPU is 2.30 GHz. In our evaluation, we instantiate ification in user authentication and platform attestation without
the D–H PN protocol and execute the experiment multiple times. trusted third party. Additionally, we have analyzed the security
The result shows that the average delay of D–H PN is about of our scheme based on PCL proof method and further analyzed
59.86 ms while the BTNC is about 94.19 ms. The overhead of three kinds of threat models, including unauthorized user, illegal
BTNC is slightly inferior to that of D–H PN protocol. It is widely platform and platform replacement attack. The results of anal-
accepted that security improvement comes with efficiency loss. ysis indicate that our scheme could discern unauthorized users,
 J. Zhang, Z. Wang, L. Shang et al. / Journal of Parallel and Distributed Computing 143 (2020) 1–16 15

detect illegal platforms and resist platform replacement attack. [16] Keke Gai, Yulu Wu, Liehuang Zhu, Lei Xu, Yan Zhang, Permissioned
Moreover, we have evaluated the performance of our scheme, blockchain and edge computing empowered privacy-preserving smart grid
which is efficient and feasible in practice. Different from existing networks, IEEE Internet Things J. (2019).
[17] Keke Gai, Yulu Wu, Liehuang Zhu, Zijian Zhang, Meikang Qiu, Differential
schemes, our scheme enhances security and feasibility of trusted
privacy-based blockchain for industrial internet of things, IEEE Trans. Ind.
network connection based on the blockchain in the distributed Inf. (2019).
environment. [18] Keke Gai, Liehuang Zhu, Meikang Qiu, Kai Xu, Kim-Kwang Raymond Choo,
Multi-access filtering for privacy-preserving fog computing, IEEE Trans.
Declaration of competing interest Cloud Comput. (2019).
[19] Qi Gao, Junwei Zhang, Jianfeng Ma, Chao Yang, Jingjing Guo, Yinbin Miao,
The authors declare that they have no known competing finan- LIP-PA: A logistics information privacy protection scheme with position
and attribute-based access control on mobile devices, Wirel. Commun.
cial interests or personal relationships that could have appeared
Mobile Comput. 2018 (2018).
to influence the work reported in this paper. [20] David Grawrock, TCG specification architecture overview revision 1.4,
2007.
Acknowledgment [21] Darrel Hankerson, Alfred J. Menezes, Scott Vanstone, Guide to elliptic curve
cryptography, Comput. Rev. 46 (1) (2005) 13.
This work was supported by the National Natural Science [22] Thomas Hardjono, Ned Smith, Cloud-based commissioning of constrained
Foundation of China (Grant Nos. 61872283, U1764263, 61702105, devices using permissioned blockchains, in: Proceedings of the 2nd
U1804263, U1708262). ACM International Workshop on IoT Privacy, Trust, and Security, 2016,
pp. 29–36.
[23] Denise Helfrich, Jason Frazier, Lou Ronnau, Paul Forbes, Cisco Network
Appendix A. Proof of the authentication for TDA of BTNC.Ini Admission Control, Volume I: NAC Framework Architecture and Design,
Pearson Education, 2006.
See Table A.1. [24] Yaxian Ji, Junwei Zhang, Jianfeng Ma, Chao Yang, Xin Yao, BMPLS:
Blockchain-based multi-level privacy-preserving location sharing scheme
Appendix B. Proof of the secrecy for TDA of BTNC.Tnc for telecare medical information systems, J. Med. Syst. 42 (8) (2018) 147.
[25] Jin H. Jo, Zachary Rose, Jamie Cross, Evan Daebel, Andrew Verderber,
John C. Kostelnick, Application of airborne lidar data and geographic
See Table B.1.
information systems (GIS) to develop a distributed generation system for
the town of normal, IL, AIMS Energy 3 (2015) 173–183.
References [26] Don Johnson, Alfred Menezes, Scott Vanstone, The elliptic curve digital
signature algorithm (ECDSA), Int. J. Inf. Secur. 1 (1) (2001) 36–63.
[1] Jawad Ali, Toqeer Ali, Yazed Alsaawy, Ahmad Shahrafidz Khalid, Shahrul- [27] Yang Liu, Zhuo Ma, Ximeng Liu, Siqi Ma, Kui Ren, Privacy-preserving object
niza Musa, Blockchain-based smart-IoT trust zone measurement archi- detection for medical images with faster R-CNN, IEEE Trans. Inf. Forensics
tecture, in: Proceedings of the International Conference on Omni-Layer Secur. (2019).
Intelligent Systems, 2019, pp. 152–157. [28] Zhuo Ma, Yang Liu, Ximeng Liu, Jianfeng Ma, Feifei Li, Privacy-preserving
[2] William L Anderson, Walter Block, Thomas J DiLorenzo, Ilana Mercer, et al., outsourced speech recognition for smart IoT devices, IEEE Internet Things
The microsoft corporation in collision with antitrust law, J. Soc. Political J. (2019).
Econ. Stud. 26 (1) (2001) 287. [29] Zhuo Ma, Yang Liu, Ximeng Liu, Jianfeng Ma, Kui Ren, Lightweight privacy-
[3] Sundeep Bajikar, Trusted Platform Module (TPM) based Security on Note- preserving ensemble classification for face recognition, IEEE Internet Things
book PCS-White Paper, Mobile Platforms Group Intel Corporation, 2002, J. (2019).
pp. 1–20.
[30] Zhuo Ma, Yilong Yang, Ximeng Liu, Yang Liu, Siqi Ma, Kui Ren, Chang Yao,
[4] Debasis Bandyopadhyay, Jaydip Sen, Internet of things: Applications and
Emir-auth: Eye-movement and iris based portable remote authentication
challenges in technology and standardization, Wirel. Pers. Commun. 58 (1)
for smart grid, IEEE Trans. Ind. Inf. (2019).
(2011) 49–69.
[31] Zhuo Ma, Tian Zhang, Ximeng Liu, Xinghua Li, Kui Ren, Real-time privacy-
[5] Fenye Bao, Ray Chen, Trust management for the internet of things and its
preserving data release over vehicle trajectory, IEEE Trans. Veh. Technol.
application to service composition, in: 2012 IEEE International Symposium
68 (8) (2019) 8091–8102.
on a World of Wireless, Mobile and Multimedia Networks (WoWMoM),
[32] Rwan Mahmoud, Tasneem Yousuf, Fadi Aloul, Imran Zualkernan, Internet
IEEE, 2012, pp. 1–6.
of things (IoT) security: Current status, challenges and prospective mea-
[6] Li Da Xu, Wu He, Shancang Li, Internet of things in industries: A survey,
sures, in: 2015 10th International Conference for Internet Technology and
IEEE Trans. Ind. Inform. 10 (4) (2014) 2233–2243.
Secured Transactions (ICITST), IEEE, 2015, pp. 336–341.
[7] Lanjun Dang, Weidong Kou, Hui Li, Junwei Zhang, Xuefei Cao, Bin Zhao, Kai
[33] Patrick McCorry, Siamak F Shahandashti, Dylan Clarke, Feng Hao, Authenti-
Fan, Efficient id-based registration protocol featured with user anonymity
cated key exchange over bitcoin, in: International Conference on Research
in mobile ip networks, 9 (2) (2010) 594–604.
in Security Standardisation, Springer, 2015, pp. 3–20.
[8] Anupam Datta, Security analysis of network protocols: compositional
[34] Chris Mitchell, Trusted Computing, Vol. 6, Iet, 2005.
reasoning and complexity-theoretic foundations, Stanford University, 2005.
[9] Mohsen Dorodchi, Maryam Abedi, Bojan Cukic, Trust-based development [35] Satoshi Nakamoto, et al., Bitcoin: A Peer-to-Peer Electronic Cash System,
framework for distributed systems and IoT, in: 2016 IEEE 40th Annual Working Paper, 2008.
Computer Software and Applications Conference (COMPSAC), Vol. 2, IEEE, [36] Arvind Narayanan, Joseph Bonneau, Edward Felten, Andrew Miller, Steven
2016, pp. 437–442. Goldfeder, Bitcoin and Cryptocurrency Technologies: A Comprehensive
[10] Keke Gai, Kim-Kwang Raymond Choo, Meikang Qiu, Liehuang Zhu, Privacy- Introduction, Princeton University Press, 2016.
preserving content-oriented wireless communication in internet-of-things, [37] Jaemin Park, Kwangjo Kim, TM-Coin: Trustworthy management of TCB
IEEE Internet Things J. 5 (4) (2018) 3059–3067. measurements in IoT, in: 2017 IEEE International Conference on Pervasive
[11] Keke Gai, Kim-Kwang Raymond Choo, Liehuang Zhu, Blockchain-enabled Computing and Communications Workshops (PerCom Workshops), IEEE,
reengineering of cloud datacenters, IEEE Cloud Comput. 5 (6) (2018) 21–25. 2017, pp. 654–659.
[12] Keke Gai, Meikang Qiu, Blend arithmetic operations on tensor-based fully [38] Rudiger Schollmeier, A definition of peer-to-peer networking for the clas-
homomorphic encryption over real numbers, IEEE Trans. Ind. Inf. 14 (8) sification of peer-to-peer architectures and applications, in: Proceedings
(2017) 3590–3598. First International Conference on Peer-To-Peer Computing, IEEE, 2001,
[13] Keke Gai, Meikang Qiu, Zhong Ming, Hui Zhao, Longfei Qiu, Spoofing- pp. 101–102.
jamming attack strategy using optimal power distributions in wireless [39] Lu Tan, Neng Wang, Future internet: The internet of things, in: 2010 3rd
smart grid networks, IEEE Trans. Smart Grid 8 (5) (2017) 2431–2439. International Conference on Advanced Computer Theory and Engineering
[14] Keke Gai, Meikang Qiu, Xiaotong Sun, A survey on FinTech, J. Netw. (ICACTE), Vol. 5, IEEE, 2010, pp. V5–376.
Comput. Appl. 103 (2018) 262–273. [40] TCG Trusted Network Connect, TNC Architecture for Interoperability,
[15] Keke Gai, Yulu Wu, Liehuang Zhu, Meikang Qiu, Meng Shen, Privacy- Specification Version, 1, 2009.
preserving energy trading using consortium blockchain in smart grid, IEEE [41] TCGTNC Workgroup. TNC IF-T: Protocol Bindings for Tunneled EAP
Trans. Ind. Inf. (2019). Methods. Specification Version, 1.
16 J. Zhang, Z. Wang, L. Shang et al. / Journal of Parallel and Distributed Computing 143 (2020) 1–16

[42] John R. Vollbrecht, Bernard Aboba, Larry J. Blunk, Henrik Levkowetz, James Lei Shang received his B.S. degree in Software en-
Carlson, Extensible authentication protocol (EAP), 2004. gineering from YunNan University, China, in 017. He
[43] Zhe Yang, Kan Yang, Lei Lei, Kan Zheng, Victor C.M. Leung, Blockchain- is currently a master degree candidate in Department
based decentralized trust management in vehicular networks, IEEE Internet of Cyber Engineering, Xidian University in China. His
Things J. 6 (2) (2019) 1495–1505. research fields include cryptography and information
[44] JunWei Zhang, JianFeng Ma, SangJae Moon, Universally composable secure security, especially trust computing.
TNC model and EAP-TNC protocol in IF-T, Sci. China Inf. Sci. 53 (3) (2010)
465–482.
[45] Liehuang Zhu, Yulu Wu, Keke Gai, Kim-Kwang Raymond Choo, Controllable
and trustworthy blockchain-based cloud data management, Future Gener.
Comput. Syst. 91 (2019) 527–535.

Di Lu received the B.S., M.S., and Ph.D. degrees from

Xidian University, China, in 006, 009, and 014, all
Junwei Zhang received his B.S., M.S. and Ph.D. de-
in Computer Science and Technology. He is currently
grees in Computer Science and Technology from Xidian
a Lecturer with the School of Computer Science and
University, China, in 004, 006 and 010, respectively.
Technology, Xidian University. His research interests
He is currently an associate professor in Depart-
include cloud computing, system, and network security.
ment of Cyber Engineering, Xidian University in China.
His research fields include cryptography and informa-
tion security, especially in provable security and data
location security in cloud computing.

Jianfeng Ma received the Ph.D. degree from Xidian

Zhuzhu Wang received her B.S. and M.S. degrees in University, Xi’an, China, in 1995. He has been a pro-
Computer Science and Technology from Xidian Univer- fessor in the Department of Computer Science and
sity. She is currently a Ph.D. Candidate in the School Technology, Xidian University since 1998. He was the
of Cyber Engineering, Xidian University. Her research special engaged professor of the Yangtze River scholar
interests cover secret sharing and deep learning neural in China. His research interests include cryptology,
network in cyber security. network security, data security and so on.