A Batch Processing Technique for Wearable Health Crowd-Sensing in the Internet of Things
- Firstly, this article proposes a batch processing technique based on certificateless cryptography for the wearable health crowd-sensing (WHCS) system. The batch processing technique uses aggregate authentication and verification procedure to improve bandwidth limitation issues in large data transfers.
- Secondly, the proposed scheme provides anonymity by obscuring users’ identities during data transmission. In obscuring the user’s identity, the wearable device and the aggregator perform anonymous computation on the user’s identity to derive anonymity tuples before sending the user’s wearable data to the cloud.
- The formal security analysis proves the scheme is resistant to forgery and replay attacks, assuming that the Computational Diffie-Hellman (CDH) problem is hard to solve by a probabilistic polynomial-time (PPT) attacker in the random oracle model (ROM).
- Additionally, results from our performance evaluation have shown the proposed method to be more efficient than other existing batch processing schemes, reducing computational and communication costs while achieving less storage overhead.
- Results from our power consumption analysis prove the proposed scheme to be energy efficient, making it suitable for network bandwidth environments.
2. Summary of Existing Research
3.1. Bilinear Pairings
- Bilinearity: and , then . where (a times) and (b times) where are scalar multiplication in the additive group .
- Non-degeneracy: a bilinear pairing is non-degenerate if all the pairs in do not map to the pairs in where is the identity element of .
- The algorithm should be efficiently computed, such that , there exists an efficient algorithm to compute that . Such a mapping is called a bilinear mapping which can be constructed using the Weil or Tate Pairings .
3.2. Hardness Assumption
3.3. Formal Definition of a Certificateless Signature Scheme (CLS)
- Setup ]: The KGC takes a security parameter and runs the setup algorithm to return params and . It keeps secret and publicly publishes .
- Partial-Private-Key extract ]: The KGC takes , and the identity of as input. It returns a partial private key value and sends it to the user through a secure channel.
- Set-Secret-Value ]: The user (U) runs this algorithm by taking its identity and . It returns as its secret value.
- Set-Private-Key ]: the user (U) takes , , as inputs, and generates a private key as .
- Set-Public-Key ]: the user (U) takes , , as inputs, and returns as public key.
- Sign ]: The user (U) signs a message m by taking identity ,a private key as inputs and generates a valid signature as . It sends the signature value to the KGS through a secure channel.
- Verify ]: The KGS receives and performs the verification algorithm by taking the user’s identity , public key to obtain the message m. It checks if received from the user is a valid signature. It returns true for a valid signature and returns false for an invalid signature. It therefore rejects the message if the signature is invalid.
3.4. Security Model
- Adversary depicts a dishonest user who does not have access to the master secret key , but may request public keys and replace public keys of its choice, extract partial private keys, extract private keys and make forge queries on signatures of identities of its choice.
- Adversary represents a mistrusted KGS, which has, access to the master key but does not perform public key replacement. It has the ability to compute partial private keys having the master secret key. However, it is restricted not to replace public keys and make private key extraction queries.
3.4.1. Game 1
- Setup: The challenger takes a security parameter as input, and runs the setup algorithm to obtain the master secret key and generate the system parameters . The challenger keeps secret, and sends to .
- Attack: The adversary challenges the oracle by making the following queries:
- Create User: If an identity has already been created, then there is nothing to be done. Otherwise the oracle runs the Private-key extract, Set-secret value, Set-public key algorithm to obtain a secret value , a partial private key and returns the as the public key.
- Hash Queries: the adversary make hash queries to the hash oracles.
- Extract partial private key queries: The adversary makes a request on the partial private key on chosen identity . The oracle runs the query and returns , if has been created, otherwise it returns a null ∅.
- Set Secret value: The adversary makes a request on a chosen . The oracle returns as the secret value if the identity has been created. Otherwise it returns a null ∅.
- Private-key-Extraction: On input of an arbitrary identity it returns to the adversary if has been created. Otherwise it returns a null ∅.
- Replace public key: the oracle runs this query and replaces the public key on the requested identity .
- Sign: Adversary makes a query on a chosen identity , a message m and .
- If has been created, it outputs a signature such that .
- If has not been created, it returns an ∅.
- Forgery: Adversary outputs a forgery on and wins the game if =, has never been queried or has never been submitted to the Partial private key oracle.
3.4.2. Game 2
- Setup: The challenger takes as input a security parameter , and runs the setup algorithm to obtain the master secret key and the system parameters . The challenger keeps secret, and sends to .
- Attack: Adversary makes similar queries defined in Game 1 in Section 3.4.1 but does not query the partial private key extract.
- Sign: makes a query on a chosen identity , a message m and and returns a signature as in the sign phase of Game 1 in Section 3.4.1.
- Forgery: adversary outputs a forgery on and wins the game if , has never been queried or has never been submitted to the Partial private key oracle.
3.5. System Requirements
- Non-repudiation: it is noteworthy that the entities existing within the wearable health crowd-sensing(WHCS) system do not deny accessing the system resources for authentication to share wearable data.
- Resistance to forgery attacks: this feature requires the inability of any known adversary of forging valid individual and aggregate signatures from the wearable data.
- Resistance to Replay attacks: the feature prevents an adversary from replaying a message during message interception to modify the wearable data.
- Data Privacy: although our scheme requires the user to submit its identity for authentication, we assume the medical cloud server cannot leak the private information of the user.
- Anonymity: it requires that the identity of user is not revealed during message transfer from the wearable device onto the medical cloud server.
- Aggregate Authentication and verification: The medical cloud server is able to authenticate large wearable sensor data simultaneously. Likewise, aggregate message–signature pair can be verified through aggregate verification.
4. System Architecture
4.1. Entity Roles
- Wearable device (WD): The wearable device is equipped with micro-sensors to monitor and detect the user’s physiological data. It performs sensing functions such as monitoring heartbeat and detecting health abnormalities such as COVID-19 symptoms. It serves as the collection point to collect all the captured wearable sensor data. It performs anonymity computations to hide the user’s identity before submitting the wearable data to the aggregation unit.
- User (U): The user represents the device owner who wears the wearable device for daily personal health monitoring. The user can request a copy of their data from the medical cloud server.
- Aggregation unit (AU): The aggregation unit consists of the user’s mobile devices that aggregates all the received wearable sensor data from the wearable device. Since the mobile device is computationally powerful than the wearable device, it is designated to perform aggregation functions. It also performs anonymous computation to generate an anonymity tuple, which conceals the user’s identity before transferring the wearable sensor data to the medical cloud server.
- Medical cloud server (MCS): The medical cloud server represents the trusted cloud model. It receives the aggregated wearable sensor data from the aggregation unit and performs batch processing functions on the received data. It also stores and analyzes the received wearable sensor data. It sends a copy of the user’s data based on the user’s request.
4.2. Scheme Construction
- Setup : The medical cloud server (MCS) executes the setup algorithm by taking a security parameter as input. The MCS defines two cyclic groups and where is an additive group and is a multiplicative group of prime order q. With P as a generator, MCS constructs a bilinear pairing . It selects as its master secret key and derives its corresponding master public key as . It returns a master private/public key pair as . It chooses three one-way hash functions and generates system parameters as . It publicly publishes and keeps private. Refer to (Algorithm 1).
- Partial-Private Key Derivative: This algorithm comprises of two steps.
- In the first step, the user(U) chooses and computes . It sets the partial public parameters as and sends it to the medical cloud server as seen in (Algorithm 2).
- The medical cloud server(MCS) receives from the user and calculates the partial private key for the user as , where .It sends through a secure channel to the user(U). Refer (Algorithm 3).
- Key Generation: The user(U) executes the key generation algorithm by generating its full public/private key pair where and after obtaining from the MCS. From (Algorithm 4).
- Aggregation unit Registration: The aggregation unit (which comprises of the user’s mobile devices) randomly selects , and registers itself to the medical cloud server (MCS) by computing where and . Reference (Algorithm 5).
- Anonymity Computation: The wearable device initially hides the user’s identity by computing, and sends to the aggregation unit (AU). The aggregation unit (AU) in turn computes to hide the user’s identity for the second time. The aggregation unit(AU) sends the tuple to medical cloud server (MCS). Reference (Algorithms 6 and 7).
- Signing: The user takes its private key , and signs its wearable sensor data m, by taking a nonce , applying a timestamp , and signs the wearable sensor data as in Algorithm 8). It returns a signature value and sends to the medical cloud server (MCS). Reference in (Algorithm 8).
- Verification: The medical cloud server(MCS) receives both and the signature .
- After receiving the tuple from the AU, the checks the validity of the tuple through the timestamp, . If the timestamp has elapsed, that means the tuple is invalid and hence rejects it. Else, it accepts the tuple and computes it as .
- It also verifies signature and checks the equation: . It accepts the signature, if it is valid. Otherwise it rejects it. Refer to (Algorithm 9).
- Batch Processing: The aggregate authentication and verification occur at this stage. In the aggregate authentication, the identities of the individual users, with their corresponding public keys and generated signature values, are aggregated by their respective aggregation units and sent to the medical cloud server for verification.
- Aggregate authentication: The respective aggregation units aggregates all messages from the respective users n having identities with corresponding public keys . It then transmits them onto the medical cloud server (MCS).
- Aggregate Verification: the medical cloud server (MCS) performs the aggregate verification algorithm to verify the received accumulated tuples and the received wearable sensor data from the aggregation units.
|Algorithm 1: Setup (Run by Medical cloud Server)|
|Algorithm 2: Partial-Key Extraction Algorithm Part 1 (Executed by U)|
|Algorithm 3: Partial-Key Extraction Algorithm Part 2 (Executed by MCS)|
|Algorithm 4: Key Generation Algorithm (Run by user)|
|Algorithm 5: Aggregation unit Registration (Run by aggregation unit)|
|Algorithm 6: Anonymity (performed by Wearable device)|
|Algorithm 7: Anonymity (Performed by Aggregation Unit)|
|Algorithm 8: Signing (Run by user(U))|
|Algorithm 9: Verification (Run by Medical cloud Server)|
- Aggregate Authentication:The medical cloud server (MCS) receives of each user. Suppose there are n number of users with identities having public keys of with generated signatures as . The authenticated signature values are aggregated as follows:
The aggregated values are sent to the MCS for aggregate verification.
- Aggregate Verification:After receiving the aggregated signature values, the MCS checks the validity of aggregate signatures by verifying if and performs the correctness equation as follows:
5. Security Proofs and Analysis
5.1. Security Proofs
- Setup: The challenger performs a system setup by randomly picking a security parameter , and establishes the system parameters as and sets Before executing the query, maintains a list . A challenged identity is selected at random by the challenger and answer queries made by the adversary based on the following oracles .
- Query: initially creates an empty list containing the tuples . A query is made on and flips a . If , then , else if , and updates the tuples with in both cases. If then chooses and sets but if , then it sets . It finally returns and updates the list
- Query: A query is made on to the oracle. scans the list and checks if the tuple exists. If it exists, returns as answer. Otherwise, picks and returns as answer and updates the list with the tuple .
- Query: A query is made on . checks if the tuple exists in the list . If it exists, is returned to . Otherwise, it picks and returns as a new hash value of and sends to and updates the list with the tuple
- Reveal-Partial-Private-Key makes a query on . flips a coin . If , outputs a failure. Else, if , and contains , checks if . If , returns to . Otherwise, if , recovers from the list and selects , and defines . computes and returns as answer and adds an element to the tuple . It finally updates the list If , and the list does not contain the tuple , then sets , and computes . C adds an element to the tuple and inserts it to and returns as an answer.
- Public-key Queries: A request is made on an identity . On receiving the query, a public key request is selected from the list and checks the tuple if it exists in . checks if . If it holds, selects and sets , and updates the list with . Otherwise, returns to . If is not in , let , then selects and sets . inserts into the tuple and returns as a reply to .
- Secret-key Queries: makes a query on a chosen identity . On receiving a query, checks if and if . If they hold, selects and returns and updates the list . Otherwise, if , sends as a response to
- Query on Public key Replacement: When the adversary submits a query to replace the public key . checks the tuple if the tuple exists in the list and sets and . It updates the list with the tuple If the tuple does not exist in , sets and , it then updates the list with the tuple .
- Sign queries: makes a sign query on an identity with ), searches the tuple from the list . If the list contains , checks whether . If , makes a public-key Query to generate and sets . Otherwise, if the tuple is empty makes a public key query to generate and sets and adds to the list, . It computes the following:
and returns as a signature on the message m.
- Forgery: Applying the forking lemma, outputs two signatures and where . Therefore, and . tosses a coin , if , outputs a failure and aborts the simulation. Otherwise, computesFrom Equations (3) and (4)Notice that, and .Therefore,Hence, . □
- denotes an event in which the adversary queries the partial private key which results in the probability of . The success probability of occurring is .
- denotes an event in which the adversary makes sign queries .
- indicates an event in which the adversary has queries to the private keys =. The success probability of occurring is . The success probability of winning the game is
5.3. Security Requirements Analysis
- Non-Repudiation: The proposed scheme satisfies non-repudiation since the wearable user cannot deny signing its wearable sensor data to the medical cloud server. Neither can the medical cloud server deny verifying the user’s data. Therefore, in case of any denial, the identity of the wearable user can serve as proof.
- Anonymity: The scheme ensures that the user’s (device owner) identity is not revealed during the transfer of data. The wearable device firstly computes to conceal the wearable user’s identity before transmitting to the aggregation unit. subsequently, the aggregation unit also computes before transmitting it to the medical cloud server. Consequently, both wearable device and aggregation unit do not reveal the user’s identity during the data transfer process.
- Resistance to forgery Attacks: According to the random oracle of theorem 1, the probability of a polynomial adversary forging a valid signature is negligible under the assumption that the ability to solve the CDH problem is hard. Hence, the scheme can resist forgery attacks.
- Resistance to replay attacks: Timestamps provide the precise time or period during which the user signed their wearable sensor data. It prevents an adversary from replaying a message if the timestamp validity of the corresponding signature is expired.
- Aggregate authentication: The proposed scheme ensures batch authentication of n messages from n group of users. Consequently, the medical cloud server is able to authenticate an individual user by computing .
- Aggregate Verification: the proposed scheme extends the batch processing to verify aggregated message-signature pairs from a large group of users to improve bandwidth efficiency during batch data transfer.
6. Performance Evaluation
6.1. Background of Comparative Schemes
6.2. Functionality Analysis
6.3. Computational Cost
6.4. Communication and Overhead Cost
6.5. Energy Consumption
Institutional Review Board Statement
Informed Consent Statement
Data Availability Statement
Conflicts of Interest
|CL-PKC||Certificateless Public Key Cryptography|
|COVID-19||Coronavirus Disease 2019|
|HACA||Hierarchical Anonymous Certificateless Authentication|
|HWSN||Healthcare wireless sensor networks|
|IBC||Identity based Cryptography|
|IoT||Internet of Things|
|KGS||Key Generation Server|
|MCS||Medical Cloud Server|
|params||Public System parameters|
|PKG||Public Key Generator|
|PKI||Public Key Infrastructure|
|WBAN||Wireless Body Area Networks|
|WHCS||Wearable Health Crowd-Sensing|
- Cecilia, J.M.; Cano, J.C.; Hernández-Orallo, E.; Calafate, C.T.; Manzoni, P. Mobile crowdsensing approaches to address the COVID-19 pandemic in Spain. IET Smart Cities 2020, 2, 58–63. [Google Scholar] [CrossRef]
- He, D.; Chan, S.; Guizani, M. User privacy and data trustworthiness in mobile crowd sensing. IEEE Wirel. Commun. 2015, 22, 28–34. [Google Scholar] [CrossRef]
- Gutmann, P. PKI: It’s not dead, just resting. Computer 2002, 35, 41–49. [Google Scholar] [CrossRef][Green Version]
- Boneh, D.; Franklin, M. Identity-based encryption from the Weil pairing. In Proceedings of the Annual International Cryptology Conference, Santa Barbara, CA, USA, 19–23 August 2001; Springer: Berlin, Heidelberg/Germany, 2001; pp. 213–229. [Google Scholar]
- Al-Riyami, S.S.; Paterson, K.G. Certificateless public key cryptography. In Proceedings of the International Conference on the Theory and Application of Cryptology and Information Security, Taipei, Taiwan, 3 November–4 December 2003; Springer: Berlin, Heidelberg/Germany, 2003; pp. 452–473. [Google Scholar]
- Ates, H.C.; Yetisen, A.K.; Güder, F.; Dincer, C. Wearable devices for the detection of COVID-19. Nat. Electron. 2021, 4, 13–14. [Google Scholar] [CrossRef]
- Channa, A.; Popescu, N.; Skibinska, J.; Burget, R. The rise of wearable devices during the COVID-19 pandemic: A systematic review. Sensors 2021, 21, 5787. [Google Scholar] [CrossRef]
- Liu, J.; Shen, H.; Narman, H.S.; Chung, W.; Lin, Z. A survey of mobile crowdsensing techniques: A critical component for the internet of things. ACM Trans. Cyber-Phys. Syst. 2018, 2, 1–26. [Google Scholar] [CrossRef]
- Owoh, N.P.; Singh, M.M. Security analysis of mobile crowd sensing applications. Appl. Comput. Inform. 2020, 18, 2–21. [Google Scholar] [CrossRef]
- Kamil, I.A.; Ogundoyin, S.O. A lightweight CLAS scheme with complete aggregation for healthcare mobile crowdsensing. Comput. Commun. 2019, 147, 209–224. [Google Scholar] [CrossRef]
- Pius Owoh, N.; Mahinderjit Singh, M. SenseCrypt: A security framework for mobile crowd sensing applications. Sensors 2020, 20, 3280. [Google Scholar] [CrossRef]
- Li, J.; Su, Z.; Guo, D.; Choo, K.K.R.; Ji, Y.; Pu, H. Secure data deduplication protocol for edge-assisted mobile crowdsensing services. IEEE Trans. Veh. Technol. 2020, 70, 742–753. [Google Scholar] [CrossRef]
- Ni, J.; Zhang, K.; Xia, Q.; Lin, X.; Shen, X.S. Enabling strong privacy preservation and accurate task allocation for mobile crowdsensing. IEEE Trans. Mob. Comput. 2019, 19, 1317–1331. [Google Scholar] [CrossRef][Green Version]
- Zhang, Y.; Deng, R.H.; Zheng, D.; Li, J.; Wu, P.; Cao, J. Efficient and robust certificateless signature for data crowdsensing in cloud-assisted industrial IoT. IEEE Trans. Ind. Inform. 2019, 15, 5099–5108. [Google Scholar] [CrossRef]
- Shim, K.A.; Lee, Y.R.; Park, C.M. EIBAS: An efficient identity-based broadcast authentication scheme in wireless sensor networks. Ad. Hoc. Netw. 2013, 11, 182–189. [Google Scholar] [CrossRef]
- Kumar, P.; Kumari, S.; Sharma, V.; Sangaiah, A.K.; Wei, J.; Li, X. A certificateless aggregate signature scheme for healthcare wireless sensor network. Sustain. Comput. Inform. Syst. 2018, 18, 80–89. [Google Scholar] [CrossRef]
- Asari, A.; Alagheband, M.R.; Bayat, M.; Asaar, M.R. A new provable hierarchical anonymous certificateless authentication protocol with aggregate verification in ADS-B systems. Comput. Netw. 2021, 185, 107599. [Google Scholar] [CrossRef]
- Joux, A. A one round protocol for tripartite Diffie–Hellman. J. Cryptol. 2004, 17, 263–276. [Google Scholar] [CrossRef]
- Karantaidou, I.; Halkidis, S.T.; Petridou, S.; Mamatas, L.; Stephanides, G. Pairing-based cryptography on the Internet of Things: A feasibility study. In Proceedings of the International Conference on Wired/Wireless Internet Communication, Boston, MA, USA, 18–20 June 2018; Springer: Berlin, Heidelberg/Germany, 2018; pp. 219–230. [Google Scholar]
- Miller, V.S. The Weil pairing, and its efficient calculation. J. Cryptol. 2004, 17, 235–261. [Google Scholar] [CrossRef]
- Tso, R.; Huang, X.; Susilo, W. Strongly secure certificateless short signatures. J. Syst. Softw. 2012, 85, 1409–1417. [Google Scholar] [CrossRef]
- Tiwari, D.; Gangadharan, G. SecAuth-SaaS: A hierarchical certificateless aggregate signature for secure collaborative SaaS authentication in cloud computing. J. Ambient Intell. Humaniz. Comput. 2021, 12, 10539–10563. [Google Scholar] [CrossRef]
- Wang, W.; Huang, H.; Wu, Y.; Huang, Q. Cryptanalysis and improvement of an anonymous batch verification scheme for mobile healthcare crowd sensing. IEEE Access 2019, 7, 165842–165851. [Google Scholar] [CrossRef]
- Wu, L.; Xu, Z.; He, D.; Wang, X. New certificateless aggregate signature scheme for healthcare multimedia social network on cloud environment. Secur. Commun. Netw. 2018, 2018, 2595273. [Google Scholar] [CrossRef]
- Ullah, I.; Amin, N.U.; Khan, M.A.; Khattak, H.; Kumari, S. An efficient and provable secure certificate-based combined signature, encryption and signcryption scheme for internet of things (IoT) in mobile health (M-health) system. J. Med. Syst. 2021, 45, 1–14. [Google Scholar] [CrossRef]
- Li, F.; Hong, J. Efficient certificateless access control for wireless body area networks. IEEE Sens. J. 2016, 16, 5389–5396. [Google Scholar] [CrossRef]
|WD anonymity computed tuple|
|AU anonymity computed tuple|
|,||Additive and Multiplicative cyclic groups|
|Three One-Way hash functions|
|master secret key|
|master secret/public key pair|
|user generated secret value|
|partial public parameters|
|Partial private key generated by MCS|
|User private key|
|User public key|
|KGS||Key Generation Server|
|MCS||Medical Cloud Server|
|Functionality||SecAuth-SaaS ||CABV-MHCS ||CASS-HMSN ||HACA-ADS-B ||Proposed|
|Scheme||Sign||Verify||Aggregate Sign||Aggregate Verify|
|Scheme||Sign Cost||Verify Cost||Total (Sign + Verify)||Batch Processing (n = 100)|
|Scheme||Sig. Size on Single Message||Sig Size for n Messages||Comm. Cost for Single Message||Comm. Cost for n Messages||Storage Overhead|
|SecAuth-SaaS ||704 bytes||704n bytes||385 bytes|
|CABV-MHCS ||320 bytes||320n bytes||233 bytes|
|CASS-HMSN ||320 bytes||320n bytes||245 bytes|
|HACA-ADS-B ||256 bytes||256n bytes||135 bytes|
|Proposed||128 bytes||128n bytes||98 bytes|
Publisher’s Note: MDPI stays neutral with regard to jurisdictional claims in published maps and institutional affiliations.
© 2022 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (https://creativecommons.org/licenses/by/4.0/).
Addobea, A.A.; Li, Q.; Amankona, I.O.; Hou, J. A Batch Processing Technique for Wearable Health Crowd-Sensing in the Internet of Things. Cryptography 2022, 6, 33. https://doi.org/10.3390/cryptography6030033
Addobea AA, Li Q, Amankona IO, Hou J. A Batch Processing Technique for Wearable Health Crowd-Sensing in the Internet of Things. Cryptography. 2022; 6(3):33. https://doi.org/10.3390/cryptography6030033Chicago/Turabian Style
Addobea, Abigail Akosua, Qianmu Li, Isaac Obiri Amankona, and Jun Hou. 2022. "A Batch Processing Technique for Wearable Health Crowd-Sensing in the Internet of Things" Cryptography 6, no. 3: 33. https://doi.org/10.3390/cryptography6030033