# MHCOOS: An Offline-Online Certificateless Signature Scheme for M-Health Devices

Authors: Abigail Akosua Addobea; Jun Hou; Qianmu Li
Journal: Security and Communication Networks
 (2020)

---

## Abstract

Current trends of mobile technology have seen a tremendous growth in its application in smart healthcare. This has resulted in the adoption and implementation of mobile health (m-health) systems by providing health assistance to the aging population. Despite its advantageous benefits, its computational complexities cannot be overlooked. M-health devices are portable processing tiny equipment with limited computational capabilities thereby making them complex for the implementation of public key cryptosystems. In spite of this, an Offline-Online signature scheme called the MHCOOS has been proposed to solve the difficulties in the computational ability. The scheme enjoys the following benefits by splitting the signing part into both offline and online phases. The offline phase performs heavy computations when a message is absent, whereas lighter computations are performed at the online stage when a message is present. Secondly, the online computations are extremely fast due to the already computed offline signature value and lighter pairings involved. Our performance analysis demonstrates how the proposed scheme outperforms other schemes. Finally, the hardness of the scheme is proven under the Bilinear Diffie–Hellman (BDH) and Computational Diffie–Hellman (CDH) problem in the random oracle model.


---

## Body

## 1. Introduction

M-health is a current technology by which its innovation uses mobile devices or smartphones to support public health and medicinal purposes. It forms a connection between Electronic Health (E-health) and smart phone technology. The practice involves monitoring, capturing, analyzing, and processing body signals recorded from biosensors embedded in the mobile devices and transferring the information onto a virtual cloud system. The ubiquitous advantage of mobile health technology allows patients and healthcare professionals to access their data anywhere and anytime. One of the advantages the m-health program provides is the reduction of the number of outpatient’s visits to the hospitals since patients can manage their health problems in their home without the need to travel to the health care units. It is an effective and a better health solution system when the patients’ live very far away from their health facilities. Mobile health platforms enable health practitioners to remotely monitor their patients’ health and give advice or prescriptions without the patient having to travel to the health center. It is without any doubt that mobile platforms are becoming more and more user friendly, computationally powerful, readily available and this has led innovators to begin to develop mobile apps of increasing complexity to leverage the portability these mobile platforms can offer. Some of the new mobile apps specifically target the assistance of individuals in relation to their own health and wellness management.Other mobile apps target towards healthcare providers to improve and facilitate the delivery of patient care. With the advent of mobile health, manufacturers incorporate commercial health apps during manufacturing into mobile devices to record health data statistics such as the heart rate, check pulses, monitor blood pressure, and check the fitness levels of patients, whereas some mobile health sensors are implanted into the body to monitor and observe the physical activity of patients. The European Commission funds a project named the MobiHealth. They explained how patients wear a lightweight monitoring system in accordance with their health needs. Their system requires shorter or longer monitoring where patients need not stay in the hospital for monitoring (http://www.mobihealth.org/).Despite the enormous advantages m-health has to offer, the problems encountered cannot be overlooked. Most mobile devices that carry out health functions are fragile lightweight devices, with limited computational capabilities and minimal processing power. Its interactivity to large cooperated networks obstructs their functionality. Most public key cryptosystems proposed in the literature involve heavy computations, and its implementation has not been suitable for mobile health devices. Likewise, their limited processing nature makes it difficult to perform excessive computational tasks. Algorithms in security protocols involve heavy computations that impede the security performance of m-health devices.


### 1.1. Our Contributions

We propose an Offline-Online Certificateless Scheme for m-health devices (mobile health devices). The idea is to split the Certificateless signature into offline and online methods. The motivation for choosing both schemes was influenced by Certificateless cryptography (CL-PKC) as introduced by Al-Riyami [1].He identified the benefits of being suitable for the lightweight infrastructure. The CL-PKC dealt with the elimination of the certificate management problem in the traditional PKI and also eliminated the key escrow problem in Identity-Based Cryptography (IBC). Similarly, CL-PKC is appropriate for low-bandwidth and lower power situations such as the mobile security applications [1]. The offline-online signature methods as presented by Even et al. [2] are useful for storage-limited devices. The execution of their method makes use of the offline phase to execute excessive computations whilst the device is at the idle state and no message is available. It further stores the message without knowing the signed message [2].MHCOOS scheme has the following advantages:(i)
It is a lightweight signature scheme that incorporates both Certificateless signature and Offline-Online Methods into one signature scheme. Thus, the Certificateless signature scheme is lightweight because the signature part is divided into both Offline and Online signing phases.(ii)
The Offline computations are performed whenever the mobile health device has not recorded any message (thus, there is no message available), and the online computations are performed when the device has recorded a message. Secondly, heavy computations occur at the Offline phase, which an offline-computed signature value is produced whilst lighter computations take place at the online phase with the already computed offline signature value.(iii)
Our scheme is attractive for mobile devices used for health applications because it does not require heavy cryptographic computations especially at the signing stage where most computations take place. Heavy computations such as bilinear pairings were not initiated which present great advantages to our scheme.(iv)
Due to the lighter computations initiated, there is optimum reduction in the overall operational overhead cost. Thus, the operational overhead cost (computation and communication cost) is much lower and insignificant.The proposed scheme is existential unforgeable under the adaptive chosen message attack against the Type I and Type II adversaries. Furthermore, the scheme is proven to be hard under the CDH and BDH assumptions in the random oracle.


### 1.2. System Requirements

For every IOT health system, there are some fundamental requirements needed to achieve in the design process which are mentioned and expounded as follows:(i)
Authentication: entities within the system should register and have legitimate access to the medical server(ii)
Device traceability: unauthorized persons should not be able to track messages (health data) sent from the client’s mobile device to the server during the online phase(iii)
Message availability: client’s health information should be readily available at the server side for easy access by the Healthcare Terminal Point(iv)
Anti-interception attack: no unscrupulous persons can gain access to the system to alter messages between the mobile device and the server as well as the server and the Healthcare Terminal Point(v)
User anonymity: Adversaries should not be able to extract user’s identity whilst the users submit their ID to the medical server during the registration phase


### 1.3. Related Work

Security is a major issue in the implementation of the m-health system. Many public key cryptosystems have been proposed for devices with low operational functionality. An example is the introduction of Elliptic Curve cryptography (ECC). Mana gave several important traditional cryptomethods, which fit into m-health context. He further suggested ECC to be an efficient public key cryptographic system suitable for mobile devices. The use of ECC for devices on the mobile health network is due to its smaller key sizes, but its energy requirements are far higher as compared to symmetric cryptosystems [3]. Tan and Wang [4] proposed a lightweight Identity-Based Encryption (IBE) for Body Sensor Networks (BSN). Their approach had several shortcomings: higher execution time, greater energy consumption due to increased computational overhead, and higher storage requirements because of public key storage. Some other book of thoughts proposed several schemes desirable for devices with acute bandwidth problems. The notion of the Offline-Online digital signature scheme was proposed by Even et al. [2]. Their scheme was applicable for low power constrained devices, where any digital signature scheme can be converted into an offline and online signing methods.Liu [5] considered their scheme [2] inefficient because of the quadratic factor increment. Most of the schemes proposed in the literature based on Identity-Based Cryptography (IBC) were suitable for most Sensor Networks but not for devices with limited computational power. However, this approach suffers from the key escrow problem where an untrusted Key Generation Center (KGC) could compute private keys of users since the KGC has the power to generate private keys.To solve the key escrow problem, Al-riyami and Paterson [1] proposed the Certificateless cryptography where users need not worry about the compromise of their private keys. In Certificateless cryptography, the KGC computes the partial private keys after the user sends their identity. The user then computes the full private keys. It also stated in their literature that their scheme supports lightweight infrastructure with low-bandwidth requirements.It is difficult to find a cryptographic scheme suitable for m-health, and a number of literatures written focus more on the security and privacy aspect. Other literature studies barely focused on the proposal of the cryptographic scheme for m-health devices. Zhou [6] proposed a lightweight Signcryption protocol (CLGSC) designed for data transmission in m-health systems. In our work, we focused on proposing a technique for m-health devices by splitting our Certificateless scheme into both offline and online phases to further lessen the computational time during the device operation.


### 1.4. Organization of the Paper

The rest of the paper is divided into the following sections. Section2 highlights on the preliminary and complexity assumptions. In Section 3, a brief description of the Offline-Online Certificateless Signatures model is given. The formal model of the MHCOOS scheme is introduced in Section 4. Section 5 deals with the performance comparison of our scheme with other schemes in the literature. Section 6 presents the conclusion.


## 1.1. Our Contributions

We propose an Offline-Online Certificateless Scheme for m-health devices (mobile health devices). The idea is to split the Certificateless signature into offline and online methods. The motivation for choosing both schemes was influenced by Certificateless cryptography (CL-PKC) as introduced by Al-Riyami [1].He identified the benefits of being suitable for the lightweight infrastructure. The CL-PKC dealt with the elimination of the certificate management problem in the traditional PKI and also eliminated the key escrow problem in Identity-Based Cryptography (IBC). Similarly, CL-PKC is appropriate for low-bandwidth and lower power situations such as the mobile security applications [1]. The offline-online signature methods as presented by Even et al. [2] are useful for storage-limited devices. The execution of their method makes use of the offline phase to execute excessive computations whilst the device is at the idle state and no message is available. It further stores the message without knowing the signed message [2].MHCOOS scheme has the following advantages:(i)
It is a lightweight signature scheme that incorporates both Certificateless signature and Offline-Online Methods into one signature scheme. Thus, the Certificateless signature scheme is lightweight because the signature part is divided into both Offline and Online signing phases.(ii)
The Offline computations are performed whenever the mobile health device has not recorded any message (thus, there is no message available), and the online computations are performed when the device has recorded a message. Secondly, heavy computations occur at the Offline phase, which an offline-computed signature value is produced whilst lighter computations take place at the online phase with the already computed offline signature value.(iii)
Our scheme is attractive for mobile devices used for health applications because it does not require heavy cryptographic computations especially at the signing stage where most computations take place. Heavy computations such as bilinear pairings were not initiated which present great advantages to our scheme.(iv)
Due to the lighter computations initiated, there is optimum reduction in the overall operational overhead cost. Thus, the operational overhead cost (computation and communication cost) is much lower and insignificant.The proposed scheme is existential unforgeable under the adaptive chosen message attack against the Type I and Type II adversaries. Furthermore, the scheme is proven to be hard under the CDH and BDH assumptions in the random oracle.


## 1.2. System Requirements

For every IOT health system, there are some fundamental requirements needed to achieve in the design process which are mentioned and expounded as follows:(i)
Authentication: entities within the system should register and have legitimate access to the medical server(ii)
Device traceability: unauthorized persons should not be able to track messages (health data) sent from the client’s mobile device to the server during the online phase(iii)
Message availability: client’s health information should be readily available at the server side for easy access by the Healthcare Terminal Point(iv)
Anti-interception attack: no unscrupulous persons can gain access to the system to alter messages between the mobile device and the server as well as the server and the Healthcare Terminal Point(v)
User anonymity: Adversaries should not be able to extract user’s identity whilst the users submit their ID to the medical server during the registration phase


## 1.3. Related Work

Security is a major issue in the implementation of the m-health system. Many public key cryptosystems have been proposed for devices with low operational functionality. An example is the introduction of Elliptic Curve cryptography (ECC). Mana gave several important traditional cryptomethods, which fit into m-health context. He further suggested ECC to be an efficient public key cryptographic system suitable for mobile devices. The use of ECC for devices on the mobile health network is due to its smaller key sizes, but its energy requirements are far higher as compared to symmetric cryptosystems [3]. Tan and Wang [4] proposed a lightweight Identity-Based Encryption (IBE) for Body Sensor Networks (BSN). Their approach had several shortcomings: higher execution time, greater energy consumption due to increased computational overhead, and higher storage requirements because of public key storage. Some other book of thoughts proposed several schemes desirable for devices with acute bandwidth problems. The notion of the Offline-Online digital signature scheme was proposed by Even et al. [2]. Their scheme was applicable for low power constrained devices, where any digital signature scheme can be converted into an offline and online signing methods.Liu [5] considered their scheme [2] inefficient because of the quadratic factor increment. Most of the schemes proposed in the literature based on Identity-Based Cryptography (IBC) were suitable for most Sensor Networks but not for devices with limited computational power. However, this approach suffers from the key escrow problem where an untrusted Key Generation Center (KGC) could compute private keys of users since the KGC has the power to generate private keys.To solve the key escrow problem, Al-riyami and Paterson [1] proposed the Certificateless cryptography where users need not worry about the compromise of their private keys. In Certificateless cryptography, the KGC computes the partial private keys after the user sends their identity. The user then computes the full private keys. It also stated in their literature that their scheme supports lightweight infrastructure with low-bandwidth requirements.It is difficult to find a cryptographic scheme suitable for m-health, and a number of literatures written focus more on the security and privacy aspect. Other literature studies barely focused on the proposal of the cryptographic scheme for m-health devices. Zhou [6] proposed a lightweight Signcryption protocol (CLGSC) designed for data transmission in m-health systems. In our work, we focused on proposing a technique for m-health devices by splitting our Certificateless scheme into both offline and online phases to further lessen the computational time during the device operation.


## 1.4. Organization of the Paper

The rest of the paper is divided into the following sections. Section2 highlights on the preliminary and complexity assumptions. In Section 3, a brief description of the Offline-Online Certificateless Signatures model is given. The formal model of the MHCOOS scheme is introduced in Section 4. Section 5 deals with the performance comparison of our scheme with other schemes in the literature. Section 6 presents the conclusion.


## 2. Preliminaries

This section highlights the conceptual properties of bilinear pairings. LetG1 be an additive group of order qG1,+ and G2 a multiplicative group of the same order G2,× and P being a generator. The structure of bilinear pairing is represented as e∧:G1×G1⟶G2 with the following properties:(1)
Bilinearity:∀ R,S,T∈G1,e∧R+S,T=e∧R,Te∧S,T and e∧R,S+T=e∧R,Se∧R,T(2)
Nondegeneracy:e∧P,P≠1G2(3)
Computability: there exists an efficient algorithme∧P,Q for all P,Q∈G1(4)
For allu∈G1,v∈G2,a,b∈Ζ,e∧ua,vb=e∧u,vabThe bilinear maps are derived from both Weil and Tate Pairing of an elliptic curve over a finite field. Boneh and Franklin [7] gave a more detailed approach on Bilinear Pairings on Tate and Weil pairings and elliptic curves for efficiency and security.


### 2.1. Complexity Assumptions

This paper is based on the following computational assumptions which are assumed to be hard to break by an attacker by any probabilistic polynomial time (PPT) algorithm:(a)
Discrete Logarithmic Problem (DLP). Given an instance g,ga∈G1 with g as the generator and a∈Zr∗, where a is unknown. The discrete logarithmic problem (DLP) in G requires the value of a to be computed. Thus, the advantage for any probabilistic polynomial time algorithm A, computing a is negligibly small.(b)
Computational Diffie–Hellman Problem (CDH). Given g,ga,gb∈G1 with generator g and a,b∈Zr∗, where a,b are unknowns. Our task is to compute C=gab in G1. The CDH problem is assumed to be a computationally hard problem. This means that for any probabilistic polynomial time algorithm A, the advantage of computing the algorithm is negligibly small.(c)
Bilinear Diffie–Hellman Parameter Generator (BDH-PG). A Bilinear Diffie–Hellman parameter generator (BDH-PG) is defined as the probabilistic polynomial time- (PPT-) bounded algorithm that takes the security parameter k∈Zr∗ as the input and generates a tuple r,G1,G2,e∧,P.(d)
MHCOOS scheme is secure against Typei adversary if the probability that an adaptively chosen message AdvMLCOOS,AiBDH−CMAk can win Game i where i=1,2. The MHCOOS scheme is secure if AdvMLCOOS,AiBDH−CMAk is negligible. Thus, AdvMLCOOS,AiBDH−CMAk≤ε.(e)
MHCOOS is existentially unforgeable against adaptive message attack if it is secure against adversaryi. Thus, AdvMLCOOS,AiBDH−CMAk≤ε holds, respectively.


## 2.1. Complexity Assumptions

This paper is based on the following computational assumptions which are assumed to be hard to break by an attacker by any probabilistic polynomial time (PPT) algorithm:(a)
Discrete Logarithmic Problem (DLP). Given an instance g,ga∈G1 with g as the generator and a∈Zr∗, where a is unknown. The discrete logarithmic problem (DLP) in G requires the value of a to be computed. Thus, the advantage for any probabilistic polynomial time algorithm A, computing a is negligibly small.(b)
Computational Diffie–Hellman Problem (CDH). Given g,ga,gb∈G1 with generator g and a,b∈Zr∗, where a,b are unknowns. Our task is to compute C=gab in G1. The CDH problem is assumed to be a computationally hard problem. This means that for any probabilistic polynomial time algorithm A, the advantage of computing the algorithm is negligibly small.(c)
Bilinear Diffie–Hellman Parameter Generator (BDH-PG). A Bilinear Diffie–Hellman parameter generator (BDH-PG) is defined as the probabilistic polynomial time- (PPT-) bounded algorithm that takes the security parameter k∈Zr∗ as the input and generates a tuple r,G1,G2,e∧,P.(d)
MHCOOS scheme is secure against Typei adversary if the probability that an adaptively chosen message AdvMLCOOS,AiBDH−CMAk can win Game i where i=1,2. The MHCOOS scheme is secure if AdvMLCOOS,AiBDH−CMAk is negligible. Thus, AdvMLCOOS,AiBDH−CMAk≤ε.(e)
MHCOOS is existentially unforgeable against adaptive message attack if it is secure against adversaryi. Thus, AdvMLCOOS,AiBDH−CMAk≤ε holds, respectively.


## 3. Formal Model of the Offline-Online Certificateless Signature Scheme

In this section, we provide a conventional model of an Offline-Online Certificateless Signature (OOCS) Scheme. The OOCS scheme consists of six polynomial time algorithms. Table1 presents the symbols and notations used in this paper with their corresponding meanings.Table 1
Key symbols used in the paper.
Symbols
Meaning
G
1
,
+
Additive notation in group 1
G
2
,
×
Multiplication notation in group 2
H
1
,
H
2
,
H
3
Three one-way hash functions
s
Secret value selected by KGC
msk
,
mpk
Master secret keys and master public keys
ID
i
Identity of the user
L
Secret value of the user in the MHCOOS scheme
S
K
ID
Private key
x
i
Secret value of the OOCS scheme
P
K
ID
Public key
prime ordr
Prime orderr
D
ID
Partial private key
l
System public parameter list published by the KGC
σ
Offline signature value
δ
Online signature value
MS
Medical server unit
MD
User’s mobile device
HTP
Healthcare Terminal Point


### 3.1. Syntax

(1)
Setup. KGC chooses 1k as a security parameter, returns a master secret key msk, and publishes a list of system public parameters list l.
(2)
Partial-Private-Key-Extract. This algorithm takes as inputs system public parameter list l,msk the identity of a user IDi∈0,1∗, and returns an output DID as the partial private key.
(3)
Set-Secret-Value. User performs this algorithm by taking system public parameters l and a user’s IDi∈0,1∗ as inputs and returns a secret value xi.
(4)
Set-Private-Key. The algorithm takes system public parameters l, the secret value xi, the partial private key DID, and returns private key SKID.
(5)
Set-Public-Key. The algorithm takes system public parameters l, the secret value xi, and returns public key PKID.
(6)
CL-OffSign. Using system public parameters l, the private key SKID of the user with identity IDi∈0,1∗and without the availability of the message, this algorithm generates an offline component value σ.
(7)
CL-OnSign. Given the message, m∈0,1∗, the signer’s identity IDi, the full private key SKID, and the offline component σ as the input, the signer executes this algorithm in the online phase with the availability of the message and generates the signature value δ.
(8)
Verify. The verification algorithm performed to determine if the signature is valid or not. It takes the identity IDi of the signer, the message m∈0,1∗, the Certificateless Signature δ, and the Public key PKID of the signer. The algorithm generates true if the signature δ is valid and null ⊥ if it is invalid.Figure1 gives a diagrammatic approach of the respective phases of an Offline-Online scheme in the ordinary literature.Figure 1
Descriptive model of the OOCS scheme. The diagram describes the respective phases of an ordinary Offline-Online scheme in the literature.


### 3.2. System Model

We provide a description of the entities within the MHCOOS model and their functionalities within the system in Figure2. The MHCOOS system consists of the user’s mobile device (MD), medical server collection unit (MS), and the Healthcare Terminal Point (HTP).(a)
The user’s mobile device (MD) has installed sensor nodes that read, sense, and collect all vital information and store them onto to the mobile device. The MD first registers and authenticates itself to the MS. The mobile device further transfers all collected vital data to the medical server collection unit.(b)
The medical server collection unit (MS) stores the received vital information from the user’s mobile device. It is responsible for the registration and authentication of the mobile clients as well as the users (doctors and nurses) from the Healthcare Terminal Point.(c)
The Healthcare Terminal Point requests for the vital information of users from the medical server collection unit. It further provides the necessary prescription in case of any detected health disorder.Figure 2
A typical mobile health (m-health) model.


## 3.1. Syntax

(1)
Setup. KGC chooses 1k as a security parameter, returns a master secret key msk, and publishes a list of system public parameters list l.
(2)
Partial-Private-Key-Extract. This algorithm takes as inputs system public parameter list l,msk the identity of a user IDi∈0,1∗, and returns an output DID as the partial private key.
(3)
Set-Secret-Value. User performs this algorithm by taking system public parameters l and a user’s IDi∈0,1∗ as inputs and returns a secret value xi.
(4)
Set-Private-Key. The algorithm takes system public parameters l, the secret value xi, the partial private key DID, and returns private key SKID.
(5)
Set-Public-Key. The algorithm takes system public parameters l, the secret value xi, and returns public key PKID.
(6)
CL-OffSign. Using system public parameters l, the private key SKID of the user with identity IDi∈0,1∗and without the availability of the message, this algorithm generates an offline component value σ.
(7)
CL-OnSign. Given the message, m∈0,1∗, the signer’s identity IDi, the full private key SKID, and the offline component σ as the input, the signer executes this algorithm in the online phase with the availability of the message and generates the signature value δ.
(8)
Verify. The verification algorithm performed to determine if the signature is valid or not. It takes the identity IDi of the signer, the message m∈0,1∗, the Certificateless Signature δ, and the Public key PKID of the signer. The algorithm generates true if the signature δ is valid and null ⊥ if it is invalid.Figure1 gives a diagrammatic approach of the respective phases of an Offline-Online scheme in the ordinary literature.Figure 1
Descriptive model of the OOCS scheme. The diagram describes the respective phases of an ordinary Offline-Online scheme in the literature.


## 3.2. System Model

We provide a description of the entities within the MHCOOS model and their functionalities within the system in Figure2. The MHCOOS system consists of the user’s mobile device (MD), medical server collection unit (MS), and the Healthcare Terminal Point (HTP).(a)
The user’s mobile device (MD) has installed sensor nodes that read, sense, and collect all vital information and store them onto to the mobile device. The MD first registers and authenticates itself to the MS. The mobile device further transfers all collected vital data to the medical server collection unit.(b)
The medical server collection unit (MS) stores the received vital information from the user’s mobile device. It is responsible for the registration and authentication of the mobile clients as well as the users (doctors and nurses) from the Healthcare Terminal Point.(c)
The Healthcare Terminal Point requests for the vital information of users from the medical server collection unit. It further provides the necessary prescription in case of any detected health disorder.Figure 2
A typical mobile health (m-health) model.


## 4. Proposed Scheme

We propose the MHCOOS Scheme in this section. The scheme consists of six algorithms.


### 4.1. System Initialization Phase

The medical server firstly initializes the system by setting up the following processes using a security parameter1k to perform the following steps:(a)
Given two cyclic groupsG1,+andG2,× of prime order r, a pairing map e∧:G1×G1⟶G2.(b)
P becomes a generator of an additive group G1,+ of prime ordrP.(c)
The MS selects its secret value,s∈Rℤr∗ and sets Ppub=sP.(d)
Chooses three one-way hash functionsH1:0,1∗⟶G1 and H2:0,1∗×G1⟶Zr∗, H3:0,1∗×G1×G1⟶Zr∗.(e)
MS performs this algorithm to generatemsk,mpk: master secret keys and master public keys, respectively. Then, publishes in the public directory list l=G1,G2,e∧,r,Ppub,H1,H2,H3.


### 4.2. Registration Phase

The mobile user registers its identity, ID with the medical server MS. The MS fetches the public directory listl, its master secret key, msk, and obtains the user’s identity, ID∈0,1∗ from the user to register the user’s details in the system by making the following computations:(a)
ComputeQID=H1ID; hashes the user’s identity(b)
Compute partial private key,DID=sH1ID=sQID


### 4.3. Key Setup Phase

The user obtains the already computed Partial Private Key from MS and further sets up its device registration by firstly generating a secret value. It then further computes its full private key and public key, respectively.(a)
Set-Secret-Value. The user ID randomly picks a secret value L∈Zr∗.(b)
Set-Private-Keys. With the secret value L and with partial Private key DID, user generates its full, Private key SKID=1/L+sH1IDP(c)
Set-Public-Key. User sets its public key PKID=LPPub


### 4.4. Authentication Phase

The device of the mobile user performs various signing processes at both stages to authenticate itself and transmit the captured health data to the medical server (MS).


### 4.5. Signing Phase

This stage of the algorithm is split into two, namely, CL-Offline signature and CL-Online signature, respectively. The algorithm works as follows.


#### 4.5.1. CL-Offline Signature

Usually, there is no message present; thus, the mobile device has not recorded any health activity such as checking pulses or the heart rate and any other activities. It performs the following minor operations to generate an offline signature valueσ used to authenticate itself to the MS.This part of the signing algorithm uses the following parameter public directory listl, SKID, user ID∈0,1∗, without the presence of a message, m=∅ to perform the following operations to generate an offline signature value, σ.(a)
Choose randomlys1,t∈RZr∗(b)
ComputeU=s1P(c)
SetY=H2U,ID,PKID(d)
ComputeX=tSKIDReturns Offline signature valueσ, where σ=U,Y,t,s1.


#### 4.5.2. CL-Online Signature

During the online signature phase, when the mobile device has recorded some health activities, thus with the presence of a messagem≠∅, it performs the following online operations with the already offline computed signature value and transmits them securely on to the medical server, MS. The MS further stores these values in a secure form till information is requested.(a)
Computeh=H3m,U,IDi,SKID(b)
Computeθ=s1ht−1modp(c)
Output online signature valueδ=U,X,θ


### 4.6. Verify

At this stage, the Healthcare Terminal Point accesses the MS to request for the user’s data and also verifies the veracity of user’s health data.(a)
Computeh=H3m∈0,1∗,U,IDi,SKID(b)
Ife∧Xδ,LP+Ppub=e∧U,Ph, accept signature(c)
Ife∧Xδ,LP+Ppub≠e∧U,Ph, reject signature


### 4.7. Correctness for Signature

The HTP further verifies using the correctness signature which is as follows:(1)e∧:Xθ,LP+Ppub=e∧:U,Ph=e∧:tSKIDs1ht−1P,LP+sP=e∧:tSKIDs1ht−1P,L+sP=e∧:t1L+sPsht−1,L+sP=e∧:s1hP,P=e∧:s1P,Ph=e∧:U,Ph.The proposed algorithm MHCOOS scheme performs better in the sense that the offline-online approach introduced at the signature stage is to reduce excess computational cost and communication overhead. No pairing computation is adopted at the signature stage owing to the fact that pairing computations are time consuming and are slower to execute when compared to other cryptographic computations like the scalar multiplication and hashing. At the offline stage, there is no message computation whilst minimal offline computations take place to generate an offline-computed value. When the mobile device records a message (health data), the online signature uses the message and the precomputed offline value to generate the online signature. This method promotes faster and quicker signature execution process.


### 4.8. Security Analysis

Theorem 1.
MHCOOS Scheme is proved to be existentially unforgeable (EUF-CMA) in the random oracle under the CDH assumption problem inG1; if Type 1 adversary AI can win the game with advantage ε at time T, it can make the following queries qHi to the Hash oracles Hi (where i=1,2,3), qE queries to the private-key extraction oracle, qPK queries to the public-key request oracle, and qsig queries to the signing oracle, and then the BDH problem can be solved with probability.(2)∈′>∈−3kqsigqH2+qsigqE+22−qH1qEqEqH1+12−k,T=t′+Oqsig+ktp+OqH1qH2+qEqH1qH2te,where T represents the total running time; the adversary would perform various queries. tp is the time to perform one pairing operation and te is the time to compute one exponentiation in G2.Proof.
The main purpose of the ChallengerC is to compute abcP from a tuple P,aP,bP,cp with the assumption that there exists an adversary AI capable of attacking the MHCOOS scheme with the above advantage.


#### 4.8.1. System Initialization Phase

LetP be a generator of the group and a be an unknown master key. The Challenger C sets Ppub=aP. The Challenger then updates an initially empty list li containing the tuple li=IDi,DID,SKID,PKID. During the game, AI starts issuing various queries in qHi as follows:(i)
H1 queries: the adversary AI is allowed to make qHi number of queries to the oracle Hi with a list identity IDi. AI selects j∈R1,qH1, where qH1 denotes the maximum number of queries. An identity IDi is submitted to the oracle H1, where i∈R1,qH1. The Challenger C checks if i=j and IDi=ID∗; if this is true, it updates a list l1 containing the tuple l1=IDi,Qi,yi and set Qi=bP and yi=⊥ (to indicate failure). If i≠j and IDi≠ID∗, the challenger gets yi and randomly sets Qi=yiP and saves the tuple l1=IDi,Qi,yi.


### 4.9. Key Setup Extraction Queries

(a)
Partial key extraction queries: ifIDi=ID∗, C performs a number of tasks and updates l with SKID,PKID, respectively, after getting an identity IDi query from AI. The tasks are as follows: C checks if l=IDi,DID,SKID,PKID,DID=⊥. If both conditions are true, C returns DID to the adversary AI. If the conditions are false, C sets partial private key DID=yi,Ppub=yiaP and returns DID to AI and updates the list l.
By inspection, if the listl≠IDi,DID,SKID,PKID, C updates the list l=IDi,DID,SKID,PKID by setting the following DID=yi,Ppub=yiaPandSKID,PKID=⊥ and adds them to the list, l.
(b)
Public key extraction queries:C performs a number of tasks and updates l, respectively, based on a query made by AI on identity IDi. The tasks are as follows: C checks the following: l=IDi,DID,SKID,PKIDandPKID≠⊥. If both conditions are true, C returns PKID to the adversary AI . If the conditions are false, C selects L∈Rℤr∗ and sets the following PKID=LPpub,SKID=L and returns PKID to AI, and then updates the list, l1.
By inspection, if the listl≠IDi,DID,SKID,PkID, C updates the list l with SKID,PKID. C selects L∗∈Rℤr∗ and sets the following PKID=LPpub,SKID=L and then updates l withSKID,PKID.
(c)
Secret value extraction queries: ifIDi=ID∗, C performs a number of tasks and updates the list, l with SKID,DID after obtaining an identity IDi query from AI. C checks the following: l=IDi,DID,SKID,PKID,PKID=⊥,DID=⊥. If these conditions are true, C executes Partial Key Extraction and Public Key Extraction Queries to obtain DID,PKID=L∗Ppub,SKID=L∗, respectively.
By inspection, if the listl≠ID,DID,SKID,PKID, C executes Partial Key Extraction and Public Key Extraction Queries to obtain DID,PKID,SKID and updates the list l with full private keys DID,SKID, respectively.
(d)
Public key replacementIDi,PKID′ queries: C performs the following operations and updates the list when AI makes the query on IDi,PKID′. C sets PKID=PKID′,SKID if the list l contains IDi,DID,SKID,PKID. Otherwise, C sets DID,PKID=PKID′,SKID=⊥ and updates the list l accordingly.(i)
H2 queries: C checks the list l2 = IDi,m,θ∗,PkID,bi, following a query from AIonm,θ,PKID. It then returns the list, l2 to AI if the list exists. Otherwise, it adds bi as a hash value to the list l2 by selecting bi∈Rℤr∗.(ii)
H3 queries: C checks the list l3 = IDi,m,θ,PKID,bi,cj, following query from AIonIDi,m,θ,PkID,cj. C then returns the list, l3 to AI if l3 exists. Otherwise, C adds cj as a hash value to the list L3 by selecting cj∈Rℤr∗.


### 4.10. Queries at the Authentication Phase

(a)
Signature queries:AI queries the challenger C, for a signature on an adaptive chosen message mi of a user IDi. The Challenger C checks the list, l=IDi,DID,SKID,PKID. C runs Partial Key Extraction and Public Key Extraction queries, respectively, if DID≠∅,SKID,PKID≠∅. AI is also allowed to generate a corresponding signature of any arbitrary length message mi with its full private key DID,SkID under the condition that IDi=ID∗ and PKID are the public key and SKID=1/L+a as the private key, where a,L∈ℤr∗. The signature value returned from the Challenger is not a valid signature since the public key has been replaced by AI, and the Challenger may not know the corresponding public key.The Challenger computes the following:


#### 4.10.1. CL-Offline Signature

(a)
Choose randomlys1,t,a,b∈RZr
(b)
ComputeU=s1∗P and set s1∗=ab
(c)
SetY=H2U,IDi,PKID
(d)
ComputeX=tSKID
(e)
Output offline signatureσ, where σ=U,Y,t,s1∗


#### 4.10.2. CL-Online Signature

(a)
Computecj=H3m,U,IDi,SKID
(b)
Computeθ∗∗=s1∗ct−1modp
(c)
Output online signature valueδ=U,X,θFor hash queries,l3 = IDi,m,θ,PKID,bi,cj, set θ∗∗=s1∗ct−1modp, and update θ=θ∗∗.


### 4.11. Correctness for Signature

The Correctness for Signature is depicted as follows:(3)e∧:Xθ∗∗,LP+Ppub=e∧:tSKIDs1∗ct−1P,LP+aP=e∧:tSKIDs1∗ct−1P,L+aP=e∧:t1L+aPs1∗ct−1,L+aP=e∧:abcP,P=e∧:P,Pabc.Hence, this is the BDH instance to the above problem which is solved for the given random listP,aP,bP,cP,wherea,b,c∈RZr∗. It is assumed that the BDH problem is difficult to break by any probabilistic polynomial time (PPT) algorithm. Therefore, the MHCOOS scheme is secure under adaptive chosen message attacker AI in the random oracle.Theorem 2.
MHCOOS Scheme is proved to be existentially unforgeable (EUF-CMA) in the random oracle under the CDH assumption problem inG1 if the Type II adversary AII can win the game with advantage ε at time T can make the following queries qHi to the Hash oracles (Hi,wherei=1,2,3), qE queries to the private-key extraction oracle, qPK queries to the public-key request oracle, and qsig queries to the signing oracle, then the CDH problem can be solved with probability.(4)ε′>ε−3kqsigqH2+qsigqE+22−qH1qEqEqH1+12−k.Proof.
The theorem relies on the assumption that there exists an adversaryAII with considerable powers having the advantage to attack the scheme without any constraint. The goal is to compute abP from a tuple P,aP,bP with assumption that there exists an adversary AII capable of attacking the MHCOOS.


### 4.12. System Initialization Phase

At the Setup phase, Challenger,C sets P as the generator G1 and sets Ppub=sP, where s is the master key of the KGC. Adversary, AII can act as the dishonest KGC. C then updates an initially empty list li containing the list IDi,SKID,PKID during the game and responds to the various queries in qHi as follows:(i)
H1 queries: the adversary AII makes qH1 number of queries to the oracle H1 with an identity IDi. AII selects j∈R1,qH1, where qH1 denotes the maximum number of queries. The Challenger C checks if i=j and IDi=ID∗; if this true, it updates a list l1 containing the tuple IDi,Qi,yi and sets Qi=aP and yi=⊥ for failure. If i≠j and IDi≠ID∗, the challenger gets yi randomly and sets Qi=yiP and updates the tuple IDi,Qi,yi.


### 4.13. Key Setup Extraction Queries

(a)
Public key extraction queries:C performs number of tasks and updates l with SKID,PKID after getting an identity IDi query from AII. The tasks are as follows: C checks the following: l=IDi,SKID,PKID,PKID=⊥. If both conditions are true, C returns PKID to the adversary AI. If the conditions are false, it sets PKID≠⊥. C selects L∈ℤr∗ and sets PKID=bPpub,SKID=L and returns PKID to AII. By inspection, if the tuple does not contain IDi,SKID,PKID, C updates the list l with SKID,PKID by selecting L∈ℤr∗ and sets PKID=bPpub,SKID=L and returns PKID to AII.
(b)
Secret value extraction queries: ifIDi=ID∗, C performs some tasks and updates l with SKID after getting an identity IDi query from AII . The tasks are as follows: C checks the following: l=IDi,SKID,PKIDPKID=⊥. If the conditions return true, C executes Public Key Extraction Queries to obtain SKID=L,PKID=LPpub. By inspection, if l≠IDi,SKID,PKID, C executes Public Key Extraction Queries to obtain PKID,SKID and updates the list l with full private keys, SKID.(i)
H2 queries: C searches a list l2 if it contains the tuple m,θ,PKID,hi, following AII query on m,θ,PKID. C then returns the tuple to AII if the tuple exists. Otherwise, C adds bi as a hash value to the tuple l2 by selecting bi∈Rℤr∗.(ii)
H3 queries: C searches the list l3 = m,θ,PkID,bi,cj, following query from AIIonm,θ,PKID,bi. C then returns the list, l3 to AI if l3 exists. Otherwise, C adds cj as a hash value to the list l3 by selecting cj∈Rℤr∗.


### 4.14. Queries at the Authentication Phase

(a)
Signature queries:AII obtains IDi,mi and allowed query the Challenger C for a corresponding signature under the condition that IDi≠ID∗.The ChallengerC then searches for a list l, containing the tuple IDi,SKID,PKID. C executes Public Key extraction Queries if the following are not found SKID,PKID. AII is also allowed to generate a corresponding signature on any arbitrary length message mi with its full private key DID,SKID under the condition that IDi=ID∗.The Challenger computes the following:(5)e∧:U,P=e∧:s1∗P,P=e∧:abP,P=e∧:P,Pab.This is an instance to the CDH problem. It is known that the CDH problem is difficult to break by any probabilistic polynomial time (PPT) algorithm. Hence, the MHCOOS scheme is secure in CDH under adaptive chosen message attackerAII in the random oracle.


## 4.1. System Initialization Phase

The medical server firstly initializes the system by setting up the following processes using a security parameter1k to perform the following steps:(a)
Given two cyclic groupsG1,+andG2,× of prime order r, a pairing map e∧:G1×G1⟶G2.(b)
P becomes a generator of an additive group G1,+ of prime ordrP.(c)
The MS selects its secret value,s∈Rℤr∗ and sets Ppub=sP.(d)
Chooses three one-way hash functionsH1:0,1∗⟶G1 and H2:0,1∗×G1⟶Zr∗, H3:0,1∗×G1×G1⟶Zr∗.(e)
MS performs this algorithm to generatemsk,mpk: master secret keys and master public keys, respectively. Then, publishes in the public directory list l=G1,G2,e∧,r,Ppub,H1,H2,H3.


## 4.2. Registration Phase

The mobile user registers its identity, ID with the medical server MS. The MS fetches the public directory listl, its master secret key, msk, and obtains the user’s identity, ID∈0,1∗ from the user to register the user’s details in the system by making the following computations:(a)
ComputeQID=H1ID; hashes the user’s identity(b)
Compute partial private key,DID=sH1ID=sQID


## 4.3. Key Setup Phase

The user obtains the already computed Partial Private Key from MS and further sets up its device registration by firstly generating a secret value. It then further computes its full private key and public key, respectively.(a)
Set-Secret-Value. The user ID randomly picks a secret value L∈Zr∗.(b)
Set-Private-Keys. With the secret value L and with partial Private key DID, user generates its full, Private key SKID=1/L+sH1IDP(c)
Set-Public-Key. User sets its public key PKID=LPPub


## 4.4. Authentication Phase

The device of the mobile user performs various signing processes at both stages to authenticate itself and transmit the captured health data to the medical server (MS).


## 4.5. Signing Phase

This stage of the algorithm is split into two, namely, CL-Offline signature and CL-Online signature, respectively. The algorithm works as follows.


### 4.5.1. CL-Offline Signature

Usually, there is no message present; thus, the mobile device has not recorded any health activity such as checking pulses or the heart rate and any other activities. It performs the following minor operations to generate an offline signature valueσ used to authenticate itself to the MS.This part of the signing algorithm uses the following parameter public directory listl, SKID, user ID∈0,1∗, without the presence of a message, m=∅ to perform the following operations to generate an offline signature value, σ.(a)
Choose randomlys1,t∈RZr∗(b)
ComputeU=s1P(c)
SetY=H2U,ID,PKID(d)
ComputeX=tSKIDReturns Offline signature valueσ, where σ=U,Y,t,s1.


### 4.5.2. CL-Online Signature

During the online signature phase, when the mobile device has recorded some health activities, thus with the presence of a messagem≠∅, it performs the following online operations with the already offline computed signature value and transmits them securely on to the medical server, MS. The MS further stores these values in a secure form till information is requested.(a)
Computeh=H3m,U,IDi,SKID(b)
Computeθ=s1ht−1modp(c)
Output online signature valueδ=U,X,θ


## 4.5.1. CL-Offline Signature

Usually, there is no message present; thus, the mobile device has not recorded any health activity such as checking pulses or the heart rate and any other activities. It performs the following minor operations to generate an offline signature valueσ used to authenticate itself to the MS.This part of the signing algorithm uses the following parameter public directory listl, SKID, user ID∈0,1∗, without the presence of a message, m=∅ to perform the following operations to generate an offline signature value, σ.(a)
Choose randomlys1,t∈RZr∗(b)
ComputeU=s1P(c)
SetY=H2U,ID,PKID(d)
ComputeX=tSKIDReturns Offline signature valueσ, where σ=U,Y,t,s1.


## 4.5.2. CL-Online Signature

During the online signature phase, when the mobile device has recorded some health activities, thus with the presence of a messagem≠∅, it performs the following online operations with the already offline computed signature value and transmits them securely on to the medical server, MS. The MS further stores these values in a secure form till information is requested.(a)
Computeh=H3m,U,IDi,SKID(b)
Computeθ=s1ht−1modp(c)
Output online signature valueδ=U,X,θ


## 4.6. Verify

At this stage, the Healthcare Terminal Point accesses the MS to request for the user’s data and also verifies the veracity of user’s health data.(a)
Computeh=H3m∈0,1∗,U,IDi,SKID(b)
Ife∧Xδ,LP+Ppub=e∧U,Ph, accept signature(c)
Ife∧Xδ,LP+Ppub≠e∧U,Ph, reject signature


## 4.7. Correctness for Signature

The HTP further verifies using the correctness signature which is as follows:(1)e∧:Xθ,LP+Ppub=e∧:U,Ph=e∧:tSKIDs1ht−1P,LP+sP=e∧:tSKIDs1ht−1P,L+sP=e∧:t1L+sPsht−1,L+sP=e∧:s1hP,P=e∧:s1P,Ph=e∧:U,Ph.The proposed algorithm MHCOOS scheme performs better in the sense that the offline-online approach introduced at the signature stage is to reduce excess computational cost and communication overhead. No pairing computation is adopted at the signature stage owing to the fact that pairing computations are time consuming and are slower to execute when compared to other cryptographic computations like the scalar multiplication and hashing. At the offline stage, there is no message computation whilst minimal offline computations take place to generate an offline-computed value. When the mobile device records a message (health data), the online signature uses the message and the precomputed offline value to generate the online signature. This method promotes faster and quicker signature execution process.


## 4.8. Security Analysis

Theorem 1.
MHCOOS Scheme is proved to be existentially unforgeable (EUF-CMA) in the random oracle under the CDH assumption problem inG1; if Type 1 adversary AI can win the game with advantage ε at time T, it can make the following queries qHi to the Hash oracles Hi (where i=1,2,3), qE queries to the private-key extraction oracle, qPK queries to the public-key request oracle, and qsig queries to the signing oracle, and then the BDH problem can be solved with probability.(2)∈′>∈−3kqsigqH2+qsigqE+22−qH1qEqEqH1+12−k,T=t′+Oqsig+ktp+OqH1qH2+qEqH1qH2te,where T represents the total running time; the adversary would perform various queries. tp is the time to perform one pairing operation and te is the time to compute one exponentiation in G2.Proof.
The main purpose of the ChallengerC is to compute abcP from a tuple P,aP,bP,cp with the assumption that there exists an adversary AI capable of attacking the MHCOOS scheme with the above advantage.


### 4.8.1. System Initialization Phase

LetP be a generator of the group and a be an unknown master key. The Challenger C sets Ppub=aP. The Challenger then updates an initially empty list li containing the tuple li=IDi,DID,SKID,PKID. During the game, AI starts issuing various queries in qHi as follows:(i)
H1 queries: the adversary AI is allowed to make qHi number of queries to the oracle Hi with a list identity IDi. AI selects j∈R1,qH1, where qH1 denotes the maximum number of queries. An identity IDi is submitted to the oracle H1, where i∈R1,qH1. The Challenger C checks if i=j and IDi=ID∗; if this is true, it updates a list l1 containing the tuple l1=IDi,Qi,yi and set Qi=bP and yi=⊥ (to indicate failure). If i≠j and IDi≠ID∗, the challenger gets yi and randomly sets Qi=yiP and saves the tuple l1=IDi,Qi,yi.


## 4.8.1. System Initialization Phase

LetP be a generator of the group and a be an unknown master key. The Challenger C sets Ppub=aP. The Challenger then updates an initially empty list li containing the tuple li=IDi,DID,SKID,PKID. During the game, AI starts issuing various queries in qHi as follows:(i)
H1 queries: the adversary AI is allowed to make qHi number of queries to the oracle Hi with a list identity IDi. AI selects j∈R1,qH1, where qH1 denotes the maximum number of queries. An identity IDi is submitted to the oracle H1, where i∈R1,qH1. The Challenger C checks if i=j and IDi=ID∗; if this is true, it updates a list l1 containing the tuple l1=IDi,Qi,yi and set Qi=bP and yi=⊥ (to indicate failure). If i≠j and IDi≠ID∗, the challenger gets yi and randomly sets Qi=yiP and saves the tuple l1=IDi,Qi,yi.


## 4.9. Key Setup Extraction Queries

(a)
Partial key extraction queries: ifIDi=ID∗, C performs a number of tasks and updates l with SKID,PKID, respectively, after getting an identity IDi query from AI. The tasks are as follows: C checks if l=IDi,DID,SKID,PKID,DID=⊥. If both conditions are true, C returns DID to the adversary AI. If the conditions are false, C sets partial private key DID=yi,Ppub=yiaP and returns DID to AI and updates the list l.
By inspection, if the listl≠IDi,DID,SKID,PKID, C updates the list l=IDi,DID,SKID,PKID by setting the following DID=yi,Ppub=yiaPandSKID,PKID=⊥ and adds them to the list, l.
(b)
Public key extraction queries:C performs a number of tasks and updates l, respectively, based on a query made by AI on identity IDi. The tasks are as follows: C checks the following: l=IDi,DID,SKID,PKIDandPKID≠⊥. If both conditions are true, C returns PKID to the adversary AI . If the conditions are false, C selects L∈Rℤr∗ and sets the following PKID=LPpub,SKID=L and returns PKID to AI, and then updates the list, l1.
By inspection, if the listl≠IDi,DID,SKID,PkID, C updates the list l with SKID,PKID. C selects L∗∈Rℤr∗ and sets the following PKID=LPpub,SKID=L and then updates l withSKID,PKID.
(c)
Secret value extraction queries: ifIDi=ID∗, C performs a number of tasks and updates the list, l with SKID,DID after obtaining an identity IDi query from AI. C checks the following: l=IDi,DID,SKID,PKID,PKID=⊥,DID=⊥. If these conditions are true, C executes Partial Key Extraction and Public Key Extraction Queries to obtain DID,PKID=L∗Ppub,SKID=L∗, respectively.
By inspection, if the listl≠ID,DID,SKID,PKID, C executes Partial Key Extraction and Public Key Extraction Queries to obtain DID,PKID,SKID and updates the list l with full private keys DID,SKID, respectively.
(d)
Public key replacementIDi,PKID′ queries: C performs the following operations and updates the list when AI makes the query on IDi,PKID′. C sets PKID=PKID′,SKID if the list l contains IDi,DID,SKID,PKID. Otherwise, C sets DID,PKID=PKID′,SKID=⊥ and updates the list l accordingly.(i)
H2 queries: C checks the list l2 = IDi,m,θ∗,PkID,bi, following a query from AIonm,θ,PKID. It then returns the list, l2 to AI if the list exists. Otherwise, it adds bi as a hash value to the list l2 by selecting bi∈Rℤr∗.(ii)
H3 queries: C checks the list l3 = IDi,m,θ,PKID,bi,cj, following query from AIonIDi,m,θ,PkID,cj. C then returns the list, l3 to AI if l3 exists. Otherwise, C adds cj as a hash value to the list L3 by selecting cj∈Rℤr∗.


## 4.10. Queries at the Authentication Phase

(a)
Signature queries:AI queries the challenger C, for a signature on an adaptive chosen message mi of a user IDi. The Challenger C checks the list, l=IDi,DID,SKID,PKID. C runs Partial Key Extraction and Public Key Extraction queries, respectively, if DID≠∅,SKID,PKID≠∅. AI is also allowed to generate a corresponding signature of any arbitrary length message mi with its full private key DID,SkID under the condition that IDi=ID∗ and PKID are the public key and SKID=1/L+a as the private key, where a,L∈ℤr∗. The signature value returned from the Challenger is not a valid signature since the public key has been replaced by AI, and the Challenger may not know the corresponding public key.The Challenger computes the following:


### 4.10.1. CL-Offline Signature

(a)
Choose randomlys1,t,a,b∈RZr
(b)
ComputeU=s1∗P and set s1∗=ab
(c)
SetY=H2U,IDi,PKID
(d)
ComputeX=tSKID
(e)
Output offline signatureσ, where σ=U,Y,t,s1∗


### 4.10.2. CL-Online Signature

(a)
Computecj=H3m,U,IDi,SKID
(b)
Computeθ∗∗=s1∗ct−1modp
(c)
Output online signature valueδ=U,X,θFor hash queries,l3 = IDi,m,θ,PKID,bi,cj, set θ∗∗=s1∗ct−1modp, and update θ=θ∗∗.


## 4.10.1. CL-Offline Signature

(a)
Choose randomlys1,t,a,b∈RZr
(b)
ComputeU=s1∗P and set s1∗=ab
(c)
SetY=H2U,IDi,PKID
(d)
ComputeX=tSKID
(e)
Output offline signatureσ, where σ=U,Y,t,s1∗


## 4.10.2. CL-Online Signature

(a)
Computecj=H3m,U,IDi,SKID
(b)
Computeθ∗∗=s1∗ct−1modp
(c)
Output online signature valueδ=U,X,θFor hash queries,l3 = IDi,m,θ,PKID,bi,cj, set θ∗∗=s1∗ct−1modp, and update θ=θ∗∗.


## 4.11. Correctness for Signature

The Correctness for Signature is depicted as follows:(3)e∧:Xθ∗∗,LP+Ppub=e∧:tSKIDs1∗ct−1P,LP+aP=e∧:tSKIDs1∗ct−1P,L+aP=e∧:t1L+aPs1∗ct−1,L+aP=e∧:abcP,P=e∧:P,Pabc.Hence, this is the BDH instance to the above problem which is solved for the given random listP,aP,bP,cP,wherea,b,c∈RZr∗. It is assumed that the BDH problem is difficult to break by any probabilistic polynomial time (PPT) algorithm. Therefore, the MHCOOS scheme is secure under adaptive chosen message attacker AI in the random oracle.Theorem 2.
MHCOOS Scheme is proved to be existentially unforgeable (EUF-CMA) in the random oracle under the CDH assumption problem inG1 if the Type II adversary AII can win the game with advantage ε at time T can make the following queries qHi to the Hash oracles (Hi,wherei=1,2,3), qE queries to the private-key extraction oracle, qPK queries to the public-key request oracle, and qsig queries to the signing oracle, then the CDH problem can be solved with probability.(4)ε′>ε−3kqsigqH2+qsigqE+22−qH1qEqEqH1+12−k.Proof.
The theorem relies on the assumption that there exists an adversaryAII with considerable powers having the advantage to attack the scheme without any constraint. The goal is to compute abP from a tuple P,aP,bP with assumption that there exists an adversary AII capable of attacking the MHCOOS.


## 4.12. System Initialization Phase

At the Setup phase, Challenger,C sets P as the generator G1 and sets Ppub=sP, where s is the master key of the KGC. Adversary, AII can act as the dishonest KGC. C then updates an initially empty list li containing the list IDi,SKID,PKID during the game and responds to the various queries in qHi as follows:(i)
H1 queries: the adversary AII makes qH1 number of queries to the oracle H1 with an identity IDi. AII selects j∈R1,qH1, where qH1 denotes the maximum number of queries. The Challenger C checks if i=j and IDi=ID∗; if this true, it updates a list l1 containing the tuple IDi,Qi,yi and sets Qi=aP and yi=⊥ for failure. If i≠j and IDi≠ID∗, the challenger gets yi randomly and sets Qi=yiP and updates the tuple IDi,Qi,yi.


## 4.13. Key Setup Extraction Queries

(a)
Public key extraction queries:C performs number of tasks and updates l with SKID,PKID after getting an identity IDi query from AII. The tasks are as follows: C checks the following: l=IDi,SKID,PKID,PKID=⊥. If both conditions are true, C returns PKID to the adversary AI. If the conditions are false, it sets PKID≠⊥. C selects L∈ℤr∗ and sets PKID=bPpub,SKID=L and returns PKID to AII. By inspection, if the tuple does not contain IDi,SKID,PKID, C updates the list l with SKID,PKID by selecting L∈ℤr∗ and sets PKID=bPpub,SKID=L and returns PKID to AII.
(b)
Secret value extraction queries: ifIDi=ID∗, C performs some tasks and updates l with SKID after getting an identity IDi query from AII . The tasks are as follows: C checks the following: l=IDi,SKID,PKIDPKID=⊥. If the conditions return true, C executes Public Key Extraction Queries to obtain SKID=L,PKID=LPpub. By inspection, if l≠IDi,SKID,PKID, C executes Public Key Extraction Queries to obtain PKID,SKID and updates the list l with full private keys, SKID.(i)
H2 queries: C searches a list l2 if it contains the tuple m,θ,PKID,hi, following AII query on m,θ,PKID. C then returns the tuple to AII if the tuple exists. Otherwise, C adds bi as a hash value to the tuple l2 by selecting bi∈Rℤr∗.(ii)
H3 queries: C searches the list l3 = m,θ,PkID,bi,cj, following query from AIIonm,θ,PKID,bi. C then returns the list, l3 to AI if l3 exists. Otherwise, C adds cj as a hash value to the list l3 by selecting cj∈Rℤr∗.


## 4.14. Queries at the Authentication Phase

(a)
Signature queries:AII obtains IDi,mi and allowed query the Challenger C for a corresponding signature under the condition that IDi≠ID∗.The ChallengerC then searches for a list l, containing the tuple IDi,SKID,PKID. C executes Public Key extraction Queries if the following are not found SKID,PKID. AII is also allowed to generate a corresponding signature on any arbitrary length message mi with its full private key DID,SKID under the condition that IDi=ID∗.The Challenger computes the following:(5)e∧:U,P=e∧:s1∗P,P=e∧:abP,P=e∧:P,Pab.This is an instance to the CDH problem. It is known that the CDH problem is difficult to break by any probabilistic polynomial time (PPT) algorithm. Hence, the MHCOOS scheme is secure in CDH under adaptive chosen message attackerAII in the random oracle.


## 5. Performance Analysis

This section presents the performance of the proposed MHCOOS scheme with other similar certificateless schemes in the literature in terms of communication cost, computational cost, and the security performance.


### 5.1. Simulation Setup Environment

The simulation environment was setup on Windows 10 Operating system on an Intel (R) Core i5-4210U CPU and 8 GB memory. We implemented our work on a Dev C++ IDE built on MINGW64.


#### 5.1.1. Communication Cost

The simulation environment for the proposed scheme (MHCOOS) was setup on a Dev C++ IDE built on MINGW64 Windows 10 Operating system on an Intel (R) Core i5-4210U CPU using the MIRACL multiprecision library. The pairing operation is defined over a supersingular elliptic curve ofy2=x3+1modr over GF (p) with 512 bits using Type 1 pairings.The compilation time of the proposed scheme was compared with CL-SDVS [8] in Figure 3 and Table 2. The compilation results were generated by using a demo C++ code to test the library. The total execution time of the proposed scheme generated 1.13 s after two rounds of execution and that of the CL-SDVS [8] was 67.93. Both schemes used the MIRACL multiprecision library for its execution. MHCOOS scheme achieved a lower communication cost due to the lighter operations used in the algorithm generation. CL-SDVS [8] used a lot of pairing computations which take longer time to execute. Furthermore, it did not adopt offline/online alternative. We therefore conclude that execution process is faster when algorithms adopt an offline-online approach.Figure 3
Simulated results generated from message signature using the MIRACL library.
(a)
(b)Table 2
Performance comparison-communication cost.
Scheme
Execution time for round 1 (s)
Execution time for round 2 (s)
Total Execution times
MHCOOS (proposed scheme)
0.619
0.511
1.13
CL-SDVS [8]
—
—
67.93


#### 5.1.2. Computation Cost

This section compares the computational operations of the proposed scheme (MHCOOS) with other schemes in the literature. Table3 elaborates the comparison analysis of our scheme and other schemes in text. We denoted pairing operations: p, hashing operation: h, scalar multiplication: sm, and exp: exponentiation in G1.Table 3
Performance comparison-communication cost.
Scheme
Signing
Verification
Offline
Online
L-OOCLS/HRAAP [9]
3M + 1Exp
3M
1P + 1Exp + 1M
MHCOOS scheme
2M
2M
2P + 1Exp
Liu et al. [10]
—
1P + 1Exp + 2M
2P + 1Exp
Kumar et al. [11]
—
3M
3P + 1M
Hafizul Islam and Biswas [8]
—
3P + 3M + Exp
1P + 1M + 1Exp
Selvi [12]
3M
—
6M + 4PAccording to Table3, the proposed scheme (MHCOOS), Selvi [12] and L-OOCLS/HRAAP scheme [9] only included the Offline and Online computations at the signing stage of their algorithm. However, schemes [8, 10, 11] did not adopt offline and online methods in their signing computations. MHCOOS scheme employs 2 scalar multiplications at both offline and online stages which are lesser when compared to schemes [9, 12] at the online phase and schemes [8, 9, 11] at the offline approach except scheme [10] which has the same number of scalar multiplications with the proposed scheme.At the verification stage, our pairing operation was slightly higher than the pairing operation in schemes [8, 9] but similar to scheme [10]. Schemes [11, 12] had the highest the number of pairing operations. The signing part of the MHCOOS scheme was split into both Offline and Online computations. During the offline computation, an offline-computed value is generated which is used in conjunction with the message (health data) to generate an online signature. No pairing computation was introduced at the signing stage due to the fact that pairing computations based on elliptic curves require heavy computational cost and extra execution time. Execution of the whole signature process is faster and quicker because at the offline stage, the device does not record any message but minute computations take place to generate a precomputed offline value.As soon as the mobile device records an activity (receives a message), the online computation takes place using the recorded message and the precomputed offline value to generate the online signature. In the MHCOOS scheme, the user need not perform a lot of computations at the verification stage despite its 2 times pairing computation because much of the computations already took place at the signing stage. Overall, the MHCOOS scheme has proven to be of much advantage over scheme [8, 9, 12] at the signing stages and better than [11, 12] at the verification stage because our scheme adopted lesser pairing computations in both stages.


### 5.2. Application Scenario

In this section, an m-health practical scenario is provided to demonstrate the workflow of a secure data transmission of the entities that employ the MHCOOS scheme. First of all, mobile health (m-health) supported by e-health is a healthcare technology by which entities utilize smart devices to access their healthcare needs. It consists of an already installed mobile medical application which records the daily and fitness activities of its users simultaneously collecting vital health data. The standard ISO TR 17522 : 2015 developed for health applications on mobile/smart devices is used to establish communication amongst entities.The data is securely transmitted via a Bluetooth and WLAN medium onto the medical server for storage. The healthcare terminal submits the user’s identity to request for their respective stored data. The data is stored at the database of the data center where the health practitioner is able to collect the recorded data of each health respondent. The communication scenario initiates the lightweight MHCOOS algorithm. It performs the offline computations when no health data is present to generate an offline-computed value. It then fully performs the online computations using the detected health data and the already offline-computed value to generate the online signature with the received health data (health data present). The various activities that take place in the MHCOOS system are well expounded in the following steps and diagramatically represented in Figure4.(a)
The MS initializes the system by generating system setup and other parameters. The user’s mobile device sends the identity of the userIDs to MS to compute DID=sH1ID for the user and transmits it securely to the user.(b)
At this stage, the health app installed on the mobile device is termed idle if it is not reading the heart beat or checking the pulse of the patient. It performs offline computations at this idle stage and generates the offline value (σ). As soon as the mobile device detects the presence of any health activity, the application starts to record the vital health data (heart rate or records his pulses). At the online stage, the application performs several computations using the already computed offline parameters with the captured data. The installed health application (health app) signs the online computed value δ on the message, thus signδ,m, and sends it to the MS for storage.(c)
During verification, the HTP submits the identity of the mobile user to the MS and requests for the health data and checks for the veracity of signature on the messagesignδ,m.Figure 4
A toy scenario for the m-health model.


## 5.1. Simulation Setup Environment

The simulation environment was setup on Windows 10 Operating system on an Intel (R) Core i5-4210U CPU and 8 GB memory. We implemented our work on a Dev C++ IDE built on MINGW64.


### 5.1.1. Communication Cost

The simulation environment for the proposed scheme (MHCOOS) was setup on a Dev C++ IDE built on MINGW64 Windows 10 Operating system on an Intel (R) Core i5-4210U CPU using the MIRACL multiprecision library. The pairing operation is defined over a supersingular elliptic curve ofy2=x3+1modr over GF (p) with 512 bits using Type 1 pairings.The compilation time of the proposed scheme was compared with CL-SDVS [8] in Figure 3 and Table 2. The compilation results were generated by using a demo C++ code to test the library. The total execution time of the proposed scheme generated 1.13 s after two rounds of execution and that of the CL-SDVS [8] was 67.93. Both schemes used the MIRACL multiprecision library for its execution. MHCOOS scheme achieved a lower communication cost due to the lighter operations used in the algorithm generation. CL-SDVS [8] used a lot of pairing computations which take longer time to execute. Furthermore, it did not adopt offline/online alternative. We therefore conclude that execution process is faster when algorithms adopt an offline-online approach.Figure 3
Simulated results generated from message signature using the MIRACL library.
(a)
(b)Table 2
Performance comparison-communication cost.
Scheme
Execution time for round 1 (s)
Execution time for round 2 (s)
Total Execution times
MHCOOS (proposed scheme)
0.619
0.511
1.13
CL-SDVS [8]
—
—
67.93


### 5.1.2. Computation Cost

This section compares the computational operations of the proposed scheme (MHCOOS) with other schemes in the literature. Table3 elaborates the comparison analysis of our scheme and other schemes in text. We denoted pairing operations: p, hashing operation: h, scalar multiplication: sm, and exp: exponentiation in G1.Table 3
Performance comparison-communication cost.
Scheme
Signing
Verification
Offline
Online
L-OOCLS/HRAAP [9]
3M + 1Exp
3M
1P + 1Exp + 1M
MHCOOS scheme
2M
2M
2P + 1Exp
Liu et al. [10]
—
1P + 1Exp + 2M
2P + 1Exp
Kumar et al. [11]
—
3M
3P + 1M
Hafizul Islam and Biswas [8]
—
3P + 3M + Exp
1P + 1M + 1Exp
Selvi [12]
3M
—
6M + 4PAccording to Table3, the proposed scheme (MHCOOS), Selvi [12] and L-OOCLS/HRAAP scheme [9] only included the Offline and Online computations at the signing stage of their algorithm. However, schemes [8, 10, 11] did not adopt offline and online methods in their signing computations. MHCOOS scheme employs 2 scalar multiplications at both offline and online stages which are lesser when compared to schemes [9, 12] at the online phase and schemes [8, 9, 11] at the offline approach except scheme [10] which has the same number of scalar multiplications with the proposed scheme.At the verification stage, our pairing operation was slightly higher than the pairing operation in schemes [8, 9] but similar to scheme [10]. Schemes [11, 12] had the highest the number of pairing operations. The signing part of the MHCOOS scheme was split into both Offline and Online computations. During the offline computation, an offline-computed value is generated which is used in conjunction with the message (health data) to generate an online signature. No pairing computation was introduced at the signing stage due to the fact that pairing computations based on elliptic curves require heavy computational cost and extra execution time. Execution of the whole signature process is faster and quicker because at the offline stage, the device does not record any message but minute computations take place to generate a precomputed offline value.As soon as the mobile device records an activity (receives a message), the online computation takes place using the recorded message and the precomputed offline value to generate the online signature. In the MHCOOS scheme, the user need not perform a lot of computations at the verification stage despite its 2 times pairing computation because much of the computations already took place at the signing stage. Overall, the MHCOOS scheme has proven to be of much advantage over scheme [8, 9, 12] at the signing stages and better than [11, 12] at the verification stage because our scheme adopted lesser pairing computations in both stages.


## 5.1.1. Communication Cost

The simulation environment for the proposed scheme (MHCOOS) was setup on a Dev C++ IDE built on MINGW64 Windows 10 Operating system on an Intel (R) Core i5-4210U CPU using the MIRACL multiprecision library. The pairing operation is defined over a supersingular elliptic curve ofy2=x3+1modr over GF (p) with 512 bits using Type 1 pairings.The compilation time of the proposed scheme was compared with CL-SDVS [8] in Figure 3 and Table 2. The compilation results were generated by using a demo C++ code to test the library. The total execution time of the proposed scheme generated 1.13 s after two rounds of execution and that of the CL-SDVS [8] was 67.93. Both schemes used the MIRACL multiprecision library for its execution. MHCOOS scheme achieved a lower communication cost due to the lighter operations used in the algorithm generation. CL-SDVS [8] used a lot of pairing computations which take longer time to execute. Furthermore, it did not adopt offline/online alternative. We therefore conclude that execution process is faster when algorithms adopt an offline-online approach.Figure 3
Simulated results generated from message signature using the MIRACL library.
(a)
(b)Table 2
Performance comparison-communication cost.
Scheme
Execution time for round 1 (s)
Execution time for round 2 (s)
Total Execution times
MHCOOS (proposed scheme)
0.619
0.511
1.13
CL-SDVS [8]
—
—
67.93


## 5.1.2. Computation Cost

This section compares the computational operations of the proposed scheme (MHCOOS) with other schemes in the literature. Table3 elaborates the comparison analysis of our scheme and other schemes in text. We denoted pairing operations: p, hashing operation: h, scalar multiplication: sm, and exp: exponentiation in G1.Table 3
Performance comparison-communication cost.
Scheme
Signing
Verification
Offline
Online
L-OOCLS/HRAAP [9]
3M + 1Exp
3M
1P + 1Exp + 1M
MHCOOS scheme
2M
2M
2P + 1Exp
Liu et al. [10]
—
1P + 1Exp + 2M
2P + 1Exp
Kumar et al. [11]
—
3M
3P + 1M
Hafizul Islam and Biswas [8]
—
3P + 3M + Exp
1P + 1M + 1Exp
Selvi [12]
3M
—
6M + 4PAccording to Table3, the proposed scheme (MHCOOS), Selvi [12] and L-OOCLS/HRAAP scheme [9] only included the Offline and Online computations at the signing stage of their algorithm. However, schemes [8, 10, 11] did not adopt offline and online methods in their signing computations. MHCOOS scheme employs 2 scalar multiplications at both offline and online stages which are lesser when compared to schemes [9, 12] at the online phase and schemes [8, 9, 11] at the offline approach except scheme [10] which has the same number of scalar multiplications with the proposed scheme.At the verification stage, our pairing operation was slightly higher than the pairing operation in schemes [8, 9] but similar to scheme [10]. Schemes [11, 12] had the highest the number of pairing operations. The signing part of the MHCOOS scheme was split into both Offline and Online computations. During the offline computation, an offline-computed value is generated which is used in conjunction with the message (health data) to generate an online signature. No pairing computation was introduced at the signing stage due to the fact that pairing computations based on elliptic curves require heavy computational cost and extra execution time. Execution of the whole signature process is faster and quicker because at the offline stage, the device does not record any message but minute computations take place to generate a precomputed offline value.As soon as the mobile device records an activity (receives a message), the online computation takes place using the recorded message and the precomputed offline value to generate the online signature. In the MHCOOS scheme, the user need not perform a lot of computations at the verification stage despite its 2 times pairing computation because much of the computations already took place at the signing stage. Overall, the MHCOOS scheme has proven to be of much advantage over scheme [8, 9, 12] at the signing stages and better than [11, 12] at the verification stage because our scheme adopted lesser pairing computations in both stages.


## 5.2. Application Scenario

In this section, an m-health practical scenario is provided to demonstrate the workflow of a secure data transmission of the entities that employ the MHCOOS scheme. First of all, mobile health (m-health) supported by e-health is a healthcare technology by which entities utilize smart devices to access their healthcare needs. It consists of an already installed mobile medical application which records the daily and fitness activities of its users simultaneously collecting vital health data. The standard ISO TR 17522 : 2015 developed for health applications on mobile/smart devices is used to establish communication amongst entities.The data is securely transmitted via a Bluetooth and WLAN medium onto the medical server for storage. The healthcare terminal submits the user’s identity to request for their respective stored data. The data is stored at the database of the data center where the health practitioner is able to collect the recorded data of each health respondent. The communication scenario initiates the lightweight MHCOOS algorithm. It performs the offline computations when no health data is present to generate an offline-computed value. It then fully performs the online computations using the detected health data and the already offline-computed value to generate the online signature with the received health data (health data present). The various activities that take place in the MHCOOS system are well expounded in the following steps and diagramatically represented in Figure4.(a)
The MS initializes the system by generating system setup and other parameters. The user’s mobile device sends the identity of the userIDs to MS to compute DID=sH1ID for the user and transmits it securely to the user.(b)
At this stage, the health app installed on the mobile device is termed idle if it is not reading the heart beat or checking the pulse of the patient. It performs offline computations at this idle stage and generates the offline value (σ). As soon as the mobile device detects the presence of any health activity, the application starts to record the vital health data (heart rate or records his pulses). At the online stage, the application performs several computations using the already computed offline parameters with the captured data. The installed health application (health app) signs the online computed value δ on the message, thus signδ,m, and sends it to the MS for storage.(c)
During verification, the HTP submits the identity of the mobile user to the MS and requests for the health data and checks for the veracity of signature on the messagesignδ,m.Figure 4
A toy scenario for the m-health model.


## 6. Conclusions

In this paper, we presented an MHCOOS scheme by adopting an Offline-Online approach to Certificateless signatures that are applicable to mobile devices used in the health environment. MHCOOS is a lightweight cryptographic scheme designed to support mobile devices used for health applications. Based on minimum bilinear pairings, the scheme splits the signing part into two phases: the offline phase and the online phase. The offline phase performs a lot of computational processes when a message (no record of health data) is unavailable to generate an offline computed value, whereas the online computations take place during the presence of a message. MHCOOS has been shown to be unforgeable against the Type I and Type II adversaries (AIandAII), respectively, under the adaptive chosen message attacks whilst it is subsequently proven to be intractable under the BDH and CDH assumptions in the random oracle. The scheme is shown to be lightweight and has wider applicability not only to mobile health (m-health) devices but other wearable devices. In our future works, we will look further to propose a different lightweight scheme useful for devices with wearable technology without the use of heavy cryptographic methods.



---

*Source: 7085623-2020-01-28.xml*