Internet of Things (IoT) is the result of rapid develop- ments in Communications and Information innovations. These technologies can be used for Patient care in several medical fields of the healthcare scenarios. IoT Health Service [1] uses embedded sensors [2] on wearable gadgets and therapeutic in- struments (e.g., Implantable Cardiovascular Defibrillator, Pulse Generator, Electronic devices for a Retinal Implant and Glass Encapsulation).

The embedded sensors that can be installed in human beings are designed with exceptional restricted battery power. Users cannot charge various sensors and portable therapeutic gadgets frequently, which significantly reduces the interest of Patients and care takers. Moreover, sensors that are implanted inside the body (for instance, Heart Rhythm Controller) are hard to recharge the battery, and the Patient’s life is in danger when

the strength of remote devices diminish. Besides, Healthcare systems ought to be lightweight in order to enhance the lifetime of the battery. The wearable gadgets [3] measure Patient’s health data and store the data in a therapeutic record. The limited storage capacity restricts the HIoT to contract out the files for future use.

The therapeutic files comprise of sensitive data and thereby needs permission to use [4]. Standard access control systems are not intended for crisis circumstances which happen often in medical field. In such a condition, where the Patient is critically sick and is not in a position to provide access rights to assigned Doctor or helpers on-time results in the Patients life risk.

  1. System Architecture

The system architecture consists of the  Key  Generator  (KG), Cloud Storage (CS), Hospital (H), the Patient (P), the attribute based Doctor (D) and the Emergency Supporting Representative (ESR). These entities are shown in Fig. 1 along with the interaction between them.

Fig. 2. Block Diagram of SIRLC


Fig. 1. Proposed System Architecture

  • System Model

The Block diagram of the SIRLC is  as  shown  in  Fig.  2. The Hospital module generates the System Key and Initialize the setup. The Doctor and Patient  details  are  generated  by  KG and stored. The Public Key  for the Patient is saved onto   the Cloud via the Internet for the Asymmetric Cryptography communication. A Emergency Supporting  Representative  list is created, maintained and Emergency-Key is provided by the Patient. In Emergency, the Hospital module assigns a suitable Doctor to a Patient. One of the ESR sends a request to the Hospital using Emergency-Key (4a, 4b and 4c) that is verified  to generate the Attribute-key. Then Doctor views the Patient’s details using the Attribute key shared by the ESR and then proceeds to treat the Patient.

In the Proposed system, [x].X means a scalar multiplication of a random large number x with a Elliptic Curve Point X.

  1. System Setup: Security parameter 1k is taken as an input,

the KG generates the HPvtK for the system, Setup(1k) →

Patient Details Registration() registers the Patient, gen- erates Secret Key PPvtK = p Zp and computes PP ubK = ECCgenPub(PPvtK).


Register Doctor Details: Each Doctor registers in Healthcare system with  his/her  respective  specialization, so that  the  Healthcare  System  can  map  the  Doctor  (D) to the Patient (P)  by  matching  their  specialization  with  the attribute of Patient’s sickness type.  The  function Doctor Details Registration() registers the Doctor, gen- erates Secret Key DPvtK = d Zp and computes DP ubK = ECCgenPub(DPvtK) with the given ECC Key.

{          ···    }  

Hospital (H): After registration of Patient  and  Doctor into the Healthcare system, the Hospital Management System maps the Doctor to a respective Patient i.e., with the function Healthcare Service(): map(DID)       PID. Here the Hos- pital management checks for the sickness type of Patient from an Attribute list of the Patient PID(Attr)=  P1, P2,        , Pn and Specialization of the Doctor (D) from the Attribute list of Doctor DID(Attr)= {D1, D2, ··· , Dm}.

  • Key Generator (KG): The KG login with the User-

name KGU and the Password KGAuth, the Function ECCgenPub() generates a Public key using attributes of Patient  i.e.,  PubKey,  PP ubK  IDPvtK  Generator  which is used as an Attribute based Key  for the Healthcare system  i.e., KG(Attr) → (PP ubK ).

  • ESR login: This module allows ESR to obtain the

detailed information of the Patient, and obtain the P

(HPvtK). KG uses different attributes of the Patient, Attr

i.e., in the Healthcare system. Patient details are registered

shared by the Patient as expressed in (1) and (2).



in the Hospital with these set of attributes. The  function  Initial  Setup()  generates  HPvtK  s  Zp  and  computes the System Public Key, HP ubK  ECCgenPub(HPvtK) using the Key Generator.

2) Patient Details Registration: Each Patient is assigned with some set of attributes Attr, depending on his/her position in the Healthcare system. The Patient registers into Hospital (H), and the KG generates the Attribute Key PP ubK for the Patient based on the given set of attributes. The function

ESR(ESRU ||ESRAuth) → PP ubK                (1)

ESR(ESRU ||ESRID) → PEK                  (2)

  • Doctor login: After obtaining PAK from ESR, the Doctor (D) uses it to access the Patient medical file PM with the use of DU and DAuth as shown in (3).

DID(DU ||DAuth||AK) → PM                    (3)

A Secure Information Retrieval using Lightweight Cryp- tography (SIRLC) for Healthcare IoT (HIoT) is proposed to obtain Patient’s Medical data in times of emergency. The  Patient must be the only authority to provide access rights of Patient’s file to the assigned Medical Practitioner. Attribute based Keys are  used  to  retrieve  Patient’s  medical  records.  In  an  Emergency  where  the  Patient  is  not  in  a  condition  to communicate, the Emergency-Key with one of the ESRs provides access to the Doctor to obtain the Medical data.

The SIRLC technique contributes in the reduction of time complexity with high  security  in  HIoT.  The  Ciphertext  size is improved by 20% against LiBAC [17]  with  the  security level of 112. The Key generation time for the user is 20 times quicker compared to the  LiBAC.  The  SIRLC,  the  reduction in the size of the Ciphertext and Key  generation time, results   in the better performance over  LiBAC.  Further,  the  SIRLC can be improved to generate an Emergency Key by many ESRs simultaneously using Distributed Emergency Key and accumulating Intermediate Keys.


Please enter your comment!
Please enter your name here