# PRIviLY: Private Remote Inference over fulLY connected deep networks for pervasive health monitoring with constrained client-side

Amine Boulemtafes, Abdelouahid Derhab, Yacine Challal

► To cite this version:

Amine Boulemtafes, Abdelouahid Derhab, Yacine Challal. PRIviLY: Private Remote Inference over fulLY connected deep networks for pervasive health monitoring with constrained client-side. Journal of information security and applications, 2023, 77, pp.103552. 10.1016/j.jisa.2023.103552. hal-05234191

HAL Id: hal-05234191

https://hal.science/hal-05234191v1

Submitted on 1 Sep 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# PRIviLY: Private Remote Inference over fully connected deep networks for pervasive health monitoring with constrained client-side

Amine Boulemtafes<fnref n="1" />,<fnref n="2" />,* · Abdelouahid Derhab<fnref n="3" /> · Yacine Challal<fnref n="4" />

## Abstract

Remote deep learning paradigm enables to better leverage the power of deep neural networks in pervasive health monitoring (PHM) applications, especially by addressing the constrained client-side environment. However, remote deep learning in the context of PHM requires to ensure three properties: (1) meet the high accuracy requirement of the healthcare domain, (2) satisfy the client-side constraints, and (3) cope with the privacy requirements related to the high sensitivity of health data. Different privacy-preserving solutions for remote deep learning exit in the literature but many of them fail to fully address the PHM requirements especially with respect to constrained client-side environments. To that end, we propose PRIviLY, a novel privacy-preserving remote inference solution, designed specifically for the popular Fully Connected Deep Networks (FCDNs). PRIviLY avoids the use of encryption for privacy preservation of sensitive information, in order to fully prevent accuracy loss, and to alleviate the server-side hardware requirements. Besides, PRIviLY adopts a non-colluding two-server architecture, and leverages the linear computations of FCDNs along with reversible random perturbation and permutation techniques in order to preserve privacy of sensitive information, while meeting low overhead requirement of constrained client-sides. At the cloud server, efficiency evaluation shows that PRIviLY achieves an improvement ratio of 4 to more than 15 times for communication, and a minimum improvement ratio of 135 times for computation overhead. At the intermediate server, the minimum improvement ratio is at least more than 10900 for computation, while for communication, the improvement ratio varies from 5 to more than 21 times. As for the client-side, PRIviLY incurs an additional overhead of about 27% in terms of communication, and between 16% and at most 27% in terms of computation.

**Keywords** Fully Connected Deep Neural Networks · Privacy · Constrained · Remote Inference

Amine Boulemtafes
aboulemtafes@cerist.dz

Abdelouahid Derhab
abderhab@ksu.edu.sa

Yacine Challal
y_challal@esi.dz

<footnote n="1">¹ Division Sécurité Informatique, Centre de Recherche sur l'Information Scientifique et Technique, Algiers, Algeria</footnote>

<footnote n="2">² Département Informatique, Faculté des Sciences exactes, Université de Bejaia, 06000 Bejaia, Algeria</footnote>

<footnote n="3">³ Center of Excellence in Information Assurance, King Saud University, Riyadh, Saudia Arabia</footnote>

<footnote n="4">⁴ Laboratoire de Méthodes de Conception des Systèmes, Ecole Nationale Supérieure d'Informatique, Algiers, Algeria</footnote>

<footnote>* Corresponding author</footnote>
# 1. Introduction

Pervasive health monitoring (PHM) is one of the most interesting fields of e-healthcare. It enables anywhere and anytime patient monitoring towards improving medical quality while reducing costs, as well as improving the quality of patients' lives. With the advancements in sensing technologies and the emergence and increasing development of deep learning, PHM applications are nowadays able to target various health diseases like pneumonia, sleep apnea, heart health assessment, and Covid-19, as well as different well-being cases like helping elderly living independently [36, 43, 49].

Besides, in order to further take advantage of the power of deep learning, powerful infrastructures with high-power computation and massive storage such as clouds are nowadays used in order to run deep neural network models. This paradigm called remote deep learning, allows to better fit the increasing depth and computation requirements of powerful deep learning models, while it enables the access to proprietary deep models. Moreover, remote inferences were shown able to incur, in appropriate settings, shorter execution time in comparison to local inferences [17].

Remote deep learning is furthermore interesting when the client-side environment is constrained in terms of computation, energy, or storage. This is the case of PHM environment which generally relies on client devices with limited power and computation. In fact, because PHM can be particularly leveraged with powerful deep learning-based data analytics [50], but its environment is considered as constrained, remote deep learning paradigm represents an effective approach to better benefit from PHM potential.

However, by transmitting sensitive data from client devices to external infrastructures, the use of remote deep learning raises a number of privacy concerns, especially that health-related information can be very sensitive. Such concerns may include the disclosure of private information, or the identification of individuals, or even the disclosure of remote models, which are often proprietary and require to be kept private.

Consequently, remote deep learning in PHM requires solutions that ensure three properties: (1) efficiency of the client-side environment generally constrained, (2) effectiveness in terms of high accuracy, which is generally requested in the healthcare domain, and (3) privacy, meeting the data sensitivity requirements of the healthcare domain.

Different privacy-preserving solutions exist in the literature [15, 46, 47], but many of them do not consider constrained client-side environments, and generally do not fully satisfy efficiency, effectiveness, and privacy requirements of PHM. Moreover, some solutions, more specifically encryption-based, generally incur a high overhead at the server-side, requiring high-performance server-side configurations [36].

In this paper, we propose PRIviLY, a novel encryption-free privacy-preserving remote inference solution for PHM, designed specifically to run on Fully Connected Deep Networks (FCDNs)<fnref n="1" />, one of the most popular deep learning models. FCDNs are mainly represented by the traditional MLP (Multi-Layer Perceptron) architecture, which is still widely used in many fields, although its simplicity [1-4]. FCDNs also include some DAE (Deep Auto Encoder), and DBN (Deep Belief Network) architectures [43]. One major advantage of FCDN is its agnostic structure, i.e. there is no specific assumption about the input [5]. In the context of PHM, different applications may rely on FCDN such as the analysis of Parkinson disease [6], the recognition of human activities [7, 8, 9], and the detection of hypoglycemia [10], heart [11, 12], pulmonary [13], and Covid-19 [14] diseases.

The main contributions and results of this work are as follows:

- We propose PRIviLY, an encryption-free solution for privacy-preserving remote FCDN-based inference solution, which fulfills PHM efficiency and effectiveness requirements.

- We leverage the non-colluding two-server architecture with two reversible obfuscation techniques, namely, random mask perturbation and random permutation, in order to preserve privacy of sensitive input data, intermediate results, and inferences, while meeting low overhead requirement of constrained client-sides.

- We avoid the use of encryption for privacy preservation of sensitive information, in order to fully prevent accuracy loss, and to alleviate the server-side hardware requirements.

- We achieve promising performance results including:

- Privacy of input data, intermediate results, and inferences, as well as the deep learning model.

- "Zero" accuracy loss, which fully meets high accuracy requirement of the healthcare domain.

<footnote n="1">1 Where each neuron of a layer *i* is connected to all the neurons of the next layer *i*+1</footnote>
* A lower server-side overhead compared to a state-of-the-art solution targeting PHM, which allows to alleviate hardware requirements.

* At the cloud server, a minimum improvement ratio of 135 times in terms of computation overhead, and an improvement ratio between 4 to more than 15 times in terms of communication.

* At the intermediate server, a minimum improvement ratio of more than 10900 times in terms of computation, and an improvement ratio that varies between 5 to more than 21 times in terms of communication.

* A slightly additional client-side overhead compared to a state-of-the-art solution targeting PHM, meeting the limited power and computation capabilities of client devices, and the unreliability of some networks and potentially high communication costs.

* A percentage of additional overhead of about 27% in terms of communication, and between 16% and at most 27% in terms of computation.

The remainder of this paper is organized as follows: Section 2 presents a brief background and definitions related to our work. Section 3 describes PRIviLY including architecture, details of reversible obfuscation techniques, and solution description. Section 4 presents an evaluation and comparison of PRIviLY. Section 4 overviews the related work. Finally, Section 5 concludes the paper.

# 2. Background and definitions

## 2.1 Fully connected deep network (FCDN)

Fully Connected Deep Networks (FCDNs) are one of the most popular deep learning models. They are mainly represented by the traditional MLP (Multi-Layer Perceptron) architecture, which is still widely used in many fields, although its simplicity [1-4]. FCDNs also include some DAE (Deep Auto Encoder), and DBN (Deep Belief Network) architectures [43]. One major advantage of FCDN is its agnostic structure, i.e. there is no specific assumption about the input [5].

In the context of PHM, different applications may rely on FCDN such as the analysis of Parkinson disease [6], the recognition of human activities [7, 8, 9], and the detection of hypoglycemia [10], heart [11, 12], pulmonary [13], and Covid-19 [14] diseases.

<figure><img src="image_2.png" /><figcaption>**Fig. 1** Main computations performed in a fully connected deep network (with two hidden layers) [18]</figcaption></figure>

As shown in Figure 1, FCDN is mainly based on the computation of weighted sums $z_i$ at each layer and for each neuron. An activation function $f(z_i)$ takes the weighted sum of neuron of its previous layer as input, and computes the output $y_i$ of this neuron.

## 2.2 Non-colluding two-server architecture

In [16] and [17], a non-colluding two-server architecture is adopted in order to design privacy-preservation solutions. This architecture consists of the introduction of a 2^nd^ server, sometimes called intermediate server, along with the cloud server in order to participate to the security and privacy protocol.

It is reported in [44] that such a model is commonly and widely adopted in the literature for the design of security solutions in various application domains. In [45], it is pointed out that such an assumption is not hard to achieve since service providers, generally represented by large companies, are heavily regulated.
From a deployment perspective, the intermediate server can be deployed in different forms including fog servers. This implementation feature is not considered as a drawback, as the current real deployment of applications, like smart city, already includes fog and cloud servers [17].

However, a potential drawback is the performance of available intermediate servers, which can potentially include mid-performance fog nodes. Therefore, the efficiency of privacy-preserving solutions at the server-side should be taken into consideration in such an architectural model, although it is not a primary objective with respect to the PHM environment constraints.

## 2.3 Random mask perturbation

Random mask perturbation technique consists of obfuscating a data vector $d$ of dimension $n$ by applying a random vector $v$ of the same dimension $n$ using element-wise addition, i.e.,

$$dv = d + v$$

## 2.4 Permutation matrix obfuscation

Permutation matrix obfuscation technique consists of multiplying the data vector $d$ by the known permutation matrix $m$ to generate an obfuscated data $d'$.

The permutation matrix $m$ is defined as a square binary matrix that has exactly one entry of 1 in each row and each column and zeros elsewhere [19].

The permutation-based obfuscation can be reversed by multiplying the obfuscated data by the transpose of $m$ denoted by $m^T$.

# 3. PRIviLY – encryption-free and Private Remote deep learning Inference over fully-connected deep networks for constrained client environments

## 3.1 Architecture and assumptions

As in [16, 17], PRIviLY mainly relies on the above-described non-colluding two-server based architecture, where the client can communicate with both intermediate and cloud servers.

As shown in Figure 2, the architecture adopted in PRIviLY comprises the following components:

* The client: It holds the health-related data on which it initiates inference requests to the cloud server.

* The cloud server (CS): It is the main host for the deep learning model, and performs the main inference process tasks.

* The intermediate server (IS): It is mainly responsible for the computation of activation functions, while ensuring privacy preservation. It can be either part of the fog architecture, or an infrastructure made available for specific PHM applications, or even a non-colluding part of the cloud architecture.

<figure><img src="image_3.png" /><figcaption>Fig. 2 Adopted non-colluding two-server architecture in PRIviLY</figcaption></figure>

Besides, the adopted architecture assumes that:

* The cloud and intermediate servers do not collude between them or with any other party.

* The honest-but-curious (HbC) adversary model applies, where the parties follow the protocol (honest) but may try to deduce private information (curious) within the limits of the protocol [17].

* Both secure, and insecure scenarios of communication channels are considered.
## 3.2 Basic idea

The key basic idea of PRIviLY is to leverage the linearity of FCDN weighted sums (see Section 2.1), which enables to introduce removable perturbations during their computation and activation, and hence ensuring privacy of the different sensitive information.

To that end, two main reversible obfuscation methods, namely, random mask perturbation and random permutation (see Section 3.3) are applied under a non-colluding two-server architecture, in order to keep private both users sensitive data and the cloud-based model.

## 3.3 Reversible obfuscation

### 3.3.1 Random mask perturbation under FCDN weighted sums

In PRIviLY, weighted sums of the neural network are calculated using data obfuscated with random mask perturbation defined in Section 2.3. Consequently, the removal process need to be performed on these weighted sums in order to result in correct inferences.

The removal of the perturbation from the computed perturbed weighted sums can be performed as follows:

$$ 
\begin{aligned}
\text{Let } d &= (d1, d2, \dots, di, \dots, dn) \text{ be the data to obfuscate, } v = (v1, v2, \dots, vi, \dots, vn) \text{ be the random mask,} \\
\text{and } Ov \text{ be the perturbed weighted sum of the neuron } j, \text{ computed using the perturbed data } dv = d + v \\
&= \text{Sum}(wk * (di + vi)); \text{ where each } wk \text{ is the weight that connects } xi \text{ to the neuron } j \\
&= \text{Sum}(wk * di + wk * vi) = \text{Sum}(wk * di) + \text{Sum}(wk * vi)
\end{aligned}
$$

Therefore, in order to remove the perturbation $v$ from $Ov$, we need to remove the sum of weighted perturbations $Sv = \text{Sum}(wk * vi)$

$$ 
\begin{aligned}
O &= Ov - Sv = \text{Sum}(wk * di) + \text{Sum}(wk * vi) - \text{Sum}(wk * vi) \\
&= \text{Sum}(wk * di)
\end{aligned}
$$

### 3.3.2 Random permutation

Two random permutation techniques can be used in PRIviLY as follows:

- Basic permutation obfuscation

This technique consists of the permutation matrix perturbation defined in Section 2.4. It is particularly used when the dimension of the target data to obfuscate is large enough so that the permutation effectively makes the data unclear.

- Advanced permutation-based obfuscation

A more advanced obfuscation method based on permutation can be used, particularly when the dimension of the input data or intermediate results is very small and cannot be effectively obfuscated using a simple permutation matrix.

As depicted in Figure 3, the advanced technique consists of multiplying the size of a data vector $d$ by a factor $n$, then redistributing its elements according to the vector $p$. The new elements of $d$ are filled with random values in the range of the original ones in order to dissimulate the originals.

The method also allows to dissimulate the real number of neurons of each layer since $n$ is unknown by IS.

<table><caption>Fig. 3 Advanced permutation-based obfuscation: Application (**left**) – Removal (**right**)</caption><thead><tr><th>app_permute_adv(d, p, n)</th><th>rem_permute_adv(d, p, n)</th></tr></thead><tbody><tr><td>1. dim(d) = dim(d) * n</td><td>1. restore order of original values of d using p</td></tr><tr><td>2. reorder original values of d according to p</td><td>2. dim(d) = dim(d)/n</td></tr><tr><td>3. fill null elements with random values in the range of the original ones</td><td>3. return d</td></tr><tr><td>4. return d</td><td></td></tr></tbody></table>

## 3.4 Solution description

As depicted in Figure 4, we describe in the following the main steps of our proposed PRIviLY solution in order to perform a private remote inference under the adopted non-colluding two-server architecture.
<figure><img src="image_4.png" /><figcaption>Fig. 4 Process of a privacy-preserving inference through a remote FCDN model using PRIviLY</figcaption></figure>

Let $d$: original sensitive data; $L$: layer; $i$: index of current layer; $f$: index of the last layer; $j$: index of current neuron; $r0, r$: random obfuscation values; $p, q$: reversible random permutations; $v, u$: reversible random perturbations; $AF[i]:$ activation function of layer $i$; $A[i]:$ Activated output of layer $i$; $W[i][j]:$ set of weights that connects to the neuron $j$ of layer $i$

The notation $x --> A$ means that $x$ is sent to $A$. If $x$ is not an obfuscated data, it is privately shared using for example Diffie-Hellman exchange method.

– Step 1:

**Client**

- [First time]

- initializes $r0 --> IS$ (private sharing), $v$

- perturbs $v$ using $r0: v.r = v * r0 --> CS$

- perturbs $d$ using $v: dv = d + v --> CS$

– Step 2:

**CS**

- computes perturbed outputs (weighted sums) of $L1$ using $dv: Ov[1]$

- initializes $q$

- permutes order of $Ov[1]$ using $q: q(Ov[1]) --> IS$

- for each neuron $j$ of $Ov[1]$, computes obfuscated sum of weighted perturbations using $v.r$ and the set of weights $W[1][j]$ used for the computation of the output $Ov[1][j]: Sv[1][j].r$

- permutes order of vector $Sv[1].r$ of $Sv[1][j].r$ sums using $q: q(Sv[1].r) --> IS$

- $AF[1]$ (true and fake ones) --> IS

– Step 3:

**IS**

- removes $r0$ from $q(Sv[1].r): q(Sv[1]) = q(Sv[1].r) / r0$

- subtracts $q(Sv[1])$ from $q(Ov[1]): q(O[1])$

- applies true and fake activation functions: $q(A[1]) = AF[1](q(O[1]))$

- initializes $u$

- perturbs true and fake $q(A[1])$ using $u: q(Au[1]) = q(A[1]) + u --> CS$

- initializes $r$

- perturbs $u$ using $r: u.r = u * r --> CS$

– Step 4:

**CS**

- selects true $q(Au[1])$ and restores correct order: $Au[1]$

For $i = 2$ to $f - 1$

– Step 5:

**CS**

- computes perturbed outputs (weighted sums) of $Li$ using $Au[i-1]: Ou[i]$

- sets $p = q$, and initializes a new $q$ adapted to $Ou[i]$ dimensions

- permutes order of $Ou[i]$ using $q: q(Ou[i]) --> IS$

- computes obfuscated sum of weighted perturbations for each neuron $j$ of $Ou[i]$ using permuted set of weights $p(W[i][j])$ and $u.r: Su[i][j].r$
- permutes order of vector Su[i].r of Su[i][j].r sums using q: q(Su[i].r)--> IS

- AF[i] (true and fake ones) --> IS

## Step 6:

**IS**

- removes *r* from q(Su[i].r): q(Su[i]) = q(Su[i].r) / r

- subtracts q(Su[i]) from q(Ou[i]): q(O[i])

- applies true and fake activation functions: q(A[i]) = AF[i](q(O[i]))

- initializes *u*

- perturbs true and fake q(A[i]) using u: q(Au[i]) = q(A[i]) + u --> CS

- initializes *r*

- perturbs *u* using *r*: u.r = *u* * *r* --> CS

- If *i* = *f* - 1 then *r* --> **Client** (private sharing)

## Step 7:

**CS**

- selects true q(Au[i]) and restores correct order: Au[i]

## Step 8:

**CS**

- computes perturbed outputs (weighted sums) of Lf using last Au[i]: Ou[f] --> **Client**

- sets *p* = *q*

- computes obfuscated sum of weighted perturbations for each neuron *j* of Ou[f] using permuted set of weights p(W[f][j]) and u.r: Su[f][j].r

- Su[f].r (the vector of the sums Su[f][j].r) --> **Client**

- AF[f] --> **Client**

## Step 9:

**Client**

- removes *r* from Su[f].r: Su[f] = Su[f].r / r

- subtracts Su[f] from Ou[f]: Ou[f]

- applies last activation function AF[f](O[f]) and reveals the inference: A[f]

**Note.** In order to dissimulate the real number of layers, CS can sometimes initiate fake layers computation by interacting with IS to make it believe that it is handling real layers. The real number of neurons in each layer can also be dissimulated using advanced permutation (see Section 3.3.2).

# 4 Performances analysis

In this section, we present an analysis of PRIviLY in terms of effectiveness, efficiency, and privacy [15], and compare it with [17] in terms of accuracy, privacy guarantees, and tasks performed on the client-side, the cloud server, and the intermediate server.

Effectiveness and efficiency analysis is furthermore supported by experimental results and compared with [17] in terms of computation and communication overhead.

Both client and server sides tests were conducted using a desktop computer equipped with an Intel Core i5-7400 CPU @ 3.00GHz × 4 and 16 GB RAM memory. The software development environment comprises Python 3.6.8/9. Paillier under Python is implemented using python-paillier library [20].

Client-side evaluation tests were conducted using generated random value vectors of different dimensions, which may represent various health-related input data used in PHM including motion signals, such as accelerometer and gyroscope measurements, and physiological parameters, such as photoplethysmography (PPG), electrocardiogram (ECG), and body temperature.

The client-side overhead is evaluated on the basis of tasks performed at both input and last layers. Efficiency is assessed as computation time, and exchanged data size.

Computation time in both client and server sides represents the average time of ten executions using pythonbenchmark library [41], while exchanged data size considers both sent and received data, and is calculated using the get_size() method from pysize library [22].

The client-side metrics are evaluated with respect to the following parameters: (number of inferences, input dimension, number of neurons at the last layer) for the computation overhead, and (number of inferences, number of neurons at the last layer) for the communication overhead (i.e., exchanged data size).
## 4.1 Effectiveness

Unlike differential privacy based solutions, PRIviLY allows to ensure both accuracy and privacy without making a trade-off between them. Moreover, unlike [17], PRIviLY does not employ encryption, allowing to avoid even the potential small impact on accuracy, which might be incurred during the encoding process of the partial homomorphic schemes.

Besides, the non-colluding two-server architecture of PRIviLY, does not affect the performance of the model as the process of inference remains the same, and is only divided between the two servers for privacy. Furthermore, the obfuscations employed in PRIviLY are fully reversible (as shown in Section 3.3), and therefore do not have any impact on the computations performed during the inference.

The above observations have been confirmed through experimental evaluation of PRIviLY, where the same accuracy as the non-private approach (i.e., with “zero”-accuracy loss) could be obtained by training different fully-connected deep networks, with different parameters and hyper-parameters.

## 4.2 Efficiency

### 4.2.1 Server-side efficiency

Tables 2 and 3 compare between [17] and PRIviLY in terms of the computation and communication tasks performed at the cloud and the intermediate servers respectively. The main tasks that improved the efficiency in PRIviLY are underlined, while extra tasks that are executed by a solution in comparison to the other are highlighted in gray. Moreover, in order to give a better insight of the difference between the two solutions, Tables 2 and 3 present an approximate comparison in terms of computation time and exchanged data size. Computation time is calculated on the basis of computation tasks and the evaluation results of basic operations benchmarked in Table 1, while exchanged data size is calculated on the basis of communication tasks. Noting that each computation task in Tables 2 and 3 is composed from one or more basic operations evaluated in Table 1.

Table 1 also presents the Paillier benchmark results described by the authors of [40], showing a higher Paillier extra overhead compared to our evaluation. However, these results are reported only for reference to show the considerable extra overhead that might be incurred by the Paillier scheme. Computation times presented in Tables 2 and 3 are only based on our own evaluation.

<table><caption>**Table 1** Basic operations comparison in terms of computation time: paillier scheme vs plain-text (1000 iterations, 2-digit numbers, paillier key-size=1024)</caption><thead><tr><th></th><th>Basic operation</th><th>Paillier (ms)</th><th>Plain-text (ms)</th><th>Ratio (times)</th></tr></thead><tbody><tr><td rowspan="7">Evaluation conducted</td><td>Addition</td><td>13.599</td><td>0.034</td><td>399.97</td></tr><tr><td>Subtraction</td><td>27.42</td><td>0.041</td><td>668.78</td></tr><tr><td>Division</td><td>-</td><td>0.035</td><td>-</td></tr><tr><td>Scalar addition</td><td>10.002</td><td>0.034</td><td>294.176</td></tr><tr><td>Scalar multiplication</td><td>9.176</td><td>0.037</td><td>248</td></tr><tr><td>Encryption</td><td>1602.729</td><td>-</td><td>42177.079/addition - 39090.951/subtraction</td></tr><tr><td>Decryption</td><td>404.139</td><td>-</td><td>10635.237/addition - 9857.049/subtraction</td></tr><tr><td rowspan="4">[40]</td><td>Addition</td><td>0.054</td><td>Addition ≈</td><td>30000</td></tr><tr><td>Subtraction</td><td>0.052</td><td>Subtraction ≈</td><td>28888</td></tr><tr><td>Encryption</td><td>18.882</td><td>Multiplication ≈</td><td>-</td></tr><tr><td>Decryption</td><td>18.865</td><td>0.0000018</td><td>-</td></tr></tbody></table>

Comparison and evaluation in Tables 2 and 3 are based on the MLP architecture described in Figure 5, and which comprises 1-neuron input, n-1 hidden fully-connected layers with m neurons, and 2-neurons output layer. For simplicity, and in order to directly leverage Table 1 results, all the calculations in Tables 2 and 3 are based on 2-digits numbers.

<figure><img src="image_5.png" /><figcaption>**Fig. 5** MLP architecture used for the server-side evaluation</figcaption></figure>
We can observe in Table 2 that CS tasks in [17] are performed over encrypted data, whereas CS in PRIViLY only deals with perturbed data, which is clearly more efficient as shown in Table 1. Moreover, two more tasks dealing with encrypted data are further needed in [17], although each of them is performed only once. Besides, two extra tasks performed on plain-text are required in PRIViLY. However, computation time evaluation shows that even with these extra tasks, PRIViLY still remains lightweight in comparison to [17] considering its overall encrypted-based tasks. In fact, as shown in Table 2 and Figure 6, PRIViLY incurs a minimum of 135 times less time than [17], depending on the size of the neural network.

As for the communication overhead, Table 2 shows that all the tasks in PRIViLY are performed over perturbed data. As a result, PRIViLY allows to mitigate the exchanged data size compared to [17] whose tasks are performed over encrypted data. It has been reported in [17] that perturbed data can be several tens of times smaller in size than encrypted data. Besides, three extra communication tasks are required in PRIViLY compared to [17]. However, even with these extra tasks, the exchanged data size in PRIViLY remains smaller than [17].

Table 2 shows the results for a single data of 1 byte, considering different ratios between the encrypted and perturbed versions of this data. For instance, for an encrypted data that is 10 times larger in size than the perturbed data, the overall size of the exchanged data in PRIViLY is from 4 to more than 5 times smaller than in [17], while if the size ratio between encrypted and perturbed data is 30 times, the exchanged data size improvement ratio varies from 12 to more than 15 times. Therefore, it is clear as shown in Figure 6, that the exchanged data size improvement ratio between the two solutions increases proportionally with the size ratio between encrypted and perturbed data.

<table><caption>**Table 2** Cloud server overhead comparison in terms of computation and communication tasks, computation time, and exchanged data size: [17] vs PRIViLY (n: total number of layers except input layer; m: number of neurons per hidden layer)</caption><thead><tr><th></th><th>HE-based solution [17]</th><th>PRIViLY</th></tr></thead><tbody><tr><td></td><td>(1) 1 x Remove v from encrypted data</td><td>(1) n x Compute m perturbed outputs</td></tr><tr><td></td><td>(2) n x Compute m encrypted outputs</td><td>(2) n-1 x Permute order of perturbed outputs vector of (of size m)</td></tr><tr><td rowspan="4">Comp</td><td>(3) n-1 x Permute order of encrypted outputs vector (of size m)</td><td>(3) n x Compute m obfuscated perturbation sums</td></tr><tr><td>(4) n-1 x Restore order of encrypted activated outputs vector (of size m)</td><td>(4) n-1 x Permute order of perturbation sums (of size m)</td></tr><tr><td>(5) 1 x Apply v on encrypted outputs of the last layer</td><td>(5) n-1 x Restore order of perturbed activated outputs (of size m)</td></tr><tr><td>(1) 1.6027/enc + 0.027/sub</td><td>(1) n * m * (m * 0.000037/smult + m * 0.000034/sadd)</td></tr><tr><td></td><td>(2) n * m * (m * 0.00917/smult + m * 0.01/sadd)</td><td>(2) n-1 * (m * 0.000037/smult + (m-1) * 0.000034/sadd)</td></tr><tr><td></td><td>(3) n-1 * (m * 0.00917/smult + (m-1) * 0.01/sadd)</td><td>(3) n * m * (m * 0.000037/smult + m * 0.000034/sadd)</td></tr><tr><td></td><td>(4) n-1 * (m * 0.00917/smult + (m-1) * 0.01/sadd)</td><td>(4) n-1 * (m * 0.000037/smult + (m-1) * 0.000034/sadd)</td></tr><tr><td></td><td>(5) 2 * 0.00917/smult</td><td>(5) n-1 * (m * 0.000037/smult + (m-1) * 0.000034/sadd)</td></tr><tr><td>CT (ms)</td><td>ct = 1.66804 + m(0.01917nm + 0.038356n - 0.038356) - 0.02n</td><td>ct = 0.000102 + m(0.000142nm + 0.000213n - 0.000213) - 0.000102n</td></tr><tr><td></td><td>n = m = 2</td><td>ct(17) = 1.858112</td><td>ct(PRIViLY) = 0.00146</td><td>improvement ratio = 1272.679 times</td></tr><tr><td></td><td>n = m = 10</td><td>ct(17) = 24.09008</td><td>ct(PRIViLY) = 0.160252</td><td>improvement ratio = 150.326 times</td></tr><tr><td></td><td>n = m = 100</td><td>ct(17) = 19549.39244</td><td>ct(PRIViLY) = 144.098602</td><td>improvement ratio = 135.666 times</td></tr><tr><td></td><td>n = m = 1000</td><td>ct(17) = 19208299.31204</td><td>ct(PRIViLY) = 142212.685102</td><td>improvement ratio = 135.067 times</td></tr><tr><td></td><td>n = m = 10000</td><td>ct(17) = 19173835018.108</td><td>ct(PRIViLY) = 142021296.850102</td><td>improvement ratio = 135.006 times</td></tr><tr><td></td><td colspan="4">PRIViLY incurs a minimum of 135 times less time than [17], depending on n and m.</td></tr><tr><td rowspan="6">Comm</td><td>• [First time] Receive v</td><td colspan="3">• [First time] Receive v.r</td></tr><tr><td>• 1 x Receive encrypted perturbed data</td><td colspan="3">• 1 x Receive perturbed data</td></tr><tr><td>• n-1 x Transmit m permuted encrypted outputs</td><td colspan="3">• n-1 x Transmit m permuted perturbed outputs</td></tr><tr><td>• n-1 x Receive m permuted encrypted activated outputs</td><td colspan="3">• n-1 x Transmit m permuted perturbation sums, n-1 x Receive u.r (of size m)</td></tr><tr><td>• 1 x Transmit perturbed encrypted outputs of the last layer</td><td colspan="3">• n-1 x Receive m permuted perturbed activated outputs</td></tr><tr><td>• 1 x Transmit perturbed encrypted outputs of the last layer</td><td colspan="3">• 1 x Transmit perturbed outputs of the last layer</td></tr><tr><td>ES</td><td colspan="4">Given r the ratio between encrypted and perturbed data*, es the exchanged data size, s = 1 byte - the size of a single data, es(17) = s + (s + s*m*2*(n-1) + s*2) * r = 1 + (1 + m*2*(n-1) + 2) * r = 1 + (2mn - 2m + 3) * r es(PRIViLY) = s + s + s*m*4*(n-1) + s*2 + s*m = 1 + 1 + m*4*(n-1) + 2 + m = 4 + 4mn - 4m + m = 4mn - 3m + 4 If r = 10, es(17) = 20mn - 20m + 31, then improvement ratio of es(17)/es(PRIViLY) ≈ 4 to 5+ times ∀m,n> = 2 If r = 20, es(17) = 40mn - 40m + 61, then improvement ratio of es(17)/es(PRIViLY) ≈ 8 to 10+ times ∀m,n> = 2</td></tr></tbody></table>
If $r = 30$, $es(17) = 60mn - 60m + 91$, then improvement ratio of $es(17)/es(PRIviLY) \approx 12$ to $15+ \text{ times } \forall m,n \ge 2$

**Comp:** Computation tasks; **Comm:** Communication tasks;

**CT:** approximate Computation Time; **value/op:** computation time per op; **ES:** approximate Exchanged data Size;

**enc:** encryption; **sub:** subtraction; **sadd:** scalar addition; **smult:** scalar multiplication

* Perturbed data can be thirty times smaller in size than encrypted data, as evaluated in [17], while it was reported in [42] that the size of an encrypted data in Paillier increases exponentially with the increase of the input data size.

<figure><img src="image_6.png" /><figcaption>**Fig. 6** Improvement (IMP) ratios at the cloud server in terms of computation time (CT) [left] and Exchanged data size (ES) [right] w.r.t. (number of layers – neurons/layer) and (ratio between encrypted and perturbed data) respectively</figcaption></figure>

On the other hand, Table 3 shows that unlike [17], where IS is in charge of almost all encryption/decryption operations, IS in PRIviLY, only performs plain-text operations, mostly related to perturbations. Specifically, two major tasks performed over encrypted data are replaced in PRIviLY with two tasks dealing with perturbed data which can be several tens of times smaller in size than their encrypted version [17]. Moreover, two more heavyweight tasks are required in [17], although each of them is performed only once. Besides, PRIviLY also requires two extra tasks. However, the overall computation tasks performed in PRIviLY still remain far lightweight compared to [17]. In fact, as shown in Table 3 and Figure 7, PRIviLY incurs a minimum of more than 10900 times less time than [17], depending on the size of the neural network.

As for the communication overhead, Table 3 shows that in PRIviLY all communication tasks are based on perturbed data. This theoretically helps mitigating the exchanged data size in comparison to [17], giving that perturbed data can be several tens of times smaller in size than encrypted data [17]. Besides, while two extra communication tasks are required in [17], PRIviLY requires three extra tasks, one of them is repeated at each layer. However, the evaluation results show that the size of exchanged data in PRIviLY remains smaller than [17]. In fact, as shown in Table 3 and Figure 7, the overall size of the exchanged data in PRIviLY can be 4 to more than 7 times smaller than that in [17] when the size ratio between encrypted and perturbed data is 10 times, while for a ratio of 30 times, the overall exchanged data size improvement ratio varies from 15 to more than 21 times.

<table><caption>**Table 3** Intermediate server overhead comparison in terms of computation and communication tasks, computation time, and exchanged data size: [17] vs PRIviLY (n: total number of layers except input layer; m: number of neurons per hidden layer)</caption><thead><tr><th></th><th>HE-based solution [17]</th><th>PRIviLY</th></tr></thead><tbody><tr><td rowspan="5">Comp</td><td>(1) 1 x Encrypt perturbed data</td><td>(1) n-1 x Remove r0/r from m perturbation sums</td></tr><tr><td>(2) n-1 x Decrypt m permuted outputs</td><td>(2) n-1 x <u>Remove perturbation sums from m permuted outputs</u></td></tr><tr><td>(3) n-1 x Apply m activation functions</td><td>(3) n-1 x Apply m activation functions</td></tr><tr><td>(4) n-1 x Encrypt m permuted activated outputs</td><td>(4) n-1 x <u>Perturb m permuted activated outputs</u></td></tr><tr><td>(5) 1 x Decrypt perturbed outputs of the last layer</td><td>(5) n-1 x Perturb u: u.r (of size m)</td></tr><tr><td rowspan="5">CT (ms)</td><td>(1) 1.6027/enc</td><td>(1) n-1 * m * 0.000035/div</td></tr><tr><td>(2) m * 0.404139/dec</td><td>(2) n-1 * m * 0.000041/sub</td></tr><tr><td>(3) -</td><td>(3) -</td></tr><tr><td>(4) n-1 * m * 1.6027/enc</td><td>(4) n-1 * m * 0.000034/sadd</td></tr><tr><td>(5) 2 * 0.404139/dec</td><td>(5) n-1 * m * 0.000037/smult</td></tr><tr><td></td><td>ct = 2.410978 + 1.6027nm - 1.198561m</td><td>ct = 0.000147nm - 0.000147m</td></tr><tr><td></td><td>n = m = 2</td><td>ct(17) = 6.424656</td><td>ct(PRIviLY) = 0.000294</td><td>improvement ratio = 21852.571 times</td></tr><tr><td></td><td>n = m = 10</td><td>ct(17) = 150.695368</td><td>ct(PRIviLY) = 0.01323</td><td>improvement ratio = 11390.428 times</td></tr><tr><td></td><td>n = m = 100</td><td>ct(17) = 15909.554878</td><td>ct(PRIviLY) = 1.4553</td><td>improvement ratio = 10932.147 times</td></tr><tr><td></td><td>n = m = 1000</td><td>ct(17) = 1601503.849978</td><td>ct(PRIviLY) = 146.853</td><td>improvement ratio = 10905.489 times</td></tr><tr><td></td><td>n = m = 10000</td><td>ct(17) = 160258016.800978</td><td>ct(PRIviLY) = 14698.53</td><td>improvement ratio = 10902.996 times</td></tr></tbody><tfoot><tr><td colspan="5">PRIviLY incurs a minimum of more than 10900 times less time than [17], depending on n and m.</td></tr></tfoot></table>

**Comm** • 1 x Receive perturbed data

• [First time] Receive r0
* 1 x Transmit encrypted perturbed data

* n-1 x Receive *m* permuted encrypted outputs

* n-1 x Transmit *m* permuted encrypted activated outputs

* 1 x Receive perturbed encrypted outputs of the last layer

* 1 x Transmit perturbed outputs of the last layer

* n-1 x Receive *m* permuted perturbed outputs

* n-1 x Receive *m* permuted perturbation sums

* n-1 x Share u.r (of size *m*)

* n-1 x Transmit *m* permuted perturbed activated outputs

* 1 x Share *r*

Given *r* the ratio between encrypted and perturbed data*, *es* the exchanged data size, *s* = 1 byte - the size of a single data,

$$ 
\begin{aligned}
es(17) &= s*3 + (s*3 + s*m*2*(n-1)) * r \\
&= 3 + (3 + m*2*(n-1)) * r = 3 + (2mn - 2m + 3) * r
\end{aligned}
 $$

ES

$$ 
\begin{aligned}
es(\text{PRIViLY}) &= s*2 + s*m*4*(n-1) \\
&= 2 + m*4*(n-1) = 2 + 4mn - 4m = 4mn - 4m + 2
\end{aligned}
 $$

If *r* = 10, *es*(17) = 20*mn* - 20* *m* + 33, then improvement ratio of *es*(17)/*es*(PRIViLY) ≈ 5 to 7+ times ∀*m*,*n*>=2

If *r* = 20, *es*(17) = 40*mn* - 40* *m* + 63, then improvement ratio of *es*(17)/*es*(PRIViLY) ≈ 10 to 14+ times ∀*m*,*n*>=2

If *r* = 30, *es*(17) = 60*mn* - 60* *m* + 93, then improvement ratio of *es*(17)/*es*(PRIViLY) ≈ 15 to 21+ times ∀*m*,*n*>=2

**Comp:** Computation tasks; **Comm:** Communication tasks;

**CT:** approximate Computation Time; **value/op:** computation time per *op*; **ES:** approximate Exchanged data Size;

**enc:** encryption; **dec:** decrypt; **sub:** subtraction; **div:** division; **sadd:** scalar addition; **smult:** scalar multiplication

* Perturbed data can be thirty times smaller in size than encrypted data, as evaluated in [17], while it was reported in [42] that the size of an encrypted data in Paillier increases exponentially with the increase of the input data size.

<figure><img src="image_7.png" /><figcaption>**Fig. 7** Improvement (IMP) ratios at the intermediate server in terms of computation time (CT) [left] and Exchanged data size (ES) [right] w.r.t. (number of layers – neurons/layer) and (ratio between encrypted and perturbed data) respectively</figcaption></figure>

### 4.2.2 Client-side efficiency

Tables 4 and 5 compare between the HE-based solution presented in [17] and PRIViLY solution proposed in this work, in terms of the computation and communication tasks performed at the client-side. The comparison is also made in terms of computation time and exchanged data size.

<table><caption>**Table 4** Client-side computation overhead comparison in terms of tasks and computation time: [17] vs PRIViLY</caption><thead><tr><th></th><th>HE-based solution [17]</th><th>PRIViLY</th><th></th></tr></thead><tbody><tr><td rowspan="5">Computation tasks</td><td>• 1 x Apply v on data</td><td>• [First time] Perturb v</td><td></td></tr><tr><td>• 1 x Remove v from outputs of the last layer</td><td>• 1 x Apply v on data</td><td></td></tr><tr><td>• 1 x Apply activation function of the last layer</td><td>• 1 x Remove r from perturbation sums, then remove them from last layer outputs</td><td></td></tr><tr><td></td><td>• 1 x Apply activation function of the last layer</td><td></td></tr><tr><td>• Input dimension (num. of vector values) [Number of inferences: 50 - Neurons at last layer: 2]</td><td></td><td></td></tr><tr><td rowspan="10">Computation time (in seconds) – average time of 10 executions)</td><td>○ 10</td><td>0.217</td><td>○ 10</td><td>0.272</td><td>• 25.34%</td></tr><tr><td>○ 100</td><td>0.229</td><td>○ 100</td><td>0.287</td><td>• 25.32%</td></tr><tr><td>○ 1000</td><td>0.254</td><td>○ 1000</td><td>0.313</td><td>• 23.22%</td></tr><tr><td>○ 10000</td><td>0.508</td><td>○ 10000</td><td>0.589</td><td>• 15.94%</td></tr><tr><td>○ 100000</td><td>2.802</td><td>○ 100000</td><td>3.395</td><td>• 21.16%</td></tr><tr><td colspan="5">Number of inferences – [Input dimension: 500 - Neurons at last layer: 2]</td></tr><tr><td>○ 1 inference</td><td>0.027</td><td>○ 1 inference</td><td>0.041</td><td>• 51.85%</td></tr><tr><td>○ 50 inferences</td><td>0.245</td><td>○ 50 inferences</td><td>0.304</td><td>• 24.08%</td></tr><tr><td>○ 100 inferences</td><td>0.496</td><td>○ 100 inferences</td><td>0.590</td><td>• 18.95%</td></tr><tr><td>○ 150 inferences</td><td>0.717</td><td>○ 150 inferences</td><td>0.908</td><td>• 26.63%</td></tr><tr><td>○ 200 inferences</td><td>0.908</td><td>○ 200 inferences</td><td>1.153</td><td>• 26.98%</td></tr><tr><td>○ 250 inferences</td><td>1.263</td><td>○ 250 inferences</td><td>1.476</td><td>• 16.86%</td></tr><tr><td>○ 300 inferences</td><td>1.471</td><td>○ 300 inferences</td><td>1.773</td><td>• 20.53%</td></tr></tbody></table>
<table><caption>Neurons at last layer - [Input dimension: 50 - Number of inferences: 50]</caption><tr><td>○ 1</td><td><b>0.212</b></td><td>○ 1</td><td><b>0.260</b></td><td>• 22.64%</td></tr><tr><td>○ 2</td><td><b>0.212</b></td><td>○ 2</td><td><b>0.266</b></td><td>• 25.47%</td></tr><tr><td>○ 4</td><td><b>0.219</b></td><td>○ 4</td><td><b>0.264</b></td><td>• 20.54%</td></tr><tr><td>○ 8</td><td><b>0.221</b></td><td>○ 8</td><td><b>0.261</b></td><td>• 18.09%</td></tr><tr><td>○ 16</td><td><b>0.222</b></td><td>○ 16</td><td><b>0.277</b></td><td>• 24.77%</td></tr><tr><td>○ 32</td><td><b>0.232</b></td><td>○ 32</td><td><b>0.283</b></td><td>• 21.98%</td></tr></table>

As shown in Table 4, the main difference, in terms of tasks, between PRIviLY and [17] consists of perturbing $v$ (which is only required once, i.e. the first time), and clearing up the perturbation sums before their removal from the last layer output.

<figure><img src="image_8.png" /><figcaption>Fig. 8 Client-side computation overhead comparison of additional overhead percentage w.r.t. potential impacting parameters</figcaption></figure>

Evaluation of the overall performed tasks, as presented in Table 4 and Figure 8, shows that PRIviLY requires up to about 51% more computation time than [17] during the 1st inference, then the additional overhead percentage decreases to vary between about 16% to at most 27% starting from the 2nd inference. Besides, input dimension and number of neurons of the last layer do not show any impact on the comparison ratio, which varies in the range of 18% - 25%.

<table><caption>Table 5 Client-side communication overhead comparison in terms of tasks and exchanged data size: [17] vs PRIviLY</caption><thead><tr><th></th><th>HE-based solution [17]</th><th>PRIViLY</th><th></th></tr></thead><tbody><tr><td>Communication tasks</td><td><ul><li>[First time] Privately share v</li><li>1 x Transmit perturbed data</li><li>1 x Receive perturbed outputs of the last layer</li></ul></td><td><ul><li>[First time] Privately share : r0 and v.r</li><li>1 x Transmit perturbed data</li><li>1 x Receive perturbed outputs of the last layer, and r</li><li>1 x Receive perturbation sums of the last layer</li></ul></td><td></td></tr><tr><td>Exchanged data size (bytes)</td><td><table><thead><tr><th colspan="2">Number of inferences - [Input dimension: 50 - Neurons at last layer: 2]</th><th colspan="2">Additional overhead percentage</th></tr></thead><tbody><tr><td>○ 1 inference</td><td>560+736 = 1296</td><td>○ 1 inference</td><td>17.28%</td></tr><tr><td>○ 50 inferences</td><td>560+36800 = 37360</td><td>○ 50 inferences</td><td>26.83%</td></tr><tr><td>○ 100 inferences</td><td>560+73600 = 74160</td><td>○ 100 inferences</td><td>27%</td></tr><tr><td>○ 150 inferences</td><td>560+110400 = 110960</td><td>○ 150 inferences</td><td>27.05%</td></tr><tr><td>○ 200 inferences</td><td>560+147200 = 147760</td><td>○ 200 inferences</td><td>27.08%</td></tr><tr><td>○ 250 inferences</td><td>560+184000 = 184560</td><td>○ 250 inferences</td><td>27.10%</td></tr><tr><td>○ 300 inferences</td><td>560+220800 = 221360</td><td>○ 300 inferences</td><td>27.11%</td></tr><tr><td>○ 1M inferences</td><td>560+736M = 736,560M</td><td>○ 1M inferences</td><td>27.15%</td></tr></tbody></table></td><td></td></tr><tr><td></td><td><table><thead><tr><th colspan="2">Neurons at last layer - [Number of inferences: 50 - Input dimension: 50]</th><th colspan="2">Additional overhead percentage</th></tr></thead><tbody><tr><td>○ 1</td><td>560+34800 = 35360</td><td>○ 1</td><td>22.69%</td></tr><tr><td>○ 2</td><td>560+36800 = 37360</td><td>○ 2</td><td>26.39%</td></tr><tr><td>○ 4</td><td>560+37600 = 38160</td><td>○ 4</td><td>28.36%</td></tr><tr><td>○ 8</td><td>560+39200 = 39760</td><td>○ 8</td><td>31.24%</td></tr><tr><td>○ 16</td><td>560+42400 = 42960</td><td>○ 16</td><td>36.36%</td></tr><tr><td>○ 32</td><td>560+48800 = 49360</td><td>○ 32</td><td>44.61%</td></tr><tr><td>○ 100</td><td>560+76000 = 76560</td><td>○ 100</td><td>64.29%</td></tr></tbody></table></td><td></td></tr></tbody></table>

As for the communication overhead, Table 5 shows that two extra data exchanges with the client-side are required in PRIviLY, namely, sharing initial obfuscation random value (which is only required once, i.e. the first time), and the reception of perturbation sums along with the obfuscation value at the last layer.
<figure><img src="image_9.png" /><figcaption>Fig. 9 Client-side communication overhead comparison of additional overhead percentage w.r.t. potential impacting parameters</figcaption></figure>

As shown in Figure 9, the exchanged data size of PRIviLY at the client-side incurs a small extra overhead, where the percentage of additional overhead starts increasing from about 17% in the 1st inference until it reaches and stabilizes around 27% starting from the 50th inference.

Besides, evaluation results shows that the number of neurons at the last layer has a higher impact on the exchanged data size. This is mainly due to the extra communication task performed in PRIviLY, i.e., the reception of perturbation sums, and which appears to rapidly grow in size when the number of neurons increases. However, we believe that DL-based applications generally rely on a low number of neurons at the last layer. In our evaluation results, a percentage of additional overhead less than or equal to 31.24% is observed for up to 8 neurons and could remain under 45% for up to almost 32 neurons.

Consequently, PRIviLY provides a lower overhead at the server-side compared to [17], which allows to alleviate hardware requirements, especially for the intermediate server, while it can maintain an overhead at the client-side that is close to that of [17], successfully meeting the efficiency requirements of PHM environment, including the limited power and computation capabilities of client devices, and the unreliability of some networks and potentially high communication costs.

## 4.3 Privacy

The target aim is to ensure four privacy goals, namely, the protection of input data, intermediate results, and inferences, and the protection of model as best as possible.

### 4.3.1 Privacy guarantees

Table 6 compares between [17] and PRIviLY in terms of privacy ensured for the different sensitive information to protect.

The comparison shows that input data, last layer outputs and inferences are primarily not shared with IS in PRIviLY, which is the best method to keep them private.

Besides, encryption-based privacy preservation against CS is replaced by perturbation protection, whose effectiveness is shown in Section 4.3.3.

<table><caption>Table 6 Privacy guarantees comparison: [17] vs PRIviLY</caption><thead><tr><th></th><th>Privacy guarantees – From> technique</th><th>PRIviLY</th></tr></thead><tbody><tr><td><strong>Sensitive information</strong></td><td><strong>HE-based solution [17]</strong></td><td><strong>PRIviLY</strong></td></tr><tr><td>Input data</td><td>CS> encryption - IS> perturbation</td><td>CS> perturbation - IS> not shared</td></tr><tr><td>Intermediate results</td><td>CS> encryption - IS> permutation</td><td>CS> perturbation - IS> permutation</td></tr><tr><td>Last layer outputs</td><td>CS> encryption - IS> perturbation</td><td>CS> perturbation - IS> not shared</td></tr><tr><td>Inferences</td><td>CS> encryption - IS> not accessible</td><td>CS> perturbation - IS> not shared</td></tr><tr><td><strong>Model</strong></td><td></td><td></td></tr><tr><td>• Parameters</td><td>• Client> not shared – IS> not shared</td><td>• Client> not shared – IS> not shared</td></tr><tr><td>• Number of layers and neurons</td><td>• Client> not shared – IS> dissimulation</td><td>• Client> not shared – IS> dissimulation</td></tr><tr><td>• Activation functions</td><td>• Client> last one shared – IS> dissimulation</td><td>• Client> last one shared – IS> dissimulation</td></tr></tbody></table>

### 4.3.2 Attack resiliency analysis

In order to further demonstrate the privacy preservation effectiveness provided by PRIviLY, we present in this section an analysis of the potential attacks that can be launched at the different levels of the inference process. To that end, we first summarize in Table 7 the different information stored or received at each entity, and
differentiate between data perceived and not perceived. Recall that PRIviLY assumes an honest-but-curious (HbC) adversary model where the parties are honest in the way that they follow the protocol, but they are curious in the way that they may try to deduce private information within the limits of what the protocol allows [16].

<table><caption>**Table 7** Information stored/received at each entity in PRIviLY</caption><thead><tr><th>Entity</th><th>Information perceived</th><th>Information not perceived</th></tr></thead><tbody><tr><td>Client</td><td>Input data - Last layer outputs and inferences (including number/type of outputs and activation function method used) - Initial/Last random obfuscation values - Initial reversible random perturbation</td><td>-</td></tr><tr><td>Cloud server</td><td>Model parameters and structure - Reversible random permutations</td><td>Input data - Reversible random perturbations - Intermediate results - Last layer outputs</td></tr><tr><td>Intermediate server</td><td>Random obfuscation values - Reversible random perturbations (except initial one)</td><td>Intermediate results</td></tr></tbody></table>

We illustrate in the following how the techniques used by PRIviLY allows to protect the different sensitive information from the adversaries who may try to get access from the different components of the system during the inference process. To that end, we analyze five main attacks<fnref n="2" /> covering attacks on the server-side, and attacks on communications between client and servers and between servers themselves. In these scenarios, we assume either insecure communication channels or compromised security measures, indicating potential vulnerabilities or unauthorized access.

* Attack on the Cloud server

We suppose that the adversary could get access to data stored/received at the Cloud server, including model parameters, input data, intermediate results generated during the inference process, and last layer outputs.

In such a scenario, stolen data cannot be exploited by the adversary in any way. In fact, input data is received obfuscated at the Cloud server, and intermediate results as well as layer last outputs are consequently obfuscated too. Moreover, these sensitive information cannot be deobfuscated by the Cloud server level since the reversible random perturbation vectors are also obfuscated.

Besides, even if the adversary accesses the model parameters and tries to run it on the obfuscated input, it cannot infer the final prediction or classification results since the activation functions cannot be applied unless the input is deobfuscated, which could be only performed by the Intermediate server.

* Attack on the Intermediate server

We suppose that the adversary could get access to data stored/received at the Intermediate server, mainly including the intermediate results.

In such a scenario, stolen data cannot be exploited by the adversary in any way since the intermediate results received at the Intermediate server are obfuscated by permutation.

Besides, the actual model structure is dissimulated from the Intermediate server by the Cloud server through adding fake layers and neurons, and providing fake activation functions among actual ones.

* Attack on Communication between Cloud server and Intermediate server

We suppose that the adversary could intercept the traffic between the Cloud and Intermediate servers (Man-in-the-Middle attack). Data exchanged between the two servers mainly include the intermediate results.

In such a scenario, stolen data cannot be exploited by the adversary in any way. In fact, intermediate results of hidden layers intercepted between the Cloud and Intermediate servers are doubly protected during transmission using random vector and permutation matrix.

As for the model structure, fake layers and neurons, as well as fake activation functions are exchanged between Cloud and Intermediate servers, which confuses the adversary about the actual model structure details.

* Attack on communication between Client and Cloud server

<footnote n="2">² Inspired from the attacks described in [16], but with some modifications to remain within the HbC adversary model.</footnote>
We suppose that the adversary could intercept the traffic between the Client and Cloud server (Man-in-the-Middle attack). Data exchanged include input data, initial reversible random perturbation, last layer outputs, and last activation function method.

In such a scenario, stolen data cannot be exploited by the adversary in any way. In fact, input data, initial reversible perturbation and last layer outputs are transmitted obfuscated.

Besides, because the adversary has no knowledge about the last layer outputs, it cannot exploit the last activation function method in order to reveal the inference.

## Attack on communication between Intermediate server and Client

We suppose that the adversary could intercept the traffic between the Client and Intermediate server (Man-in-the-Middle attack). Data exchanged include initial and last random obfuscation values.

In such a scenario, stolen data cannot be exploited by the adversary in any way. In fact, the adversary cannot intercept the random obfuscation values as they are shared between the Client and Intermediate server in a private manner using special mechanisms like Diffie-Hellman exchange method.

### 4.3.3 Reversible obfuscations effectiveness

Figures 10–11 illustrate the effectiveness of random mask and basic permutation matrix perturbations in obfuscating sensitive data, followed by an illustrative example of the advanced permutation-based obfuscation.

Figures 10 and 11 show the application of random mask obfuscations on a row entry of the “Pima Indians Diabetes” dataset, and an image from “MNIST” dataset respectively.

<table><caption>Fig. 10 Random 8-dim vector applied on a row entry of the “Pima Indians Diabetes” dataset [17]</caption><tr><td>Original data D:</td><td>[ 1. 85. 66. 29. 0. 26.6 0.351 31. ]</td></tr><tr><td>Random vector V:</td><td>[-3.72, 0.85, -9.27, -3.31, 9.73, 8.5, 4.32, -8.79]</td></tr><tr><td>Perturbed data D+V:</td><td>[-2.72 85.85 56.73 25.69 9.73 35.1 4.671 22.21 ]</td></tr></table>

<figure><img src="image_10.png" /></figure>

<figure><img src="image_11.png" /><figcaption>Fig. 11 28x28 random mask applied on an image from “MNIST” dataset (original – perturbed) [17]</figcaption></figure>

Figure 12 shows the application of basic permutation matrix on an image resulting from the “MNIST” dataset.

<figure><img src="image_12.png" /><figcaption>Fig. 12 26x26 basic permutation matrix (left) applied on a 26x26 image (original – perturbed)–(right) [17]</figcaption></figure>

Lastly, the below example illustrates the application of the advanced permutation-based obfuscation:

Let $n = 2$, $d = [1 2 3]$, and $p = [2 6 5]$, i.e., the 1st element is moved to the 2nd position, the 2nd element is moved to the 6th position, and so on.

### Application of permutation

1. multiply dimension of $d$: $d = [1 2 3 \text{ null null null}]$
2. Reorder *d* according to *p*: d = [null 1 null null 3 2]
3. Fill *d* with random values: d = [4 1 3 6 3 2]

Removal of permutation

1. Restore order of *d* using *p*: d = [1 2 3 6 null null]

2. Restore dimension of d: d = [1 2 3]

5. Related work

The privacy-preserving deep-learning-based remote inference solutions are generally based on the following four main key concepts [15]:

* Secure Multiparty Computation (SMC) [25, 48], where the deep network is executed jointly between two servers in a way that preserves sensitive input data privacy.

* Transformation [31, 32], where input data is first transformed locally in order to obfuscate sensitive information, before it is transmitted to the cloud server. Generative adversarial networks based obfuscations are generally used.

* Model splitting [25], where the inference task is performed collaboratively between the client-side and server-side environments, through splitting the deep network into a local partition and a remote partition, which are executed by the client and the server respectively. In order to avoid recovering input data from the output of the local part, methods like dropout and step-wise activation functions are used.

* Homomorphic encryption (HE) [37], where the deep network is executed on HE-based encrypted data, which allows to perform linear computations without prior decryption.

As shown in Table 8, conventional solutions based on the above-described key concepts, present a number of limitations with respect to PHM environment constraints and requirements.

In SMC-based solutions [23–25], two servers are deployed to host the deep learning model partially or completely, which represents a model privacy concern. Furthermore, the introduction of HE by some solutions [37, 38] increases the client-side overhead, while solutions approximating activation functions [38] may suffer from accuracy loss. As for model splitting [26–29] and transformation-based solutions [30–32], a trade-off between accuracy and data privacy is made, while the client-side overhead depends on the local network or partition. Moreover, inferences in the earlier-mentioned concepts are not protected. Lastly, HE-based conventional solutions [33–35] present limitations in terms of client-side efficiency, as they are generally characterized by high client-side computation and communication overhead. Besides, some HE-based solutions [39] need to approximate activation functions by polynomials, which may lead to accuracy loss [25, 36].

<table><caption>Table 8. Performance of concept-based conventional solutions w.r.t. PHM requirements</caption><thead><tr><th>Concept-based conventional solutions</th><th>Client-side overhead</th><th>Accuracy</th><th>Privacy</th></tr></thead><tbody><tr><td>SMC</td><td>low | high<sup>a</sup></td><td>high | potential loss<sup>b</sup></td><td>model hosted by two different servers</td></tr><tr><td>Transformation</td><td>depends on local network</td><td>trade-off</td><td>- trade-off<br/>- inferences not protected</td></tr><tr><td>Model splitting</td><td>depends on local partition</td><td>trade-off</td><td>- trade-off<br/>- inferences not protected</td></tr><tr><td>HE</td><td>high</td><td>high | potential loss<sup>b</sup></td><td>Ensured</td></tr></tbody></table>

- main limitations are in italic

a if homomorphic encryption is used [37, 38]

b if activation functions are approximated [39]

Among the above-presented concepts, HE shows promising performance as it ensures both effectiveness and privacy. Therefore, some recent efforts have been directed towards improving conventional HE-based solutions in terms of efficiency, which allowed to better leverage the performance of HE in constrained client-side environments.
<table><caption>**Table 9.** Reviewed enhanced HE-based solutions meeting PHM requirements</caption><thead><tr><th>Solution</th><th>Client-side overhead</th><th>Accuracy</th><th>Privacy</th></tr></thead><tbody><tr><td>[16]</td><td>not fully mitigated</td><td>high</td><td>intermediate results not protected</td></tr><tr><td>[17]</td><td>low</td><td>high</td><td>Ensured</td></tr></tbody></table>

- main limitations are in italic

Baryalai et al. [16] and Boulemtafes et al. [17] followed this direction and adopted HE-based solutions with a non-colluding two-server architecture in order to reduce the burden on the client-side and provide better effectiveness. In Table 9, we compare the two solutions with respect to the main PHM requirements. The two solutions can successfully retain high effectiveness, with a potential small accuracy loss due to the encoding process used in the adopted Paillier scheme. However, intermediate results in [16] are not protected and the client overhead is not fully mitigated. In contrast, all sensitive data in [17] could be protected, while the client overhead is efficiently mitigated.

<table><caption>**Table 10.** PRIviLY vs Reviewed enhanced HE-based solutions</caption><thead><tr><th>Solution</th><th>Client-side overhead</th><th>Server-side overhead</th><th>Accuracy</th><th>Privacy</th></tr></thead><tbody><tr><td>[16]</td><td>[cryptographic operations] – not fully mitigated</td><td>[cryptographic-based operations] – high</td><td>high</td><td>intermediate results not protected</td></tr><tr><td>[17]</td><td>[no cryptographic operations] – low</td><td>[cryptographic-based operations] – high</td><td>high</td><td>ensured</td></tr><tr><td>PRIviLY</td><td>[no cryptographic operations] – low (close to [17])</td><td>[encryption-free] – mitigated</td><td>“zero” / loss</td><td>ensured</td></tr></tbody></table>

- main limitations are in italic

- main advantages of PRIviLY are underlined

As shown in Table 10, and differently from [16] and [17], PRIviLY is an encryption-free solution, that ensures the following:

* Specifically, but effectively, targets FCDNs, including MLP and some DAE and DBN models.

* Achieves “zero” accuracy loss, avoiding even the potential small loss incurred by encoding process in Paillier HE scheme.

* Provides a better efficiency at the server-side, which allows to alleviate hardware requirements especially for the intermediate server.

## 6. Conclusion

In this paper, we have proposed PRIviLY, an encryption-free privacy-preserving solution for remote inference over cloud-based fully connected deep networks (FCDN) in the context of pervasive health monitoring (PHM) applications. The aim is to ensure privacy of the different sensitive information and deep learning model, while ensuring an effectiveness with “zero” accuracy loss, and meeting efficiency requirements of the target environment.

To that end, PRIviLY adopts a non-colluding two-server architecture, and leverages the linearity of weighted sums of FCDN to introduce reversible random mask perturbations, supported by reversible random permutations.

Performances analysis showed that PRIviLY can ensure privacy of sensitive information and deep learning model with “zero” accuracy loss, avoiding even the potential small loss incurred by homomorphic encryption-based solutions. PRIviLY is also able to provide a lower overhead at the server-side compared to [17], allowing to alleviate hardware requirements especially for the intermediate server, while it is close to [17] in terms of the client-side efficiency.

PRIviLY showed a minimum improvement ratio of 135 times in terms of computation overhead, and an improvement ratio comprised between 4 to more than 15 times in terms of communication at the cloud server compared to [17]. Additionally, an improvement ratio of more than 10900 times in terms of computation overhead is observed at the intermediate server, while in terms of communication, the improvement ratio varies
between 5 to more than 21 times. As for the client-side efficiency, PRIviLY showed lower performance compared to [17] but with only a small additional overhead percentage of about 27% in terms of communication, and between 16% and at most 27% in terms of computation overhead.

As PRIviLY currently addresses FC deep networks, it would be interesting as future work to investigate the feasibility of the solution over other popular deep networks architectures, particularly those used in PHM applications, such as CNN and RNN networks.

**Data availability** The datasets “MNIST” and “Pima Indians Diabetes” used to demonstrate reversible obfuscations effectiveness are publicly accessible in “Wolfram Data” Repository (https://doi.org/10.24097/wolfram.62081.data) and “Replication Data for: Pima Indians Diabetes” (https://doi.org/10.7910/DVN/XFOZQR) respectively.

## References

[1] Primanita, A. “Computing Games and Its Implication to Measuring Playing Experience”. Doctoral dissertation, Iida Laboratory, Japan Advanced Institute of Science and Technology.

[2] Wan, Z. (2020). “Scalable and Analog Neuromorphic Computing Systems”, Doctoral dissertation, UCLA.

[3] Nadeem, M. A., & Lee, S. U. J. (2020). Machine Learning Evaluation of the Requirement Engineering Process Models for Cloud Computing and Security Issues. *Applied Sciences, 10*(17), 5851.

[4] Cheng, J., Chen, M., Li, C., Liu, Y., Song, R., Liu, A., & Chen, X. (2020). Emotion recognition from multi-channel eeg via deep forest. *IEEE Journal of Biomedical and Health Informatics*.

[5] Ramsundar, B., & Zadeh, R. B. (2018). *TensorFlow for deep learning: from linear regression to reinforcement learning*. “O’Reilly Media, Inc.”.

[6] Wan, S., Liang, Y., Zhang, Y., & Guizani, M. (2018). Deep multi-layer perceptron classifier for behavior analysis to estimate parkinson’s disease severity using smartphones. *IEEE Access, 6*, 36825-36833.

[7] Daily Activity Recognition with Large-Scaled Real-Life Recording Datasets Based on Deep Neural Network Using Multi-Modal Signals 2018

[8] A Wristocracy Deep Learning on Wrist-worn Sensing for Recognition of User Complex Activities 2015

[9] Amroun, H., Temkit, M. H., & Ammi, M. (2017, June). Dnn-based approach for recognition of human activity raw data in non-controlled environment. In 2017 IEEE International Conference on AI & Mobile Services (AIMS) (pp. 121-124). IEEE.

[10] Alfian, G., Syafrudin, M., Anshari, M., Benes, F., Atmaji, F. T. D., Fahrurrozi, I., ... & Rhee, J. (2020). Blood glucose prediction model for type 1 diabetes based on artificial neural network with time-domain features. *Biocybernetics and Biomedical Engineering, 40*(4), 1586-1599.

[11] Sannino, G., & De Pietro, G. (2018). A deep learning approach for ECG-based heartbeat classification for arrhythmia detection. *Future Generation Computer Systems, 86*, 446-455.

[12] Radha, M., de Groot, K., Rajani, N., Wong, C. C., Kobold, N., Vos, V., ... & Aarts, R. M. (2018). Wrist-worn blood pressure tracking in healthy free-living individuals using neural networks. *arXiv preprint arXiv:1805.09121*.

[13] Nunavath, V., Goodwin, M., Fidje, J. T., & Moe, C. E. (2018, September). Deep Neural Networks for Prediction of Exacerbations of Patients with Chronic Obstructive Pulmonary Disease. In *International Conference on Engineering Applications of Neural Networks* (pp. 217-228). Springer, Cham.

[14] Hassantabar S, Stefano N, Ghanakota V, Ferrari A, Nicola GN, Bruno R, Marino IR, Jha NK. Coviddeep: Sars-cov-2/covid-19 test based on wearable medical sensors and efficient neural networks. arXiv preprint arXiv:2007.10497. 2020 Jul 20.

[15] Boulemtafes, A., Derhab, A., & Challal, Y. (2020). “A review of privacy-preserving techniques for deep learning”. *Neurocomputing, 384*, 21-45.

[16] M. Baryalai, J. Jang-Jaccard, and D. Liu, “Towards privacy-preserving classification in neural networks,” *2016 14th Annual Conference on Privacy, Security and Trust (PST)*, 2016.
[17] Boulemtafes, A., Derhab, A., Ait Ali Braham, N., & Challal, Y. (2023). Privacy-preserving remote deep-learning-based inference under constrained client-side environment. *Journal of Ambient Intelligence and Humanized Computing*, 14(1): 553-566.

[18] Shrestha, A., & Mahmood, A. (2019). Review of deep learning algorithms and architectures. *IEEE Access*, 7, 53040-53065.

[19] Brualdi, R. A. (2006). Combinatorial matrix classes (Vol. 13). Cambridge University Press.

[20] data61/python-paillier: A library for Partially Homomorphic Encryption in Python (2021). In: GitHub. https://github.com/data61/python-paillier (Last access: 12/4/2022).

[22] bosswissam/pysize: Measure size of memory object in python. In: GitHub. https://github.com/bosswissam/pysize (Last access: 12/4/2022).

[23] Huang K, Liu X, Fu S, Guo D, Xu M. A lightweight privacypreserving CNN feature extraction framework for mobile sensing. IEEE Transactions on Dependable and Secure Computing. 2019.

[24] Ma X, Chen X, Zhang X. Non-interactive privacy-preserving neural network prediction. Inf Sci. 2019;481:507-19.

[25] Li, M., Chow, S. S., Hu, S., Yan, Y., Shen, C., & Wang, Q. (2020). Optimizing privacy-preserving outsourced convolutional neural network predictions. *IEEE Transactions on Dependable and Secure Computing*, 19(3), 1592-1604.

[26] Osia SA, Shamsabadi AS, Sajadmanesh S, Taheri A, Katevas K, Rabiee HR, Lane ND, Haddadi H. A hybrid deep learning architecture for privacy-preserving mobile analytics. *IEEE Internet of Things J.* 2020;7(5):4505-18.

[27] Chi J, Owusu E, Yin X, Yu T, Chan W, Tague P, Tian Y. Privacy partitioning: Protecting user data during the deep learning inference phase. arXiv preprint arXiv:1812.02863. 2018. arXiv preprint.

[28] Yu CH, Chou CN, Chang E. Distributed layer-partitioned training for privacy-preserved deep learning. In 2019 IEEE Conference on Multimedia Information Processing and Retrieval (MIPR) 2019 Mar 28 (pp. 343-346). IEEE.

[29] Dong H, Wu C, Wei Z, Guo Y. Dropping activation outputs with localized first-layer deep network for enhancing user privacy and data security. IEEE Transactions on Information Forensics and Security. 2017 Oct 17;13(3):662-70.

[30] Leroux S, Verbelen T, Simoens P, Dhoedt B. Privacy aware ofloading of deep neural networks. 2018. arXiv preprint.

[31] Raval N, Machanavajjhala A, Pan J. Olympus: Sensor Privacy through Utility Aware Obfuscation. Proceedings on Privacy Enhancing Technologies. 2019;2019(1):5-25.

[32] Xu, D., Zheng, M., Jiang, L., Gu, C., Tan, R., & Cheng, P. (2020). Lightweight and unobtrusive data obfuscation at IoT edge for remote inference. *IEEE Internet of Things Journal*, 7(10), 9540-9551.

[33] Gilad-Bachrach R, Dowlin N, Laine K, Lauter K, Naehrig M, Wernsing J. Cryptonets: Applying neural networks to encrypted data with high throughput and accuracy. In International conference on machine learning 2016

[34] Chabanne H, De Wargny A, Milgram J, Morel C, Prouf E. Privacy-preserving classification on deep neural network. Cryptology ePrint Archive. 2017.

[35] Zhu Q, Lv X. 2p-dnn: Privacy-preserving deep neural networks based on homomorphic cryptosystem. arXiv preprint arXiv:1807.08459. 2018. arXiv preprint.

[36] Boulemtafes, A., Derhab, A. & Challal, Y. Privacy-preserving deep learning for pervasive health monitoring: a study of environment requirements and existing solutions adequacy. *Health Technol.* 12, 285-304 (2022). https://doi.org/10.1007/s12553-022-00640-3

[37] Vizitiu A, Niță CI, Puiu A, Suciu C, Itu LM. Towards privacy-preserving deep learning based medical imaging applications. In 2019 IEEE International Symposium on Medical Measurements and Applications (MeMeA) 2019 Jun 26 (pp. 1-6). IEEE.
[38] Ma X, Chen X, Zhang X. Non-interactive privacy-preserving neural network prediction. Inf Sci. 2019;481:507-19.

[39] Hesamifard E, Takabi H, Ghasemi M. Cryptodl: Deep neural networks over encrypted data. arXiv preprint 2017.

[40] Sidorov, V., Wei, E. Y. F., & Ng, W. K. (2022). Comprehensive Performance Analysis of Homomorphic Cryptosystems for Practical Data Processing. *arXiv preprint arXiv:2202.02960*.

[41] Karlheinzniebuhr/pythonbenchmark: A simple Python Benchmark Library (2017). In: GitHub. https://github.com/Karlheinzniebuhr/pythonbenchmark (Last access: 12/4/2022).

[42] Shahzadi Farah et al. (2012), "An Experimental Study on Performance Evaluation of Asymmetric Encryption Algorithms", Recent Advances in Information Science, Proceeding of the 3rd European Conf. of Computer Science, (EECS-12).

[43] Boulemtafes, A., Khemissa, H., Derki, M. S., Amira, A., & Djedjig, N. (2021). Deep learning in pervasive health monitoring, design goals, applications, and architectures: An overview and a brief synthesis. *Smart Health, 22*, 100221.

[44] Zheng, Y., Duan, H., & Wang, C. (2018). Learning the truth privately and confidently: Encrypted confidence-aware truth discovery in mobile crowdsensing. *IEEE Transactions on Information Forensics and Security*, 13(10), 2475-2489.

[45] Qiu, G., Huo, H., Gui, X., & Dai, H. (2022). Privacy-Preserving Outsourcing Scheme for SVM on Vertically Partitioned Data. *Security and Communication Networks*, 2022.

[46] D. Zhang, X. Chen, D. Wang, and J. Shi, "A Survey on Collaborative Deep Learning and Privacy-Preserving," *2018 IEEE Third International Conference on Data Science in Cyberspace (DSC)*, 2018.

[47] S. Chang and C. Li, "Privacy in Neural Network Learning: Threats and Countermeasures," *IEEE Network*, vol. 32, no. 4, pp. 61-67, 2018.

[48] Melanson, D., Maia, R., Kim, H. S., Nascimento, A., & De Cock, M. (2023). Secure Multi-Party Computation for Personalized Human Activity Recognition. *Neural Processing Letters*, 1-27.

[49] Reffad, H., Djenaoui, A., & Alti, A. (2020). Distributed Secure Services Based on IoT and Blockchain for e-Health Remote Care. In *Conference Proceedings ICCSA'2021* (p. 1).

[50] Sujith, A. V. L. N., Sajja, G. S., Mahalakshmi, V., Nuhmani, S., & Prasanalakshmi, B. (2022). Systematic review of smart health monitoring using deep learning and Artificial intelligence. *Neuroscience Informatics, 2*(3), 100028.