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.
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. Section 2 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. Let be an additive group of order and a multiplicative group of the same order and being a generator. The structure of bilinear pairing is represented as with the following properties:(1)Bilinearity: and (2)Nondegeneracy: (3)Computability: there exists an efficient algorithm for all (4)For all
The 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 with as the generator and , where a is unknown. The discrete logarithmic problem (DLP) in G requires the value of to be computed. Thus, the advantage for any probabilistic polynomial time algorithm computing is negligibly small.(b)Computational Diffie–Hellman Problem (CDH). Given with generator and , where are unknowns. Our task is to compute in . The CDH problem is assumed to be a computationally hard problem. This means that for any probabilistic polynomial time algorithm , 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 as the input and generates a tuple .(d)MHCOOS scheme is secure against Type adversary if the probability that an adaptively chosen message can win Game where . The MHCOOS scheme is secure if is negligible. Thus, .(e)MHCOOS is existentially unforgeable against adaptive message attack if it is secure against adversary . Thus, 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. Table 1 presents the symbols and notations used in this paper with their corresponding meanings.
3.1. Syntax
(1)Setup. KGC chooses as a security parameter, returns a master secret key , and publishes a list of system public parameters list .(2)Partial-Private-Key-Extract. This algorithm takes as inputs system public parameter list the identity of a user , and returns an output as the partial private key.(3)Set-Secret-Value. User performs this algorithm by taking system public parameters and a user’s as inputs and returns a secret value .(4)Set-Private-Key. The algorithm takes system public parameters , the secret value , the partial private key , and returns private key .(5)Set-Public-Key. The algorithm takes system public parameters , the secret value , and returns public key .(6)CL-OffSign. Using system public parameters , the private key of the user with identity and without the availability of the message, this algorithm generates an offline component value .(7)CL-OnSign. Given the message, , the signer’s identity , the full private key , 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 of the signer, the message , the Certificateless Signature , and the Public key of the signer. The 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.
3.2. System Model
We provide a description of the entities within the MHCOOS model and their functionalities within the system in Figure 2. 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.
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 parameter to perform the following steps:(a)Given two cyclic groups of prime order , a pairing map .(b) becomes a generator of an additive group of prime .(c)The MS selects its secret value, and sets .(d)Chooses three one-way hash functions and , .(e)MS performs this algorithm to generate : master secret keys and master public keys, respectively. Then, publishes in the public directory list
4.2. Registration Phase
The mobile user registers its identity, ID with the medical server MS. The MS fetches the public directory list , its master secret key, , and obtains the user’s identity, from the user to register the user’s details in the system by making the following computations:(a)Compute ; hashes the user’s identity(b)Compute partial private key,
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 randomly picks a secret value .(b)Set-Private-Keys. With the secret value and with partial Private key , user generates its full, Private key (c)Set-Public-Key. User sets its public key
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 list , , user without the presence of a message, to perform the following operations to generate an offline signature value, .(a)Choose randomly (b)Compute (c)Set (d)Compute
Returns Offline signature value , where .
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 message , 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)Compute (b)Compute (c)Output online signature value
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)Compute (b), accept signature(c), reject signature
4.7. Correctness for Signature
The HTP further verifies using the correctness signature which is as follows:
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 in ; if Type 1 adversary can win the game with advantage at time T, it can make the following queries to the Hash oracles (where ), queries to the private-key extraction oracle, queries to the public-key request oracle, and 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. is the time to perform one pairing operation and is the time to compute one exponentiation in
Proof. The main purpose of the Challenger is to compute from a tuple with the assumption that there exists an adversary capable of attacking the MHCOOS scheme with the above advantage.
4.8.1. System Initialization Phase
Let be a generator of the group and be an unknown master key. The Challenger sets . The Challenger then updates an initially empty list containing the tuple During the game, starts issuing various queries in as follows:(i) queries: the adversary is allowed to make number of queries to the oracle with a list identity . selects , where denotes the maximum number of queries. An identity is submitted to the oracle , where . The Challenger checks if and ; if this is true, it updates a list containing the tuple and set and (to indicate failure). If and the challenger gets and randomly sets and saves the tuple .
4.9. Key Setup Extraction Queries
(a)Partial key extraction queries: if , performs a number of tasks and updates with , respectively, after getting an identity query from . The tasks are as follows: checks if . If both conditions are true, returns to the adversary . If the conditions are false, sets partial private key and returns to and updates the list . By inspection, if the list updates the list by setting the following and adds them to the list, .(b)Public key extraction queries: performs a number of tasks and updates , respectively, based on a query made by on identity . The tasks are as follows: checks the following: . If both conditions are true, returns to the adversary . If the conditions are false, selects and sets the following and returns to , and then updates the list, . By inspection, if the list updates the list with . selects and sets the following and then updates .(c)Secret value extraction queries: if , performs a number of tasks and updates the list, with after obtaining an identity query from . checks the following: . If these conditions are true, executes Partial Key Extraction and Public Key Extraction Queries to obtain , respectively. By inspection, if the list , executes Partial Key Extraction and Public Key Extraction Queries to obtain and updates the list with full private keys , respectively.(d)Public key replacement queries: performs the following operations and updates the list when makes the query on . sets if the list contains Otherwise, sets and updates the list accordingly.(i) queries: checks the list = following a query from . It then returns the list, to if the list exists. Otherwise, it adds as a hash value to the list by selecting .(ii) queries: checks the list = following query from . then returns the list, to if exists. Otherwise, adds as a hash value to the list by selecting .
4.10. Queries at the Authentication Phase
(a)Signature queries: queries the challenger for a signature on an adaptive chosen message of a user . The Challenger checks the list, . runs Partial Key Extraction and Public Key Extraction queries, respectively, if . is also allowed to generate a corresponding signature of any arbitrary length message with its full private key under the condition that and are the public key and as the private key, where . The signature value returned from the Challenger is not a valid signature since the public key has been replaced by , and the Challenger may not know the corresponding public key.
The Challenger computes the following:
4.10.1. CL-Offline Signature
(a)Choose randomly (b)Compute and set (c)Set (d)Compute (e)Output offline signature , where
4.10.2. CL-Online Signature
(a)Compute (b)Compute (c)Output online signature value
For hash queries, = , set , and update .
4.11. Correctness for Signature
The Correctness for Signature is depicted as follows:
Hence, this is the BDH instance to the above problem which is solved for the given random list . 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 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 if the Type II adversary can win the game with advantage at time T can make the following queries to the Hash oracles (), queries to the private-key extraction oracle, queries to the public-key request oracle, and queries to the signing oracle, then the CDH problem can be solved with probability.
Proof. The theorem relies on the assumption that there exists an adversary with considerable powers having the advantage to attack the scheme without any constraint. The goal is to compute from a tuple with assumption that there exists an adversary capable of attacking the MHCOOS.
4.12. System Initialization Phase
At the Setup phase, Challenger, sets as the generator and sets , where is the master key of the KGC. Adversary, can act as the dishonest KGC. then updates an initially empty list containing the list during the game and responds to the various queries in as follows:(i) queries: the adversary makes number of queries to the oracle with an identity . selects , where denotes the maximum number of queries. The Challenger checks if and ; if this true, it updates a list containing the tuple and sets and for failure. If and , the challenger gets randomly and sets and updates the tuple .
4.13. Key Setup Extraction Queries
(a)Public key extraction queries: performs number of tasks and updates with after getting an identity query from . The tasks are as follows: checks the following: . If both conditions are true, returns to the adversary . If the conditions are false, it sets . selects and sets and returns to . By inspection, if the tuple does not contain updates the list with by selecting and sets and returns to .(b)Secret value extraction queries: if , performs some tasks and updates with after getting an identity query from . The tasks are as follows: checks the following: . If the conditions return true, executes Public Key Extraction Queries to obtain . By inspection, if executes Public Key Extraction Queries to obtain and updates the list with full private keys, .(i) queries: searches a list if it contains the tuple , following query on . then returns the tuple to if the tuple exists. Otherwise, adds as a hash value to the tuple by selecting .(ii) queries: searches the list = following query from . then returns the list, to if exists. Otherwise, adds as a hash value to the list by selecting .
4.14. Queries at the Authentication Phase
(a)Signature queries: obtains and allowed query the Challenger for a corresponding signature under the condition that .
The Challenger then searches for a list , containing the tuple . executes Public Key extraction Queries if the following are not found . is also allowed to generate a corresponding signature on any arbitrary length message with its full private key under the condition that .
The Challenger computes the following:
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 attacker 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 of 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.
(a)
(b)
5.1.2. Computation Cost
This 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 .
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. 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 Figure 4.(a)The MS initializes the system by generating system setup and other parameters. The user’s mobile device sends the identity of the user to MS to compute 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 , 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 .
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 (), 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.
Data Availability
The 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/pk-demo.cpp was used to test pk-demo.cpp of the library file.
Conflicts of Interest
The authors declare that there are no conflicts of interest.
Acknowledgments
This paper was supported by Fundamental Research Funds for the Central Universities (no. 30918012204), Military Common Information System Equipment Pre-Research Special Technology Project (315075701), 2019 Industrial Internet Innovation and Development Project from the Ministry of Industry and Information Technology of China, and 2018 Jiangsu Province Major Technical Research Project “Information Security Simulation System,” Shanghai Aerospace Science and Technology Innovation Fund (SAST2018-103).