A Batch Processing Technique for Wearable Health CrowdSensing in the Internet of Things
Abstract
:1. Introduction
 Firstly, this article proposes a batch processing technique based on certificateless cryptography for the wearable health crowdsensing (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 DiffieHellman (CDH) problem is hard to solve by a probabilistic polynomialtime (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.
Motivation
2. Summary of Existing Research
3. Preliminaries
3.1. Bilinear Pairings
 Bilinearity: $\forall P\in {\mathcal{G}}_{1},\forall P\in {\mathcal{G}}_{2}$ and $a,b\in {Z}_{q}^{*}$, then $\phantom{\rule{0.222222em}{0ex}}\widehat{e}(aP,bQ)=\phantom{\rule{0.222222em}{0ex}}\widehat{e}{(P,Q)}^{ab}$. $\forall a,b\in {\mathbb{Z}}_{q}^{*},\phantom{\rule{0.222222em}{0ex}}\phantom{\rule{0.222222em}{0ex}}\widehat{e}(aP,bQ)=\phantom{\rule{0.222222em}{0ex}}\widehat{e}{(P,Q)}^{ab}$ where $aP=P+P+P\dots +P$ (a times) and $bP=P+P+P\dots +P$ (b times) where $a,b$ are scalar multiplication in the additive group [4].
 Nondegeneracy: a bilinear pairing $\widehat{e}(P,Q)\ne {1}_{{\mathbb{G}}_{2}}$ is nondegenerate if all the pairs in ${\mathbb{G}}_{1}$ do not map to the pairs in ${\mathbb{G}}_{2}$ where ${1}_{{\mathbb{G}}_{2}}$ is the identity element of ${\mathbb{G}}_{2}$.
 The algorithm should be efficiently computed, such that $\forall P,Q\in {\mathbb{G}}_{1}$, there exists an efficient algorithm to compute that $\widehat{e}(P,Q)$. Such a mapping $\widehat{e}$ is called a bilinear mapping which can be constructed using the Weil or Tate Pairings [20].
3.2. Hardness Assumption
3.3. Formal Definition of a Certificateless Signature Scheme (CLS)
 Setup $[\left({1}^{k}\right)\to (params,msk)$]: The KGC takes a security parameter ${1}^{k}$ and runs the setup algorithm to return params and $msk$. It keeps $msk$ secret and publicly publishes $params$.
 PartialPrivateKey extract $[(params,msk,I{D}_{i})\to {D}_{i}$]: The KGC takes $params$, $msk$ and the identity $I{D}_{i}$ of $Use{r}_{i}$ as input. It returns a partial private key value ${D}_{i}$ and sends it to the user through a secure channel.
 SetSecretValue $[(params,I{D}_{i})\to {x}_{i}$]: The user (U) runs this algorithm by taking its identity $I{d}_{i}$ and $params$. It returns ${x}_{i}$ as its secret value.
 SetPrivateKey $[(params,I{D}_{i},{D}_{i})\to {S}_{i}$]: the user (U) takes $params$, $I{D}_{i}$, ${D}_{i}$ as inputs, and generates a private key as ${S}_{i}$.
 SetPublicKey $[(params,I{D}_{i},{x}_{i})\to {P}_{i}$]: the user (U) takes $params$, $I{D}_{i}$, ${x}_{i}$ as inputs, and returns ${P}_{i}$ as public key.
 Sign $[(params,I{D}_{i},{S}_{i})\to {\sigma}_{i}$]: The user (U) signs a message m by taking identity $I{D}_{i}$,a private key ${S}_{i}$ as inputs and generates a valid signature as ${\sigma}_{i}$. It sends the signature value ${\sigma}_{i}$ to the KGS through a secure channel.
 Verify $[m\stackrel{?}{=}({\sigma}_{i},I{D}_{i},{P}_{i})$]: The KGS receives ${\sigma}_{i}$ and performs the verification algorithm by taking the user’s identity $I{D}_{i}$, public key ${P}_{i}$ to obtain the message m. It checks if ${\sigma}_{i}$ 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 ${\mathcal{A}}_{1}$ depicts a dishonest user who does not have access to the master secret key $msk$, 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 ${\mathcal{A}}_{2}$ 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 $\mathcal{C}$ takes a security parameter ${1}^{k}$ as input, and runs the setup algorithm to obtain the master secret key $msk$ and generate the system parameters $params$. The challenger $\mathcal{C}$ keeps $msk$ secret, and sends $params$ to ${\mathcal{A}}_{1}$.
 Attack: The adversary ${\mathcal{A}}_{1}$ challenges the oracle by making the following queries:
 Create User: If an identity $I{D}_{i}$ has already been created, then there is nothing to be done. Otherwise the oracle runs the Privatekey extract, Setsecret value, Setpublic key algorithm to obtain a secret value ${x}_{i}$, a partial private key ${D}_{i}$ and returns the ${P}_{i}$ as the public key.
 Hash Queries: the adversary ${\mathcal{A}}_{1}$ make hash queries to the hash oracles.
 Extract partial private key queries: The adversary ${\mathcal{A}}_{1}$ makes a request on the partial private key on chosen identity $I{D}_{i}$. The oracle runs the query and returns ${D}_{i}$, if $I{D}_{i}$ has been created, otherwise it returns a null ∅.
 Set Secret value: The adversary ${\mathcal{A}}_{1}$ makes a request on a chosen $I{D}_{i}$. The oracle returns ${x}_{i}$ as the secret value if the identity $I{D}_{i}$ has been created. Otherwise it returns a null ∅.
 PrivatekeyExtraction: On input of an arbitrary identity $I{D}_{i}$ it returns ${D}_{i}$ to the adversary ${\mathcal{A}}_{1}$ if $I{D}_{i}$ has been created. Otherwise it returns a null ∅.
 Replace public key: the oracle runs this query and replaces the public key ${P}_{i}^{*}$ on the requested identity $I{D}_{i}$.
 Sign: Adversary ${\mathcal{A}}_{1}$ makes a query on a chosen identity $I{D}_{i}$, a message m and ${P}_{i}$.
 If $I{D}_{i}$ has been created, it outputs a signature $\sigma $ such that $Verify(I{D}_{i},m,{P}_{i},\sigma )=true$.
 If $\mathit{I}{D}_{i}$ has not been created, it returns an ∅.
 Forgery: Adversary ${\mathcal{A}}_{1}$ outputs a forgery on $(I{D}_{i}^{*},{P}_{i}^{*},m*,{\sigma}^{*})$ and wins the game if $Verify(I{D}_{i},m,{P}_{i},\sigma )$=$true$, $I{D}^{*}$ has never been queried or has never been submitted to the Partial private key oracle.
3.4.2. Game 2
 Setup: The challenger $\mathcal{C}$ takes as input a security parameter ${1}^{k}$, and runs the setup algorithm to obtain the master secret key $msk$ and the system parameters $params$. The challenger $\mathcal{C}$ keeps $msk$ secret, and sends $params$ to ${\mathcal{A}}_{2}$.
 Attack: Adversary ${\mathcal{A}}_{2}$ makes similar queries defined in Game 1 in Section 3.4.1 but does not query the partial private key extract.
 Sign: ${\mathcal{A}}_{2}$ makes a query on a chosen identity $I{D}_{i}$, a message m and ${P}_{i}$ and returns a signature $\sigma $ as in the sign phase of Game 1 in Section 3.4.1.
 Forgery: adversary ${\mathcal{A}}_{2}$ outputs a forgery on $(I{D}_{i}^{*},{P}_{i}^{*},{m}^{*},{\sigma}^{*})$ and wins the game if $Verify(I{D}_{i},m,{P}_{i},\sigma )=true$, $I{D}_{i}^{*}$ has never been queried or has never been submitted to the Partial private key oracle.
3.5. System Requirements
 Nonrepudiation: it is noteworthy that the entities existing within the wearable health crowdsensing(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 microsensors to monitor and detect the user’s physiological data. It performs sensing functions such as monitoring heartbeat and detecting health abnormalities such as COVID19 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.
Design Objectives
4.2. Scheme Construction
 Setup $\left({1}^{k}\right)$: The medical cloud server (MCS) executes the setup algorithm by taking a security parameter ${1}^{k}$ as input. The MCS defines two cyclic groups ${\mathbb{G}}_{1}$ and ${\mathbb{G}}_{2}$ where ${\mathbb{G}}_{1}$ is an additive group and ${\mathbb{G}}_{2}$ is a multiplicative group of prime order q. With P as a generator, MCS constructs a bilinear pairing $\widehat{e}:{\mathbb{G}}_{1}\times {\mathbb{G}}_{1}\to {\mathbb{G}}_{2}$. It selects ${x}_{MCS}{\in}_{R}{\mathbb{Z}}_{q}^{*}$ as its master secret key and derives its corresponding master public key as ${P}_{MCS}={x}_{MCS}P$. It returns a master private/public key pair as $({x}_{MCS},{P}_{MCS})$. It chooses three oneway hash functions ${H}_{1}:{\{0,1\}}^{*}\to {\mathbb{G}}_{1};{H}_{2}:{\{0,1\}}^{*}\times {\mathbb{G}}_{1}\to {\mathbb{Z}}_{q}^{*};{H}_{3}:{\{0,1\}}^{*}\times {\mathbb{G}}_{1}\times {\mathbb{G}}_{1}\to {\mathbb{Z}}_{q}^{*};$ and generates system parameters as $params$. It publicly publishes $params$ and keeps ${x}_{MCS}$ private. Refer to (Algorithm 1).
 PartialPrivate Key Derivative: This algorithm comprises of two steps.
 (a)
 In the first step, the user(U) chooses ${s}_{i}{\in}_{R}{\mathbb{Z}}_{q}^{*}$ and computes ${R}_{i}={s}_{i}P$. It sets the partial public parameters as $\langle I{d}_{i},{R}_{i}\rangle $ and sends it to the medical cloud server as seen in (Algorithm 2).
 (b)
 The medical cloud server(MCS) receives $\langle I{D}_{i},{R}_{i}\rangle $ from the user and calculates the partial private key for the user as ${S}_{i}={x}_{MCS}{Q}_{i}$, where ${Q}_{i}={H}_{1}(I{D}_{i}\left\right{R}_{i})$.It sends $\langle {Q}_{i},{S}_{i}\rangle $ 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 $\langle {P}_{i},P{r}_{i}\rangle $ where $P{r}_{i}=({s}_{i},{S}_{i})$ and ${P}_{i}=({R}_{i},{Q}_{i})$ after obtaining $\langle {Q}_{i},{S}_{i}\rangle $ from the MCS. From (Algorithm 4).
 Aggregation unit Registration: The aggregation unit (which comprises of the user’s mobile devices) randomly selects ${c}_{i}{\in}_{R}{\mathbb{Z}}_{q}^{*}$, and registers itself to the medical cloud server (MCS) by computing $({J}_{i},{T}_{i})$ where ${J}_{i}={c}_{i}{Q}_{i}$ and ${T}_{i}={c}_{i}{S}_{i}$. Reference (Algorithm 5).
 Anonymity Computation: The wearable device initially hides the user’s identity by computing, ${B}^{l}=(I{d}_{i}\left\right{h}_{i}\left\right{W}_{i}\left\right{t}_{i}\left\rightm\left\right{U}_{i}{)}^{l}$ and sends ${B}^{l}$ to the aggregation unit (AU). The aggregation unit (AU) in turn computes ${B}^{l{P}_{MCS}}=(I{d}_{i}\left\right{h}_{i}\left\right{W}_{i}\left\right{t}_{i}\left\rightm\left\right{U}_{i}{)}^{l{P}_{MCS}}$ to hide the user’s identity for the second time. The aggregation unit(AU) sends the tuple ${B}^{l{P}_{MCS}}$ to medical cloud server (MCS). Reference (Algorithms 6 and 7).
 Signing: The user takes its private key $P{r}_{i}=({s}_{i},{S}_{i})$, and signs its wearable sensor data m, by taking a nonce ${n}_{i}{\in}_{R}{\mathbb{Z}}_{q}^{*}$, applying a timestamp ${t}_{i}\in {T}_{s}$, and signs the wearable sensor data as in Algorithm 8). It returns a signature value ${\sigma}_{i}=\langle {U}_{i},{V}_{i}\rangle $ and sends ${\sigma}_{i}$ to the medical cloud server (MCS). Reference in (Algorithm 8).
 Verification: The medical cloud server(MCS) receives both ${B}^{l{P}_{MCS}}$ and the signature ${\sigma}_{i}=\langle {U}_{i},{V}_{i}\rangle $.
 (a)
 After receiving the tuple ${B}^{l{P}_{MCS}}=(I{d}_{i}\left\right{h}_{i}\left\right{W}_{i}\left\right{t}_{i}\left\rightm\left\right{U}_{i}{)}^{l{P}_{MCS}}$ from the AU, the $MCS$ checks the validity of the tuple through the timestamp, ${t}_{i}$. If the timestamp ${t}_{i}$ has elapsed, that means the tuple is invalid and hence rejects it. Else, it accepts the tuple and computes it as ${B}^{1/l}=(I{d}_{i}\left\right{h}_{i}\left\right{W}_{i}\left\right{t}_{i}\left\rightm\left\right{U}_{i}{)}^{{x}_{MCS}}$.
 (b)
 It also verifies signature and checks the equation: $\widehat{e}({V}_{i},P)=\widehat{e}({J}_{i}+{h}_{i}{U}_{i},{P}_{MCS})$. 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.
 (a)
 Aggregate authentication: The respective aggregation units aggregates all messages from the respective users n having identities $(I{d}_{i}\cdots I{d}_{n})$ with corresponding public keys $({R}_{i}\cdots {R}_{n})$. It then transmits them onto the medical cloud server (MCS).
 (b)
 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 $\left({1}^{k}\right)$ (Run by Medical cloud Server) 

Algorithm 2: PartialKey Extraction Algorithm Part 1 $(I{D}_{i},{s}_{i})$ (Executed by U) 

Algorithm 3: PartialKey Extraction Algorithm Part 2 $(I{D}_{i},{R}_{i},{H}_{1})$ (Executed by MCS) 

Algorithm 4: Key Generation $\langle {Q}_{i},{S}_{i}\rangle $ Algorithm (Run by user) 

Algorithm 5: Aggregation unit Registration $\left({c}_{i}\right)$ (Run by aggregation unit) 

Algorithm 6: Anonymity $\left(l\right)$ (performed by Wearable device) 

Algorithm 7: Anonymity $\left({P}_{MCS}\right)$ (Performed by Aggregation Unit) 

Algorithm 8: Signing $(m,{n}_{i},{t}_{i},P{r}_{i})$ (Run by user(U)) 

Algorithm 9: Verification $({\sigma}_{i},{P}_{i})$ (Run by Medical cloud Server) 
Batch Processing
 Aggregate Authentication:The medical cloud server (MCS) receives $\left\{{V}_{i},{U}_{i},m,I{D}_{i},{t}_{i},{B}^{l{P}_{MCS}}\right\}$ of each user. Suppose there are n number of users $\left({U}_{1}\cdots {U}_{n}\right)$ with identities $\left(I{D}_{i}\cdots I{D}_{n}\right)$ having public keys of $\left({R}_{1}\cdots {R}_{n}\right)$ with generated signatures as $\left({\sigma}_{1}\cdots {\sigma}_{n}\right)$. The authenticated signature values are aggregated as follows:
 (a)
 $V={\sum}_{i=1}^{n}{V}_{i}$
 (b)
 $U={\sum}_{i=1}^{n}{U}_{i}{h}_{i}$
 (c)
 $R={\sum}_{i=1}^{n}{R}_{i}$
 (d)
 $\mathcal{J}={\sum}_{i=1}^{n}{\mathcal{J}}_{i}$
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 $\phantom{\rule{4pt}{0ex}}\widehat{e}({V}_{i},P)=\widehat{e}(\mathcal{J}+U,{P}_{MCS})$ and performs the correctness equation as follows:$$\begin{array}{cc}\hfill \phantom{\rule{1.em}{0ex}}& \widehat{e}({V}_{i},P)=\widehat{e}(\sum _{i=1}^{n}{V}_{i},P)\hfill \\ \hfill \phantom{\rule{1.em}{0ex}}& =\prod _{i=1}^{n}\widehat{e}({V}_{i},P)\hfill \\ \hfill \phantom{\rule{1.em}{0ex}}& =\prod _{i=1}^{n}\widehat{e}({T}_{i}+{n}_{i}{h}_{i}{s}_{i}{P}_{MCS},P)\hfill \\ \hfill \phantom{\rule{1.em}{0ex}}& =\prod _{i=1}^{n}\widehat{e}({T}_{i},P)\widehat{e}({n}_{i}{h}_{i}{s}_{i}{P}_{MCS},P)\hfill \\ \hfill \phantom{\rule{1.em}{0ex}}& =\prod _{i=1}^{n}\widehat{e}(\mathcal{J},{P}_{MCS}\widehat{e}({U}_{i}{h}_{i},{P}_{MCS})\hfill \\ \hfill \phantom{\rule{1.em}{0ex}}& =\widehat{e}(\mathcal{J}+U,{P}_{MCS})\hfill \end{array}$$
5. Security Proofs and Analysis
5.1. Security Proofs
 Setup: The challenger $\mathcal{C}$ performs a system setup by randomly picking a security parameter ${1}^{k}$, and establishes the system parameters as $\xi =\left\{{\mathbb{G}}_{1},{\mathbb{G}}_{2},{MCS}_{pub},\widehat{e},\mathcal{P},q,{H}_{1},{H}_{2},{H}_{3}\right\}$ and sets ${MCS}_{pub}=X.$ Before executing the query, $\mathcal{C}$ maintains a list ${L}_{\mathrm{i}}=\left({Id}_{i},{s}_{i},{R}_{i},{\mathrm{S}}_{i}\right)$. A challenged identity ${Id}_{i}$ is selected at random by the challenger $\mathcal{C}$ and answer queries made by the adversary ${\mathcal{A}}_{1}$ based on the following oracles ${L}_{{H}_{1}},{L}_{{H}_{2}},{L}_{{H}_{3}},{L}_{1},{L}_{2}$.
 ${H}_{1}$ Query: $\mathcal{C}$ initially creates an empty list containing the tuples $\u2329{Id}_{i},{R}_{i},{Q}_{i},{c}_{i},coin\phantom{\rule{4pt}{0ex}}{x}_{i}\u232a$. A query is made on ${Id}_{i}$ and $\mathcal{C}$ flips a $coin\phantom{\rule{4pt}{0ex}}{x}_{i}$. If ${x}_{i}\stackrel{yields}{\u27f6}0$, then $Pr\left(coin\phantom{\rule{4pt}{0ex}}{x}_{i}\right)=\epsilon $, else if ${x}_{i}\stackrel{yields}{\u27f6}1$, $Pr\left(coin\phantom{\rule{4pt}{0ex}}{x}_{i}\right)=1\epsilon $ and updates the tuples with $\u2329{Id}_{i},{R}_{i},{Q}_{i},{c}_{i},coin\phantom{\rule{4pt}{0ex}}{x}_{i}\u232a$ in both cases. If ${x}_{i}\stackrel{yields}{\u27f6}0,$ then $\mathcal{C}$ chooses ${\alpha}_{i}{\in}_{R}{Z}_{q}^{*}$ and sets ${Q}_{i}={H}_{1}\left({Id}_{i}\Vert {R}_{i}\right)=b{\alpha}_{i}P$ but if ${x}_{i}\stackrel{yields}{\u27f6}1$, then it sets ${Q}_{i}={\alpha}_{i}P$. It finally returns ${Q}_{i}$ and updates the list ${L}_{{H}_{1}}.$
 ${H}_{2}$ Query: A query is made on $\langle {m}_{i},{U}_{i}\rangle $ to the ${H}_{2}$ oracle. $\mathcal{C}$ scans the list ${L}_{{H}_{2}}=\langle {m}_{i},{U}_{i},{h}_{i}\rangle $ and checks if the tuple exists. If it exists, $\mathcal{C}$ returns $\langle {m}_{i},{U}_{i}\rangle $ as answer. Otherwise, $\mathcal{C}$ picks ${h}_{i}{\in}_{R}{Z}_{q}^{*}$ and returns ${h}_{i}$ as answer and updates the list ${L}_{{H}_{2}}$ with the tuple $\langle {m}_{i},{U}_{i},\phantom{\rule{4pt}{0ex}}{h}_{i}\rangle $.
 ${H}_{3}$ Query: A query is made on $\langle {m}_{i},{U}_{i}\rangle $. $\mathcal{C}$ checks if the tuple $\langle {m}_{i},{U}_{i},{c}_{i}\rangle $ exists in the list ${L}_{{H}_{3}}$. If it exists, $\langle {m}_{i},{U}_{i}\rangle $ is returned to ${\mathcal{A}}_{1}$. Otherwise, it picks ${c}_{i}{\in}_{R}{\mathbb{Z}}_{q}^{*}$ and returns ${c}_{i}$ as a new hash value of ${H}_{3}$ and sends $\u2329{m}_{i},{U}_{i}\u232a$ to ${\mathcal{A}}_{1}$ and updates the list with the tuple $\langle {m}_{i},{U}_{i},{c}_{i}\rangle .$
 RevealPartialPrivateKey $\mathrm{Queries}:{\mathcal{A}}_{1}$ makes a query on ${Id}_{i}$. $\mathcal{C}$ flips a coin ${x}_{i}$. If ${x}_{i}\stackrel{yields}{\u27f6}0$, $\mathcal{C}$ outputs a failure. Else, if ${x}_{i}\stackrel{yields}{\u27f6}1$, and ${L}_{i}$ contains $({Id}_{i},{s}_{i},{R}_{i},{S}_{i})$, $\mathcal{C}$ checks if ${S}_{i}=\perp $. If ${S}_{i}\ne \perp $, $\mathcal{C}$ returns ${S}_{i}$ to ${\mathcal{A}}_{1}$. Otherwise, if ${S}_{i}=\perp $, $\mathcal{C}$ recovers $\langle {Id}_{i},{R}_{i},{Q}_{i},{c}_{i},coin\phantom{\rule{4pt}{0ex}}{x}_{i}\rangle $ from the list ${L}_{{H}_{1}}$ and selects ${\alpha}_{i}{\in}_{R}{Z}_{q}^{*}$, and defines ${Q}_{i}={H}_{1}({Id}_{i}\left\right{R}_{i})={\alpha}_{i}P$. $\mathcal{C}$ computes ${S}_{i}={x}_{MCS}{\alpha}_{i}P$ and returns ${S}_{i}$ as answer and adds an element to the tuple $({Id}_{i},{s}_{i},{R}_{i},{S}_{i})$. It finally updates the list ${L}_{\mathrm{i}}.$ If ${x}_{i}\stackrel{yields}{\u27f6}1$, and the list does not contain the tuple $\left({Id}_{i},{s}_{i},{R}_{i},{\mathrm{S}}_{i},\right)$, then $\mathcal{C}$ sets ${S}_{i}=\perp $, and computes ${S}_{i}={x}_{MCS}{\alpha}_{i}P$. C adds an element to the tuple $({Id}_{i},{s}_{i},{R}_{i},{S}_{i},)$ and inserts it to ${L}_{i}$ and returns ${S}_{i}$ as an answer.
 Publickey Queries: A request is made on an identity ${Id}_{i}$. On receiving the query, a public key request ${R}_{i}$ is selected from the list ${L}_{i}$ and $\mathcal{C}$ checks the tuple $({Id}_{i},{s}_{i},{R}_{i},{S}_{i})$ if it exists in ${L}_{i}$. $\mathcal{C}$ checks if ${R}_{i}=\perp $. If it holds, $\mathcal{C}$ selects ${s}_{i}{\in}_{R}{\mathbb{Z}}_{q}^{*}$ and sets ${{R}_{i}=s}_{i}P$, and updates the list with $({s}_{i},{R}_{i})$. Otherwise, $\mathcal{C}$ returns ${R}_{i}$ to ${\mathcal{A}}_{1}$. If $\left({Id}_{i},{s}_{i},{R}_{i},{\mathrm{S}}_{i},\right)$ is not in ${L}_{\mathrm{i}}$, let ${S}_{i}=\perp $, then $\mathcal{C}$ selects ${s}_{i}{\in}_{R}{\mathbb{Z}}_{q}^{*}$ and sets ${{R}_{i}=s}_{i}P$. $\mathcal{C}$ inserts ${R}_{i}$ into the tuple $\left({Id}_{i},{s}_{i},{R}_{i},{\mathrm{S}}_{i},\right)$ and returns ${R}_{i}$ as a reply to ${\mathcal{A}}_{1}$.
 Secretkey Queries: ${\mathcal{A}}_{1}$ makes a query on a chosen identity ${Id}_{i}$. On receiving a query, $\mathcal{C}$ checks if ${Id}_{i}={Id}_{i}^{*}$ and if ${S}_{i}=\perp $. If they hold, $\mathcal{C}$ selects ${s}_{i}{\in}_{R}{\mathbb{Z}}_{q}^{*}$ and returns ${s}_{i}$ and updates the list ${L}_{i}=({Id}_{i},{s}_{i},{R}_{i},{S}_{i})$. Otherwise, if ${s}_{i}\ne \perp $, $\mathcal{C}$ sends ${s}_{i}$ as a response to ${\mathcal{A}}_{1}.$
 Query on Public key Replacement: When the adversary ${\mathcal{A}}_{1}$ submits a query to replace the public key ${Id}_{i}$. $\mathcal{C}$ checks the tuple if the tuple $({Id}_{i},{s}_{i},{R}_{i},{S}_{i})$ exists in the list ${L}_{i}$ and sets ${R}_{i}={R}_{i}^{*}$ and ${s}_{i}=\perp $. It updates the list with the tuple $({Id}_{i},{s}_{i},{R}_{i},{S}_{i}).$ If the tuple $({Id}_{i},{s}_{i},{R}_{i},{S}_{i})$ does not exist in ${L}_{i}$, $\mathcal{C}$ sets ${R}_{i}={R}_{i}^{*}$ and ${s}_{i}=\perp $, it then updates the list with the tuple $({Id}_{i},{s}_{i},R,{S}_{i})$.
 Sign queries: ${\mathcal{A}}_{1}$ makes a sign query on an identity $I{d}_{i}$ with $({m}_{i},{V}_{i}$), $\mathcal{C}$ searches the tuple $({Id}_{i},{s}_{i},{R}_{i},{S}_{i})$ from the list ${L}_{i}$. If the list ${L}_{i}$ contains $({Id}_{i},{s}_{i},{R}_{i},{S}_{i})$, $\mathcal{C}$ checks whether ${S}_{i}=\perp $. If ${S}_{i}=\perp $, $\mathcal{C}$ makes a publickey Query to generate ${s}_{i}$ and sets ${R}_{i}={s}_{i}P$. Otherwise, if the tuple is empty $\mathcal{C}$ makes a public key query to generate ${s}_{i}$ and sets ${R}_{i}={s}_{i}P$ and adds $({Id}_{i},{s}_{i},{R}_{i},{S}_{i})$ to the list, ${L}_{i}$. It computes the following:
 (a)
 ${U}_{i}={n}_{i}{R}_{i}$.
 (b)
 ${W}_{i}=({n}_{i}\left\right{t}_{i},{U}_{i})$.
 (c)
 ${h}_{i}={H}_{3}({m}_{i}\left\right{W}_{i})$.
 (d)
 ${V}_{i}={T}_{i}+{n}_{i}{h}_{i}{s}_{i}{P}_{MCS}$.
and returns ${\sigma}_{i}=\langle {U}_{i},{V}_{i}\rangle $ as a signature on the message m.  Forgery: Applying the forking lemma, $\mathcal{C}$ outputs two signatures ${\sigma}_{i}^{*}=\langle {U}_{i}^{*},{V}_{i}^{*}\rangle $ and ${\sigma}_{i}^{*}=\langle {U}_{i}^{*},{V}_{i}^{{}^{\prime}*}\rangle $ where ${V}_{i}\ne {V}_{i}^{{}^{\prime}*}$. Therefore, ${V}_{i}^{*}={T}_{i}^{*}+{n}_{i}^{*}{h}_{i}^{*}{s}_{i}^{*}{P}_{MCS}$ and ${V}_{i}^{{}^{\prime}*}={T}_{i}^{*}+{n}_{i}^{*}{h}_{i}^{{}^{\prime}*}{s}_{i}^{*}{P}_{MCS}$. $\mathcal{C}$ tosses a coin ${x}_{i}$, if ${x}_{i}\stackrel{yields}{\u27f6}1$, $\mathcal{C}$ outputs a failure and aborts the simulation. Otherwise, $\mathcal{C}$ computes$$\begin{array}{cc}& \widehat{e}({V}_{i}^{*},P)=\widehat{e}({T}_{i}^{*}+{n}_{i}^{*}{h}_{i}^{*}{s}_{i}^{*}{P}_{MCS},P)\end{array}$$$$\begin{array}{cc}& \widehat{e}({V}_{i}^{{}^{\prime}*},P)=\widehat{e}({T}_{i}^{*}+{n}_{i}^{*}{h}_{i}^{{}^{\prime}*}{s}_{i}^{*}{P}_{MCS},P)\end{array}$$$$\begin{array}{cc}& \widehat{e}({V}_{i}^{*},P)=\widehat{e}({T}_{i}^{*}+{n}_{i}^{*}{h}_{i}^{*}{s}_{i}^{*}P,{P}_{MCS})\end{array}$$$$\begin{array}{cc}& \widehat{e}({V}_{i}^{{}^{\prime}*},P)=\widehat{e}({T}_{i}^{*}+{n}_{i}^{*}{h}_{i}^{{}^{\prime}*}{s}_{i}^{*}P,{P}_{MCS})\end{array}$$From Equations (3) and (4)$$\widehat{e}\left({V}_{i}^{*}{V}_{i}^{{}^{\prime}*},P\right)=\phantom{\rule{4pt}{0ex}}\widehat{e}\left(\left({h}_{i}^{*}{h}_{i}^{{*}^{\prime}}\right){n}_{i}^{*}{s}_{i}^{*}P\right)$$$$\widehat{e}\left({V}_{i}^{*}{V}_{i}^{{}^{\prime}*},P\right)=\phantom{\rule{4pt}{0ex}}\widehat{e}\left(\left({h}_{i}^{*}{h}_{i}^{{*}^{\prime}}\right){n}_{i}^{*}{S}_{i}^{*}\right)$$Notice that, ${Q}_{i}={\alpha}_{i}bP$ and ${S}_{i}^{*}={x}_{MCS}{Q}_{i}=a{\alpha}_{i}bP$.Therefore,$${V}_{i}^{*}{V}_{i}^{{}^{\prime}*}=({h}_{i}^{*}{h}_{i}^{{*}^{\prime}})a{\alpha}_{i}bP$$Hence, $abP=({V}_{i}^{*}{V}_{i}^{{}^{\prime}*}){({h}_{i}^{*}{h}_{i}^{{*}^{\prime}})}^{1}{\alpha}_{i}^{1}$. □
5.2. Analysis
 ${E}_{1}$ denotes an event in which the adversary ${\mathcal{A}}_{1}$ queries the partial private key which results in the probability of ${E}_{1}$$\left(Pr\left[{E}_{1}\right]\right)=\frac{{q}_{k}}{{2}^{t}}$. The success probability of ${E}_{1}$ occurring is $1\frac{{q}_{k}}{{2}^{t}}$.
 ${E}_{2}$ denotes an event in which the adversary ${\mathcal{A}}_{1}$ makes sign queries ${E}_{2}$$\left(Pr\left[{E}_{2}\right]\right)=1/{q}_{sig}$.
 ${E}_{3}$ indicates an event in which the adversary ${\mathcal{A}}_{1}$ has queries to the private keys =$\frac{{q}_{sk}}{{q}^{t}}$. The success probability of ${E}_{3}$ occurring is $1\frac{{q}_{sk}}{{q}^{t}}$. The success probability of ${\mathcal{A}}_{1}$ winning the game is ${\mathcal{E}}^{\prime}>{q}^{E}\frac{1}{\left({q}_{sig}(1\frac{{q}_{k}}{{2}^{t}}\right)}\left(1\frac{{q}_{sk}}{{q}^{t}}\right)$
5.3. Security Requirements Analysis
 NonRepudiation: The proposed scheme satisfies nonrepudiation 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 ${B}^{l}=(I{d}_{i}\left\right{h}_{i}\left\right{W}_{i}\left\right{t}_{i}\left\rightm\left\right{U}_{i}{)}^{l}$ to conceal the wearable user’s identity before transmitting to the aggregation unit. subsequently, the aggregation unit also computes ${B}^{l{P}_{MCS}}=(I{d}_{i}\left\right{h}_{i}\left\right{W}_{i}\left\right{t}_{i}\left\rightm\left\right{U}_{i}{)}^{l{P}_{MCS}}$ 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 $\left\{{V}_{i},{W}_{i},m,I{d}_{i},{t}_{i},{U}_{i}\right\}$.
 Aggregate Verification: the proposed scheme extends the batch processing to verify aggregated messagesignature 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
 (a)
 The storage overhead of SecAuthSaaS [22] is $2{\sigma}_{i}+Y+{m}_{i}+{s}_{i}=385$ bytes.
 (b)
 The storage overhead of CABVMHCS [23] is ${\sigma}_{i}+I{d}_{i}+{W}_{i}+{m}_{i}+{t}_{i}=233$ bytes.
 (c)
 The storage overhead of CASSHMSN [24] is ${\sigma}_{i}+I{d}_{i}+{m}_{i}+p{k}_{i}=245$ bytes.
 (d)
 The storage overhead of HACAADSB [17] is ${\sigma}_{i}+I{d}_{i}+{m}_{i}=135$ bytes.
6.5. Energy Consumption
7. Discussion
8. Conclusions
Author Contributions
Funding
Institutional Review Board Statement
Informed Consent Statement
Data Availability Statement
Conflicts of Interest
Abbreviations
AP  Application Provider 
AU  Aggregation Unit 
C  Client 
CLC  Certificateless Cryptography 
CDH  Computational DiffieHellman 
CLPKC  Certificateless Public Key Cryptography 
COVID19  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 
MITM  Maninthemiddle attack 
MITMO  Maninthemobile attack 
params  Public System parameters 
PKG  Public Key Generator 
PKI  Public Key Infrastructure 
U  User 
WBAN  Wireless Body Area Networks 
WD  Wearable Device 
WHCS  Wearable Health CrowdSensing 
References
 Cecilia, J.M.; Cano, J.C.; HernándezOrallo, E.; Calafate, C.T.; Manzoni, P. Mobile crowdsensing approaches to address the COVID19 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. Identitybased 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]
 AlRiyami, 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 COVID19. Nat. Electron. 2021, 4, 13–14. [Google Scholar] [CrossRef]
 Channa, A.; Popescu, N.; Skibinska, J.; Burget, R. The rise of wearable devices during the COVID19 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. CyberPhys. 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 edgeassisted 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 cloudassisted 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 identitybased 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 ADSB 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. Pairingbased 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. SecAuthSaaS: 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 certificatebased combined signature, encryption and signcryption scheme for internet of things (IoT) in mobile health (Mhealth) 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]
Notation  Description 

${1}^{k}$  Security Parameter 
${B}^{l}$  WD anonymity computed tuple 
${B}^{l{P}_{MCS}}$  AU anonymity computed tuple 
$\widehat{e}$  Bilinear map 
$\widehat{e}:{\mathbb{G}}_{1}\times {\mathbb{G}}_{1}\to {\mathbb{G}}_{2}$  Bilinear pairing 
${\mathbb{G}}_{1}$, ${\mathbb{G}}_{2}$  Additive and Multiplicative cyclic groups 
${H}_{1},{H}_{2},{H}_{3}$  Three OneWay hash functions 
$I{D}_{i}$  user identity 
$msk$  master secret key 
m  message 
$params$  Public parameters 
P  Generator 
$\langle {x}_{MCS},{P}_{MCS}\rangle $  master secret/public key pair 
${s}_{i}$  user generated secret value 
${R}_{i}$  partial public parameters 
${Q}_{i}$  Partial private key generated by MCS 
$P{r}_{i}=\langle {s}_{i},{S}_{i}\rangle $  User private key 
${P}_{i}=\langle {R}_{i},{Q}_{i}\rangle $  User public key 
AU  Aggregation Unit 
KGS  Key Generation Server 
MCS  Medical Cloud Server 
U  User 
WD  Wearable device 
Functionality  SecAuthSaaS [22]  CABVMHCS [23]  CASSHMSN [24]  HACAADSB [17]  Proposed 

Batch Processing  ✓  ✓  ✓  ✗  ✓ 
Forgery Attack  ✓  ✓  ✓  ✓  ✓ 
NonRepudiation  ✓  ✓  ✗  ✓  ✓ 
Anonymity  ✗  ✓  ✗  ✓  ✓ 
Replay Attack  ✗  ✓  ✗  ✗  ✓ 
Bandwidth Performance  ✓  ✓  ✓  ✓  ✓ 
Scheme  Sign  Verify  Aggregate Sign  Aggregate Verify 

SecAuthSaaS [22]  $4{T}_{pa}+3{T}_{sm}$  $6{T}_{bp}$  $2n{T}_{bp}+4{T}_{sm}+(n+1){T}_{pa}$  $2{T}_{sm}+(n+2){T}_{pa}$ 
CABVMHCS [23]  $1{T}_{sm}+2{T}_{pa}$  $3{T}_{bp}+1{T}_{pa}+1{T}_{sm}$  $n{T}_{sm}$  $3n{T}_{bp}$ 
CASSHMSN [24]  $4{T}_{sm}$+ $2{T}_{pa}$  $1{T}_{pa}$+ $2{T}_{sm}+3{T}_{bp}$  $4n{T}_{sm}+2n{T}_{pa}$  $3n{T}_{bp}+2n{T}_{sm}$ 
HACAADSB [17]  $2{T}_{pa}+1{T}_{sm}$  $1{T}_{pa}+3{T}_{bp}$  $n{T}_{sm}+2{T}_{pa}$  $3n{T}_{bp}$ 
Proposed  $2{T}_{sm}+1Tpa$  $2{T}_{bp}+1{T}_{pa}+2{T}_{sm}$  $n{T}_{sm}$  $2n{T}_{bp}$ 
Scheme  Sign Cost  Verify Cost  Total (Sign + Verify)  Batch Processing (n = 100) 

SecAuthSaaS [22]  0.335  24.324  40.819  1226.28 
CABVMHCS [23]  0.121  12.269  12.627  1225.5 
CASSHMSN [24]  0.4  12.362  12.762  1274.8 
HACAADSB [17]  0.121  12.176  12.534  1225.5 
Proposed  0.2  8.308  8.694  820.1 
Scheme  Sig. Size on Single Message  Sig Size for n Messages  Comm. Cost for Single Message  Comm. Cost for n Messages  Storage Overhead 

SecAuthSaaS [22]  $5{G}_{1}+\left{Z}_{q}^{*}\right$  $5n{G}_{1}+\left{Z}_{q}^{*}\right$  704 bytes  704n bytes  385 bytes 
CABVMHCS [23]  $2{G}_{1}+\left{Z}_{q}^{*}\right+$  $2n{G}_{1}+\left{Z}_{q}^{*}\right$  320 bytes  320n bytes  233 bytes 
CASSHMSN [24]  $2{G}_{1}+{Z}_{q}^{*}$  $2n{G}_{1}+{Z}_{q}^{*}$  320 bytes  320n bytes  245 bytes 
HACAADSB [17]  $2{Z}_{q}^{*}+{G}_{1}$  $2n{Z}_{q}^{*}+{G}_{1}$  256 bytes  256n bytes  135 bytes 
Proposed  $2{Z}_{q}^{*}$  $2n{Z}_{q}^{*}$  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/).
Share and Cite
Addobea, A.A.; Li, Q.; Amankona, I.O.; Hou, J. A Batch Processing Technique for Wearable Health CrowdSensing 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 CrowdSensing in the Internet of Things. Cryptography. 2022; 6(3):33. https://doi.org/10.3390/cryptography6030033
Chicago/Turabian StyleAddobea, Abigail Akosua, Qianmu Li, Isaac Obiri Amankona, and Jun Hou. 2022. "A Batch Processing Technique for Wearable Health CrowdSensing in the Internet of Things" Cryptography 6, no. 3: 33. https://doi.org/10.3390/cryptography6030033