Internet of Things Framework for Oxygen Saturation Monitoring in COVID-19 Environment

1). Registration and Key Generation:

The data of oximeters are passed on to the mobile devices and then sent to the CoVEn. Therefore, keeping in mind the security dynamics of mobile devices, the framework needs to utilize some cryptographic authentication services. For this purpose, we have used the bilinear pairings-based signcryption–unsigncryption for transferring the data from users to CoVEn. The process starts with a registration phase. In this phase, mobile devices send the integrated circuit metrics (ICMetrics) data to the CoVEn for generating the keys [42]. It uses system-level characteristics to provide identification of the devices. We then map the ICMetrics to provide a pseudo-identity to the devices and the mapping can be stored separately by the network operator(s). We assume here that the framework already has obtained the ICMetric data from the operator and then proceeds accordingly. These ICMetrics data are the initialization point in the registration phase. Receiving these data, KG computes hash of it. PHOTON-256 hash (PH) is used here [43]. This hash algorithm provides the benefits of lightweight and less complexity. KG generates the private-public key pair for the respective user (device willing for registration). KG inputs a random point on an elliptic curve over a finite field with an order , where is a random prime number and , and are the integer elements such that: .

It then computes a master secret key (msk) and system parameters (param). These parameters further help the device in the signcryption process. Once this registration is completed and system parameters are set up, the hashed ICMetrics and timestamp are processed along with the msk and param. The timestamp is of 64 bits. Timestamp helps for preventing stale or revocation of the keys. is used for synchronizing the system time error. The given ICMetrics identity (ICM) of the device is hashed with PHOTON-256 to output as: . Using this hashed identity, KG’s msk, and master public key, device-based key pairs are calculated and sent to the users through a preassumed secure channel. The overall process is summarized in Algorithm 1.

Algorithm 1 Registration and Key Generation

• 1:

  Input:

• 2:

  Output:

• 3:

  Obtain a cyclic additive group from of prime order with generator

• 4:

  Obtain the non-zero elements of to generate the cyclic multiplicative group . The order of this group should be q and generator is .

• 5:

  

• 6:

  Select a random number

• 7:

  Master public key

• 8:

  KG public key

• 9:

  Initialize the hash function PH

• 10:

  Publish param:

• 11:

  Compute

• 12:

  

• 13:

  

• 14:

  Return

2). Oximeter Signcrypted Transmission:

Once the oximeter readings are obtained from the patients, either the smart healthcare network or the manual accounting through mobile devices is done. The mobile device (user) sends the reading data in a signcrypted way. These reading data contain the age, sex, address, location area (mobile device), and oxygen saturation measurements . In generalization, these data can be represented as a message of variable size, which is given as

Therefore, it means that the mobile device sends the signcrypted message over the transmission medium of the IoT framework. The reasons for using signcryption include to reducing network overhead, less complexity, and less time consuming, which are the inherent advantages of signcryption methods over generic confidentiality-authentication schemes. The keys generated in the registration phase are used for this signcryption. A registered mobile device or user executes a signcryption process. The signcryption process inputs , message , private key , and KG’s public key . The process outputs a signcrypted message . This message is then transmitted along with the . The process is shown in Algorithm 2. Here, represents Hummingbird encryption function, which enhances the complexity reduction and provides standard security [44].

Algorithm 2 Signcryption for Data Request

• 1:

  Input:

• 2:

  Output:

• 3:

  Choose two random numbers

• 4:

  Compute

• 5:

  Compute

• 6:

  Compute

• 7:

  Compute

• 8:

  Compute

• 9:

  Return

3). CoVEn Unsigncryption:

DG receives the signcrypted messages and unsigncrypts them. After unsigncryption, it sends the data for analysis with the probabilistic classification phase. The unsigncrypted data are sent further by DG only if they are found secure, else the received is aborted. To verify the security parameters, DG takes the help of KG for security service verification. As signcryption–unsigncryption is used here, the framework ensures the security services of confidentiality, integrity, digital signature, and nonrepudiation and privacy in addition. DG accumulates all signcrypted messages with corresponding so that the consecutive readings of a user can be correlated and processed for probabilistic classification. Consider that DG has received a version of as . DG decrypts using its preconfigured private key . It then obtains . It computes . Then, the hash value of , and is calculated using PHOTON-256. This hashed output is then used for the calculation of and is compared to . If the matching result is true, is accepted. The process is summarized in Algorithm 3.

Algorithm 3 Unsigncryption by DG

• 1:

  Input:

• 2:

  Output:

• 3:

  Compute

• 4:

  Compute

• 5:

  Compute

• 6:

  Compute

• 7:

  Compute

• 8:

  If , then accept as else abort

Once CoVEn receives the measurements of oximeters in , it maps the data with and stores in the database. The decreasing oxygen saturation level is having the pivot role in the presented solution. However, the decreasing oxygen saturation level needs to be monitored multiple time. Therefore, CoVEn stores the values of oxygen saturation corresponding to . Whenever a message is unsigncrypted, DG searches in the database, if found, then it appends the values in a time-based function; else, it adds the new and maps the saturation value for further processing. Fig. 4 shows this data aggregation process in CoVEn.

4). Probabilistic Analysis:

The data stored by the DG are processed for probabilistic classification. The probabilistic classifier is used to predict for a given input of observation sets and a probability distribution over a set of classes. As a categorization of this classifier, the presented framework uses binary classification [45]. Binary classification is used to classify the elements of a given set into two groups; hence, the name is “binary.” It predicts the belongingness of the elements in a group on the basis of a classification rule [46]. In the literature, we observe that binary classification is already in use for COVID-19 detection [31]; however, medical images (chest X-rays) are used for this. Therefore, it is a novelty of the presented framework that analyzes the probability based on oxygen saturation using an IoT framework.

Binary classification using the Probit Model [47] is advantageous in the presented framework as it uses two classes: 1) suspicious and 2) nonsuspicious. These two classes are considered to be the elements of a response . This model also uses a vector of regressors which are assumed to influence the outcome . The relationship between and is given as

where is the probability, is the cumulative distribution function (CDF) of the standard normal distribution, and is calculated by maximum likelihood estimate (MLE). Consider the system works on a data set , where is an oximeter data and is the classification response. For the single oximeter reading observation, conditional probability on the vector of inputs of that observation, CoVEn calculates the following:

where is calculated as vector, i.e., oximeter readings for a single user and is calculated as the vector of coefficients. Following this, the likelihood is estimated for a single user observation as

Since the observations are independent and identically distributed, the likelihood of the entire sample ( users), or the joint likelihood is calculated as the product of the likelihoods of the single observations as

Following the joint likelihood, the joint log-likelihood function is calculated for all the observations as:

The estimator maximizes the function if is nonsingular. This log-likelihood function is globally concave in and converges fast to the unique maximum. is given by the following.

denotes the probability distribution function of the standard normal distribution.

Note that this probabilistic classification is applicable for a span of multiple readings for each user, if any user’s reading is found less than the oxygen saturation threshold , the probability can be fixed as 1 and severity can be calculated accordingly. In the present experimentation process, 95% oxygen saturation is considered as . The summarization of this phase is shown in Algorithm 4.

Algorithm 4 Probabilistic Classification

• 1:

  Input:

• 2:

  Output:

• 3:

  Initialize threshold of saturation

• 4:

  Initialize binary class: suspicious=1, non-suspicious=0

• 5:

  If

• 6:

  

• 7:

  Else

• 8:

  {

• 9:

  For (m successive osm)

• 10:

  If

• 11:

  Compute

• 12:

  Severity alert ()

• 13:

  Return

• 14:

  }

5). Severity Detection and Alerting:

The above phase classifies the user readings as suspicious or nonsuspicious for COVID-19 infection. Along with this classification, the present solution also uses severity detection depending upon how rapid decrease of oxygen saturation needs medical help; thus, to generate an alarm to the user to visit near by medical center. The severity is alarmed to the users in either of the three levels: 1) low; 2) mild; and 3) high. We use the Severity alert () with the following conditions as shown in Algorithm 5 to generate the alarm back to the users. Note that this is a user-specific calculation.

Algorithm 5 Severity Alert ()

• 1:

  Input:

• 2:

  Output: alert

• 3:

  If

• 4:

  alert = high

• 5:

  Else

• 6:

  {

• 7:

  for i=1 to m

• 8:

  {

• 9:

  Calculate

• 10:

  If ( is in decreasing mode)

• 11:

  alert = high

• 12:

  Else

• 13:

  alert = low

• 14:

  Return alert

The alerts are then responded back to the user by CoVEn using the application alerts. These responses also use the same IoT infrastructure for obtaining the alert responses.

6). Data Block Generation:

Once the CoVEn calculates classification probability and severity alert, the same data are also transmitted in the blockchain. To create the blockchain, the DG bundles the transactions of messages (oximeter messages and alerts) in a single block. Being the consortium blockchain, the proof of blockchain member authenticity is not important. However, some special issues like compromised peers or 51% handling problem can be researched as future work on this present framework. The use of the blockchain in the present solution is having the objectives such that using the severity and classification results, the medical help can be properly provided to the required patients of COVID suspects. Along with this, every stakeholder involved in the process; for example, medical officers, medicine suppliers, and resource managers can also be beneficial using the information of the this blockchain. Moreover, an overall monitoring process by the government can be issued. The block generation is shown in Fig. 5. Blocks are generated periodically by the CoVEn

7). Consensus and Chaining of Blocks:

Reputation-based Byzantine fault tolerant (RBFT) is used in the framework as it is suitable for a consortium network. It provides the required benefits of decentralization, transaction finality, security and reliability, increased throughput, and reduced delay [48]. In the presented framework, a customization of RBFT is executed to reach the consensus decision. After the creation of the block , the validator broadcast it in the blockchain network. The members of the blockchain validate the information of the block individually and sign the header of the block initiated. The signatures from the entities are working as votes. The use of the consortium blockchain and this vote-based consensus help in advantageous factors of low latency, high speed and prevention of 51% attacks. For signature, lightweight identity-based signature is used [49]. However, any other signature schemes can also be used here. Algorithm 6 shows the consensus approach. We assume number of members in the consortium and unique signatures to be executed on the block for the block to be verified. Here, verification only needs to be checked for the integrity of the block information and data availability in distributed orientation. RBFT functioning is shown in Fig. 6.

Algorithm 6 Customized RBFT and Block Chaining

• 1:

  Input:

• 2:

  Output: Consensus decision

• 3:

  CoVEn: Broadcast

• 4:

  Verify the transactions and write into local transaction pool

• 5:

  for (member=i to N)

• 6:

  { calculate Sig( :header);

• 7:

  }

• 8:

  If

• 9:

  {

• 10:

  NTP server invoke

• 11:

  Compute timestamp and hash

• 12:

  Consensus = true

• 13:

  Update the blockchain

• 14:

  }

• 15:

  Else

• 16:

  Wait for next time period T

• 17:

  Return consensus