Review of Pu et al.’s Scheme [63]

Pu et al. [63] proposed two schemes for a “data aggregation mechanism” to preserve the sensitive data of the customers. In their first scheme, each IoT-enabled smart device breaks up the actual data randomly, keeps one part of the data to itself, and then sends the remaining part to the other IoT devices of the network which belong to the same group through a symmetric cryptographic method. Each IoT device does the addition of received pieces. The held piece is used to get the immediate result and this is then sent to the aggregator component. Furthermore, the “homomorphic encryption method” [64] and “Advanced Encryption Standard (AES) encryption method” [65] are applied to achieve secure communication. However, in their second scheme, the slicing method was also used. The noisy data are used to protect the exchanged data of the devices from disclosure attack. Their conducted analysis proves the integrity and confidentiality properties of the IoT device’s data. In addition, the dynamic device addition is not supported in their scheme. Their proposed schemes have the following phases: ^[1]

node for verification purposes. If the verification happens successfully, the aggregator aggregates the ciphertext. Next, the server decrypts it with its private key sk and obtains the entire data of that particular region.

Review of Dwivedi et al.’s Scheme [66]

Dwivedi et al. [66] addressed the security and privacy issues in an IoT-based healthcare environment. They proposed a framework based on the blockchain model which is suitable for IoT devices and depends on blockchain’s distributed nature. The additional security and privacy properties of their model are based on the advanced cryptographic algorithms. They provided a solution that makes IoT application data and their transactions more secure and anonymous via a blockchain-based computing environment. However, their scheme does not support dynamic device addition or smart card/smart phone revocation phases.

This scheme is based on the following cryptographic primitives:

• • Addition/Rotation/XOR (ARX) encryption algorithm: ARX is a kind of symmetric key encryption that was used to encrypt the data for blockchain. The algorithm utilizes simple operations like “modular addition,” “bitwise rotation” and “exclusive-OR (XOR)” operations, and it provides support for lightweight encryption, particularly in small devices. Some examples of ARX include Speck, ChaCha20, BLAKE and XXTEA.
• • Digital signature: Digital signature is frequently used for authentication processes. The application of “normal digital signatures” may not be fitted due to deployed resource-restricted IoT devices, as those signature schemes are heavy-weight. Therefore, the use of “lightweight digital signatures” has been suggested. In Dwivedi et al.’s scheme [66], the sender has a pair of private-public keys (sks_pnr sks_pul), and also the receiver will have another pair of private-public keys (rks_prh„ rks_pul). The sender’s private key sks_priv is applied to sign the message, w'hereas the sender’s public key sks_pilb is used for the verification of signed messages at the receiver’s end.
• • Digital ring signature: The “lightweight ring signature technology” is behind the development of the ring signature. It allows a signer to sign the data in an anonymous manner. The signature is then mixed with other groups “named ring” and only the “actual signer” knows which member has signed the message. Using the ring in Dwivedi et al.’s scheme [66], the “signer’s anonymity” and “signature correctness” are satisfied.
• • Diffie-Hellman key exchange: In Dwivedi et al.’s scheme [66], there was a requirement to transfer the public keys in the network. In order to provide a more secure public key exchange, the public keys of the entities are also shared secretly. For the sharing of the public key, say the sender’s public key (sks_puh), securely in the network, the “Diffie-Hellman key exchange” method has been utilized [67]. It is worth noting that the “Diffie-Hellman key exchange” protocol helps both the sender and receiver to establish a common secret key over an insecure channel. A more secure version of the

“Diffie-Hellman key exchange” protocol, known as the “station-to-station key agreement” protocol, can be further utilized in case the network is vulnerable to a “man-in-the-middle attack” [37].

Review of Kim et al.’s Scheme [68]

Kim et al. [68] proposed a scheme for the privacy-preserving collection of personal health-related data streams, which are characterized as temporal data. The data are collected at fixed intervals through the benefit of “Local Differential Privacy (LDP).” A data contributor is used to provide a privacy budget of the LDP. It reports a small quantity of salient data, which is extracted from the health data stream.

The data collector can reassemble the health data segments based on the noisy salient data received from the data contributor. Through the conducted practical demonstration, it is shown that their proposed scheme can achieve significant accuracy gains over other compared methods. However, “dynamic device addition” and “smart card/smart phone revocation” are not supported in their scheme. A straightforward method might have a high expected error in case of a large sequence length. To overcome this problem, another method has been suggested to collect health data streams. Their proposed system has two components: (i) “data contributor’s deviceside processing” and (ii) “data collection server-side processing.”

Their scheme consists of the following functionalities:

• • Data contributor’s device-side processing: Their technique identifies a small number of salient points from the sequence of the provided “health data stream,” unsettles these points under the process of LDP and then reports the noisy salient points to the “data collection server.”
• • Data collection server-side processing: Their scheme has the ability to reconstruct the sequence on the basis of noisy salient points received from the “data contributor” and store it in the database for further use. The proposal behind this method is that it avoids the “high expected error” occurring due to the large sequence length under the selection of the small number of salient points from the health data stream.

Comparative Analysis of Existing Privacy-Preserving Protocols

In this section, we compare various security and functionality features (FR_rFR₂₀) of the schemes of Hamza et al. [50], Deebak et al. [51], Pu et al. [63], Dwivedi et al. [66] and Kim et al. [68] provided in Table 5.1.

The following features have been considered in the comparative study: ^[2]

TABLE 5.1

Comparison of Functionality and Security Features

Note: x: “a scheme does not protect against a specific attack or it does not support a particular feature”; "a scheme protects against a specific attack or it supports a particular feature”; NA: "not applicable in a scheme.”

• • FR,;. “resilience against sensing device physical capture attack”
• • FR₇: “support to server independent password update phase”
• • F/?₈: “support for biometric update phase”
• • FR₉: “formal security verification using AVISPA automated software tool”
• • FR_W: “support to smart card revocation phase”
• • FR_U: “protection against known session-specific temporary information attack”
• • FR_n- “user anonymity property”
• • F/?₁₃: “protection against privileged-insider attack”

FR_H: “protection against off-line password guessing attack”

• • FT?,,: “protection against stolen smart card/mobile device attack”
• • F/?,₆: “protection against denial-of-service (DoS) attack”
• • F/?|₇: “protection against impersonation attacks”

• • FR_ls: “support to formal security analysis under standard model (e.g., ROR model)”
• • FR_ig: “support to security analysis through BAN logic proof’
• • FR₂₀: “support to dynamic sensing device addition phase”

Table 5.1 shows that Hamza et al.’s scheme [50] does not provide the features FR_}, FR_g, F/?,„ FR_i6 and FR_K-FR_2U. The scheme of Deebak et al. [51] provides the majority of the features except some features FR₇-FR_g, FR_U, FR_l6 and FR₂0. The scheme of Pu et al. [63] does not support the features FR₇-FR₅, FR_g, FR_l6 and FR_m-FR₂₀. Similar to Pu et al.’s scheme [63], the scheme of Dwivedi et al. [66] also does not provide the features FR₇-FR₅, FR₉ and FR_[S-FR₂₀. Finally, similar to Pu et al.’s scheme [63], the scheme of Kim et al. [68] fails to maintain the features FR₃-FR_S, FR_q, FR_U, and FR_ti-FR₂₀.

It is then clear that most of the compared schemes do not provide the required security and functionality features, and they are also vulnerable to various types of attacks. Hence, it is essential to come up with more efficient and robust privacypreserving protocols for the IoHT communication environment that can be deployed for practical applications.

• [1] Key generation: In this phase, a series of keys and other important parameters are distributed. The server first generates a private key, say sk, andits corresponding public key, say pk. A group key is then generated andalso broadcasted to all the group members in each group along with otherparameters for the update of the group key. • Data division and confusion: In this phase, various devices perform thesegmentation of their data and then swap the data pieces in a pairwise manner. A topical residential is assumed which is comprised of an aggregatorconnected with a large number of devices. The devices collect the datafor a particular duration of time. Each device slices the data into a number of pieces randomly. After that the devices exchange their respectivepieces with each other to obtain the obfuscated data. After receiving theciphertext, the device decrypts it to obtain the data slice. Moreover, it wasalso mentioned that the keys used for device-to-device communication areupdated continuously. • Reporting and aggregation: After the exchange of “partial collected data,”the actual data need to be blended. For this purpose, all the blended dataare encrypted with the public key pk of the server. Furthermore, the deviceswill compute the hash identity, real time and preceding ciphertext to helpthe aggregator to check whether the message has been manipulated or not.The devices report the ciphertext, real time and hash value to the aggregator
• [2] FRt: “protection against replay attack” • FR2: “protection against man-in-the middle attack” • FRy “mutual authentication” • FRy “session key agreement” • FRS: “untraceability property”