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.
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
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.
The attribute authorization center generates parameters, such as PK and SK.
When a patient is admitted to the hospital, first assign to the patient, secretly decide on , and transmit them to the patient via a secure channel. Only the patient and the hospital server know 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.
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 and outputting a key that identifies with that set. The algorithm first chooses a random , and then random for each attribute . Then, it computes the key as . After completion, the SK and patient parameters are sent back to the patient side through the secure channel.
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 can be used with their own private key for encryption and then the ciphertext CT is transmitted to the hospital server for storage.
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 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:
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 parameter is generated through the PRNG. Then, obtain stored in the complete authentication, calculate , , and , and finally send to the hospital server.
When the hospital server receives the parameters it first finds the corresponding according to and then calculates , and compares . 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 , . If and , that indicates that the authenticity of the patient’s identity has been confirmed.
The hospital server generates the parameter through the PRNG, calculates , , and and determines the session key . The is recorded in the previous authentication. Finally, transmit to the patient.
When the patient side receives the three parameters
, the device calculate
through the one-time key hash value and compare
. 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
and
. If
and
, 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
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
. Let
and, finally,
are sent to the hospital server.
Hospital server and doctor side:
The authentication request is initiated by the doctor’s side and the parameter is generated through the PRNG. Then, obtain stored in the complete authentication, calculate , , , and get the patient to apply for the patient data. Finally, send to the hospital server.
When the hospital server receives the parameters , it first finds the corresponding according to , calculates , and then compares . 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 , . If and , that indicates that the authenticity of the doctor’s identity has been confirmed.
The hospital server generates the parameter through the PRNG, calculates , , and and determines the(a) session key . The is recorded in the previous authentication. Finally, transmit to the doctor.
When the patient side receives the three parameters , calculate through the one-time key hash value. Compare 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 and . If and , it means that the authenticity of the identity of the hospital server has been confirmed.
When the doctor wants to apply for the data and the mutual authentication is completed, first, the current
is obtained by the hospital server. According to Stage 1, the corresponding data set is found by the
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.
Finally, is transmitted to the doctor.
After the doctor receives , first calculate and compare . If not equal, the transmission parameters have been altered or forged and the connection would be rejected. If equal, you can decrypt using the session key and access the original data.