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

. 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 beneﬁts, 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 Oﬄine-Online signature scheme called the MHCOOS has been proposed to solve the diﬃculties in the computational ability. The scheme enjoys the following beneﬁts by splitting the signing part into both oﬄine and online phases. The oﬄine 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 oﬄine signature value and lighter pairings involved. Our performance analysis demonstrates how the proposed scheme out-performs other schemes. Finally, the hardness of the scheme is proven under the Bilinear Diﬃe–Hellman (BDH) and Computational Diﬃe–Hellman (CDH) problem in the random oracle model.


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. e 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. e 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.
e European Commission funds a project named the MobiHealth. ey explained how patients wear a lightweight monitoring system in accordance with their health needs. eir 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.

Our Contributions.
We propose an Offline-Online Certificateless Scheme for m-health devices (mobile health devices). e idea is to split the Certificateless signature into offline and online methods. e 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. e 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]. e offline-online signature methods as presented by Even et al. [2] are useful for storage-limited devices. e 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. us, the Certificateless signature scheme is lightweight because the signature part is divided into both Offline and Online signing phases.
(ii) e 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. us, the operational overhead cost (computation and communication cost) is much lower and insignificant.
e 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.

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 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. e 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). eir 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. e notion of the Offline-Online digital signature scheme was proposed by Even et al. [2]. eir 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. e 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.

Organization of the Paper.
e rest of the paper is divided into the following sections. Section 2 highlights on the preliminary and complexity assumptions. In Section 3, a brief description of the Offline-Online Certificateless Signatures model is given. e 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.

Preliminaries
is section highlights the conceptual properties of bilinear pairings. Let G 1 be an additive group of order q(G 1 , +) and G 2 a multiplicative group of the same order (G 2 , × ) and P being a generator. e structure of bilinear pairing is represented as e ∧ : G 1 × G 1 ⟶ G 2 with the following properties: e 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.

Complexity Assumptions.
is 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, g a ) ∈ G 1 with g as the generator and a ∈ Z * r , where a is unknown. e discrete logarithmic problem (DLP) in G requires the value of a to be computed. us, the advantage for any probabilistic polynomial time algorithm A, computing a is negligibly small.
Given (g, g a , g b ) ∈ G 1 with generator g and a, b ∈ Z * r , where a, b are unknowns. Our task is to compute C � g ab in G 1 . e CDH problem is assumed to be a computationally hard problem. is 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 ∈ Z * r as the input and generates a tuple (r, G 1 , G 2 , e ∧ , P).
(d) MHCOOS scheme is secure against Type i adversary if the probability that an adaptively chosen message

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. e OOCS scheme consists of six polynomial time algorithms. Table 1 presents the symbols and notations used in this paper with their corresponding meanings.

Syntax
(1) Setup. KGC chooses 1 k as a security parameter, returns a master secret key msk, and publishes a list of system public parameters list l.

Security and Communication Networks
(2) Partial-Private-Key-Extract. is algorithm takes as inputs system public parameter list l, msk the identity of a user ID i ∈ 0, 1 { } * , and returns an output D ID as the partial private key.
(3) Set-Secret-Value. User performs this algorithm by taking system public parameters l and a user's ID i ∈ 0, 1 { } * as inputs and returns a secret value x i . (4) Set-Private-Key. e algorithm takes system public parameters l, the secret value x i , the partial private key D ID , and returns private key SK ID . (5) Set-Public-Key. e algorithm takes system public parameters l, the secret value x i , and returns public key PK ID . (6) CL-OffSign. Using system public parameters l, the private key SK ID of the user with identity ID i ∈ 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 ID i , the full private key SK ID , 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. e verification algorithm performed to determine if the signature is valid or not. It takes the identity ID i of the signer, the message m ∈ 0, 1 { } * , the Certificateless Signature δ, and the Public key PK ID of the signer. e algorithm generates true if the signature δ is valid and null ⊥ if it is invalid. Figure 1 gives a diagrammatic approach of the respective phases of an Offline-Online scheme in the ordinary literature.

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

System Initialization Phase.
e medical server firstly initializes the system by setting up the following processes using a security parameter 1 k to perform the following steps: (e) MS performs this algorithm to generate msk, mpk : master secret keys and master public keys, respectively. en, publishes in the public directory list

Registration
Phase. e mobile user registers its identity, ID with the medical server MS. e MS fetches the public directory list l, 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) Compute Q ID � H 1 (ID); hashes the user's identity (b) Compute partial private key, D ID � sH 1 (ID) � sQ ID

Key Setup Phase.
e 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 Table 1: Key symbols used in the paper.

Symbols
Meaning (G 1 , +) Additive notation in group 1 (G 2 , ×) (a) Set-Secret-Value. e user ID randomly picks a secret value L ∈ Z * r . (b) Set-Private-Keys. With the secret value L and with partial Private key D ID , user generates its full, Private key SK ID � (1/(L + sH 1 (ID)))P (c) Set-Public-Key. User sets its public key PK ID � LP Pub

Authentication Phase.
e 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).

Signing Phase.
is stage of the algorithm is split into two, namely, CL-Offline signature and CL-Online signature, respectively. e algorithm works as follows.  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. is part of the signing algorithm uses the following parameter public directory list l, SK ID , user ID ∈ 0, 1 { } * , without the presence of a message, (m � ∅) to perform the following operations to generate an offline signature value, σ.

CL-Online
Signature. During the online signature phase, when the mobile device has recorded some health activities, thus with the presence of a message (m ≠ ∅), it performs the following online operations with the already offline computed signature value and transmits them securely on to the medical server, MS. e MS further stores these values in a secure form till information is requested.
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. (1) e 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. is method promotes faster and quicker signature execution process.

Theorem 1. MHCOOS Scheme is proved to be existentially unforgeable (EUF-CMA) in the random oracle under the CDH assumption problem in G 1 ; if Type 1 adversary A I can win the game with advantage ε at time T, it can make the following queries q H i to the Hash oracles
, q E queries to the private-key extraction oracle, q PK queries to the public-key request oracle, and q sig queries to the signing oracle, and then the BDH problem can be solved with probability.
where T represents the total running time; the adversary would perform various queries. t p is the time to perform one pairing operation and t e is the time to compute one exponentiation in G 2 .
Proof. e main purpose of the Challenger C is to compute abcP from a tuple (P, aP, bP, cp) with the assumption that there exists an adversary A I capable of attacking the MHCOOS scheme with the above advantage. and randomly sets Q i � y i P and saves the tuple l 1 � (ID i , Q i , y i ). and PK ID ≠ ⊥}. If both conditions are true, C returns PK ID to the adversary A I . If the conditions are false, C selects L ∈ R Z * r and sets the following PK ID � LP pub , SK ID � L and returns PK ID to A I , and then updates the list, l 1 . By inspection, if the list l ≠ (ID i , D ID , SK ID , Pk ID ), C updates the list l with ( SK ID , PK ID ). C selects L * ∈ R Z * r and sets the following PK ID � LP pub , SK ID � L} and then updates l with (SK ID , PK ID ). (c) Secret value extraction queries: if ID i � ID * , C performs a number of tasks and updates the list, l with (SK ID , D ID ) after obtaining an identity ID i query from A I . C checks the following: l � { (ID i , D ID , SK ID , PK ID ), PK ID � ⊥, D ID � ⊥}. If these conditions are true, C executes Partial Key Extraction and Public Key Extraction Queries to obtain D ID , PK ID � L * P pub , SK ID � L * , respectively. By inspection, if the list l ≠ (ID, D ID , SK ID , PK ID ), C executes Partial Key Extraction and Public Key Extraction Queries to obtain D ID , (PK ID , SK ID ) and updates the list l with full private keys (D ID , SK ID ), respectively. (d) Public key replacement (ID i , PK ID ′ ) queries: C performs the following operations and updates the list when A I makes the query on (ID i , PK ID ′ ). C sets PK ID � PK ID ′ , SK ID if the list l contains (ID i , D ID , SK ID , PK ID ).

Key Setup Extraction Queries
Otherwise, C sets D ID , PK ID � PK ID ′ , SK ID � ⊥ and updates the list l accordingly.
(i) H 2 queries: C checks the list l 2 � (ID i , m, θ * , Pk ID , b i ), following a query from A I on (m, θ, PK ID ). It then returns the list, l 2 to A I if the list exists. Otherwise, it adds b i as a hash value to the list l 2 by selecting b i ∈ R Z * r . (ii) H 3 queries: C checks the list l 3 � (ID i , m, θ, PK ID , b i , c j ), following query from A I on (ID i , m, θ, Pk ID , c j ). C then returns the list, l 3 to A I if l 3 exists. Otherwise, C adds c j as a hash value to the list L 3 by selecting c j ∈ R Z * r .

Queries at the Authentication Phase
(a) Signature queries: A I queries the challenger C, for a signature on an adaptive chosen message m i of a user ID i . e Challenger C checks the list, l � (ID i , D ID , SK ID , PK ID ). C runs Partial Key Extraction and Public Key Extraction queries, respectively, if D ID ≠ ∅, (SK ID , PK ID ) ≠ ∅ . A I is also allowed to generate a corresponding signature of any arbitrary length message m i with its full private key (D ID , Sk ID ) under the condition that ID i � ID * and PK ID are the public key and SK ID � 1/(L + a) as the private key, where a, L ∈ Z * r . e signature value returned from the Challenger is not a valid signature since the public key has been replaced by A I , and the Challenger may not know the corresponding public key.
e Challenger computes the following:

Correctness for Signature.
e Correctness for Signature is depicted as follows: (3)

Security and Communication Networks
Hence, this is the BDH instance to the above problem which is solved for the given random list (P, aP, bP, cP), where a, b, c ∈ R Z * r . It is assumed that the BDH problem is difficult to break by any probabilistic polynomial time (PPT) algorithm. erefore, the MHCOOS scheme is secure under adaptive chosen message attacker A I 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 in G 1 if the Type II adversary A II can win the game with advantage ε at time T can make the following queries q H i to the Hash oracles (H i , where i � 1, 2, 3), q E queries to the private-key extraction oracle, q PK queries to the public-key request oracle, and q sig queries to the signing oracle, then the CDH problem can be solved with probability.
Proof. e theorem relies on the assumption that there exists an adversary A II with considerable powers having the advantage to attack the scheme without any constraint. e goal is to compute abP from a tuple (P, aP, bP) with assumption that there exists an adversary A II capable of attacking the MHCOOS. □ 4.12. System Initialization Phase. At the Setup phase, Challenger, C sets P as the generator G 1 and sets P pub � sP, where s is the master key of the KGC. Adversary, A II can act as the dishonest KGC. C then updates an initially empty list l i containing the list (ID i , SK ID , PK ID ) during the game and responds to the various queries in q H i as follows: (i) H 1 queries: the adversary A II makes q H1 number of queries to the oracle H 1 with an identity ID i . A II selects j ∈ R [1, q H1 ], where q H1 denotes the maximum number of queries. e Challenger C checks if i � j and ID i � ID * ; if this true, it updates a list l 1 containing the tuple (ID i , Q i , y i ) and sets Q i � aP and y i � ⊥ for failure. If i ≠ j and ID i ≠ ID * , the challenger gets y i randomly and sets Q i � y i P and updates the tuple (ID i , Q i , y i ).

Key Setup Extraction Queries
(a) Public key extraction queries: C performs number of tasks and updates l with (SK ID , PK ID ) after getting an identity ID i query from A II . e tasks are as follows: C checks the following: l � (ID i , SK ID , PK ID ), PK ID � ⊥}. If both conditions are true, C returns PK ID to the adversary A I . If the conditions are false, it sets PK ID ≠ ⊥. C selects L ∈ Z * r and sets PK ID � bP pub , SK ID � L and returns PK ID to A II . By inspection, if the tuple does not contain (ID i , SK ID , PK ID ), C updates the list l with (SK ID , PK ID ) by selecting L ∈ Z * r and sets PK ID � bP pub , SK ID � L and returns PK ID to A II . (b) Secret value extraction queries: if ID i � ID * , C performs some tasks and updates l with SK ID after getting an identity ID i query from A II . e tasks are as follows: C checks the following: l � (ID i , SK ID , PK ID )PK ID � ⊥ . If the conditions return true, C executes Public Key Extraction Queries to obtain SK ID � L, PK ID � LP pub . By inspection, if l ≠ (ID i , SK ID , PK ID ), C executes Public Key Extraction Queries to obtain (PK ID , SK ID ) and updates the list l with full private keys, SK ID .
(i) H 2 queries: C searches a list l 2 if it contains the tuple (m, θ, PK ID , h i ), following A II query on (m, θ, PK ID ). C then returns the tuple to A II if the tuple exists. Otherwise, C adds b i as a hash value to the tuple l 2 by selecting b i ∈ R Z * r . (ii) H 3 queries: C searches the list l 3 � (m, θ, Pk ID , b i , c j ), following query from A II on (m, θ, PK ID , b i ). C then returns the list, l 3 to A I if l 3 exists. Otherwise, C adds c j as a hash value to the list l 3 by selecting c j ∈ R Z * r .

Queries at the Authentication Phase
(a) Signature queries: A II obtains (ID i , m i ) and allowed query the Challenger C for a corresponding signature under the condition that (ID i ≠ ID * ).
e Challenger C then searches for a list l, containing the tuple (ID i , SK ID , PK ID ). C executes Public Key extraction Queries if the following are not found (SK ID , PK ID ). A II is also allowed to generate a corresponding signature on any arbitrary length message m i with its full private key (D ID , SK ID ) under the condition that ID i � ID * . e Challenger computes the following: is 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 attacker A II in the random oracle.

Performance Analysis
is 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.

Simulation Setup Environment.
e 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.

Communication Cost.
e 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. e pairing operation is defined over a supersingular elliptic curve of y 2 � x 3 + 1modr over GF (p) with 512 bits using Type 1 pairings. e compilation time of the proposed scheme was compared with CL-SDVS [8] in Figure 3 and Table 2. e compilation results were generated by using a demo C++ code to test the library. e 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.

Computation Cost.
is section compares the computational operations of the proposed scheme (MHCOOS) with other schemes in the literature. Table 3 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 G 1 .
According to Table 3, 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. e signing part of the MHCOOS scheme was split into both Offline and Online computations. During the offline computation, an offlinecomputed 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.

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   User sends ID to MS e data is securely transmitted via a Bluetooth and WLAN medium onto the medical server for storage. e healthcare terminal submits the user's identity to request for their respective stored data. e 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. e 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). e various activities that take place in the MHCOOS system are well expounded in the following steps and diagramatically represented in Figure 4.
(a) e MS initializes the system by generating system setup and other parameters. e user's mobile device sends the identity of the user ID s to MS to compute D ID � sH 1 (ID) 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. e 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 message sign(δ, m).

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. e 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 (A I and A II ), 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. e 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.
Data Availability e data used in running the simulation were download from the Miracl Github repository from the below website: https:// github.com/miracl/MIRACL. A demo code from this site https://github.com/miracl/MIRACL/blob/master/source/pkdemo.cpp was used to test pk-demo.cpp of the library file.

Conflicts of Interest
e authors declare that there are no conflicts of interest.