Keywords

1 Introduction

With the rapid advancement in semiconductor technology and communication networks, wireless sensor network has been realized for solving problems in various domains including defence, health care, gaming and entertainment. Sensors are wearable or implanted in human body for regular sensing of vital physiological parameters for continuous monitoring and support purposes. The specialized wireless sensor network applied for remote health monitoring and support may be termed as wireless body area network (WBAN) or wireless body sensor network (WBSN) or medical body sensor network (MBSN), and people who may be in demand of such system are from both rural and urban areas [1]. Moreover, the purpose of using such system has both the perspectives: fitness regime and continuous health monitoring remotely without being manned and without any mobility restriction for elderly people living in rural areas. This system is advantageous over traditional doctor–patient system for mainly: (i) precision in data measurement, (ii) timeliness or proper interval of physiological data measurement and (iii) physically seeing a doctor for measuring blood pressure, sugar, temperature, heart rate [2], etc., which are irrelevant. But complete success of such remote healthcare system depends completely on how accurately actual measured data are being received at the diagnosis end within permissible delay limit of 10–250 ms [3]. Vital signals sent wirelessly may face threats in the form of (i) modified information—attacks towards integrity, (ii) leakage to sensitive patient information—attacks towards confidentiality, (iii) data access by illegitimate user—attacks towards authentication and (iv) data lost or delayed in transit—may cause havoc on patient’s life. A lot of works have been done to address these issues [4]. In tier 1, sensor nodes send signal to the coordinator node over short range (distance around 2 m). Coordinator node then forwards the signals to the tier 2 through access point (AP). Here, various intra-BSNs, cellular networks and Internet connectivity take place. In tier 2 communication, APs and Internet are connected with cloud-based medical server from where concerned caregiver can access the vital signals. Signal being transmitted beyond tier 1 is vulnerable to all types of security attacks in transit through insecure wireless channel.

Figure 1 depicts security measures taken at tier 2 and tier 3 to ensure confidentiality and integrity here.

Fig. 1
figure 1

Three-tier architecture of MBSN

Full size image

Rest of the paper is organized as follows: Sect. 2 describes related works, proposed work and algorithm are illustrated in Sect. 3, Sect. 4 elaborates experimental set-up followed by detailed experimental results in Sect. 5, and finally, the whole work is concluded in Sect. 6.

2 Related Work

Physiological data of patients transmitted through MBSN from patient to doctor are vulnerable for different attacks. Intruders can easily alter this vital health information which can be life threatening. Therefore, strong security techniques are needed to achieve proper confidentiality, authenticity and integrity of data. Researchers proposed key generation techniques from biological information [5], and some researches show the authentication [6, 7] techniques using biometric information of human body such as ECG, finger print and heart rate. Table 1 shows the recent works on various security aspects for BSN applications.

Table 1 Comparative literature survey
Full size table

3 Proposed Work

Our proposed security system is implemented in cloud which will secure the data transmission between tier 2 and tier 3. Figure 2 shows the key generation process from fingerprint of patient, key sharing process, encryption and decryption.

Fig. 2
figure 2

Key generation, encryption, key regeneration and decryption process

Full size image

Firstly, fingerprint images of patients and doctors are captured, and it is converted to its equivalent matrix, and then the matrix is stored to cloud server along with doctor and patient id, respectively. For the authentication of doctor’s identity, doctor’s fingerprint information is used, and for the key generation purpose, patient’s fingerprint information is used. A random element is selected from the fingerprint matrix. We have used two different encryption techniques: Algorithm 1 shows the steps using triple DES [11], while Algorithms 2 shows the steps using AES-128 [6, 12].

For AES, 128-bit hash of randomly selected element is computed using SHAKE-128(SHA-3) algorithm, and then, this hash is used as the encryption key. After encryption, encrypted health data and the random element are stored in the cloud database. During decryption, random element and encrypted health data are fetched, and decryption key is generated by computing the hash of random element again.

For 3DES, three numbers of 64-bit key are generated; for that, three random elements are chosen and 64-bit hash is calculated for all these elements using SHAKE-128(SHA-3) algorithm. Here, 3DES is followed by encryption–decryption–encryption for encryption, where in each step random element is stored in cloud along with key id (K1, K2, K3). For decryption, reverse process of encryption is followed which is decryption–encryption–decryption; here, for each step keys are fetched from cloud. Then, the hash of K1, K2, K3 is again computed which are used as a decryption key.

figure a
figure b
figure c
figure d
figure e

Notations used in the above algorithms are as follows:

  1. 1.

    doctor_request: Doctor sending request to patient for health data

  2. 2.

    doc_thumb_sent: Doctor sending his thumb signal with request of health data.

  3. 3.

    doc_thumb_stored: Thumb information of doctor stored in cloud.

  4. 4.

    thumb_info: Thumb information of patient and doctor in matrix form.

  5. 5.

    n: Number of vital signals.

4 Experimental Set-Up

For our experiments, a cloud-based database server is used to store physiological signal of patients in encrypted format. A cloud server is also known as virtual private server, but its hardware components are physically located in different places. The main reasons behind using the cloud server are remote access of data, flexibility, cost-effectiveness, etc. Back end of our implemented system is controlled by PHP and AJAX, and front end is designed using HTML 5 and CSS. We have considered a notebook PC here as a PDA device which forwards the physiological signal of patients to the cloud. Table 2 and Table 3 show the simulation environment of PDA device and cloud-based server, respectively. Tables 4 and 5 show the hardware resource utilization during the secure transmission of patient’s health data from patient to doctor via cloud server.

Table 2 Simulation environment of cloud server
Full size table
Table 3 Simulation environment of PDA
Full size table
Table 4 Resource utilization of cloud server
Full size table
Table 5 Resource utilization of PDA
Full size table

We can see from the above tables that resource utilization is very low, so our implementation can be easily adopted in a low-end system also.

5 Results and Discussion

We have performed the experimental test in five phases with five runs of 10 min each. The physiological information of patient such as body temperature, heart rate and blood pressure is transmitted in real time from patient to doctor upon request of doctor. In the first phase, physiological data of patients are sent to doctor via cloud server in plain text format without any security with an interval of 1 min. Secondly, physiological data are sent to doctor during attack on transmission. Here, in our scenario we have considered application layer-based http flood attack (DDOS) and man-in-middle (MITM) attack. For the DDOS attack simulation, we have used a Python-based attacking tool named Golden Eye. To simulate the environment, an attack is targeted to apache-based PDA/personal server’s IP address from an another PDA device; during simulation, we first sent 20 GET method request to the targeted IP address per second using http protocol for 12 min (with an interval of 1 min) and recorded the end-to-end delay. Next, we sent 50, 110 and 150 GET method requests and recorded the end-to-end delay, respectively, but for the 150 request the targeted system is crashed (system turned-off) because of memory exhaust. We also recorded the CPU utilization of the targeted PDA device during the attack. For the man-in-middle attack, it is periodically and randomly targeted where an attacker reads the health information during transmission and again re-transmits it to doctor. Comparison of average end-to-end delay and resource utilization between DDOS attack and non-attacked period are shown in Figs. 3 and 4, respectively. Comparison of average transmission delay between man-in-middle attack, dos attack and normal traffic is shown in Fig. 5.

Fig. 3
figure 3

End-to-end delay of physiological data transmission in plain text during DDOS attack

Full size image
Fig. 4
figure 4

Resource utilization of PDA device during transmission of physiological data in plain text during DDOS attack

Full size image
Fig. 5
figure 5

Comparison of end-to-end delay during normal transmission, MITM and DDOS attack

Full size image

Figure 3 shows that end-to-end delay for transmission of physiological signal is increasing during the attack. It is under the permissible delay when requests are 6 per second but after that it crossed the limit, so here we can detect the attack because of delay. Figure 5 shows that during man-in-the-middle attack, end-to-end delay is more than normal transmission, so if there is any extra delay then we could say that there is an attack.

In third stage, physiological data of patients are transmitted from PDA to doctor via cloud server with confidentiality and authenticity. Here, secure key distribution is done in order to prevent man-in-middle attack on secret key. For our implementation, we have used doctor’s thumb information to achieve authentication, for confidentiality light weight faster symmetric encryption algorithm AES and triple DES is used. To generate secret key, patient’s thumb information has been used. Average data size of the physiological signal of patients is 3.21 KB. Here, we have provided the averages of five different sets of data. Explanations of various parameters used are as follows:

  • 1. Doctor’s thumb authentication time (DTAT): This reflects the required time to compare and validate doctor’s bio-signal (thumb print) to the bio-signal stored in cloud database when doctor wants to see patient health data.

  • 2. Data read time (DRT): This means the required time to read the vital signals of patient’s from the PDA device.

  • 3. AES encryption time (AES-ET): This shows the time required to encrypt patient’s health data using encryption algorithm and the key generation from patient’s thumb information.

  • 4. Data store time (DST): This means the time required to save encrypted health data and the information to regenerate the secret key in the cloud database server.

  • 5. Data fetch time (DFT): This shows the time required to fetch encrypted health data and the secret key information.

  • 6. AES decryption time (AES-DT): This reflects the time required to regenerate the secret key from the fetched information and to decrypt the health data into readable format.

  • 7. DES encryption–decryption–encryption time (DES-EDET): This shows the time required for encryption process and the generation of 3 no’s of 64-bit key from patient’s thumb information.

  • 8. DES decryption–encryption–decryption time (DES-DEDT): This shows the time required for decryption process and the regeneration of 3 no’s of 64-bit key from patient’s thumb information.

For detailed view and better understanding, total end-to-end delay and its different components of secure patient health data transmission using AES and triple DES encryption with authenticity and confidentiality are plotted graphically in Fig. 6 and Fig. 8, respectively. Results of Fig. 7 show that DTAT lies between 2.23 and 2.67 ms, DRT lies between 0.29 and 0.41 ms, AES-ET lies between 5.32 and 6.01 ms, DST lies between 1.02 and 1.49 ms, DFT lies between 0.12 and 0.31 ms and AES-DT lies between 4.71 and 5.32 ms. Similarly from Fig. 8, we can understand that DES-EDET and DES-DEDT are increased slightly because of three layers of DES encryption and decryption process and generation of 3 no’s of 64-bit key. Average total time required for both AES and triple DES using 128- and 192-bit keys is, respectively, 15.05 ms and 29.54 ms. Hence, end-to-end delay is only 6.02 and 11.82% of 250 ms which is the permissible delay limit for healthcare application.

Fig. 6
figure 6

End-to-end delay of physiological data transmission using AES

Full size image
Fig. 7
figure 7

End-to-end delay of physiological data transmission using triple DES

Full size image
Fig. 8
figure 8

Comparison between end-to-end delay of physiological data transmission using AES and triple DES

Full size image

6 Conclusion

This work implements symmetric key encryption techniques such as AES and triple DES for confidentiality of data, and secret key used for encryption and decryption is hash-based key generated using SHA-3 to ensure integrity beyond tier 2 and between tier 2 and tier 3. This secure system implements a complete security to the vital signals being transmitted in open wireless network exploiting biological information extract of the MBSN user for secret key generation. Experimental results satisfy delay constraints of specific application, e.g. healthcare domain demanding real-time streaming of data in spite of additional security measures applied.