Lightweight Mutual Authentication for Healthcare IoT

Abstract

“Smart medical” applications refer to the fusion of technology and medicine that connects all linked sensor equipment with the patients, including those that measure physiological signals, such as blood pressure, pulse, and ECG. In addition, these physiological signal data are highly private and should be safely protected. It takes much longer to complete authentication processes in the traditional way, either based on public key infrastructure or attribute-based encryption, which is a burden for IoT devices. Hence, on the basis of attribute-based encryption, we propose lightweight authentication to shorten the time spent on authentication. Moreover, we use the patients’ data and timestamps as seeds to generate random numbers for authentication. The experiments show that the lightweight authentication using Xeon E3-1230 computer is about 4.45 times faster than complete authentication and 5.8 times faster than complete authentication when using Raspberry Pi. Our proposal significantly improves the disadvantages of IoT devices that lack computing power.

1. Introduction

In recent years, with the advancement of information technology and the popularization of the Internet, human life has become more and more convenient and computers can easily communicate with each other through the Internet. In the early days, all messages were delivered in plaintext, which was easy for those who wanted to directly retrieve the messages and forge and modify them to achieve specific purposes. Consequently, the issue of information security has become more and more important. As a result, cryptography [1,2,3,4] plays a key role. Many scholars have proposed various encryption methods to ensure information security and that messages are safe during network communication and data exchange. However, the security of the only message is still not enough. Nowadays, the transmission of messages on the Internet requires a more effective authentication mechanism to ensure the mutual trust between sender and receiver, especially in the field of medical information where patient data has an even higher concern of privacy. For example, when doctors request patient physiological data to check from the hospital server under a complete authentication mechanism, the doctor’s identity may be forged by other interested parties to verify the legitimacy of each other through authentication.

With the development of the Internet of Things [5,6,7,8,9,10,11], 5G, and AI (artificial intelligence) technology, there have been billions of interconnected devices so far and the authentication between devices has become a new security issue [12,13,14,15,16,17,18]. According to the definition of eHealth by the World Health Organization (WHO) [19], it is mainly in the application of information technology in the medical and health fields, including medical care, disease management, public health, medical education, research, etc. Hospitals are gradually adapted to transform and deploy these applications, which can be roughly divided into three categories: mobile medical (M-health), medical information system (health IT), and wearable devices (telehealth and telemedicine). This study takes the “smart ward” (Figure 1) as an example. In the layout of the ward, all connected sensing devices are paired with patients [5,8] for real-time detection, which includes measurement of the patient’s heart beat rate, blood pressure, pulse, electrocardiography (ECG), and other related physiological signals. These data are highly private, so if there is an inadequate encryption and authentication mechanism, these data may be leaked out or used improperly.

The epidemic of COVID-19 has prompted the development of telemedicine. The physiological data of patients is usually collected using IoT devices with low computing power. However, the traditional authentication method, either based on public key infrastructure or attribute-based encryption, is a burden for IoT devices. This research includes two authentication methods. One is complete authentication, which uses attribute encryption as the main architecture. Since complete authentication is too time-consuming to be built into IoT devices with limited computing power, we propose a lightweight authentication method as the alternative authentication method without losing security requirements to make overall authentication more efficient.

2. Preliminary Research

2.1. Cryptography

Cryptography is a method of protecting information and communications through the use of codes so that only those for whom the information is intended can read and process it.

In modern cryptography, security concerns itself with the following four objectives:

• Confidentiality: a third party should not obtain information content, only the sender and the receiver.
• Integrity: the information cannot be altered in storage or transit between sender and intended receiver without the alteration being detected.
• Authentication: the sender and receiver can confirm each other’s identity and the origin and destination of the information [8,10,11,12,13,14,15,16,17,18,20,21].
• Non-repudiation: the sender of the information cannot later deny their intentions in the creation or transmission of the information.

At present, the mainstream encryption methods include “symmetric key encryption”, “asymmetric key encryption”, “identity-based encryption”, and “attribute-based encryption”.

2.2. Bilinear Pairing

In recent years, bilinear pairing has widely been used in cryptography. It refers to the corresponding linear mapping function relationship between two cyclic groups, and the set formed by all points on the elliptic curve forms the group relationship in algebraic geometry. Therefore, the operation of bilinear pairing can be applied to the elliptic curve.

A bilinear mapping $e:G\times G\to G_1$ satisfies the followings properties for which $P$ is a generator of $G$.

Bilinearity: $e\left(aP, bQ\right)=e{\left(P,Q\right)}^{ab}$, $\forall P,Q\in G_1,a,b\in Z_p^{*}$.

Non-degeneracy: If $P$ is the generator in $G_1$, then $e\left(P, P\right)$ is also the generator of $G_2$, also $e\left(P, P\right)\ne 1$.

Computability: There exists an efficient algorithm to compute $e\left(P, Q\right), \forall P, Q \in G$.

Access Structure:

Let $P=\left\{P_1,\dots ,P_n\right\}$ be a set of parties; a collection $A\subseteq 2^{\left\{P_1,\dots ,P_n\right\}}$ is monotone. $\forall B, C : if B\in A and B\subseteq C then C\in A$. An access structure (or monotone access structure) is a collection (or monotone collection) A of non-empty subsets of $\left\{P_1,\dots , P_n\right\}$, i.e., $A\subseteq 2^{\left\{P_1,\dots , P_n\right\}}\backslash \{\varnothing \}$. The sets in A are called the authorized sets and the sets not in $A$ are called the unauthorized sets.

Access structure is usually used in attribute encryption. The role in the set is defined as an attribute. In our research, only the monotonic attribute structure is considered. We are only concerned with whether logic gate (AND, OR) or threshold can be constructed. As shown in Figure 2, the attributes held by Doctor A are {‘D.ID = 100572’, ‘surgery’, ‘C.R’, ‘Op.x’, ‘Op.y’}, which satisfies the formulated access structure. Doctor B holds {‘surgery’, ‘resident’, ‘Op.z’, ‘Op.c’} and other attributes but lacks part of the attribute ‘D.ID = 100,572’, and Doctor B only holds the identity of ‘resident’, which cannot satisfy the ‘C.R’ attribute, and {‘Op.z’, ‘Op.c’} does not satisfy the threshold condition. Similarly, Nurses A hold attributes, such as {‘surgery’, ‘nurse’, ‘Op.x’, ‘Op.o’}, but cannot satisfy the ‘C.R’ attribute because of the identity of ‘nurse’, and attributes {‘Op.x’, ‘Op.o’} do not satisfy the threshold conditions. Therefore, if attribute encryption is used, the access structure in Figure 2 is not satisfied, that is, it cannot be decrypted.

2.3. Random Number

In recent years, random numbers are usually used in symmetric and asymmetric encryption to generate keys through the random number generator (RNG). The RNG is divided into two kinds, one is a true random number generator (TRNG). The other is a pseudo-random number generator (PRNG). The following briefly describes the difference between TRNG and PRNG.

True random numbers [22,23,24,25,26] satisfy two conditions: randomness and unpredictability. The randomness refers to the randomness in statistical significance, that is, uncertainty. Unpredictability means that the value of the next random number cannot be guessed from the previous random number sequence. Most of the true random numbers need to rely on sophisticated instruments to generate, such as collecting electromagnetic signals in outer space or RLC oscillation circuits, and so on. The disadvantage is that the technical requirements are relatively high and the cost is very expensive. Therefore, in practical applications, pseudo-random numbers are more widely used.

The so-called pseudo-random number is generated by a function (e.g., linear congruence function). These sequences seem to be random but they are generated through a certain repeatable calculation math method. The sequence can be calculated through the function, which only satisfies the statistical characteristics of random numbers. However, this also means that if the seed is known, the same random number can be produced through the function, so it cannot meet the unpredictability in the condition of a truly random number.

For this type of PRNG, if the seed is unknown, the next output cannot be predicted even if the previous random number is known. This is forward unpredictability.

Each instance of backward unpredictability is also to be achieved. That is, the original seed value cannot be calculated through the known random number.

According to the National Institute of Standards and Technology (NIST), the detection of 15 random numbers (arbitrary length) provided in SP800-22 rev1a can detect whether the random degree of the sequence is high enough to be difficult to guess.

2.4. Public Key Infrastructure (PKI)

Public key infrastructure (PKI) [27,28] is the framework of encryption and cybersecurity that protects communications between the server (website) and the client (the users). It is a kind of asymmetric encryption, its infrastructure includes entities (Entity), certification authority (CA), register authority (RA), and verification authority (VA), as shown in Figure 3.

The certificate is a certificate application that is managed and audited by the registration center. The certificate application is sent to the certificate center and issued after processing. In the process of user credentials, the first step is to query the status of credentials from the certificate revocation list (CRL) to determine whether the credentials are still trusted or discarded for some reason. At present, Online Certificate Status Protocol (OCSP) has become mainstream for checking the credential status instead of the certificate revocation list. The certificate is checked for the correctness of the chain and itself. PKI is currently used in the field of network services and browser verification, digital signatures, data encryption, credit card transactions, etc.

2.5. Attribute-Based Encryption

Attribute-based encryption [29,30,31] was proposed by Sahai et al. in 1995 and its earliest model concept can be traced back to identity-based encryption (IBE) which was proposed by Shamir in 1984 [32]. IBE algorithm is also a kind of public-key encryption and solves the condition that a PKI and certificate management center (CA) need to be used in public-key encryption. In IBE, users can generate individual public keys based on their unique information, such as ID number, email account, mobile phone number, etc. However, whether it is IBE or PKI, the encryption of both is one-to-one encryption. That is to say, each transmission of encrypted data corresponds to a decryption key. When the data are encrypted and transmitted to others, the data must be repeatedly encrypted according to the attributes of each recipient or the public key. If there are N recipients, it must be encrypted N times. As a result, the number of keys is too large, which makes management difficult and less flexible.

However, Sahai et al. proposed fuzzy identity-based encryption [29] and this model is also considered to be the predecessor of ABE. The user defines an access policy with a threshold value when encrypting data and the encrypted ciphertext is paired with a specific attribute. When decrypting, the receiver’s compliance with the access rules is determined, according to the attribute held by the receiver, and the receiver can decrypt the data if it matches. So, ABE can be regarded as an extension of IBE. IBE is represented by identity and ABE is represented by a collection of attributes. Therefore, the emergence of ABE solves the shortcomings of IBE one-to-one encryption and the difficulty of key management. The difference between ABE and the traditional encryption system is that ABE can be one-to-many encryption. When encrypting, the access rules are added to the receiver’s attributes so that the receiver can receive it according to the possession of its private key. If the attribute set conforms to its access rules it can be decrypted. It is based on this characteristic that ABE is more flexible than IBE and PKI and it also reduces the management complexity of users or managers.

At present, attribute encryption [33] is mainly divided into ciphertext policy attribute-based encryption (CP-ABE) [34,35,36,37,38,39,40,41,42,43,44] and key policy attribute-based encryption (KP-ABE) [45,46,47,48]. The difference between the two ABE systems is that one is to pair the access rules with the private key and the other is to encrypt the access rules and messages into ciphertext.

2.5.1. Key Policy Attribute-Based Encryption (KP-ABE)

KP-ABE was proposed by Goyal et al. [30]. In this encryption system, the user sets the attributes and encrypts the plaintext to pair them. That is to say, the ciphertext is linked with a set of attributes, and the access policy is linked with the private key. The receiver decides whether to decrypt it according to the access policy paired with a private key that satisfies the attribute, as shown in Figure 4.

The algorithm is based on symmetric bilinear pairing, $e:G_0\times G_0\to G_1$, where the order of $G_0$ is a prime number $p$, g is a generator of $G_0$, and a hash function $H={\left\{0,1\right\}}^{*}\to G_0$. This encryption method is mainly divided into four stages: setup, key generation, encryption, and decryption.

Setup: Define the universe of attributes $U=\left\{1,2,\dots ,n\right\}$, Now, choose a value $t_i$ for each attribute i in $U$ where $t_i\in Z_p^{*}$, and choose a $y\in Z_p$. The public key is $PK=\left(T_1=g^{t1},\dots T_n=g^{tn},Y=e{\left(g,g\right)}^y\right)$ and the master key is $MK=(t_1,\dots t_n,y$).

Key generation: The algorithm outputs a key that enables the user to decrypt a message encrypted under a set of attributes γ if and only if T (γ) = 1. The algorithm proceeds as follows. First, choose a polynomial $p_x$ for each node $x$ (including the leaves) in the tree T. These polynomials are chosen in a top-down manner, starting from the root node $r$. For each node $x$ in the tree, set the degree $d_x$ of the polynomial $p_x$ to be one less than the threshold value $t_x$ of that node, that is, $p_x$ = $t_x-1$. Now, for the root node $r$, set $p_r$(0) = y. For any other node $x$, set $p_r\left(0\right)=p_{parrent\left(x\right)}\left(index\left(x\right)\right)$ and choose $d_x$ other points randomly to completely define $p_x$. Once the polynomials have been decided, for each leaf node $x$, give the following secret value to the user: $D_x=g^{\frac{p_x\left(0\right)}{t_{att\left(x\right)}}} for x\in S$.

The set of above secret values is the decryption $D$.

Encryption($M,\gamma ,$ PK): To encrypt message $M$, elect a secret $s$ where $s\in Z_p$, and encrypt an attribute set γ. The ciphertext is $E=(\gamma , E^{\prime }=M{Y}^S,{\left\{E_i=T_i^S\right\}}_{i\in \gamma })$.

Decryption($E,D$): First, define a recursive algorithm DecryptNode($E,D$, $x$) for each leaf node $x$ in the access tree:

$$\mathrm{DecryptNode}(E,D,x)=\left\{e\left(D_x,E_i\right)=e\left(g^{\frac{p_x\left(0\right)}{t_i}},g^{s{t}_i}\right)=e{\left(g,g\right)}^{s{p}_x\left(0\right)} for i=att\left(x\right)\in \gamma \right\}$$

Since $p_x\left(0\right)=p_{parrent\left(x\right)}\left(index\left(x\right)\right)$, for each node $x$, $e{\left(g,g\right)}^{s{p}_x\left(0\right)}$ is obtained by interpolation and the calculation is repeated until the root node. Finally, the root node R can be obtained:

$$R=\left\{e\left(D_R,E_i\right)=e\left(g^{\frac{p_R\left(0\right)}{t_i}},g^{s{t}_i}\right)=e{\left(g,g\right)}^{s{p}_R\left(0\right)}=e{\left(g,g\right)}^{sy}=Y^s\right\}$$

Decryption algorithm simply divides out $Y^s$ and recovers the message $M$.

2.5.2. Ciphertext Policy Attribute-Based Encryption (CP-ABE)

CP-ABE which is the exact opposite of KP-ABE, was proposed by Bethencourt et al. [31]. CP-ABE means linking the access policy with the ciphertext and the private key is linked with a set of attributes. For example, the maker can customize its attribute strategy or can add the receiver’s attribute to its attribute strategy. This is “authorization”. When the receiver receives it, he can decrypt it according to whether the set of attributes possessed by his private key conforms and if it conforms to the access rules of the ciphertext pairing, as shown in Figure 5.

The algorithm is based on symmetric bilinear pairing, $e:G_0\times G_0\to G_1$, where the order of $G_0$ is a prime number $p$, g is a generator of $G_0$, and a hash function $H={\left\{0,1\right\}}^{*}\to G_0$. This encryption method is mainly divided into four stages: setup, key generation, encryption, and decryption.

Setup: The setup algorithm chooses a bilinear group $G_0$ of prime order p with generator $g$. Next, it chooses two random exponents $\alpha ,\beta \in Z_p$. The public key is published as $PK=(G_1,g,h=g^{\beta },f=g^{\frac{1}{\beta }},e{\left(g,g\right)}^{\alpha })$ and the master key as $MK=\left(\beta ,g^{\alpha }\right)$.

Key generation ($MK, S$): The key generation algorithm takes a set of attributes $S$ as an input and outputs a key that identifies with that set. The algorithm first chooses a random $r\in Z_p$ and then a random $r_j\in Z_p$ for each attribute $j\in S$. Then, it computes the key as $SK=(D=g^{\frac{\alpha +r}{\beta }} \forall j\in S:D_j=g^{r}H{\left(j\right)}^{r_j},{D^{\prime }}_j=g^{r_j}).$

Encryption (PK, $M,\tau$): This algorithm encrypts a message $M$ under the tree access structure $\tau$. The algorithm first chooses a polynomial $p_x$ for each node x (including the leaves) in the tree $\tau$. These polynomials are chosen in a top-down manner, starting from the root node R. For each node x in the tree, set the degree dx of the polynomial $p_x$ to be one less than the threshold value $t_x$ of that node, that is, $t_R-1$. Starting with the root node R, the algorithm chooses a random $s\in Z_p$ and sets $p_R\left(0\right)=s$. Then, it randomly chooses $t_R$ other points of the polynomial $p_R$ to completely define it. For any other node x, it sets $p_x\left(0\right)=p_{parrent\left(x\right)}\left(index\left(x\right)\right)$ and chooses $t_x-1$ other points randomly to completely define $p_x$. Let $X$ be the set of leaf nodes in $\tau$. The ciphertext is then constructed by giving the tree access structure $\tau$ and computing:

$$CT=(\tau ,\tilde{C}=Me{\left(g,g\right)}^{\alpha s},C=h^s \forall x\in X:C_x=g^{p_x\left(0\right)},{C^{\prime }}_x=H{\left(att\left(x\right)\right)}^{p_x\left(0\right)})$$

Decryption (CT, SK): We specify our decryption procedure as a recursive algorithm. For ease of exposition, we present the simplest form of the decryption algorithm and discuss potential performance improvements in the next subsection.

First, define a recursive algorithm DecryptNode(CT, SK, $x$) taken as input, a ciphertext $CT=(\tau ,\tilde{C},C, \forall x\in X:C_x,{C^{\prime }}_x)$, a private key SK, which is associated with a set S of attributes, and a node x from $\tau$. If the node x is a leaf node, then we let $i=\left(att\left(x\right)\right)$ and define it as follows: If $i\in S$, then:

$$\begin{array}{cc}DecrypNode(CT ,SK, x)& =\frac{e\left(D_i, C_x\right)}{e\left({D^{\prime }}_i, {C^{\prime }}_x\right)}=\frac{e\left(g^{r}H{\left(i\right)}^{r_i}, g^{p_x\left(0\right)}\right)}{e\left(g^{r_i}, H{\left(i\right)}^{p_x\left(0\right)}\right)}=\frac{e\left(g^{r}H{\left(i\right)}^{r_i}, g^{p_x\left(0\right)}\right)}{e\left(g^{p_x\left(0\right)}, H{\left(i\right)}^{r_i}\right)}=\frac{e{\left(g^r{g}^{p_x\left(0\right)}, g^{p_x\left(0\right)}\right)}^{r{p}_x\left(0\right)}}{e({H\left(i\right)}^{r_i}, {H\left(i\right)}^{r_i})}\\ & =\frac{e\left(g^r{g}^{p_x\left(0\right)}, g^{p_x\left(0\right)}\right)}{1}=e(g, g)\hfill \end{array}$$

(1)

If $i\notin S:$

$$DecrypNode\left(CT, SK, x\right)=\perp otherwise$$

We now consider the recursive case when x is a non-leaf node. For all nodes $z$ that are children of x, it calls DecryptNode(CT, SK, $z$) and stores the output as $F_z$. Let $S_x$ be an arbitrary $t_x$-sized set of child nodes $z$ such that $F_z\ne \perp$. If no such set exists, then the node was not satisfied, so $DecrypNode\left(CT,SK,z\right)=\perp otherwise$:

$$\begin{array}{cc}{F}_z& ={\displaystyle {\displaystyle \prod }_{z\in S_x}^{}}{F}_z{}^{{\Delta }_{i,{S^{\prime }}_x}\left(0\right)}, where i=index\left(z\right),{S^{\prime }}_x=\left\{index\left(z\right):z\in S_x\right\}\hfill \\ & =\prod _{z\in S_x}^{}{(e{(g,g)}^{r{p}_z(0)})}^{{\Delta }_{i,{S^{\prime }}_x}\left(0\right)} (\mathrm{by} \mathrm{construction})\hfill \\ & =\prod _{z\in S_x}^{}{\left(e{\left(g,g\right)}^{p_{parrent\left(z\right)}\left(index\left(z\right)\right)}\right)}^{{\Delta }_{i,{S^{\prime }}_x}\left(0\right)}=\prod _{z\in S_x}^{}{\left(e{\left(g,g\right)}^{r{p}_x\left(i\right)}\right)}^{{\Delta }_{i,{S^{\prime }}_x}\left(0\right)}=e{\left(g,g\right)}^{r{p}_x\left(0\right)}\hfill \end{array}$$

(Using polynomial interpolation) and return the result.

The algorithm begins by simply calling the function on the root node R of the tree $\tau$. If the tree is satisfied by $S$, we set $DecrypNode\left(CT,SK,x\right)=e{\left(g,g\right)}^{r{p}_R\left(0\right)}=e{\left(g,g\right)}^{rs}$,

$$M=\frac{\tilde{C}}{e\left(C,D\right)/e{\left(g,g\right)}^{rs}}=\frac{\tilde{C}}{e(h^s,g^{\frac{\alpha +r}{\beta }})/e{\left(g,g\right)}^{rs}}=\frac{\tilde{C}}{e(g^{\beta s},g^{\frac{\alpha +r}{\beta }})/e{\left(g,g\right)}^{rs}}=\frac{\tilde{C}}{e{(g,g)}^{s\left(\alpha +r\right)}/e{(g,g)}^{rs}}=\frac{\tilde{C}}{e{(g,g)}^{\alpha s}}$$

(2)

3. Proposed Scheme

In this study, there are two types of authentications: complete authentication and lightweight authentication. For complete authentication, this study uses attribute-based encryption is the main framework. Nevertheless, complete authentication takes a long time, which is a burden for IoT devices. Therefore, we propose lightweight authentication instead. Firstly, we list the hardware and software of the proposed scheme. We used two different sets of device specifications: a server-level CPU used to simulate the hospital server and attribute authorization center and Raspberry Pi 3B+ used to simulate patients’ IoT devices. In order to implement the CP-ABE algorithm, it is necessary to install PBC (pairing-based cryptography) library (version:0.5.14, San Francisco, USA, https://crypto.stanford.edu/pbc), GMP library(version: 6.2.1, Boston, USA, https://gmplib.org), M4, bison, flex, OpenSSL (version: 1.1.1k, https://www.openssl.org), libbswcpabe (version: 0.9, San Francisco, USA, https://acsc.cs.utexas.edu/cpabe), cpabe (version: 0.11, San Francisco, USA, https://acsc.cs.utexas.edu/cpabe), and other packages to construct an experimental environment. Random number detection uses NIST STS (version: 2.1.2, Gaithersburg, USA, https://csrc.nist.gov/projects/random-bit-generation/documentation-and-software). The specification differences between the two hardware devices are shown in

Table 1. Hardware specifications.

	Server-Level CPU	IoT Devices
CPU	Intel(R) Xeon(R) CPU E3-1230 v3	ARM Cortex-A53
GPU	NVIDIA GT 630	Broadcom Video Core IV
RAM	12 GB	1 GB
HD	500 GB	32 GB
OS	Ubuntu 18.04.5LTS	Raspbian OS

.

The framework of the study is shown in Figure 6, and there are mainly four roles: attribute authorization center, authorizer, authorized person, and hospital server, as described in

Table 2. The role introduction.

Name	Explanation
Attribute authorization center	Manage the attribute set of the authorized person and assigns the attribute to the authorized person.
Authorizer	Patient, encrypt data and send it to the hospital server store
Authorized person	Doctor or nurse can access physiological data as the authorized person
Hospital server	Store data and provide access to doctors and nurses

.

Chuang et al. proposed an authentication mechanism that fixed the time range in two static authentications [15]. Continuous authentication can be used between devices in this time range. Based on this concept of authentication, we improved and named the two authentication stages complete authentication and lightweight authentication. The timeline of complete authentication and lightweight authentication is shown in Figure 7.

Complete authentication uses the CP-ABE algorithm, detailed in Section 3.1. Our proposed lightweight mutual authentication is described in Section 3.2. The physiological data and timestamps of patients are used as seeds to generate random numbers in lightweight mutual authentication. The notations and definitions used in complete authentication and lightweight authentication shown in

Table 3. The notations and definitions used in complete authentication.

Notation	Definition	Notation	Definition
$I{D}_p$	The identity of patient	$s{k}_p$	The secret value of patient
$I{D}_d$	The identity of doctor
$MK$	Master key	>>	A right shift operation
$PK$	Public key	$\oplus$	A bitwise exclusive-or operation
$SK$	Secret key	||	A concatenation operation
$e\left(g,g\right)$	bilinear pairing	$timestamp$	timestamp
$M$	plaintext	$CT$	ciphertext

and

Table 4. The notations and definitions used in lightweight authentication.

Notation	Definition	Notation	Definition
$I{D}_p$	The identity of patient	$M_1,M_2$	Hmac value
$I{D}_d$	The identity of doctor	$\oplus$	A bitwise exclusive-or operation
$P_1,P_2$	Intermediate variables by patient	||	A concatenation operation
$D_1,D_2$	Intermediate variables by doctor	$timestamp$	timestamp
$S_1,S_2,S_3,S_4$	Intermediate variables by hospital server	$HMA{C}_{s{k}_p},HMA{C}_{s{k}_d}$	Hash-based message authentication code function
$s{k}_p,s{k}_d$	The secret value	$h()$	Hash function
$X_1,Y_1, X_2,Y_2$	Authentication parameters	$r_1,r_2,r_3,r_4$	Random number by PRNG
$I{D}_p{C}_1$	ciphertext	Session key	Session key

.

We first describe the timing of complete authentication and lightweight authentication. For the first time, both parties (patients and hospital servers) complete the authentication; however, the time range set in our study is not fixed (as shown in Figure 7). When one party does not retain the data coming from the previous authentication (complete authentication or lightweight authentication), it is impossible to generate random numbers through the physiological data as seeds and, as a result, it is impossible to carry out lightweight authentication so that the other party is required to complete the authentication again. If both parties have the data stored from the previous authentication, the lightweight authentication proposed in this study can be used within the certification time.

3.1. Complete Authentication

In our complete authentication, we take the CP-ABE algorithm proposed by Bettencourt et al. [31] and add a timestamp. Let $M=(D_{1I{D}_{p1}}\left||\dots |\right|D_{1I{D}_{pi}}||timestam{p}_n)$ when the plaintext data are transmitted. The complete authentication proposed in this study is divided into five stages: system initial stage, patient registration stage, key generation stage, encryption stage, and decryption stage.

• System initial stage:

The attribute authorization center generates parameters, such as PK and SK.

• Patient registration stage:

When a patient is admitted to the hospital, first assign $I{D}_p$ to the patient, secretly decide on $s{k}_p$, and transmit them to the patient via a secure channel. Only the patient and the hospital server know $s{k}_p$ so that a third party has no right to obtain it.

Then, the attribute authorization center provides specific attribute characteristics according to the patient. For example, if a patient comes to the neurology wing of hospital A, the attribute authorization center can provide the patient with {“Hospital A”, “Neurology”, “Patient”, “Name”, “gender”, “age”...} and other attributes; if anyone needs to authorize the patient data to be viewed by other doctors or nurses, other people’s attributes can be added to the patient’s access policy to construct a new access rule so that when the other party receives encrypted data, it can be decrypted according to whether the attributes of the existing private key can match or not.

• Key generation stage:

During this stage, the attribute authorization center generates a private key (SK) for the patient, which is paired with the patient access rules. Before the key is paired with the patient access rule, the access rule is converted into an access tree. This means inputting a set of attributes $S$ and outputting a key that identifies with that set. The algorithm first chooses a random $r\in Z_p$, and then random $r_j\in Z_p$ for each attribute $j\in S$. Then, it computes the key as $SK=(D=g^{\frac{\alpha +r}{\beta }} \forall j\in S:D_j=g^{r}H{\left(j\right)}^{r_j},{D^{\prime }}_j=g^{r_j})$. After completion, the SK and patient $s{k}_p$ parameters are sent back to the patient side through the secure channel.

• Encryption stage:

At this stage, after the patient has collected data over time, the physiological data can be divided into four categories: heartbeat, heart rate, blood pressure, blood oxygen, and respiration. To get a timestamp, we use the UNIX time format, for example, 12:00:00 am on 30 June 2021, which is equivalent to 1,625,025,600. The data $M=(D_{1I{D}_{p1}}\left||\dots |\right|D_{1I{D}_{pi}}||timestam{p}_n)$ can be used with their own private key for encryption and then the ciphertext CT is transmitted to the hospital server for storage.

• Decryption stage:

When the hospital server receives the CT, it is directly stored in the database. The authorized person (doctor or nurse) can apply for viewing access. If the subsequent lightweight authentication is required (it can be the authorizer and the hospital authentication or the authorized person and the hospital authentication), the hospital server needs to use the private key for decryption, because the patient’s access rules have the attributes of the authorized hospital server. After decryption, use $(D_{1I{D}_{p1}}\left||\dots |\right|D_{1I{D}_{pi}}||timestam{p}_n)$ as the seed to conduct the lightweight authentication.

3.2. Lightweight Authentication

In lightweight mutual authentication, the physiological data and timestamps of patients are used as seeds to generate random numbers. Then, the random numbers are used to create a session key. The lightweight mutual authentication scheme is shown in Figure 8.

Patient side:

• Stage 1

The patient data collection regularly transmits the data to the hospital server for storage. The authentication request is initiated by the patient side and the $r_1$ parameter is generated through the PRNG. Then, obtain $s{k}_p$ stored in the complete authentication, calculate $X_1=h\left(s{k}_p\oplus r_1\right)$, $P_1=h\left(r_1\oplus h\left(I{D}_p\right)\right)\oplus h\left(s{k}_p\right)$, and $P_2=HMA{C}_{s{k}_p}\left( I{D}_p,X_1,P_1\right)$, and finally send $I{D}_p, X_1, P_1, P_2$ to the hospital server.

• Stage 2

When the hospital server receives the parameters $I{D}_p, X_1, P_1, P_2$ it first finds the corresponding $s{k}_p$ according to $I{D}_p$ and then calculates ${P^{\prime }}_2=HMA{C}_{s{k}_p}\left( I{D}_p,X_1,P_1\right)$, and compares ${P^{\prime }}_2=P_2$. If they are not equal, it means that the transmission parameters have been tampered with or forged. Such authentication requests would be rejected. If they are equal, continue to calculate ${X^{\prime }}_1=h\left(s{k}_p\oplus r_1\right)$, ${P^{\prime }}_1=h\left(r_1\oplus h\left(I{D}_p\right)\right)\oplus h\left(s{k}_p\right)$. If ${X^{\prime }}_1=X_1$ and ${P^{\prime }}_1=P_1$, that indicates that the authenticity of the patient’s identity has been confirmed.

The hospital server generates the $r_2$ parameter through the PRNG, calculates $Y_1=h\left(r_1\right)\oplus h\left(s{k}_p\oplus r_2\right)$, $S_1=h\left(Y_1\oplus h\left(I{D}_p\right)\right)\oplus \left(s{k}_p\right)$, and $S_2=HMA{C}_{s{k}_p}\left(r_1,r_2,Y_1,S_1\right)$ and determines the session key $=h\left(r_1\left|\right|r_2\left|\left|s{k}_p\right|\right|timestam{p}_n\right)$. The $timestam{p}_n$ is recorded in the previous authentication. Finally, transmit $Y_1,S_1,S_2$ to the patient.

• Stage 3

When the patient side receives the three parameters $Y_1,S_1,S_2$, the device calculate ${S^{\prime }}_2=HMA{C}_{s{k}_p}\left(r_1,r_2,Y_1,S_1\right)$ through the one-time key hash value and compare ${S^{\prime }}_2=S_2$. If they are not equal, it means that the transmission parameters have been tampered with or forged. This authentication request would be rejected. If they are equal, continue to calculate ${S^{\prime }}_1=h\left(Y_1\oplus h(I{D}_p\right))\oplus \left(s{k}_p\right)$ and ${Y^{\prime }}_2=h\left(r_1\right)\oplus h\left(s{k}_p\oplus r_2\right)$. If ${S^{\prime }}_1=S_1$ and ${Y^{\prime }}_1=Y_1$, it means that the authenticity of the identity of the hospital server has been confirmed. After the patient collects the data, the device obtains the current time $timestam{p}_{n+1}$ and encrypts the data set. The data have several transactions. Taking the first transaction as an example, any symmetric encryption method (such as AES, DPFSM, STFSM, or DPFSV-CML) [49,50,51,52] can be used to encrypt it with the session key, and the ciphertext $I{D}_p{C}_1=E_{session key}(D_{1I{D}_{p1}}\left||\dots |\right|D_{1I{D}_{pi}}||timestam{p}_{n+1})$. Let $M_1=HMA{C}_{s{k}_d}\left(I{D}_p{C}_1\left||\dots |\right|I{D}_p{C}_k\right)$ and, finally, $I{D}_p{C}_1,\dots ,I{D}_p{C}_k,M_1$ are sent to the hospital server.

Hospital server and doctor side:

• Stage 1

The authentication request is initiated by the doctor’s side and the $r_3$ parameter is generated through the PRNG. Then, obtain $s{k}_d$ stored in the complete authentication, calculate $X_2=h\left(s{k}_d\oplus r_3\right)$, $D_1=h\left(r_3\oplus h\left(I{D}_d\right)\right)\oplus h\left(s{k}_d\right)$, $D_2=HMA{C}_{s{k}_d}\left(I{D}_d,X_2,D_1\right)$, and get the patient $I{D}_p$ to apply for the patient $I{D}_p$ data. Finally, send $I{D}_d,I{D}_p,X_2,D_1,D_2$ to the hospital server.

• Stage 2

When the hospital server receives the parameters $I{D}_d,I{D}_p,X_2,D_1,D_2$, it first finds the corresponding $s{k}_d$ according to $I{D}_d$, calculates ${D^{\prime }}_2=HMA{C}_{s{k}_d}\left(I{D}_d,X_2,D_1\right)$, and then compares ${D^{\prime }}_2=D_2$. If they are not equal, it means that the transmission parameters have been tampered with or forged. This authentication request would be rejected. If they are equal, continue to calculate ${X^{\prime }}_2=h\left(s{k}_d\oplus r_3\right)$, ${D^{\prime }}_1=h\left(r_3\oplus h\left(I{D}_d\right)\right)\oplus h\left(s{k}_d\right)$. If ${X^{\prime }}_2=X_2$ and ${D^{\prime }}_1=D_1$, that indicates that the authenticity of the doctor’s identity has been confirmed.

The hospital server generates the $r_4$ parameter through the PRNG, calculates $Y_2=h\left(r_3\right)\oplus h\left(s{k}_p\oplus r_4\right)$, $S_3=h\left(Y_2\oplus h\left(I{D}_d\right)\right)\oplus \left(s{k}_p\right)$, and $S_4=HMA{C}_{s{k}_p}\left(r_3,r_4,Y_2,S_3\right)$ and determines the(a) session key $=h\left(r_3\left|\right|r_4\left|\left|s{k}_d\right|\right|timestam{p}_n\right)$. The $timestam{p}_n$ is recorded in the previous authentication. Finally, transmit $Y_2,S_3,S_4$ to the doctor.

• Stage 3

When the patient side receives the three parameters $Y_2,S_3,S_4$, calculate ${S^{\prime }}_4=HMA{C}_{s{k}_p}\left(r_3,r_4,Y_2,S_3\right)$ through the one-time key hash value. Compare ${S^{\prime }}_4=S_4$ and if they are not equal, it means that the transmission parameters have been tampered with or forged. This authentication request would be rejected. If they are equal, continue to calculate ${S^{\prime }}_3=h\left(Y_2\oplus h\left(I{D}_d\right)\right)\oplus \left(s{k}_p\right)$ and ${Y^{\prime }}_2=h\left(r_3\right)\oplus h\left(s{k}_p\oplus r_4\right)$. If ${S^{\prime }}_3=S_3$ and ${Y^{\prime }}_2=Y_2$, it means that the authenticity of the identity of the hospital server has been confirmed.

• Stage 4

When the doctor wants to apply for the data and the mutual authentication is completed, first, the current $timestam{p}_{n+1}$ is obtained by the hospital server. According to Stage 1, the corresponding data set is found by the $I{D}_p$ provided by the doctor. There are several pieces of data. Taking the first piece as an example, through the session key encryption, we derive ciphertext.

$$I{D}_p{C}_1=E_{session key}(D_{1I{D}_{p1}}\left||\dots |\right|D_{1I{D}_{pi}}||timestam{p}_{n+1}).$$

$$M_2=HMA{C}_{s{k}_d}\left(I{D}_p{C}_1\left||\dots |\right|I{D}_p{C}_k\right).$$

Finally, $I{D}_p{C}_1\dots I{D}_p{C}_k, M_2$ is transmitted to the doctor.

• Stage 5

After the doctor receives $I{D}_p{C}_1,\dots I{D}_p{C}_k,M_2$, first calculate ${M^{\prime }}_2=HMA{C}_{s{k}_d}\left(I{D}_p{C}_1\left||\dots |\right|I{D}_p{C}_k\right)$ and compare ${M^{\prime }}_2=M_2$. If not equal, the transmission parameters have been altered or forged and the connection would be rejected. If equal, you can decrypt $I{D}_p{C}_1$ using the session key and access the original data.

4. Results and Discussion

4.1. Performance Analysis

We used two different computers to simulate the equipment used by patients: Raspberry Pi 3B+ and hospital server, Xeon E3-1230. In Section 4.1.1, we compared the time consumed by the two devices in the key generation, encryption, and decryption stages of complete authentication. In Section 4.1.2, we compared the time consumption for the lightweight authentication of the two devices. Finally, in the same equipment environment, we compared the difference in the encryption stage time consumption between complete authentication and lightweight authentication.

4.1.1. Complete Authentication Performance Analysis

For the key generation stage, encryption stage, and decryption stage of complete authentication, we increased the number of attributes from 1 to 60 in each stage of the algorithm. We calculated the execution time in each stage and took the average time of 100 executions. By our observation, the attributes of a patient are about 20~30, plus about 50 attributes to be authorized to doctors or hospital servers. Therefore, we set the maximum number of attributes to 60. We compiled a time consumption diagram of the two devices at each stage in Figure 9, Figure 10, Figure 11, Figure 12, Figure 13 and Figure 14.

In Figure 9, Figure 10, Figure 11, Figure 12, Figure 13 and Figure 14, we can find that the execution time and the number of attributes grow linearly. For the Xeon E3-1230 server, the most time-consuming operation is the encryption stage (Figure 11). The number of attributes is 60, which takes 2.69 s in encryption time. In contrast, the encryption time of Raspberry Pi (Figure 12) takes 9.8 s. The difference between Xeon E3-1230 and Raspberry Pi is about 3.64 times. Under the same number of attributes (60), Xeon E3-1230 takes 1.11 s in the decryption stage (Figure 13). In contrast, the decryption time of Raspberry Pi (Figure 14) takes 6.79 s. Therefore, the decryption time between Xeon E3-1230 and Raspberry Pi is about 6.11 times. In summary, the IoT device (Raspberry Pi) with lower capacity and weak computing power takes more time for this number of indigenous attributes.

On the other hand, using Raspberry Pi to generate keys is very time-consuming (Figure 10). It takes 35 s to generate keys for 60 attributes, while Xeon E3-1230 only takes 2.8 s. The difference is 12.5 times. Therefore, it is quite time-consuming to perform complex mathematical operations, such as ECC and bilinear pairing, in the case of weak computational ability.

It was observed in this study that the computational capacity of Raspberry Pi is not strong compared to Xeon E3-1230. Whether in the encryption stage or decryption stage, the average difference is about 3.9 times. Therefore, our lightweight authentication can allow IoT devices to save more time and computing resources while being secure enough.

Next, we compared the effect of data size on the encryption and decryption time. When the number of attributes is 30, the attribute size is placed in the ordinate and the data size is placed in the abscissa. We find that the data M = ($D_{1I{D}_{p1}}\left||\dots |\right|D_{1I{D}_{pi}}\left|\right|timestam{p}_n)$ collected every minute is about 1 KB, so the test data size increases from 1 KB to 65 KB. In Figure 15, Figure 16, Figure 17 and Figure 18, we can see that when the number of attributes is fixed, whether using Xeon E3-1230 or Raspberry Pi, the execution time of encryption and decryption is not much affected by the size of the data.

4.1.2. Lightweight Authentication Performance Analysis

In this section, we analyze patient and hospital server authentication as well as hospital server and doctor authentication using lightweight authentication. Here, we first ignored the time when the parameters are passed. We analyzed the time of $T_{hash}, T_{HMAC},T_{XOR},T_{Encrption},T_{Random}$. A total of 100 experiments were carried out and the time average was taken.

We executed steps 1 to 4 with $4T_{hash}+1T_{HMAC}+3T_{XOR}+1T_{Random}$ per run. For the Xeon E3-1230 server, step 2 took more time to find $s{k}_p$ but we ignored this because the time depends on the bandwidth of the network. It took about 16 ms to make a session key and 2.2 ms to encrypt data into ciphertext. The total time consumption for lightweight authentication is 4 × (16 × 4 + 3.6 + 0.9 × 3 + 1.6) + 16 + 2.2 = 314.2 ms. Similarly, for Raspberry Pi 3B+, it took about 41 ms to make the session key and 6.4 ms to encrypt the data into ciphertext. The total time consumption is about 4 × (41 × 4 + 8 + 7.52 × 3 + 11) + 41 + 6.4 = 869.64 ms shown in

Table 5. Xeon E3-1230 server and Raspberry Pi 3B+ time in lightweight authentication.

	Explanation	Xeon E3-1230	Raspberry Pi 3 B+
$T_{hash}$	$SHA3$ hash operation	16 ms	41 ms
$T_{HMAC}$	Hash-based message authentication	3.6 ms	8 ms
$T_{XOR}$	$XOR$	0.9 ms	7.52 ms
$T_{Encrption}$	Encrypt with session key	2.2 ms	6.4 ms
$T_{Random}$	random number generator	1.6 ms	11 ms

.

Under the advantages of the Xeon E3-1230 cores and multithreading, the lightweight authentication time between Xeon and Raspberry is only about 2.76 times. However, the average difference in complete authentication is 7.9 times. Therefore, the proposed lightweight authentication is indeed effective in shortening the authentication time of IoT devices.

Next, we changed the conditions to use the same device for comparison between different authentication types. We took 30 attributes, for example, when testing complete authentication. The Xeon E3-1230 server (Figure 11) took about 1400 ms for complete authentication and lightweight authentication took 314.2 ms, which is 4.45 times the difference. Raspberry Pi took about 5050 ms for complete authentication (Figure 12) and 869.64 ms for lightweight authentication, which is 5.8 times the difference. It can be seen that the disadvantage of weak computing ability in IoT devices is improved.

5. Security Analysis

In this section, we discuss the security of lightweight authentication in three parts: the first is resistance to replay attacks, the second is resistance to man-in-the-middle attacks, and the third is forward secrecy. We detail the random number results used in lightweight authentication and the security analysis of the session key.

5.1. Resistance to Replay Attacks

We assume that malicious attackers steal ${\mathrm{P}}_1,{\mathrm{S}}_3,{\mathrm{X}}_1,{\mathrm{Y}}_1,$ and other parameters during the patient and hospital server authentication. Because these parameters are generated through random numbers ${\mathrm{r}}_1,{\mathrm{r}}_2$, the parameters are only valid at this authentication, and the random number of ${\mathrm{r}}_1,{\mathrm{r}}_2$ has changed at the next authentication. Since the original stolen parameters are invalid and cannot complete the authentication, the lightweight authentication proposed in this study effectively resists the retransmission attack.

5.2. Resistance to Man-in-the-Middle Attacks

We assume that there is a malicious attack during the authentication between the patient and the hospital server and that the attacker wants to forge the identity of the hospital server to authenticate with the patient. Because it is impossible to know the initial $s{k}_p$ parameters, as well as the $r_1,r_2$ parameters generated by the two sides through PRNG, it is impossible to produce $Y_1,S_1,S_2$, and other parameters. Therefore, the lightweight authentication proposed in our study can effectively resist man-in-the-middle attacks.

5.3. Forward Secrecy

The purpose of forwarding secrecy is to ensure that in each lightweight authentication, the data encrypted by the session key is not inferred from the session key used in the next authentication to achieve the decryption of ciphertext data. The session key used in this study is Session Key $=h\left(r_1\left|\right|r_2\left|\left|s{k}_p\right|\right|timestam{p}_n\right)$, which $r_1, r_2,timestam{p}_n$, and other parameters change with the indigenous time. Even if the session key is illegally obtained, the previously transmitted encrypted data cannot be unlocked. Therefore, the lightweight authentication proposed in this study meets the forward secrecy principle.

5.4. The Test Results of the Random Number

In this study, our random number is generated through the patient’s physiological data and timestamps as seeds for PRNG, based on the detection of 15 random numbers (arbitrary length) in NIST SP800-22 rev.1a, the STS 2.1.2 suite.

Table 6. NIST SP800-22 15 random number test results.

	Result		Result
Frequency	PASS	Overlapping Template	PASS
Block Frequency	PASS	Universal Statistical	PASS
Cumulative Sums	PASS	Approximate Entropy	PASS
Runs	PASS	Serial	FAIL
Longest-Run-of-Ones	PASS	Linear Complexity	PASS
Binary Matrix Rank	PASS	Random Excursions	Insufficient number of cycles
FFT	FAIL	Random Excursions Varian	Insufficient number of cycles
Non-overlapping Template	PASS

shows the results of testing the random numbers used in the proposed lightweight authentication.

Our study passed 11 out of 15 tests, in which Random Excursions fails to run completely due to insufficient random numbers. FFT detection tests whether the deviation of the bit stream in the random sequence is random. In general, the bit stream takes eight as a unit. If the deviation is small, it means that the block is random. Serial detection mainly refers to whether the number of combinations of all possible bit stream in the block to be tested is the same as that in the true random number. If so, it means that the block is random. For example, when the bit stream is set to 2, its combination has 00, 01, 10, and 11, and the probability of each combination needs to be equal (0.25) under the condition that these four satisfy the true random number. We speculate that the reason for failing to pass these two tests is that the random number generator by PRNG is not chaotic enough when physiological data are used as seeds, so the probability distribution in all block combinations is not uniform.

5.5. Security Analysis of Session Key

The Session Key $=\mathrm{h}\left(r_1\left|\right|r_2\left|\left|s{k}_p\right|\right|{\mathrm{timestamp}}_{\mathrm{n}}\right)$ is used in the existing AES, DPFSM, STFSM, DPFSV-CML, and other algorithms; there is a detailed analysis in the above algorithm research. The random number $\left(r_1,r_2,r_3,r_4\right)$ used in the production is not completely detected by 15 items in NIST SP800-22 without the previously stored physiological data and timestamps. The random number cannot be computed in a short time and the random number is not transmitted on the network. Both sides make random numbers by themselves; it is not easy to copy the session key in a short time even if the parameters have been compromised.

Therefore, it is very difficult to brute force crack the session key that we use. Our key length is 512 bits. As of June 2022, the world’s fastest supercomputer is Frontier [53], with 8,730,112 cores, 1102.00 PFlop/s computing capacity, and 1 PFlop/s (${10}^{15}$ floating-point operations per second). Furthermore, if the session key was brute force cracked by Frontier, the fastest computer in the world, it would take 1.217 × 10¹³⁶ s (3.859082 × 10¹²⁸ years). In other words, the session key used in this study is almost unlikely to be cracked when random numbers are generated through the physiological data of patients as seeds.

6. Conclusions

In this study, we mainly focused on identity authentication, data confidentiality, and integrity based on the framework of CP-ABE. According to the time cycle mechanism, it is divided into complete authentication and lightweight authentication. The complete authentication with CP-ABE is too time-consuming; hence, we propose a lightweight mutual authentication. In the complete authentication stage, we use CP-ABE to ensure the confidentiality of patient’s physiological data. In the lightweight authentication stage, we use the hash function and XOR gate so that some physiological sensing devices with lower computing ability can deal with the parameter calculation. The main contribution of our study is to use the patient’s physiological data and timestamps as seeds for random number generators for authentication.

Instead of key transmitting, both sides can correctly calculate the random number as the key themselves through the previous storage of physiological data and timestamps during the authentication period. The random number generated by PRNG does not need to transmit to the other side during the authentication period; both sides can synchronize and calculate the random number themselves. In this study, even if the intentional person steals other parameters, it would be infeasible to complete the mutual authentication because the most critical random number cannot be correctly calculated. Finally, mutual authentication is completed before encryption and decryption through the session key.

We used two different specifications of the equipment to simulate the roles represented in a real environment. The experiments show that the use of Xeon E3-1230 takes 314.2 ms in lightweight authentication time, which is about 4.45 times faster than the complete authentication. This means achieving a time-saving advantage. Using Raspberry Pi in our proposed lightweight authentication costs 869.64 ms, which is 5.8 times faster than the complete authentication. This means that it greatly improves the disadvantage of IoT devices in weak computing power without losing security. In lightweight authentication, the time cost of the two devices is only 2.76 times less, greatly reducing the hardware gap between the two devices. In summary, the lightweight certification proposed in this study has achieved the advantages of being lightweight, saving time, and reducing computational power.