# Decentralized Data Aggregation: A New Secure Framework Based on Lightweight Cryptographic Algorithms

Authors: Xin Xie; Yu-Chi Chen
Journal: Wireless Communications and Mobile Computing
 (2021)

---

## Abstract

Blockchain has become very popular and suitable to the Internet of Things (IoT) field due to its nontamperability and decentralization properties. The number of IoT devices and leaders (who own IoT devices) is increased exponentially, and thus, data privacy and security are undoubtedly significant concerns. In this paper, we summarize some issues for the BeeKeeper system, a blockchain-based IoT system, proposed by Zhou et al., and then aim for presenting an improved solution for decentralized data aggregation (DDA) on IoT. Firstly, we formally state the security requirements of DDA. Secondly, we propose our basic DDA system by using secret sharing to improve its efficiency and smart contracts as the computing processors. Moreover, the proposed full-fledged system achieves data sharing (e.g., a leader to access data of others’ devices), which is realized by using local differential privacy and cryptographic primitives such as token-based encryption. Finally, to show the feasibility, we provide some implementations and experiments for the DDA systems.


---

## Body

## 1. Introduction

The Internet of Things (IoT) is the extensive concept of Internet with physical devices for jointly realizing a service or achieving target functionality. For example, these devices (embedded systems or sensors) communicate and interact with others over the Internet and also can be remotely monitored and controlled. In fact, IoT has offered numerous applications in the aspects of consumer, commerce, industry, and infrastructure. For education purposes, Raspberry Pi plays the role of a cheap and fundamental platform to develop applications of IoT. Typically, in IoT systems, the purpose for collecting data may be used in the future (e.g., analysis for behaviors of consumers), and such data are stored in the centralized cloud storage. Hence, users are enforced to trust that the centralized cloud will protect their unencrypted data.This suffices to wrap up the following issues for centralized cloud-based IoT systems.(i)
Centralization: the cloud is in charge of providing and maintaining the service. If it crashes, the centralized system is no longer to work [1]. For example, denial of service attacks may focus on the single cloud to terminate the functionality(ii)
Trust: the users outsource their data to the cloud [2] and only hold limited control for their data. They have to fully trust the cloud which does not modify and delete the stored data(iii)
Scalability: more efficient IoT devices and larger bandwidth communication produce big data streams [3]. Therefore, the centralized cloud must be accordingly efficient or scalable for tackling those data(iv)
Data security: the stored data are unencrypted. Sensitive data are directly revealed to the cloud. However, encryption may be a solution, but processing over encrypted data is always an issue. In the past, plenty of clever notions [4–6] are proposed to address thisBlockchain, introduced by Nakamoto [7], is referred to as the core technology of Bitcoin. It can be regarded as the distributed ledger consisting of blocks chained in order. The potential advantages of blockchain for improving IoT systems are as follows:
(i)
Decentralization and tamper proof [8]: the property of decentralization in blockchain frees our IoT system from setting up centralized nodes. Anyone (a.k.a. a node or participant in the protocol) can join or leave the protocol execution at any time without getting permission from an authority. In general, it is an effective method for maintaining a public, immutable, and ordered ledger of records (for instance, in the Bitcoin, these records are simply transactions); that is, records can be added to the end of the ledger at any time (but only to the end of it); additionally, it is guaranteed that records previously added cannot be removed or reordered and that all honest nodes have a consistent view of the ledger, which is referred to as consistency(ii)
Anonymous: since the data exchange between the nodes of the blockchain follows a fixed and predictable algorithm, the blockchain network is trustless and can exchange data based on addresses instead of identities(iii)
Smart contracts (SC): SC are a powerful application based on blockchain, where SC programs deployed on the blockchain and can be triggered or executed by events. SC can also make our IoT devices smarter since the behavior of them can be specified by SCIn a sense, blockchain seems a sort of potential solution to the above-mentioned issues in the IoT scenario, including centralization, trust, and scalability, since it provides decentralized services, distributed trust, and permissionless property for scalability.


### 1.1. Related Work

Very recently, Zhou et al. [9] proposed a blockchain-based threshold IoT system, named as BeeKeeper. This system applies secret sharing to encrypt data. In this system, there are three entities: a leader, the leader’s devices, and a certain number of servers, and all of them only communicate with blockchain. The threshold is denoted by t-out-of-n (n>t), which implies that there are totally n servers, and any t suffice to complete the task. Let us keep highlighting the procedure of the system. Devices collect data and then submit them to blockchain. Servers will retrieve them from blockchain, run some operations, and return the processed data back to blockchain. Finally, the leader can submit his/her request to blockchain and obtain the (aggregation) result as long as at least t servers complete the processing over the data. In fact, the same authors [10] have proposed an improvement named as BeeKeeper 2.0, which can offer some additional functionalities, but the overall framework is not significantly changed. In addition to data aggregation, blockchain can be also applied to key management in IoT [11].


### 1.2. Contributions

The motivation of this paper is the observation in BeeKeeper, regarding a few concerns briefly shown as follows. (1) At leastt servers must be maintained to operate for keeping functionality. (2) Blockchain seems only the communication platform and database. (3) The underlying secret sharing is realized by using polynomials. Our main results are conceptually simple solutions where we use smart contracts (supporting data aggregation) to overcome (1) and (2) and then rely on secret sharing to improve efficiency to (3). We propose a warm-up system which is composed of the above building blocks and achieves decentralized data aggregation on IoT. However, in the warm-up, the devices are of the leader, which means that he/she cannot obtain the results collected by the other leaders’ devices. It is an extensional feasibility, but indeed induces privacy issues for accessing others’ data. Hence, we provide a full-fledged system to achieve this by using local differential privacy and token-based encryption. Accordingly, we also state the security definition for our systems, and under such the definition prove their security. As shown in Table 1, we briefly explain the difference from the previous works. The proposed DDA/DDA+ does not need to set up a server to handle complex calculations. The aggregation of data is left to record nodes of DDA/DDA+ or the owner of the smart contract (i.e., leader), which operates with the (simple) logic design. For the verification function, Zhou et al. [9, 10] require additional verification for all participants. However, in our DDA+ scheme, we only need to consider devices to verify the legitimacy of the leader, for which we provide a token tk. In the high level DDA+, data privacy protection is added. We use local differential privacy to protect sensitive data of devices over gathering. In addition, our smart contract sets up multiple functions, not just processing transfer operations. Finally, we complete the security proof of the program.Table 1
Comparison with previous works.
BeeKeeper [10]BeeKeeper+ [9]DDADDA+Leader✓✓✓Devices✓✓✓Servers✓××Verification✓×✓Privacy protecting××✓Data aggregationServersNodes/leaderNodes/leaderSmart contractTransferMultifunctionMultifunctionSecurityNo proofSDS, NDS, SCS, OSSDS, NDS, SCS, OS


#### 1.2.1. Comparisons to the Previous Version [12]

In the full version, we go through the main ideas of protocol design and then give a solid description of security. In addition, we present the full-fledged construction from local differential privacy and prove the security in a formal way. Finally, experiments are provided to show its effectiveness.


### 1.3. Organization

The remainder of this paper is organized as follows. First of all, Section2 briefly describes the basic technologies of the decentralized data aggregation (DDA) system. Then, in Section 3, we present the system model and security requirements of this system. Thereafter, the warm-up and full-fledged DDA systems are described in Sections 4 and 5, respectively. Implementations and analysis of the systems are given in Section 6. Finally, we provide the conclusions of this paper in Section 7.


## 1.1. Related Work

Very recently, Zhou et al. [9] proposed a blockchain-based threshold IoT system, named as BeeKeeper. This system applies secret sharing to encrypt data. In this system, there are three entities: a leader, the leader’s devices, and a certain number of servers, and all of them only communicate with blockchain. The threshold is denoted by t-out-of-n (n>t), which implies that there are totally n servers, and any t suffice to complete the task. Let us keep highlighting the procedure of the system. Devices collect data and then submit them to blockchain. Servers will retrieve them from blockchain, run some operations, and return the processed data back to blockchain. Finally, the leader can submit his/her request to blockchain and obtain the (aggregation) result as long as at least t servers complete the processing over the data. In fact, the same authors [10] have proposed an improvement named as BeeKeeper 2.0, which can offer some additional functionalities, but the overall framework is not significantly changed. In addition to data aggregation, blockchain can be also applied to key management in IoT [11].


## 1.2. Contributions

The motivation of this paper is the observation in BeeKeeper, regarding a few concerns briefly shown as follows. (1) At leastt servers must be maintained to operate for keeping functionality. (2) Blockchain seems only the communication platform and database. (3) The underlying secret sharing is realized by using polynomials. Our main results are conceptually simple solutions where we use smart contracts (supporting data aggregation) to overcome (1) and (2) and then rely on secret sharing to improve efficiency to (3). We propose a warm-up system which is composed of the above building blocks and achieves decentralized data aggregation on IoT. However, in the warm-up, the devices are of the leader, which means that he/she cannot obtain the results collected by the other leaders’ devices. It is an extensional feasibility, but indeed induces privacy issues for accessing others’ data. Hence, we provide a full-fledged system to achieve this by using local differential privacy and token-based encryption. Accordingly, we also state the security definition for our systems, and under such the definition prove their security. As shown in Table 1, we briefly explain the difference from the previous works. The proposed DDA/DDA+ does not need to set up a server to handle complex calculations. The aggregation of data is left to record nodes of DDA/DDA+ or the owner of the smart contract (i.e., leader), which operates with the (simple) logic design. For the verification function, Zhou et al. [9, 10] require additional verification for all participants. However, in our DDA+ scheme, we only need to consider devices to verify the legitimacy of the leader, for which we provide a token tk. In the high level DDA+, data privacy protection is added. We use local differential privacy to protect sensitive data of devices over gathering. In addition, our smart contract sets up multiple functions, not just processing transfer operations. Finally, we complete the security proof of the program.Table 1
Comparison with previous works.
BeeKeeper [10]BeeKeeper+ [9]DDADDA+Leader✓✓✓Devices✓✓✓Servers✓××Verification✓×✓Privacy protecting××✓Data aggregationServersNodes/leaderNodes/leaderSmart contractTransferMultifunctionMultifunctionSecurityNo proofSDS, NDS, SCS, OSSDS, NDS, SCS, OS


### 1.2.1. Comparisons to the Previous Version [12]

In the full version, we go through the main ideas of protocol design and then give a solid description of security. In addition, we present the full-fledged construction from local differential privacy and prove the security in a formal way. Finally, experiments are provided to show its effectiveness.


## 1.2.1. Comparisons to the Previous Version [12]

In the full version, we go through the main ideas of protocol design and then give a solid description of security. In addition, we present the full-fledged construction from local differential privacy and prove the security in a formal way. Finally, experiments are provided to show its effectiveness.


## 1.3. Organization

The remainder of this paper is organized as follows. First of all, Section2 briefly describes the basic technologies of the decentralized data aggregation (DDA) system. Then, in Section 3, we present the system model and security requirements of this system. Thereafter, the warm-up and full-fledged DDA systems are described in Sections 4 and 5, respectively. Implementations and analysis of the systems are given in Section 6. Finally, we provide the conclusions of this paper in Section 7.


## 2. Preliminaries

In this section, we briefly introduce some preliminaries. We useλ to denote security parameters and PPT to denote polynomial time adversaries. Also, the assumptions are generated by the λ parameter; we define a negligible function for any polynomial function polyλ and satisfies λ sufficiently large, neglλ≤1/polyλ holds.


### 2.1. Secret Sharing

Secret sharing [13, 14] is a notion that divides a secret into shares. The secret can be recovered by combining certain numbers of shares. Here, secret sharing for n participants only allows n shares together to recover the secret, so-called n,n secret sharing. Also, for some specific functionality, we state the definition as follows.Additive secret sharing: a secret message secret will be split inton shares (share1, share2,…, sharen) in n,n secret sharing scheme. This scheme consists of five phases.
(i)
ShareGen (1λ, n, secret): given security parameter 1λ, device numbers n, secret ∈S as input, then outputs share1,…, sharen∈0,1ℓ(ii)
SecretRec (share1,…, sharen): taking all the shares share1,…,sharen as input, this algorithm can output secret(iii)
AddOnShare (share,x): it takes data x, share as input, and then generates sharex(iv)
PartialRec (share1x1,…, sharenxn): this algorithm takes share1x1,…,sharenxn as input and then outputs partrec as the result for partial recovery(v)
Extract (partrec, secret): it takes partrec and secret as input and returns sumxWe give the formal security definition ofn,n secret sharing as follows.Definition 1.
Letn be the number of participants, which implies that only collecting n shares can recover the secret. Accordingly, any n−1 shares cannot get any information about the secret. The probability of an (unbounded) adversary A is
(1)PrAsharej1,⋯,sharejn−1→secret=1S,where j1,⋯,jn−1∈x1≤x≤n,x∈N and j1,⋯,jn−1 is not repeated.The construction can be easily realized by using additive secret sharing.


### 2.2. Smart Contract-Based Aggregation Service

The smart contract-based aggregation service can mainly achieve identification of devices and data aggregation. Note that smart contracts do not provide any confidentiality. In general, a smart contract-based aggregation service is composed of the following algorithms (The SC provides the specified functionality for the specified authorized user and provides data signature and verification, since the underlying blockchain works with signatures).(i)
InitContractϱ: given only the security parameters ϱ as input, it initially creates and deploys the personal smart contract on the blockchain and finally outputs the corresponding smart contract address (SC.Address)(ii)
AddDevice(SC.Address,leaderId,id,Q): it takes the smart contract address SC.Address, the personal identity of the system leader leaderId, the devices’ id id, and the id list Q (all id∈Q), and then, the algorithm generates as inputs and outputs flagid (flag indicates that the device holds permissions to execute certain functions in SC) of every id and updated id list Q′(iii)
Upload(SC.Address,id,flag,m,DB): it takes the smart contract address SC.Address, the devices’ id id, the corresponding flag flag, the collected data m, and the database DB (all m∈DB) as inputs. Subsequently, the algorithm can generate and output the result database DB′(iv)
Aggregation(SC.Address,DB′,leaderId): it takes the smart contract address SC.Address, the result database DB0, and the personal id of system leader leaderId as inputs. Finally, it returns the aggregation result xThe smart contract-based aggregation service system holds the following security properties.Definition 2.
The probability that a polynomial adversaryA without leaderId and corresponding conditions in this system can execute the AddDevice algorithm is negligible, that is,
(2)PrAddDeviceASC.Address,⊥,id,Q⟶flagid,DB′≤neglλ,
where id denotes the deviceid∈Q.Definition 3.
The probability that the polynomial adversaryA as a device without corresponding flag in this smart contract-based aggregation service system can upload data is negligible, that is,
(3)PrUploadASC.Address,id,⊥,m,DB⟶DB′≤neglλ,
wherem denotes the data uploaded m∈DB.Definition 4.
The probability that a polynomial adversaryA without leaderId and corresponding conditions in this system can execute the Aggregation algorithm is negligible, that is,
(4)PrAggregationASC.Address,DB′,⊥⟶x≤neglλ.


## 2.1. Secret Sharing

Secret sharing [13, 14] is a notion that divides a secret into shares. The secret can be recovered by combining certain numbers of shares. Here, secret sharing for n participants only allows n shares together to recover the secret, so-called n,n secret sharing. Also, for some specific functionality, we state the definition as follows.Additive secret sharing: a secret message secret will be split inton shares (share1, share2,…, sharen) in n,n secret sharing scheme. This scheme consists of five phases.
(i)
ShareGen (1λ, n, secret): given security parameter 1λ, device numbers n, secret ∈S as input, then outputs share1,…, sharen∈0,1ℓ(ii)
SecretRec (share1,…, sharen): taking all the shares share1,…,sharen as input, this algorithm can output secret(iii)
AddOnShare (share,x): it takes data x, share as input, and then generates sharex(iv)
PartialRec (share1x1,…, sharenxn): this algorithm takes share1x1,…,sharenxn as input and then outputs partrec as the result for partial recovery(v)
Extract (partrec, secret): it takes partrec and secret as input and returns sumxWe give the formal security definition ofn,n secret sharing as follows.Definition 1.
Letn be the number of participants, which implies that only collecting n shares can recover the secret. Accordingly, any n−1 shares cannot get any information about the secret. The probability of an (unbounded) adversary A is
(1)PrAsharej1,⋯,sharejn−1→secret=1S,where j1,⋯,jn−1∈x1≤x≤n,x∈N and j1,⋯,jn−1 is not repeated.The construction can be easily realized by using additive secret sharing.


## 2.2. Smart Contract-Based Aggregation Service

The smart contract-based aggregation service can mainly achieve identification of devices and data aggregation. Note that smart contracts do not provide any confidentiality. In general, a smart contract-based aggregation service is composed of the following algorithms (The SC provides the specified functionality for the specified authorized user and provides data signature and verification, since the underlying blockchain works with signatures).(i)
InitContractϱ: given only the security parameters ϱ as input, it initially creates and deploys the personal smart contract on the blockchain and finally outputs the corresponding smart contract address (SC.Address)(ii)
AddDevice(SC.Address,leaderId,id,Q): it takes the smart contract address SC.Address, the personal identity of the system leader leaderId, the devices’ id id, and the id list Q (all id∈Q), and then, the algorithm generates as inputs and outputs flagid (flag indicates that the device holds permissions to execute certain functions in SC) of every id and updated id list Q′(iii)
Upload(SC.Address,id,flag,m,DB): it takes the smart contract address SC.Address, the devices’ id id, the corresponding flag flag, the collected data m, and the database DB (all m∈DB) as inputs. Subsequently, the algorithm can generate and output the result database DB′(iv)
Aggregation(SC.Address,DB′,leaderId): it takes the smart contract address SC.Address, the result database DB0, and the personal id of system leader leaderId as inputs. Finally, it returns the aggregation result xThe smart contract-based aggregation service system holds the following security properties.Definition 2.
The probability that a polynomial adversaryA without leaderId and corresponding conditions in this system can execute the AddDevice algorithm is negligible, that is,
(2)PrAddDeviceASC.Address,⊥,id,Q⟶flagid,DB′≤neglλ,
where id denotes the deviceid∈Q.Definition 3.
The probability that the polynomial adversaryA as a device without corresponding flag in this smart contract-based aggregation service system can upload data is negligible, that is,
(3)PrUploadASC.Address,id,⊥,m,DB⟶DB′≤neglλ,
wherem denotes the data uploaded m∈DB.Definition 4.
The probability that a polynomial adversaryA without leaderId and corresponding conditions in this system can execute the Aggregation algorithm is negligible, that is,
(4)PrAggregationASC.Address,DB′,⊥⟶x≤neglλ.


## 3. System Model

### 3.1. Syntax of Decentralized Data Aggregation

In this section, we aim for a concrete notion, called decentralized data aggregation (DDA). We formally present the system model below. In a nutshell, DDA consists of three phases, denoted by DDA = (Initialization, DataCollection, and DataReconstruction). Some notations are listed in Table2. The DDA syntax is formally described as follows.
(i)
Initialization (1λ, ϱ, n, L.EOA, Di.EOA, S, Q): the algorithm takes as inputs the security parameter 1λ, ϱ, device quantity n, leader’s public address L.EOA, public address of the i-th device Di.EOA, leader’s private key S, device address set Q and outputs Ki, SC.Address, flagLid, Q′(ii)
Data Collection (SC.Address, L.EOA, mi, DB, Ki): the algorithm takes as inputs contract address SC.Address, leader’s public address L.EOA, the raw data for the i-th device mi, device i stored database DB, the private key of the i-th device Ki and outputs C(iii)
Data Reconstruction (C,S): the algorithm takes as inputs ciphertext C, leader’s private key S, and outputs MTable 2
Notations.
SymbolDescription1λ,ϱThe security parameters1nNumber of devices planned to be deployedDiThe deviceDi belongs to the leader LDi′The deviceDi′ does not belong to the leader LQ/NQThe collection of device IDsDB/DB′The identity ofDi or Di’s databaseX.EOAThe public address of the entityX running on platformX.EPKThe private address of the entityX running on platformSC.AddressThe smart contract addressS/S′A secret value set by the leaderKi/Ki′The shared key valueSThe domain of secret keyrndThe number of rounds of device update data1These two different security parameters are used to initialize the different functions.


### 3.2. Security Requirements

In our security model, privacy-preserving aggregation is our main concern. Since the smart contract is completely public, we assume that there are no inside threats in which the contract code is secure. To clarify our security definition, we assume that there are only three parties on the system: the leader, the smart contract, and the device belonging to the leader’s IoT. We elaborate the following security definitions for all probability polynomial time adversariesA where we can quantify its computation is polynomially bounded such as polyλ.
(1)
Single Device Security (SDS). We assume an adversary A who knows the probability distribution of the plaintext space M of one of the devices, but does not have any knowledge of the key. A can eavesdrop on communication (leader and IoT device) and thus observe the ciphertext of an IoT device. Let us briefly describe this simple security experiment ExpDDA,ASDS as follows:(i)
Setup: the challenger randomly selectsS and obtains Ki sequence i=1,⋯,n, and then, A outputs a pair of message m0,m1∈M(ii)
Challenge phase: the challenger randomly selectsKi and a bit b∈0,1, and then, C←DataCollectionSC.Address,L.EOA,mb,⊥,Ki is computed and given to A. We refer to C as the challenge ciphertext. Note that the ciphertext C only has a ciphertext generated by a single device operation(iii)
Guess:A outputs a bit b′We definedA’s advantage as
(5)AdvDDA,ASDS=PrExpDDA,ASDSλ=1.(2)
n−1Threshold Device Security (NDS). We assume an adversary A who is given n−1K values, but cannot infer S. Collecting the knowledge of n−1 pieces reveals no significant information about S. Let us briefly describe this simple security experiment ExpDDA,ANDS as follows:(i)
Setup: the challenger randomly selectsS and obtains Ki sequence i=1,⋯,n(ii)
Challenge phase: the challenger randomly selectn−1K values to send to A(iii)
Guess:A outputs S′Definition 5 (SDS).
We say that DDA meets Single Device Security if for all probabilistic polynomial time adversaryA, AdvDDA,ASDS≤1/2+neglλ.We definedA′s advantage as
(6)AdvDDA,ANDS=PrExpDDA,ANDSλ=1.(3)
Smart Contract Security (SCS). We assume an adversary A (A.EOA) who tries to modify the uploaded data. Let us briefly describe this simple security experiment ExpDDA,ASCS as follows.Definition 6 (NDS).
We say that DDA meetsn−1 Threshold Device Security if for all probabilistic polynomial time adversary A, AdvDDA,ANDS≤neglλ.L.EOA must authorize A.EOA to enter SC, that is, run AddDevice, A does not get L.EOA’s flag flagid.
(i)
Setup: the challenger deploys the smart contract and returnsSC.Address to A(ii)
Challenge phase: the challenger randomly selectsq identities of devices to run AddDevice(iii)
Guess:A outputs flagid. We defined A’s advantage as(7)AdvDDA,ASCS=PrExpDDA,ASCSλ=1.(4)
Outlier Security (OS). We assume that the external adversary A gets the result of all ciphertext aggregation. Let us briefly describe this simple security experiment ExpDDA,AOS as follows:(i)
Setup: the challenger randomly selectsS, and the set of K is generated by the Initialization algorithm i=1,2,⋯,n. A outputs a pair of message m0,m1∈M(ii)
Challenge phase: the challenger randomly chooses a bitb∈0,1 and generates ciphertext aggregated by n devices by running C←DataCollectionSC.Address,L.EOA,mb,DB,Ki and gives C to A(iii)
Guess:A outputs a bit b′Definition 7 (SCS).
We say that DDA meets Smart Contract Security if for all probabilistic polynomial time adversaryA,
(8)AdvDDA,ASCS≤neglλ.We definedA′s advantage asAdvDDA,AOS=PrExpDDA,AOSλ=1.Definition 8 (OS).
We say that DDA meets Outlier Security if for all probabilistic polynomial time adversaryA,
(9)AdvDDA,AOS≤12+neglλ.


## 3.1. Syntax of Decentralized Data Aggregation

In this section, we aim for a concrete notion, called decentralized data aggregation (DDA). We formally present the system model below. In a nutshell, DDA consists of three phases, denoted by DDA = (Initialization, DataCollection, and DataReconstruction). Some notations are listed in Table2. The DDA syntax is formally described as follows.
(i)
Initialization (1λ, ϱ, n, L.EOA, Di.EOA, S, Q): the algorithm takes as inputs the security parameter 1λ, ϱ, device quantity n, leader’s public address L.EOA, public address of the i-th device Di.EOA, leader’s private key S, device address set Q and outputs Ki, SC.Address, flagLid, Q′(ii)
Data Collection (SC.Address, L.EOA, mi, DB, Ki): the algorithm takes as inputs contract address SC.Address, leader’s public address L.EOA, the raw data for the i-th device mi, device i stored database DB, the private key of the i-th device Ki and outputs C(iii)
Data Reconstruction (C,S): the algorithm takes as inputs ciphertext C, leader’s private key S, and outputs MTable 2
Notations.
SymbolDescription1λ,ϱThe security parameters1nNumber of devices planned to be deployedDiThe deviceDi belongs to the leader LDi′The deviceDi′ does not belong to the leader LQ/NQThe collection of device IDsDB/DB′The identity ofDi or Di’s databaseX.EOAThe public address of the entityX running on platformX.EPKThe private address of the entityX running on platformSC.AddressThe smart contract addressS/S′A secret value set by the leaderKi/Ki′The shared key valueSThe domain of secret keyrndThe number of rounds of device update data1These two different security parameters are used to initialize the different functions.


## 3.2. Security Requirements

In our security model, privacy-preserving aggregation is our main concern. Since the smart contract is completely public, we assume that there are no inside threats in which the contract code is secure. To clarify our security definition, we assume that there are only three parties on the system: the leader, the smart contract, and the device belonging to the leader’s IoT. We elaborate the following security definitions for all probability polynomial time adversariesA where we can quantify its computation is polynomially bounded such as polyλ.
(1)
Single Device Security (SDS). We assume an adversary A who knows the probability distribution of the plaintext space M of one of the devices, but does not have any knowledge of the key. A can eavesdrop on communication (leader and IoT device) and thus observe the ciphertext of an IoT device. Let us briefly describe this simple security experiment ExpDDA,ASDS as follows:(i)
Setup: the challenger randomly selectsS and obtains Ki sequence i=1,⋯,n, and then, A outputs a pair of message m0,m1∈M(ii)
Challenge phase: the challenger randomly selectsKi and a bit b∈0,1, and then, C←DataCollectionSC.Address,L.EOA,mb,⊥,Ki is computed and given to A. We refer to C as the challenge ciphertext. Note that the ciphertext C only has a ciphertext generated by a single device operation(iii)
Guess:A outputs a bit b′We definedA’s advantage as
(5)AdvDDA,ASDS=PrExpDDA,ASDSλ=1.(2)
n−1Threshold Device Security (NDS). We assume an adversary A who is given n−1K values, but cannot infer S. Collecting the knowledge of n−1 pieces reveals no significant information about S. Let us briefly describe this simple security experiment ExpDDA,ANDS as follows:(i)
Setup: the challenger randomly selectsS and obtains Ki sequence i=1,⋯,n(ii)
Challenge phase: the challenger randomly selectn−1K values to send to A(iii)
Guess:A outputs S′Definition 5 (SDS).
We say that DDA meets Single Device Security if for all probabilistic polynomial time adversaryA, AdvDDA,ASDS≤1/2+neglλ.We definedA′s advantage as
(6)AdvDDA,ANDS=PrExpDDA,ANDSλ=1.(3)
Smart Contract Security (SCS). We assume an adversary A (A.EOA) who tries to modify the uploaded data. Let us briefly describe this simple security experiment ExpDDA,ASCS as follows.Definition 6 (NDS).
We say that DDA meetsn−1 Threshold Device Security if for all probabilistic polynomial time adversary A, AdvDDA,ANDS≤neglλ.L.EOA must authorize A.EOA to enter SC, that is, run AddDevice, A does not get L.EOA’s flag flagid.
(i)
Setup: the challenger deploys the smart contract and returnsSC.Address to A(ii)
Challenge phase: the challenger randomly selectsq identities of devices to run AddDevice(iii)
Guess:A outputs flagid. We defined A’s advantage as(7)AdvDDA,ASCS=PrExpDDA,ASCSλ=1.(4)
Outlier Security (OS). We assume that the external adversary A gets the result of all ciphertext aggregation. Let us briefly describe this simple security experiment ExpDDA,AOS as follows:(i)
Setup: the challenger randomly selectsS, and the set of K is generated by the Initialization algorithm i=1,2,⋯,n. A outputs a pair of message m0,m1∈M(ii)
Challenge phase: the challenger randomly chooses a bitb∈0,1 and generates ciphertext aggregated by n devices by running C←DataCollectionSC.Address,L.EOA,mb,DB,Ki and gives C to A(iii)
Guess:A outputs a bit b′Definition 7 (SCS).
We say that DDA meets Smart Contract Security if for all probabilistic polynomial time adversaryA,
(8)AdvDDA,ASCS≤neglλ.We definedA′s advantage asAdvDDA,AOS=PrExpDDA,AOSλ=1.Definition 8 (OS).
We say that DDA meets Outlier Security if for all probabilistic polynomial time adversaryA,
(9)AdvDDA,AOS≤12+neglλ.


## 4. Warm-Up: A Basic DDA System

Inspired by the secure decentralized privacy system [15] and the secret sharing [14], we propose the basic decentralized privacy data aggregation on the architecture of smart contracts. In this basic scheme, we mainly use cryptographic primitives such as secret sharing to protect the security of devices’ data. As shown in Figure 1, the system consists of three main entities: leaders, devices that provide data, and smart contracts.Figure 1
Sketch of basic DDA system.


### 4.1. Construction

The details of the proposed system are elaborated as follows.(i)
Initialization1λ,ϱ,n,L.EOA,Di.EOA,S,Q:
(1)
The leaderL uses ShareGen to generate n values
(10)Ki⟵ShareGen1λ,n,S,and then, the leader deploys each Ki∈0,1ℓ to each device Di that he/she controls. Hence, the device has parameters Di.EPK,Di.EOA,Ki.(2)
The leaderL creates SC
(11)SC.Address⟵InitContractϱ.And then runs AddDevice program to deploy his own devices
(12)flagLid,Q′⟵AddDeviceSC.Address,L.EOA,Di.EOA,Q.(ii)
DataCollectionSC.Address,L.EOA,mi,DB,Ki:
(1)
The leader requests data from SC. In order to protect the privacy of the raw datami∈0,1ℓ in SC, the device Di uses AddOnShare to encrypt data
(13)DSi⟵AddOnShareKi,mi.SC receivesDSi and then updates the database DB by using
(14)DB′⟵UploadSC.Address,L.EOA,flagLidDSi,DB.(2)
The leader runs Aggregation. In fact, the data will be aggregated using a leader-specified algorithm PartialRec:(15)C⟵AggregationSC.Address,DB′,L.EOA=PartialRecK1m1,⋯,Knmn.(iii)
DataReconstructionC,S: the leader uses his secret value to recover the raw data by computing:(16)M=ExtractC,S.


### 4.2. Security Analysis

The security proof of the proposed DDA is located on the supplemental materials. Here, we sketch the security in an implicit way with respect to SDS, NDS, SCS, and OS.(i)
(SDS) As noted earlier (Definition5), Ki is a one-time key so that the proposed system is equivalent to one-time pad. A does not have a Ki key; in order to distinguish the single device’s ciphertext C, it is trivial for A to succeed with probability 1/2 by outputting a random guess(ii)
(NDS) As noted earlier (Definition6), the n−1 key K give no information at all on S so that the proposed system is equivalent to secret sharing. From Definition 1, the adversary can only be randomly selected from the domain S, and the probability of success is 1/S(iii)
(SCS) As noted earlier (Definition7), an external A needs to be authorized by the leader (AddDevice) to add their own data to the specified database (Upload). From Definition 2, unless A can destroy the security of the smart contract SCS, the probability of success is negligible(iv)
(OS) As noted earlier (Definition8), S is a one-time key so that the proposed system is equivalent to one-time pad. A does not have an S key; in order to distinguish the ciphertext C aggregation results of n devices, it is trivial for A to succeed with probability 1/2 by outputting a random guess


## 4.1. Construction

The details of the proposed system are elaborated as follows.(i)
Initialization1λ,ϱ,n,L.EOA,Di.EOA,S,Q:
(1)
The leaderL uses ShareGen to generate n values
(10)Ki⟵ShareGen1λ,n,S,and then, the leader deploys each Ki∈0,1ℓ to each device Di that he/she controls. Hence, the device has parameters Di.EPK,Di.EOA,Ki.(2)
The leaderL creates SC
(11)SC.Address⟵InitContractϱ.And then runs AddDevice program to deploy his own devices
(12)flagLid,Q′⟵AddDeviceSC.Address,L.EOA,Di.EOA,Q.(ii)
DataCollectionSC.Address,L.EOA,mi,DB,Ki:
(1)
The leader requests data from SC. In order to protect the privacy of the raw datami∈0,1ℓ in SC, the device Di uses AddOnShare to encrypt data
(13)DSi⟵AddOnShareKi,mi.SC receivesDSi and then updates the database DB by using
(14)DB′⟵UploadSC.Address,L.EOA,flagLidDSi,DB.(2)
The leader runs Aggregation. In fact, the data will be aggregated using a leader-specified algorithm PartialRec:(15)C⟵AggregationSC.Address,DB′,L.EOA=PartialRecK1m1,⋯,Knmn.(iii)
DataReconstructionC,S: the leader uses his secret value to recover the raw data by computing:(16)M=ExtractC,S.


## 4.2. Security Analysis

The security proof of the proposed DDA is located on the supplemental materials. Here, we sketch the security in an implicit way with respect to SDS, NDS, SCS, and OS.(i)
(SDS) As noted earlier (Definition5), Ki is a one-time key so that the proposed system is equivalent to one-time pad. A does not have a Ki key; in order to distinguish the single device’s ciphertext C, it is trivial for A to succeed with probability 1/2 by outputting a random guess(ii)
(NDS) As noted earlier (Definition6), the n−1 key K give no information at all on S so that the proposed system is equivalent to secret sharing. From Definition 1, the adversary can only be randomly selected from the domain S, and the probability of success is 1/S(iii)
(SCS) As noted earlier (Definition7), an external A needs to be authorized by the leader (AddDevice) to add their own data to the specified database (Upload). From Definition 2, unless A can destroy the security of the smart contract SCS, the probability of success is negligible(iv)
(OS) As noted earlier (Definition8), S is a one-time key so that the proposed system is equivalent to one-time pad. A does not have an S key; in order to distinguish the ciphertext C aggregation results of n devices, it is trivial for A to succeed with probability 1/2 by outputting a random guess


## 5. Full-Fledged DDA+ System

In practical applications, the leaders need crowdsourcing data because more information can make better, more informed decisions for leaders. We consider if the data collected by the leader is the total number of smokers in a region. Assuming that an incoming person joins the statistics, the leader can query the number of people before and after, thereby exposing the privacy of the new user. (Assuming smoking is sensitive data for individuals.) For any such crowdsourcing, privacy preservation mechanisms should be used to reduce and control the privacy risks introduced by the data collection process [16]. We consider a balance between the usefulness of data leaking and the data collected.Firstly, we consider a method of centralizing differential privacy (also called differential privacy on curator model). As shown in Figure2, we can set SC or the third party to add differential privacy to the noise-adding mechanism, such as Laplace, indexing mechanism [17, 18]. However, such method cannot be realized. The specific security considerations are stated as follows:
(i)
SC is currently fully open, so the noise addition process will also be exposed(ii)
Even if some of the data processing process is not public, centralized privacy may cause collusion problemsFigure 2
Sketch of centralized differential privacy DDA system.This privacy issues are actually considered in the area of differential privacy. We have some alternatives (e.g., local differential privacy) to overcome a few issues of the curator model [16].


### 5.1. Additional Primitives

(1)
Local Differential Privacy (LDP). We explicitly describe the LDP settings and their concepts. In the LDP setup, there is a group of leaders, and the i-th leader has a private value vi in a certain domain D. These leaders interact with the untrusted aggregator such that the aggregator learns statistical information about the distribution of private values in the leader population, while the information leakage for each individual is bounded. Specifically, the leader uses the algorithm L to perturb the private value vi and sends Lvi to the aggregator. The aggregator then processes the collected reports to recover statistical information. The algorithm L satisfies the following properties.(2)
Token-Controlled Public Key Encryption. The point of a token-controlled public key encryption scheme is that the sender randomly picks a token from predefined token space. The sender encrypts the information using the token and the receiver’s public key. In addition, the sender needs to send the token to a “semitrusted” third party. The receiver decrypts using the valid token and private key. We now formally define a token-controlled public key encryption scheme as follows.Definition 9 (LDP) [19, 20].
A randomized functionL satisfies ∈-local differential privacy (∈-LDP) if and only if for any two input tuples v,v′∈DomL and for any possible output y of L, we have
(17)PrLv=y≤e∈×PrLv′=y.Definition 10 (TCPKE) [21].
A token-controlled public key encryption (in short TCPKE) scheme consists of the following algorithms:(i)
GKTCPKE1λ: it takes a security parameter 1λ∈ℕ as input and outputs a private and public key pair sk,pk. Note that pk is the security parameter, finite plaintext space P, a finite token space T, and a ciphertext space C(ii)
GTTCPKE1λ: it takes a security parameter 1λ∈ℕ as input and randomly outputs a token k∈T(iii)
ETCPKEpk,tk,m: it takes pk, tk, and m∈P as input and outputs a ciphertext c∈C(iv)
DTCPKEsk,tk,c: it takes sk, tk, and c as input; this algorithm outputs a plaintext m∈P or a special symbol ⊥ as null


### 5.2. Details of DDA+

Based on the above security concerns, we have modified the model.(i)
LDP [19]: the differential privacy is deployed on the local device side, and the other devices response to the leader with strong ε-differential privacy guarantees(ii)
TCPKE [21]: the cryptographic primitives (token) are added to ensure the unforgeability of the data requester and resist against external adversary attacksAs shown in Figure3, the proposed full-fledged DDA+ system consists of two parts. (1) The data interaction between the leader and the device is discussed in Section 4. (2) The leader interacts with the external devices. As a conclusion, the leader only collects randomized answers from each IoT device (by LDP techniques). We will show the details of data interaction with external devices.Figure 3
Sketch of local differential privacy DDA+ system.


#### 5.2.1. Definition

We slightly modify the definition of the DDA model. Note that for each IoT, we assume a universal for the ease of presentation and analysis. The DDA+ syntax is formally described as follows:
(i)
Initialization1λ,ϱ,n,S′,L.EPK,Di′.EOA,NQ: the algorithm takes as inputs 1λ,ϱ,n, leader’s private key S′, the private address registered by the leader on a platform L.EPK, device address set NQ, and generates Ki′,SC.Address,flagU′id,Di′.pk,Di′.sk,C,NQ′(ii)
DataCollectionSC.Address,C,L.EOA,Di′.sk,mi′,NDB,ϵ: the algorithm takes as inputs SC.Address, the leader’s ciphertext and token C, leader’s public address L.EOA, device private key Di′.sk, the raw data for the i-th device mi′, device i stored database NDB, the device’s privacy budget, and outputs NC(iii)
DataReconstructionNC,S′: the algorithm takes inputs as ciphertext NC, leader’s private key S′, and outputs NM


#### 5.2.2. Construction

(i)
Initialization(1λ, ϱ, n, S0, L.EPK, Di.EOA, NQ):
(1)
The leaderL uses ShareGen to generate n values: Ki′⟵ShareGen1λ,n,S′. Note that these Ki′∈0,1ℓ are used by devices that are not associated with L(2)
The leaderL creates SC
(18)SC.Address⟵InitContractϱand then runs AddDevice program to authorize alien device:
(19)flagUid′,NQ′⟵AddDeviceSC.Address,L.EOA,Di′.EOA,NQ.(3)
The deviceDi′ runs GKTCPKE algorithm and generates a private and public key pair:
(20)Di′.pk,Di′.sk⟵GKTCPKE1λ.(4)
The leader runsGTTCPKE and randomly chooses a token tk∈T:
(21)tk←$GTTCPKE1λ.Then, the leader needs to encrypt a shared secret valueKi0, calculated as follows:
(22)ci=ETCPKEDi′.pki,tk,Ki′.Finally, the leader releasesC=ci,tk. Note that tk is transmitted to SC, and SC will sign tk for the device specified by the leader, and the device will verify it.
(ii)
DataCollectionSC.Address,C,L.EOA,Di′.sk,mi′,NDB,ϵ:(1)
The device decryptsci to obtain Ki′:
(23)Ki′=DTCPKEDi′.sk,tk,ci.(2)
In the local differential privacy budgetε, the device uses the algorithm L to generate the noisy data Nmi∈0,1ℓ:
(24)Nmi⟵Lmi′,ε.(3)
In order to protect the privacy of the noisy data in SC, the deviceDi′ runs the AddOnShare algorithm:
(25)NDSi⟵AddOnShareKi′,Nmi.Then, it updates the database NDB where it is located:(26)NDB′⟵UploadSC.Address,L.EOA,flagLid′,NDSi,NDB.(4)
The leader runs the Aggregation program. In fact, the data will be aggregated using a leader-specified algorithm PartialRec:(27)NC⟵AggregationSC.Address,NDB′,L.EOA=PartialRecKi′Nm1,⋯,Kn′Nmn.(iii)
DataReconstructionNC,S0: the leader decrypts using his secret value to restore the noisy data by computing:(28)NM=ExtractNC,S′.The leader can query multiple times for data statistics and mining.


#### 5.2.3. Security Analysis

The extended DDA+ system still satisfies the security of SDS, NDS, SCS, and OS. The proof of the scheme is similar to that of Section 4, and we do not discuss it further


#### 5.2.4. Privacy Analysis

According to Definition9, the leader who receives the perturbed tuple y cannot distinguish whether the true tuple is v or another v0 with high confidence (controlled by parameter), regardless of the background information of the leader. This provides plausible deniability to the leader. The attributes of the tuple vi can be either numerical or categorical. According to the privacy data types of IoT devices, different statistical methods are used for estimation and more details in Nguyen et al. [22], e.g., for a single binary attribute, it is sufficient to estimate the distribution of IoT device data using a typical random response [23]. We consider that in the following scenario, n sensors (IoT devices) are distributed among n patients, and the probability that a patient has a disease of type A is π; we want to count the expected value of π. If the aggregator (leader) directly obtains the corresponding data of the user for statistics, the patient will reveal privacy. Thus, each user ui reports her true answer with probability p and random answer with probability 1−p. Then, we can simply calculate the expected value
(29)Eπ^=12p−1p−1+πp+1−π1−p=π.According to Definition9, ∈-LDP require that ∈=lnp/1−p.


## 5.1. Additional Primitives

(1)
Local Differential Privacy (LDP). We explicitly describe the LDP settings and their concepts. In the LDP setup, there is a group of leaders, and the i-th leader has a private value vi in a certain domain D. These leaders interact with the untrusted aggregator such that the aggregator learns statistical information about the distribution of private values in the leader population, while the information leakage for each individual is bounded. Specifically, the leader uses the algorithm L to perturb the private value vi and sends Lvi to the aggregator. The aggregator then processes the collected reports to recover statistical information. The algorithm L satisfies the following properties.(2)
Token-Controlled Public Key Encryption. The point of a token-controlled public key encryption scheme is that the sender randomly picks a token from predefined token space. The sender encrypts the information using the token and the receiver’s public key. In addition, the sender needs to send the token to a “semitrusted” third party. The receiver decrypts using the valid token and private key. We now formally define a token-controlled public key encryption scheme as follows.Definition 9 (LDP) [19, 20].
A randomized functionL satisfies ∈-local differential privacy (∈-LDP) if and only if for any two input tuples v,v′∈DomL and for any possible output y of L, we have
(17)PrLv=y≤e∈×PrLv′=y.Definition 10 (TCPKE) [21].
A token-controlled public key encryption (in short TCPKE) scheme consists of the following algorithms:(i)
GKTCPKE1λ: it takes a security parameter 1λ∈ℕ as input and outputs a private and public key pair sk,pk. Note that pk is the security parameter, finite plaintext space P, a finite token space T, and a ciphertext space C(ii)
GTTCPKE1λ: it takes a security parameter 1λ∈ℕ as input and randomly outputs a token k∈T(iii)
ETCPKEpk,tk,m: it takes pk, tk, and m∈P as input and outputs a ciphertext c∈C(iv)
DTCPKEsk,tk,c: it takes sk, tk, and c as input; this algorithm outputs a plaintext m∈P or a special symbol ⊥ as null


## 5.2. Details of DDA+

Based on the above security concerns, we have modified the model.(i)
LDP [19]: the differential privacy is deployed on the local device side, and the other devices response to the leader with strong ε-differential privacy guarantees(ii)
TCPKE [21]: the cryptographic primitives (token) are added to ensure the unforgeability of the data requester and resist against external adversary attacksAs shown in Figure3, the proposed full-fledged DDA+ system consists of two parts. (1) The data interaction between the leader and the device is discussed in Section 4. (2) The leader interacts with the external devices. As a conclusion, the leader only collects randomized answers from each IoT device (by LDP techniques). We will show the details of data interaction with external devices.Figure 3
Sketch of local differential privacy DDA+ system.


### 5.2.1. Definition

We slightly modify the definition of the DDA model. Note that for each IoT, we assume a universal for the ease of presentation and analysis. The DDA+ syntax is formally described as follows:
(i)
Initialization1λ,ϱ,n,S′,L.EPK,Di′.EOA,NQ: the algorithm takes as inputs 1λ,ϱ,n, leader’s private key S′, the private address registered by the leader on a platform L.EPK, device address set NQ, and generates Ki′,SC.Address,flagU′id,Di′.pk,Di′.sk,C,NQ′(ii)
DataCollectionSC.Address,C,L.EOA,Di′.sk,mi′,NDB,ϵ: the algorithm takes as inputs SC.Address, the leader’s ciphertext and token C, leader’s public address L.EOA, device private key Di′.sk, the raw data for the i-th device mi′, device i stored database NDB, the device’s privacy budget, and outputs NC(iii)
DataReconstructionNC,S′: the algorithm takes inputs as ciphertext NC, leader’s private key S′, and outputs NM


### 5.2.2. Construction

(i)
Initialization(1λ, ϱ, n, S0, L.EPK, Di.EOA, NQ):
(1)
The leaderL uses ShareGen to generate n values: Ki′⟵ShareGen1λ,n,S′. Note that these Ki′∈0,1ℓ are used by devices that are not associated with L(2)
The leaderL creates SC
(18)SC.Address⟵InitContractϱand then runs AddDevice program to authorize alien device:
(19)flagUid′,NQ′⟵AddDeviceSC.Address,L.EOA,Di′.EOA,NQ.(3)
The deviceDi′ runs GKTCPKE algorithm and generates a private and public key pair:
(20)Di′.pk,Di′.sk⟵GKTCPKE1λ.(4)
The leader runsGTTCPKE and randomly chooses a token tk∈T:
(21)tk←$GTTCPKE1λ.Then, the leader needs to encrypt a shared secret valueKi0, calculated as follows:
(22)ci=ETCPKEDi′.pki,tk,Ki′.Finally, the leader releasesC=ci,tk. Note that tk is transmitted to SC, and SC will sign tk for the device specified by the leader, and the device will verify it.
(ii)
DataCollectionSC.Address,C,L.EOA,Di′.sk,mi′,NDB,ϵ:(1)
The device decryptsci to obtain Ki′:
(23)Ki′=DTCPKEDi′.sk,tk,ci.(2)
In the local differential privacy budgetε, the device uses the algorithm L to generate the noisy data Nmi∈0,1ℓ:
(24)Nmi⟵Lmi′,ε.(3)
In order to protect the privacy of the noisy data in SC, the deviceDi′ runs the AddOnShare algorithm:
(25)NDSi⟵AddOnShareKi′,Nmi.Then, it updates the database NDB where it is located:(26)NDB′⟵UploadSC.Address,L.EOA,flagLid′,NDSi,NDB.(4)
The leader runs the Aggregation program. In fact, the data will be aggregated using a leader-specified algorithm PartialRec:(27)NC⟵AggregationSC.Address,NDB′,L.EOA=PartialRecKi′Nm1,⋯,Kn′Nmn.(iii)
DataReconstructionNC,S0: the leader decrypts using his secret value to restore the noisy data by computing:(28)NM=ExtractNC,S′.The leader can query multiple times for data statistics and mining.


### 5.2.3. Security Analysis

The extended DDA+ system still satisfies the security of SDS, NDS, SCS, and OS. The proof of the scheme is similar to that of Section 4, and we do not discuss it further


### 5.2.4. Privacy Analysis

According to Definition9, the leader who receives the perturbed tuple y cannot distinguish whether the true tuple is v or another v0 with high confidence (controlled by parameter), regardless of the background information of the leader. This provides plausible deniability to the leader. The attributes of the tuple vi can be either numerical or categorical. According to the privacy data types of IoT devices, different statistical methods are used for estimation and more details in Nguyen et al. [22], e.g., for a single binary attribute, it is sufficient to estimate the distribution of IoT device data using a typical random response [23]. We consider that in the following scenario, n sensors (IoT devices) are distributed among n patients, and the probability that a patient has a disease of type A is π; we want to count the expected value of π. If the aggregator (leader) directly obtains the corresponding data of the user for statistics, the patient will reveal privacy. Thus, each user ui reports her true answer with probability p and random answer with probability 1−p. Then, we can simply calculate the expected value
(29)Eπ^=12p−1p−1+πp+1−π1−p=π.According to Definition9, ∈-LDP require that ∈=lnp/1−p.


## 5.2.1. Definition

We slightly modify the definition of the DDA model. Note that for each IoT, we assume a universal for the ease of presentation and analysis. The DDA+ syntax is formally described as follows:
(i)
Initialization1λ,ϱ,n,S′,L.EPK,Di′.EOA,NQ: the algorithm takes as inputs 1λ,ϱ,n, leader’s private key S′, the private address registered by the leader on a platform L.EPK, device address set NQ, and generates Ki′,SC.Address,flagU′id,Di′.pk,Di′.sk,C,NQ′(ii)
DataCollectionSC.Address,C,L.EOA,Di′.sk,mi′,NDB,ϵ: the algorithm takes as inputs SC.Address, the leader’s ciphertext and token C, leader’s public address L.EOA, device private key Di′.sk, the raw data for the i-th device mi′, device i stored database NDB, the device’s privacy budget, and outputs NC(iii)
DataReconstructionNC,S′: the algorithm takes inputs as ciphertext NC, leader’s private key S′, and outputs NM


## 5.2.2. Construction

(i)
Initialization(1λ, ϱ, n, S0, L.EPK, Di.EOA, NQ):
(1)
The leaderL uses ShareGen to generate n values: Ki′⟵ShareGen1λ,n,S′. Note that these Ki′∈0,1ℓ are used by devices that are not associated with L(2)
The leaderL creates SC
(18)SC.Address⟵InitContractϱand then runs AddDevice program to authorize alien device:
(19)flagUid′,NQ′⟵AddDeviceSC.Address,L.EOA,Di′.EOA,NQ.(3)
The deviceDi′ runs GKTCPKE algorithm and generates a private and public key pair:
(20)Di′.pk,Di′.sk⟵GKTCPKE1λ.(4)
The leader runsGTTCPKE and randomly chooses a token tk∈T:
(21)tk←$GTTCPKE1λ.Then, the leader needs to encrypt a shared secret valueKi0, calculated as follows:
(22)ci=ETCPKEDi′.pki,tk,Ki′.Finally, the leader releasesC=ci,tk. Note that tk is transmitted to SC, and SC will sign tk for the device specified by the leader, and the device will verify it.
(ii)
DataCollectionSC.Address,C,L.EOA,Di′.sk,mi′,NDB,ϵ:(1)
The device decryptsci to obtain Ki′:
(23)Ki′=DTCPKEDi′.sk,tk,ci.(2)
In the local differential privacy budgetε, the device uses the algorithm L to generate the noisy data Nmi∈0,1ℓ:
(24)Nmi⟵Lmi′,ε.(3)
In order to protect the privacy of the noisy data in SC, the deviceDi′ runs the AddOnShare algorithm:
(25)NDSi⟵AddOnShareKi′,Nmi.Then, it updates the database NDB where it is located:(26)NDB′⟵UploadSC.Address,L.EOA,flagLid′,NDSi,NDB.(4)
The leader runs the Aggregation program. In fact, the data will be aggregated using a leader-specified algorithm PartialRec:(27)NC⟵AggregationSC.Address,NDB′,L.EOA=PartialRecKi′Nm1,⋯,Kn′Nmn.(iii)
DataReconstructionNC,S0: the leader decrypts using his secret value to restore the noisy data by computing:(28)NM=ExtractNC,S′.The leader can query multiple times for data statistics and mining.


## 5.2.3. Security Analysis

The extended DDA+ system still satisfies the security of SDS, NDS, SCS, and OS. The proof of the scheme is similar to that of Section 4, and we do not discuss it further


## 5.2.4. Privacy Analysis

According to Definition9, the leader who receives the perturbed tuple y cannot distinguish whether the true tuple is v or another v0 with high confidence (controlled by parameter), regardless of the background information of the leader. This provides plausible deniability to the leader. The attributes of the tuple vi can be either numerical or categorical. According to the privacy data types of IoT devices, different statistical methods are used for estimation and more details in Nguyen et al. [22], e.g., for a single binary attribute, it is sufficient to estimate the distribution of IoT device data using a typical random response [23]. We consider that in the following scenario, n sensors (IoT devices) are distributed among n patients, and the probability that a patient has a disease of type A is π; we want to count the expected value of π. If the aggregator (leader) directly obtains the corresponding data of the user for statistics, the patient will reveal privacy. Thus, each user ui reports her true answer with probability p and random answer with probability 1−p. Then, we can simply calculate the expected value
(29)Eπ^=12p−1p−1+πp+1−π1−p=π.According to Definition9, ∈-LDP require that ∈=lnp/1−p.


## 6. Implementations

We discuss the implementations in the aspects of LDP, secret sharing, and smart contracts.


### 6.1. The LDP Perturbation Data FunctionL

We use Python 2.7 programming language to implement the experiments. Then, we take Raspberry Pi 3 as a data collector (the leader’s device or other device) and they equip a quad-core ARMv7 CPU 1200 MHz and 1 GB RAM. Moreover, we use the Google RAPPOR [24] to realize the LDP. In DDA+ system, the devices run this algorithm to generate the noisy data. Suppose each device only stores a 1-bit binary data, where the probability of the number of 1s in all the devices’ data is π. Each device determines a true value (without flipping the 1-bit data) with a probability p. After the randomized response, we can obtain the noisy data. For analyzing the deviation from the original and noisy data aggregations, we fix π=0.3 and then set p=0.75 and p=0.8 to get ϵ=ln3 and ϵ=ln4, respectively. The deviation of pure data and noisy data with different p is shown in Figures 4 and 5. By observation over the experimental results, it suffices to use p=0.75 if we accept 10% deviation on 300 devices (p=0.8 if on more than 500 devices).Figure 4
The deviation of pure data and noisy data withp=0.75.Figure 5
The deviation of pure data and noisy data withp=0.8.


### 6.2. Performance of the Secret Sharing Scheme

For evaluating the performance, we use python programming language with version 2.7 and import random module, numpy module, etc., to implement the experiment, running Intel(R) Core(TM) i7-7700 CPU 3.60 GHz and 8 GB memory in Windows 10 as the operating environment of Ethereum. Firstly, the leader uses ShareGen to generate shares and sends them to devices. Devices use AddOnShare to encrypt the data. Next, as long as the leader wants to require some data, he uses PartialRec and Extract to recover the data. The execution time of each algorithm is shown in Figure6.Figure 6
Performance of additive secret sharing.


### 6.3. Simulations on Smart Contracts

We run our DDA+ system on the Ethereum blockchain through Solidity 0.6.12 and deploy it upon the Ropsten test network on February 17, 2021, where the gas price is approximately 2.1578 Gwei. Note that, at the same time, Ethereum average gas price on the public network is 183.087 Gwei. On our simulation, we firstly have to deploy the main contract, where we use AddDevice and RemoveDevice transaction to add device and delete device, respectively. If the leader would like to access, he can send Aggregation transaction. When devices collect some data, they send Upload transaction to the blockchain. In Table 3, every transaction has a different processing fee. We found that the highest cost is exactly on contract deploying. The other types of transactions only require a lesser cost.Table 3
Transaction fee.
TransactionGas used (wei)Transaction fee (wei)InitContract7576581.634E+15AddDevice1140372.461E+14RemoveDevice379408.187E+13Upload468631.101E+14Aggregation582491.259E+14


## 6.1. The LDP Perturbation Data FunctionL

We use Python 2.7 programming language to implement the experiments. Then, we take Raspberry Pi 3 as a data collector (the leader’s device or other device) and they equip a quad-core ARMv7 CPU 1200 MHz and 1 GB RAM. Moreover, we use the Google RAPPOR [24] to realize the LDP. In DDA+ system, the devices run this algorithm to generate the noisy data. Suppose each device only stores a 1-bit binary data, where the probability of the number of 1s in all the devices’ data is π. Each device determines a true value (without flipping the 1-bit data) with a probability p. After the randomized response, we can obtain the noisy data. For analyzing the deviation from the original and noisy data aggregations, we fix π=0.3 and then set p=0.75 and p=0.8 to get ϵ=ln3 and ϵ=ln4, respectively. The deviation of pure data and noisy data with different p is shown in Figures 4 and 5. By observation over the experimental results, it suffices to use p=0.75 if we accept 10% deviation on 300 devices (p=0.8 if on more than 500 devices).Figure 4
The deviation of pure data and noisy data withp=0.75.Figure 5
The deviation of pure data and noisy data withp=0.8.


## 6.2. Performance of the Secret Sharing Scheme

For evaluating the performance, we use python programming language with version 2.7 and import random module, numpy module, etc., to implement the experiment, running Intel(R) Core(TM) i7-7700 CPU 3.60 GHz and 8 GB memory in Windows 10 as the operating environment of Ethereum. Firstly, the leader uses ShareGen to generate shares and sends them to devices. Devices use AddOnShare to encrypt the data. Next, as long as the leader wants to require some data, he uses PartialRec and Extract to recover the data. The execution time of each algorithm is shown in Figure6.Figure 6
Performance of additive secret sharing.


## 6.3. Simulations on Smart Contracts

We run our DDA+ system on the Ethereum blockchain through Solidity 0.6.12 and deploy it upon the Ropsten test network on February 17, 2021, where the gas price is approximately 2.1578 Gwei. Note that, at the same time, Ethereum average gas price on the public network is 183.087 Gwei. On our simulation, we firstly have to deploy the main contract, where we use AddDevice and RemoveDevice transaction to add device and delete device, respectively. If the leader would like to access, he can send Aggregation transaction. When devices collect some data, they send Upload transaction to the blockchain. In Table 3, every transaction has a different processing fee. We found that the highest cost is exactly on contract deploying. The other types of transactions only require a lesser cost.Table 3
Transaction fee.
TransactionGas used (wei)Transaction fee (wei)InitContract7576581.634E+15AddDevice1140372.461E+14RemoveDevice379408.187E+13Upload468631.101E+14Aggregation582491.259E+14


## 7. Conclusions

In this paper, we propose the DDA/DDA+ systems based on smart contract as the heart to achieve decentralization. However, they rely on privacy and cryptographic algorithms to protect the data of IoT devices and satisfy the security requirements. To wrap up our techniques, we use secret sharing to preserve the data processing mechanism efficiently. We apply local differential privacy and tokens as extensions of the access capabilities of other leaders’ devices.



---

*Source: 5565663-2021-04-15.xml*