1 Introduction

With the exponential growth of data, deep learning has been rapidly developed in many fields, such as natural language processing [1], autonomous driving [2], and medical diagnosis [3]. In deep learning, a large amount of data is collected, which is used to train a powerful and accurate model. However, these collected data might include some sensitive information [4,5,6]. For example, in e-healthcare systems, the users’ health data include sensitive information. If these health data are directly uploaded to the cloud server for training and prediction, the users’ sensitive data and health status will be ineluctably leaked to the cloud server.

Federated learning is an effective technology to solve the privacy problem of user data [7,8,9]. In federated learning, when training a neural network model, the users only require to upload the local gradients obtained through local training to the cloud server, instead of uploading and sharing their original data. The cloud server is able to obtain a global model by aggregating the gradients uploaded by the users. However, a lot of researches have shown that even if the users’ training data is not required to be uploaded to the cloud server, the cloud server is still able to infer the private training data based on the shared local gradients [10,11,12]. To protect the users’ privacy, plenty of privacy-preserving federated learning schemes have been proposed [13,14,15,16,17]. Bonawitz et al. [18] designed a privacy-preserving federated learning scheme by using secure multi-party computation technique. Phong et al. [19] constructed a federated learning scheme supporting privacy protection, in which the gradients are encrypted by using two homomorphic encryption technologies. Jia et al. [20] adopted differential privacy technology to achieve users’ privacy protection in federated learning. In the above schemes, the cloud server can carry out the gradient aggregation without exposing the privacy of the users’ local gradients.

Another important issue in federated learning is the verification of the correctness of the aggregated result [21, 22]. In practice, to reduce computation overhead, a “lazy” cloud server may not aggregate all gradients sent by the users [23]. Even worse, a malicious cloud server may generate and return an incorrect aggregated gradient to the users for the sake of impacting the model updates [24]. To solve the above problems, Xu et al. [4] proposed a verifiable and privacy-preserving federated learning scheme. This scheme is able to guarantee the privacy of user data by masking the local gradients and verifying the correctness of the aggregated result by using the homomorphic hash function. However, if the malicious users collude with the cloud server, they can launch the brute force attack to recover the users’ local gradients. Hahn et al. [11] proposed a federated learning scheme supporting verifiability and privacy preserving, which can resist brute force attacks. Nevertheless, this scheme is vulnerable to replay attacks in the verification phase, in which the cloud server may use the previous aggregated gradient to trick the users into passing the verification.

In this paper, we propose a privacy-preserving federated learning scheme with verifiability (PPFLV), which is able to resist replay attacks.

Contribution: Our contributions can be summarized as follows:

  1. 1.

    We design a novel double gradient verification method, which can resist replay attacks. With the two aggregated encrypted gradients returned by the cloud server, the users only need to perform the lightweight calculation to check whether the cloud server correctly aggregates the users’ gradients. The users are able to recover the aggregated gradient from the aggregated encrypted gradients. Furthermore, by employing this verification method, the cloud server cannot successfully pass the verification with the previous or wrong aggregated gradients.

  2. 2.

    We design an efficient double gradient blinding and encryption method to blind and encrypt the users’ local gradients, which is compatible with our designed verification method. We use the secret sharing technique to share the users’ private keys and noise. The correctness of these secret shares can be verified by employing the verification technology based on discrete logarithms. In addition, when the users are offline or the network is delayed, the online users can recover the offline users’ private keys and the online users’ noises, while the correctness of the aggregated gradient can still be guaranteed.

  3. 3.

    We provide the security analysis and performance evaluation of the proposed PPFLV. The security analysis demonstrates that the proposed PPFLV satisfies correctness, gradient privacy, immunity from replay attack and unforgeability. The experiment results show that the proposed PPFLV has high accuracy and is efficient in terms of gradient encryption, gradient aggregation and verification.

Organization: The rest of this paper is organized as follows. Section 2 shows the related works. In Sect. 3, we introduce the system model and the threat model. In Sect. 4, We present the preliminaries for PPFLV. In Sect. 5, we present the construction of the proposed PPFLV. We give the security analysis and performance evaluation of the proposed PPFLV in Sects. 6 and 7, respectively. We conclude the paper in Sect. 8.

2 Related work

In recent years, federated learning has been used in a wide range of industries. Privacy preserving and verifiability of aggregated results in federated learning have received considerable attention. In federated learning, the cloud server can recover the users’ private data based on the local gradients uploaded by the users. To protect user data privacy, plenty of privacy-preserving federated learning schemes [25,26,27,28,29] have been proposed. Privacy-preserving federated learning focuses on protecting users’ data privacy and preventing users from exposing sensitive data. Phong et al. [19] used Paillier homomorphic encryption technology and LWE homomorphic encryption technology to encrypt gradients for achieving privacy protection. Tang et al. [30] proposed a robust privacy-preserving federated learning scheme that protects the privacy of local gradients and global models. Based on ElGamal multiplicative homomorphic encryption technology, Fang et al. [31] put forward a privacy-preserving federated learning scheme, in which the gradients of the participants can be protected. Using homomorphic encryption technology, the encrypted gradients still can be aggregated. Jia et al. [20] and Wei et al. [32] utilized differential privacy to protect users’ data privacy in federated learning. In these two schemes [20, 32], the noise is added to the gradients to achieve differential privacy. By combining secure multi-party computing with differential privacy technology, Mugunthan et al. [33] designed a federated learning scheme supporting privacy-preserving. Zhou et al. [34] introduced a trusted blinding server to blind the gradient ciphertexts and constructed a privacy-preserving federated learning scheme. The problem of collusion between the cloud server and the users can be solved in this scheme. Bonawitz et al. [18] put forward a federated learning scheme with privacy protection by using secret sharing. In this scheme, secure multi-party computation technology is utilized to calculate the sums of model parameters. The above schemes can realize the users’ privacy protection and gradient aggregation, but they cannot guarantee the correctness of the aggregated results.

To verify the correctness of aggregated gradient generated by the cloud server, many verifiable federated learning schemes [16, 35,36,37,38] have been proposed. Xu et al. [4] utilized homomorphic hash function to check the correctness of aggregated gradients. Peng et al. [39] constructed a verifiable federated learning scheme based on blockchain, which is able to optimize the training process in federated learning by using the reward mechanism of blockchain. In this scheme, the verifiable proofs are recorded in the blockchain. Fu et al. [21] adopted Lagrange interpolation to achieve the verification of aggregated gradients and used Chinese remainder theorem to reduce communication overhead. Zhang et al. [24] utilized bilinear aggregate signature to construct a federated learning scheme supporting secure verification. In this scheme, the participants can check whether the aggregation server correctly aggregates the gradients uploaded by the participants. Guo et al. [40] also considered the problem of aggregated gradient verification, and used homomorphic hash to guarantee the correctness of the aggregated gradient. Xu et al. [41] put forward a non-interactive verifiable federated learning scheme, which introduces two servers to aggregate the gradients. In this scheme, the users are able to verify the correctness of aggregated gradient by cross-authentication. Hahn et al. [11] proposed a double aggregation approach to complete the verification of aggregated gradient. Only lightweight primitives are used in this scheme, which improves the computational efficiency of verification. However, this scheme cannot resist replay attacks. The cloud server can pass the verification of the participants by using the previous aggregated gradient. Thus, it is meaningful to explore a privacy-preserving and verifiable federated learning scheme with efficient encryption and verification while resisting replay attacks.

3 System model and threat model

3.1 System model

The system model of PPFLV is shown in Fig. 1. It consists of three kinds of entities: cloud server, user group and KGC (Key Generation Center).

Fig. 1
figure 1

System model

  • Cloud server: The cloud server is in charge of aggregating the encrypted gradients sent by users. The cloud server generates and sends the aggregated encrypted gradients to each user in the group. The aggregated encrypted gradients are used to verify whether the cloud server performs the aggregation operation correctly.

  • User group: A user group consists of multiple users. The users train the model locally, encrypt the local gradients, and send the encrypted gradients to the cloud server. After receiving the aggregated encrypted gradients sent by the cloud server, the users can check the correctness of aggregated encrypted gradients. If the aggregated encrypted gradients are correct, the users can calculate the aggregated gradient and update the model.

  • KGC: KGC is responsible for initializing the model parameters of the neural network, and generating system parameters and public-private key pairs for the users.

3.2 Threat model

In our threat model, KGC is a trustworthy entity and does not collude with the users and the cloud server. The users are regarded as an honest-but-curious entity. They honestly perform the specified procedures based on the agreed agreement, but are curious about other users’ data privacy. The cloud server is considered to be a malicious entity. The cloud server may attempt to infer the data privacy of all users. The cloud server may also perform incomplete aggregation operation, and falsify the wrong aggregated encrypted gradients or use the previous aggregated encrypted gradient to deceive the users.

4 Preliminaries

In this section, we introduce the preliminaries such as Shamir’s secret sharing, authenticated encryption and key agreement.

4.1 Shamir’s secret sharing

In Shamir’s t-out-of-n secret sharing technique [42], a secret value \(\tau\) is split into n shares, where n indicates the total number of shares and t is the threshold. The secret value \(\tau\) can be reconstructed by more than t shares. The Shamir’s secret sharing protocol consists of the following algorithms:

  1. 1.

    \(ShamirS.share(\tau ,t,U)\rightarrow {{\tau }_{i}}\): The secret share algorithm takes as input the secret value \(\tau\), a user group U with logical identities \([0,1,\ldots ,n-1]\) and the threshold t \((t<n)\), and outputs the secret share \({{\tau }_{i}}\) for each member \({{U}_{i}}\) \((i\in [0,n-1])\).

  2. 2.

    \(ShamirS.recon({{\left\{ {{\tau }_{i}} \right\} }_{i\in \mu }},t)\rightarrow \tau\): The secret reconstruction algorithm takes as input a set of secret shares \(\{{{\tau }_{i}}|i\in \mu ,\mu \subseteq [0,n-1]\}\) and the threshold t \((t<n)\), and outputs a secret value \(\tau\).

4.2 Authenticated encryption

Authenticated encryption (AE) is a symmetric encryption algorithm, in which the encryption key and the decryption key are the same. AE is used to ensure the confidentiality and integrity of user data [43]. The algorithms of AE are as follows:

  1. 1.

    \(AE.gen\left( \lambda \right) \rightarrow \kappa\): Taking the key space \(\lambda\) as input, this algorithm samples a secret key \(\kappa\) randomly and uniformly from the key space \(\lambda\).

  2. 2.

    \(AE.enc\left( m,\kappa \right) \rightarrow c\): Taking the secret key \(\kappa\) and the plaintext m as input, this algorithm outputs the ciphertext c.

  3. 3.

    \(AE.dec(c,\kappa )\rightarrow m\): Taking the secret key \(\kappa\) and a ciphertext c as input, this algorithm outputs the plaintext m.

4.3 Key agreement

Diffie-Hellman key agreement [44] is used in our PPFLV to generate the shared encryption key of AE for any two users. Let \(\mathbb {G}\) be a group with prime order q and g be the generator of the group \(\mathbb {G}\). The Diffie-Hellman key agreement consists of the following algorithms:

  1. 1.

    \(KA.gen(g,q,\mathbb {G})\rightarrow (S{{K}_{i}},P{{K}_{i}})\): This algorithm takes a generator g, the order q and the group \(\mathbb {G}\) as input, and outputs the secret key \(S{{K}_{i}}\) and the public key \(P{{K}_{i}}={{g}^{S{{K}_{i}}}}\).

  2. 2.

    \(KA.agree(S{{K}_{i}},P{{K}_{j}})\rightarrow {{\alpha }_{i,j}}\): This algorithm takes the secret key \(S{{K}_{i}}\) of the user \(U_i\) and the public key \(P{{K}_{j}}\) of the user \(U_j\) as input, and output the shared encryption key \({{\alpha }_{i,j}}\). In our PPFLV, the shared encryption key \({{\alpha }_{i,j}}\) is calculated as follows: \({{\alpha }_{i,j}}=H({{P{{K}_{j}}}^{S{{K}_{i}}}})\), where \(H:\mathbb {G}\rightarrow \mathbb {Z}_{q}^{*}\) is cryptographic hash function. Note that \({{\alpha }_{i,j}}={{\alpha }_{j,i}}\).

5 The proposed scheme

5.1 Overview

The main idea of our proposed scheme is to achieve the verifiability of aggregated gradient on the basis of privacy protection. To achieve privacy protection, we design a novel double gradient blinding and encryption method to blind and encrypt the users’ local gradients. The user \({{U}_{i}}\) \((i\in [0,n-1])\) blinds the local gradient \({{\omega }_{i}}\) as \({{a}_{i}}={{\omega }_{i}}+{{\pi }_{{{s}_{1}}}}(R)\) and \({{b}_{i}}={{\omega }_{i}}\cdot {{\pi }_{{{s}_{1}}}}(R)\) under a pseudo-random function \({{\pi }_{{{s}_{1}}}}(\cdot )\), where R is the current iteration number. The user \({{U}_{i}}\) \((i\in [0,n-1])\) uses his private key \(S{{K}_{i}}\) and the user \({{U}_{j}}\)’s \((j\in [0,n-1],j\equiv i(\bmod 2),j\ne i)\) public key \(P{{K}_{j}}\) to compute a secret value \({{\alpha }_{i,j}}=KA.agree(S{{K}_{i}},P{{K}_{j}})\). Note that \({{\alpha }_{i,j}}={{\alpha }_{j,i}}\). The user \({{U}_{i}}\) \((i\in [0,n-1])\) utilizes \({{\alpha }_{i,j}}\) to calculate a random vector \({{F}_{{{s}_{2}}}}({{\alpha }_{i,j}} ||R)\) under a pseudo-random function \({{F}_{{{s}_{2}}}}(\cdot )\), then encrypts the blinded gradients \({{a}_{i}}\) and \({{b}_{i}}\) as follows:

$$\begin{aligned}&\begin{aligned} {{\hat{a}}_{i}}=&{{a}_{i}}+\sum \limits _{j\equiv i(\bmod 2),j>i}{{{F}_{{{s}_{2}}}}({{\alpha }_{i,j}} ||R)}- \sum \limits _{j\equiv i(\bmod 2),j<i}{{{F}_{{{s}_{2}}}}({{\alpha }_{i,j}} ||R)} \end{aligned} \\&\begin{aligned} {{\hat{b}}_{i}}=&{{b}_{i}}+\sum \limits _{j\equiv i(\bmod 2),j>i}{{{F}_{{{s}_{2}}}}({{\alpha }_{i,j}} ||R)}- \sum \limits _{j\equiv i(\bmod 2),j<i}{{{F}_{{{s}_{2}}}}({{\alpha }_{i,j}} ||R)} \end{aligned} \end{aligned}$$

In the encrypted gradients \({{\hat{a}}_{i}}\), \({{\hat{a}}_{j}}\) \((j\equiv i(\bmod 2),j>i)\), the random vectors \({{F}_{{{s}_{2}}}}({{\alpha }_{i,j}} ||R)\) and \({{F}_{{{s}_{2}}}}({{\alpha }_{j,i}} ||R)\) respectively generated by the users \({{U}_{i}}\) and \({{U}_{j}}\) can cancel each other out. In the encrypted gradients \({{\hat{b}}_{i}}\), \({{\hat{b}}_{j}}\) \((j\equiv i(\bmod 2),j>i)\), the random vectors \({{F}_{{{s}_{2}}}}({{\alpha }_{i,j}} ||R)\) and \({{F}_{{{s}_{2}}}}({{\alpha }_{j,i}} ||R)\) respectively generated by the users \({{U}_{i}}\) and \({{U}_{j}}\) can also cancel each other out. If the cloud server is able to successfully receive the encrypted gradients from all users, the cloud sever aggregates the encrypted gradients as follows:

$$\begin{aligned}{} & {} \sum \limits _{i\in [0,n-1],i\equiv 0(\bmod 2)}{{{{\hat{a}}}_{i}}}+\sum \limits _{i\in [0,n-1],i\equiv 1(\bmod 2)}{{{{\hat{a}}}_{i}}}=\sum \limits _{i\in [0,n-1]}{{{a}_{i}}},\\{} & {} \sum \limits _{i\in [0,n-1],i\equiv 0(\bmod 2)}{{{{\hat{b}}}_{i}}}+\sum \limits _{i\in [0,n-1],i\equiv 1(\bmod 2)}{{{{\hat{b}}}_{i}}}=\sum \limits _{i\in [0,n-1]}{{{b}_{i}}}. \end{aligned}$$

Based on the aggregated encrypted gradients \(\sum \limits _{i\in [0,n-1]}{{{a}_{i}}}\) and \(\sum \limits _{i\in [0,n-1]}{{{b}_{i}}}\), each user \({{U}_{i}}\) \((i\in [0,n-1])\) is able to obtain the aggregated gradient through the equation:

$$\begin{aligned} \sum \limits _{i\in [0,n-1]}{{{a}_{i}}}-|n |\cdot {{\pi }_{{{s}_{1}}}}(R)=\sum \limits _{i\in [0,n-1]}{{{b}_{i}}}\cdot \frac{1}{{{\pi }_{{{s}_{1}}}}(R)}=\sum \limits _{i\in [0,n-1]}{{{\omega }_{i}}}. \end{aligned}$$

However, in practice, not all users send the gradients to the cloud server. There are some users who go offline due to external factors [18]. When some users are offline, the online users cannot obtain the correct aggregated gradient since the random vectors added in the encrypted gradients of offline users cannot be cancelled out. To solve the user offline problem, we use the secret sharing technique to share the private keys of all users. We set the identity set of all online users to \({{I}_{online}}\) and the identity set of all offline users to \({{I}_{offline}}=\{0,1,...,n-1\}-{{I}_{online}}\). Each user \({{U}_{i}}\) \((i\in [0,n-1])\) utilizes the secret sharing technique to share his private key \(S{{K}_{i}}\) to other users in the group. If the user \({{U}_{j}}\) \((j\in {{I}_{offline}})\) is offline during the training process, the cloud server can recover the offline users \({{U}_{j}}\) \((j\in {{I}_{offline}})\)’ private keys \(S{{K}_{j}}\) \((j\in {{I}_{offline}})\) based on the secret shares provided by more than t users. Then the cloud server can calculate the secret values \({{\alpha }_{j,v}}=KA.agree(S{{K}_{j}},P{{K}_{v}})\) \((j\in {I}_{offline}, v\in [0,n-1],v\equiv j(\bmod 2),v\ne j)\) based on the recovered private keys \(S{{K}_{j}}\) \((j\in {{I}_{offline}})\) of the offline users \({{U}_{j}}\) \((j\in {{I}_{offline}})\) and the public keys \(P{{K}_{v}}\) \((v\in [0,n-1],v\equiv j(\bmod 2),v\ne j)\) of the users \({{U}_{v}}\) \((v\in [0,n-1],v\equiv j(\bmod 2),v\ne j)\). In this way, the cloud server is able to recover the random vectors \({{F}_{{{s}_{2}}}}({{\alpha }_{j,v}} ||R)\) \((j\in {{I}_{offline}},v\in [0,n-1],v\equiv j(\bmod 2),v\ne j)\) and removed these random vectors from \(\sum \limits _{i\in [0,n-1]}{{{a}_{i}}}\) and \(\sum \limits _{i\in [0,n-1]}{{{b}_{i}}}\) during the aggregation process.

Although the above method can solve the user offline problem, there is still network latency issue. Due to network latency, there are some users who did not upload the encrypted gradients to the cloud server on time [4]. This incurs that the cloud server identifies these users with network latency as offline users. The cloud server recovers the private keys of these users, calculates the corresponding secret values, and recovers the random vectors. Once these users with network latency successfully upload the encrypted gradients to the cloud server, the cloud server may be able to correctly recover these users’ local gradients by canceling out the random vectors.

To solve the problem of network latency, we add a noise \({{\beta }_{i}}\) in the encrypted gradients \({{\hat{a}}_{i}}\), \({{\hat{b}}_{i}}\) \((i\in [0,n-1])\). Each user \({{U}_{i}}\) \((i\in [0,n-1])\) utilizes the secret sharing technique to share the noise \({{\beta }_{i}}\) to other users in the group. The encrypted gradients \(a_{i}'\), \(b_{i}'\) \((i\in [0,n-1])\) are computed as follows: \(a_{i}'={{\hat{a}}_{i}}+{{F}_{{{s}_{2}}}}({{\beta }_{i}})\) and \(b_{i}'={{\hat{b}}_{i}}+{{F}_{{{s}_{2}}}}({{\beta }_{i}})\). Using the above method, the users’ local gradients will not be leaked to the cloud server. Meanwhile, the users still can obtain the correct aggregated gradient. After receiving the encrypted gradients from the online users, the cloud server recovers the noises \({{\beta }_{i}}\) \((i\in {{I}_{online}})\) and the private keys \(S{{K}_{j}}\) \((j\in {{I}_{offline}})\) based on the secret shares provided by more than t users. With the recovered private keys \(S{{K}_{j}}\) \((j\in {{I}_{offline}})\) of the offline users \({{U}_{j}}\) \((j\in {{I}_{offline}})\) and the public keys \(P{{K}_{v}}\) \((v\in [0,n-1],v\equiv j(\bmod ) 2,v\ne j)\) of the user \({{U}_{v}}\) \((v\in [0,n-1],v\equiv j(\bmod ) 2,v\ne j)\), the cloud server can compute the secret values \({{\alpha }_{j,v}}=KA.agree(S{{K}_{j}},P{{K}_{v}})\) \((j\in {{I}_{offline}}, v\in [0,n-1],v\equiv j(\bmod ) 2,v\ne j)\) and recovers the random vectors \({{F}_{{{s}_{2}}}}({{\alpha }_{j,v}}||R)\) \((j\in {{I}_{offline}}, v\in [0,n-1],v\equiv j(\bmod ) 2,v\ne j)\). The cloud server performs the aggregation operation as below:

$$\begin{aligned}&\begin{aligned} A=&\sum \limits _{i\in {{I}_{online}}}{{{a}_{i}'}}-\sum \limits _{i\in {{I}_{online}}}{{{F}_{{{s}_{2}}}}({{\beta }_{i}})}\\&-\sum \limits _{j\in {{I}_{offline}},v\in [0,n-1],v\equiv j(\bmod 2),v>j}{{{F}_{{{s}_{2}}}}({{\alpha }_{j,v}} ||R)}\\&+\sum \limits _{j\in {{I}_{offline}},v\in [0,n-1],v\equiv j(\bmod 2),v<j}{{{F}_{{{s}_{2}}}}({{\alpha }_{j,v}} ||R)} \end{aligned}\\&\begin{aligned} B=&\sum \limits _{i\in {{I}_{online}}}{{{b}_{i}'}}-\sum \limits _{i\in {{I}_{online}}}{{{F}_{{{s}_{2}}}}({{\beta }_{i}})}\\&-\sum \limits _{j\in {{I}_{offline}},v\in [0,n-1],v\equiv j(\bmod 2),v>j,}{{{F}_{{{s}_{2}}}}({{\alpha }_{j,v}} ||R)}\\&+\sum \limits _{j\in {{I}_{offline}},v\in [0,n-1],v\equiv j(\bmod 2),v<j}{{{F}_{{{s}_{2}}}}({{\alpha }_{j,v}} ||R)} \end{aligned} \end{aligned}$$

As a result, the cloud server can remove the random vectors \({{F}_{{{s}_{2}}}}({{\beta }_{i}})\) \((i\in {{I}_{online}})\) of the online users and the random vectors \({{F}_{{{s}_{2}}}}({{\alpha }_{j,v}} ||R)\) \((j\in {{I}_{offline}},v\in [0,n-1],v\equiv j(\bmod 2))\) of the offline users during the aggregation phase. The users can obtain the correct aggregated encrypted gradients. Based on the aggregated encrypted gradients, the users can compute the aggregated gradient.

To verify the correctness of aggregated encrypted gradients, we design a novel double gradient verification method. Inspired of VerSA [11], we use the current iteration round number to verify the correctness of aggregated encrypted gradients to resist replay attacks. In VerSA [11], the user u computes \(\alpha = \sum \nolimits _{v\in \mu }{{{s}_{u,v}}}\), where \(\mu\) is the set of current online users and \({{s}_{u,v}}\) \((v\in \mu )\) are the secret values negotiated by the user u with other users. Then the user u calculates two vectors \(a=PRG(\alpha ||0)\) and \(b=PRG(\alpha ||1)\). The user u uses a and b to encrypt the local gradient \({{x}_{u}}\) and obtain a model verification code \(F({{x}_{u}})=a\circ {{x}_{u}}+b\). Each user u sends the masked gradient \(y_{u}\) and the model verification code \(F({{x}_{u}})\) to the cloud server. The cloud server respectively aggregates \({{y}_{u}}\) and \({F({{x}_{u}})}\) to obtain the aggregated gradient \(z=\sum \nolimits _{u\in \mu }{{{y}_{u}}}\) and the aggregated model verification code \(z'=\sum \nolimits _{u\in \mu }{F({{x}_{u}})}\). The cloud server returns z and \(z'\) to all users. Each user can verify the correctness of the aggregated gradient z by checking whether the equation \(z'=a\circ z+|\mu |\cdot b\) holds. However, when the online users involved in two iterations are the same, \(\alpha\) remains consistent. Consequently, the verification parameters a and b also remain unchanged. This implies that the cloud server could exploit the previous aggregated gradient z and its corresponding aggregated model verification code \(z'\) to deceive the users into passing the verification.

To resist replay attack, we use the current iteration round number R to blind and encrypt the local gradients. Consequently, the aggregated encrypted gradients A and B contain the iteration round number R. In the verification phase, the cloud server utilizes the current iteration round number R to verify the correctness of aggregated encrypted gradients A and B. Thus, the cloud server cannot use the previous aggregated encrypted gradients to pass the verification.

5.2 Description of the proposed scheme

Our proposed scheme contains the following four phase: initialization phase, training phase, aggregation phase, and verification and update phase. In the initialization phase, KGC initializes the model parameters of the neural network, then generates security parameters and public/private key pairs for users. KGC sends the corresponding public/private key pair to each user. Each user utilizes the secret sharing technique to share his private key and the noise to other users in the group. In the training phase, each user trains the neural network by using his local dataset. Then each user blinds the local gradient, encrypts the blinded gradients, and sends the encrypted gradients to the cloud server. In the aggregation phase, the cloud server aggregates the encrypted gradients sent by the users and sends the aggregated encrypted gradients to all online users. In the verification and update phase, after receiving the aggregated encrypted gradients from the cloud server, the online users verify the correctness of the aggregated encrypted gradients. If the aggregated encrypted gradients can pass the verification, the users recover the aggregated gradient from the aggregated encrypted gradients and locally updates the trainable parameters. The specific flow is shown in Fig. 2.

Fig. 2
figure 2

Architecture of the PPFLV

  1. 1.

    Initialization phase

    1. (a)

      KGC initializes the model parameter W of the neural network and setups the learning rate \(\eta\) based on the neural network architecture negotiated by the users. KGC generates two public-private key pairs \(\left( P{{K}_{i}},S{{K}_{i}} \right)\), \(\left( sp{{k}_{i}},ss{{k}_{i}} \right)\) and a noise \({{\beta }_{i}}\) for each user \({{U}_{i}}\) \((i\in [0,n-1])\). The first public-private key pair \(\left( P{{K}_{i}},S{{K}_{i}} \right)\) \((i\in [0,n-1])\) is utilized to generate the secret value, and the second public-private key pair \(\left( sp{{k}_{i}},ss{{k}_{i}} \right)\) \((i\in [0,n-1])\) is used to encrypt the secret shares of the private key. KGC also generates two secret seeds \({{s}_{1}}\), \({{s}_{2}}\in \mathbb {Z}_{q}^{*}\) and two pseudo-random functions \({{\pi }_{{{s}_{1}}}}(\cdot )\) and \({{F}_{{{s}_{2}}}}(\cdot )\). The secret seed \({{s}_{1}}\) is used to blind the local gradients and verify the correctness of aggregated encrypted gradients. The secret seed \({{s}_{2}}\) is used to encrypt the blinded gradients.

    2. (b)

      KGC sends the secret seeds \({{s}_{1}}\), \({{s}_{2}}\) and the public-private key pairs \(\left( P{{K}_{i}},S{{K}_{i}} \right)\), \(\left( sp{{k}_{i}},ss{{k}_{i}} \right)\) to each user \({{U}_{i}}\) \((i\in [0,n-1])\) and publishes the pseudo-random functions \({{\pi }_{{{s}_{1}}}}(\cdot )\) and \({{F}_{{{s}_{2}}}}(\cdot )\). KGC sends the secret seed \({{s}_{2}}\) to the cloud server.

    3. (c)

      Each user \({{U}_{i}}\) \((i\in [0,n-1])\) sends his public key \(\left( P{{K}_{i}},sp{{k}_{i}} \right)\) and the identity i to the cloud server and other users in the group U.

    4. (d)

      Each user \({{U}_{i}}\) \((i\in [0,n-1])\) chooses a random polynomial

      $$\begin{aligned} {{h}_{i}}(x)=S{{K}_{i}}+\sum \nolimits _{d=1}^{t-1}{{{\rho }_{i,d}}}{{x}^{d}}\bmod q \ ({{\rho }_{i,d}}\in \mathbb {Z}_{q}^{*}) \end{aligned},$$
      (1)

      where \({{\rho }_{i,d}}\) \((d\in [1,t-1])\) are the random values used to generate the random polynomial \(h_{i}(x)\) and the commitment values. The user \({{U}_{i}}\) \((i\in [0,n-1])\) caculates his private key \(S{{K}_{i}}\)’s secret share \(S{{K}_{i,j}}={{h}_{i}}(j)\) \((j\in [0,n-1],j\ne i)\), then generates and publishes the commitment values \({{g}^{S{{K}_{i}}}}\) and \({{g}^{{{\rho }_{i,d}}}}\) \((d\in [1,t-1])\). The user \({{U}_{i}}\) \((i\in [0,n-1])\) selects the other random polynomial

      $$\begin{aligned} {{f}_{i}}(x)={{\beta }_{i}}+\sum \nolimits _{d=1}^{t-1}{{{\delta }_{i,d}}}{{x}^{d}}\bmod q \ ({{\delta }_{i,d}}\in \mathbb {Z}_{q}^{*}) \end{aligned},$$
      (2)

      where \({\delta }_{i,d}\) \((d\in [1,t-1])\) are the random values used to generate the random polynomial \(f_{i}(x)\) and the commitment values. The user \({{U}_{i}}\) \((i\in [0,n-1])\) computes the noise \({{\beta }_{i}}\)’s secret share \({{\beta }_{i,j}}={{f}_{i}}(j)\) \((j\in [0,n-1])\), then generates and publishes the commitment values \({{g}^{{{\beta }_{i}}}}\) and \({{g}^{{{\delta }_{i,d}}}}\) \((d\in [1,t-1])\).

    5. (e)

      The user \({{U}_{i}}\) \((i\in [0,n-1])\) encrypts his secret shares \(S{{K}_{i,j}}\) \((j\in [0,n-1],j\ne i)\) and \({{\beta }_{i,j}}\) \((j\in [0,n-1],j\ne i)\) in the authenticated encryption manner:

      $$\begin{aligned} \begin{aligned} {{c}_{i,j}}&\leftarrow AE.enc(KA.agree(sp{{k}_{j}},ss{{k}_{i}}),S{{K}_{i,j}}\Vert i\Vert j) \\ c_{i,j}'&\leftarrow AE.enc(KA.agree(sp{{k}_{j}},ss{{k}_{i}}),\beta _{i,j}\Vert i\Vert j) \end{aligned} \end{aligned}$$

      The user \({{U}_{i}}\) \((i\in [0,n-1])\) sends the ciphertexts \({{c}_{i,j}}\) \((j\in [0,n-1],j\ne i)\) and \(c_{i,j}'\) \((j\in [0,n-1],j\ne i)\) to the cloud server. The cloud server broadcasts \(\{{{c}_{i,j}},c_{i,j}'|i\in [0,n-1],i\ne j\}\) to each user \({{U}_{j}}\) in the group.

    6. (f)

      After receiving the ciphertexts \({{c}_{i,j}}\), \(c_{i,j}'\) \((i\in [0,n-1],i\ne j)\) from the cloud server, each user \({{U}_{j}}\) \((j\in [0,n-1])\) respectively decrypts the ciphertexts \({{c}_{i,j}}\) and \(c_{i,j}'\) as follows:

      $$\begin{aligned} \begin{aligned} S{{K}_{i,j}}&\leftarrow AE.dec(KA.agree(sp{{k}_{i}},ss{{k}_{j}}),{{c}_{i,j}}\Vert i\Vert j) \\ {{\beta }_{i,j}}&\leftarrow AE.dec(KA.agree(sp{{k}_{i}},ss{{k}_{j}}),c_{i,j}'\Vert i\Vert j) \end{aligned} \end{aligned}$$

      The user \({{U}_{j}}\) \((j\in [0,n-1])\) verifies whether the secret shares \(S{{K}_{i,j}}\) \((i\in [0,n-1],i\ne j)\) and \({{\beta }_{i,j}}\) \((i\in [0,n-1],i\ne j)\) are correct by following the equations:

      $$\begin{aligned} {{g}^{S{{K}_{i,j}}}}={{g}^{S{{K}_{i}}}}\prod \nolimits _{d=1}^{t-1}{{{({{g}^{{{\rho }_{i,d}}}})}^{{{j}^{d}}}}} \end{aligned}$$
      (3)

      and

      $$\begin{aligned} {{g}^{{{\beta }_{i,j}}}}={{g}^{{{\beta }_{i}}}}\prod \nolimits _{d=1}^{t-1}{{{({{g}^{{{\delta }_{i,d}}}})}^{{{j}^{d}}}}} \end{aligned}$$
      (4)

      If the equations (3), (4) hold, the user \({{U}_{j}}\) believes \(S{{K}_{i,j}}\) \((i\in [0,n-1],i\ne j)\) and \({{\beta }_{i,j}}\) \((i\in [0,n-1],i\ne j)\) are correct. The user \({{U}_{j}}\) \((j\in [0,n-1])\) stores the secret shares \(S{{K}_{i,j}}\) and \({{\beta }_{i,j}}\) from the users \({{U}_{i}}\) \((i\in [0,n-1],i\ne j)\).

  2. 2.

    Training phase

    1. (a)

      Each user \({{U}_{i}}\) \((i\in [0,n-1])\) trains the neural network with his local dataset \({{D}_{i}}={{\{<{{x}_{l}},{{y}_{l}}>\}}_{l\in [1,K]}}\) and computes the local gradient \({{\omega }_{i}}\). The user \({{U}_{i}}\) computes the loss function in the R-th iteration as follows:

      $$\begin{aligned} {{L}_{\varphi }}(D_{i}',W)=\frac{1}{|D_{i}'|}\sum \limits _{({{x}_{l}},{{y}_{l}})\in D_{i}'}C(\varphi (x_l, W), y_l) \end{aligned}$$

      where \(\varphi ()\) represents neural network, W represents trainable parameters in \(\varphi ()\), \(D_{i}'\) is the subset of \({{D}_{i}}\), and C() represents the criterion to compute the discrepancy between the network’s output \(\varphi (x_l, W)\) and the label data \(y_l\). The user \({{U}_{i}}\) computes the local gradient \({{\omega }_{i}}=\nabla {{L}_{\varphi }}(D_{i}',W)\), where \(\nabla\) denotes the vector differential operator.

    2. (b)

      Algorithm 1 describes the processes of gradient blinding and encryption. To protect privacy, the user \({{U}_{i}}\) \((i\in [0,n-1])\) uses the secret seed \({{s}_{1}}\) to blind the local gradient \({{\omega }_{i}}\) as \({{a}_{i}}={{\omega }_{i}}+{{\pi }_{{{s}_{1}}}}(R)\) and \({{b}_{i}}={{\omega }_{i}}\cdot {{\pi }_{{{s}_{1}}}}(R)\) under a pseudo-random function \({{\pi }_{{{s}_{1}}}}(\cdot )\), where R is the current iteration number. The user \({{U}_{i}}\) \((i\in [0,n-1])\) computes the secret value \({{\alpha }_{i,j}}=KA.agree(S{{K}_{i}},P{{K}_{j}})\) with his private key \(S{{K}_{i}}\) and the public key \(P{{K}_{j}}\) of the user \({{U}_{j}}\) \((j\in [0,n-1],j\equiv i(\bmod 2),j\ne i)\). Note that \({{\alpha }_{i,j}}=\alpha _{j,i}^{{}}\). Based on the noise \({{\beta }_{i}}\), the secret value \({{\alpha }_{i,j}}\) \((j\in [0,n-1],j\equiv i(\bmod 2),j\ne i)\), the current iteration number R and pseudo-random function \({{F}_{{{s}_{2}}}}(\cdot )\), the user \({{U}_{i}}\) encrypts the blinded gradients \({{a}_{i}}\) and \({{b}_{i}}\) as follows:

      $$\begin{aligned}&\begin{aligned} a_{i}'=&{{a}_{i}}+{{F}_{{{s}_{2}}}}({{\beta }_{i}})+\sum \limits _{j\equiv i(\bmod 2),j>i}{{{F}_{{{s}_{2}}}}({{\alpha }_{i,j}}\Vert R)}\\&-\sum \limits _{j\equiv i(\bmod 2),j<i}{{{F}_{{{s}_{2}}}}({{\alpha }_{i,j}}\Vert R)} \end{aligned}\end{aligned}$$
      (5)
      $$\begin{aligned}&\begin{aligned} b_{i}'=&{{b}_{i}}+{{F}_{{{s}_{2}}}}({{\beta }_{i}})+\sum \limits _{j\equiv i(\bmod 2),j>i}{{{F}_{{{s}_{2}}}}({{\alpha }_{i,j}}\Vert R)}\\&-\sum \limits _{j\equiv i(\bmod 2),j<i}{{{F}_{{{s}_{2}}}}({{\alpha }_{i,j}}\Vert R)} \end{aligned} \end{aligned}$$
      (6)
    3. (c)

      The user \({{U}_{i}}\) \((i\in [0,n-1])\) sends the encrypted gradients \(a_{i}'\), \(b_{i}'\) to the cloud server.

      Algorithm 1
      figure c

      Gradient blinding and encryption algorithm

  3. 3.

    Aggregation phase

    1. (a)

      After receiving the encrypted gradients \(a_{i}'\), \(b_{i}'\) from the user \({{U}_{i}}\) \((i\in [0,n-1])\), the cloud server sets the identity set of all online users to \({{I}_{online}}\), and sets the identity set of all offline users to \({{I}_{offline}}=\{0,1,...,n-1\}-{{I}_{online}}\). The cloud server verifies whether \({{I}_{online}}\ge t\), where t is the threshold value of the secret sharing. If \({{I}_{online}}\ge t\), the cloud server broadcasts the identity sets \({{I}_{online}}\) and \({{I}_{offline}}\) to all online users.

    2. (b)

      The online user \({{U}_{i}}\) \((i\in {{I}_{online}}, v\in {I}_{offline})\) sends the secret shares \(S{{K}_{v,i}}\) \((i\in {{I}_{online}})\) of the private keys \(S{{K}_{v}}\) \((v\in {{I}_{offline}})\) of all offline users \({{U}_{v}}\) \((v\in {{I}_{offline}})\) and the secret shares \({{\beta }_{i,j}}\) \((i,j\in {{I}_{online}},j\ne i)\) of the noise \({{\beta }_{i}}\) to the cloud server.

    3. (c)

      The cloud server recovers the private keys \(S{{K}_{v}}\) \((v\in {{I}_{offline}})\) of all offline users \({{U}_{v}}\) \((v\in {{I}_{offline}})\) and the noises \({{\beta }_{i}}\) \((i\in {{I}_{online}})\) of all online users \({{U}_{i}}\) \((i\in {{I}_{online}})\) based on the received secret shares \(S{{K}_{v,i}}\) \((v\in {{I}_{offline}},i\in {{I}_{online}})\) and the secret shares \({{\beta }_{i,j}}\) \((i,j\in {{I}_{online}},j\ne i)\), respectively. Then, the cloud server computes the secret values \({{\alpha }_{v,j}}=KA.agree(S{{K}_{v}},P{{K}_{j}})\) \((v\in {{I}_{offline}}, j\in [0,n-1],j\equiv v(\bmod 2),j\ne v)\) by using the private keys \(S{{K}_{v}}\) \((v\in {{I}_{offline}})\) of offline users \({{U}_{v}}\) \((v\in {{I}_{offline}})\) and the public keys \(P{{K}_{j}}\) \((j\in [0,n-1],j\equiv v(\bmod 2),j\ne v)\) of the users \({{U}_{j}}\) \((j\in [0,n-1],j\equiv v(\bmod 2),j\ne v)\).

    4. (d)

      The cloud server performs the double gradient aggregation operation as follows:

    $$\begin{aligned}&\begin{aligned} A=&\sum \limits _{i\in {{I}_{online}}}{{a}_{i}'}-\sum \limits _{i\in {{I}_{online}}}{{{F}_{{{s}_{2}}}}({{\beta }_{i}})}-\\&\sum \limits _{v\in {{I}_{offline}},j\in [0,n-1],j\equiv v(\bmod 2),j>v}{{{F}_{{{s}_{2}}}}({{\alpha }_{v,j}}\Vert R)}+\\&\sum \limits _{v\in {{I}_{offline}},j\in [0,n-1],j\equiv v(\bmod 2),j<v}{{{F}_{{{s}_{2}}}}({{\alpha }_{v,j}}\Vert R)} \end{aligned}\end{aligned}$$
    (7)
    $$\begin{aligned}&\begin{aligned} B=&\sum \limits _{i\in {{I}_{online}}}{b_{i}'}-\sum \limits _{i\in {{I}_{online}}}{{{F}_{{{s}_{2}}}}({{\beta }_{i}})}-\\&\sum \limits _{v\in {{I}_{offline}},j\in [0,n-1],j\equiv v(\bmod 2),j>v}{{{F}_{{{s}_{2}}}}({{\alpha }_{v,j}}\Vert R)}+\\&\sum \limits _{v\in {{I}_{offline}},j\in [0,n-1],j\equiv v(\bmod 2),j<v}{{{F}_{{{s}_{2}}}}({{\alpha }_{v,j}}\Vert R)} \end{aligned} \end{aligned}$$
    (8)

    The cloud sever sends the aggregated encrypted gradients A and B to all online users \({{U}_{i}}\) \((i\in {{I}_{online}})\).

  4. 4.

    Verification and update phase Algorithm 2 describes the processes of verification and update. After receiving the aggregated encrypted gradients A and B from the cloud server, the online users \({{U}_{i}}\) \((i\in {{I}_{online}})\) verify whether the cloud server correctly performs the aggregation operation through the following equation:

    $$\begin{aligned} A-|{{I}_{online}} |\cdot {{\pi }_{{{s}_{1}}}}(R)=B\cdot \frac{1}{{{\pi }_{{{s}_{1}}}}(R)} \end{aligned}$$
    (9)

    If the equation (9) holds, it means that the aggregated encrypted gradients A and B are correct. Then, the user \({{U}_{i}}\) \((i\in {{I}_{online}})\) calculates the aggregated gradient \(\omega =A-|{{I}_{online}} |\cdot {{\pi }_{{{s}_{1}}}}(R)\) and locally updates the trainable parameter \(W=W-\eta \cdot \frac{\omega }{|{{I}_{online}}|}\). The next round of federated learning will be executed until the termination condition is satisfied.

    Algorithm 2
    figure d

    Verification and update algorithm

6 Security analysis

Theorem 1

(Correctness) When the cloud server correctly aggregates all online users’ encrypted gradients, the aggregated encrypted gradients can pass the users’ verification.

Proof

To simplify the following derivation, we suppose that the cloud server is able to receive encrypted gradients \((a_{i}',b_{i}')\) sent by the online user \({{U}_{i}}\) \(({i \in {I}_{online}})\). Here, we consider the cases of offline users and network latency. The cloud server identifies the users with network latency as offline users because these users cannot upload the encrypted gradients to the cloud server on time.

The cloud server aggregates all online users’ \(a_{i}'\) \(({i \in {I}_{online}})\) as follows:

$$\begin{aligned} \begin{aligned} \sum \limits _{i\in {{I}_{online}}}{{{a}_{i}}'}=&\sum \limits _{i\in {{I}_{online}}}{{{a}_{i}}}+\sum \limits _{i\in {{I}_{online}}}{{{F}_{{{s}_{2}}}}({{\beta }_{i}})}+\\&\sum \limits _{i\in {{I}_{online}},j\in [0,n-1],j\equiv i(\bmod 2),j>i}{{{F}_{{{s}_{2}}}}({{\alpha }_{i,j}}\Vert R)}-\\&\sum \limits _{i\in {{I}_{online}},j\in [0,n-1],j\equiv i(\bmod 2),j<i}{{{F}_{{{s}_{2}}}}({{\alpha }_{i,j}}\Vert R)}\\ =&\sum \limits _{i\in {{I}_{online}}}{{{a}_{i}}}+\sum \limits _{i\in {{I}_{online}}}{{{F}_{{{s}_{2}}}}({{\beta }_{i}})}+\\&\sum \limits _{i\in {{I}_{online}},j\in {{I}_{online}},j\equiv i(\bmod 2),j>i}{{{F}_{{{s}_{2}}}}({{\alpha }_{i,j}}\Vert R)}+\\&\sum \limits _{v\in {{I}_{offline}}}{\sum \limits _{j\in {[0,n-1]},j\equiv v(\bmod 2),j>v}{{{F}_{{{s}_{2}}}}({{\alpha }_{v,j}}\Vert R)}}-\\ \end{aligned} \\ \begin{aligned} \quad \quad \quad \quad \quad&\sum \limits _{i\in {{I}_{online}},j\in {{I}_{online}},j\equiv i(\bmod 2),j<i}{{{F}_{{{s}_{2}}}}({{\alpha }_{i,j}}\Vert R)}-\\&\sum \limits _{v\in {{I}_{offline}}}{\sum \limits _{j\in {[0,n-1]},j\equiv v(\bmod 2),j<v}{{{F}_{{{s}_{2}}}}({{\alpha }_{v,j}}\Vert R)}} \end{aligned} \end{aligned}$$

\({{F}_{{{s}_{2}}}}({{\alpha }_{i,j}}\Vert R)\) and \({{F}_{{{s}_{2}}}}({{\alpha }_{j,i}}\Vert R)\) generated by the users \({{U}_{i}}\) \(({i \in {I}_{online}})\) and \({{U}_{j}}\) \(({j \in {I}_{online}})\) can cancel each other out. \({{F}_{{{s}_{2}}}}({{\alpha }_{v,j}}\Vert R)\) between the offline users \({{U}_{v}}\) \(({v \in {I}_{offline}})\) and the users \({{U}_{j}}\) \(({j \in [0,n-1]}, j\equiv v(\bmod ) 2, j>v)\), \({{F}_{{{s}_{2}}}}({{\alpha }_{v,j}}\Vert R)\) between the offline users \({{U}_{v}}\) \(({v \in {I}_{offline}})\) and the users \({{U}_{j}}\) \(({j \in [0,n-1]},\) \(j\equiv v(\bmod )2, j<v)\), and the \(\sum \limits _{i\in {{I}_{online}}}{{{F}_{{{s}_{2}}}}({{\beta }_{i}})}\) cannot be cancelled out. Thus,

$$\begin{aligned} \begin{aligned} \sum \limits _{i\in {{I}_{online}}}{{{a}_{i}}'}=&\sum \limits _{i\in {{I}_{online}}}{{{a}_{i}}}+\sum \limits _{i\in {{I}_{online}}}{{{F}_{{{s}_{2}}}}({{\beta }_{i}})}+\\&\sum \limits _{v\in {{I}_{offline}}}{\sum \limits _{j\in {[0,n-1]},j\equiv v(\bmod 2),j>v}{{{F}_{{{s}_{2}}}}({{\alpha }_{v,j}}\Vert R)}}-\\&\sum \limits _{v\in {{I}_{offline}}}{\sum \limits _{j\in {[0,n-1]},j\equiv v(\bmod 2),j<v}{{{F}_{{{s}_{2}}}}({{\alpha }_{v,j}}\Vert R)}} \end{aligned} \end{aligned}$$

The cloud server can recover the noise \({{\beta }_{i}}\) \((i\in {{I}_{online}})\) and the private key \(S{{K}_{v}}\) \((v\in {{I}_{offline}})\) based on the secret shares provided by more than t users. With the recovered private key \(S{{K}_{v}}\) of the offline user \({{U}_{v}}\) \((v\in {{I}_{offline}})\) and the public key \(P{{K}_{j}}\) of the user \({{U}_{j}}\) \((j\in [0,n-1],j\equiv v(\bmod ) 2, j>v)\), the cloud server can compute the secret value \({{\alpha }_{v,j}}=KA.agree(S{{K}_{v}},P{{K}_{j}})\) and recovers the random vectors \({{F}_{{{s}_{2}}}}({{\alpha }_{v,j}}\Vert R)\) \((v\in {{I}_{offline}}, j\in [0,n-1],j\equiv v(\bmod ) 2, j>v)\). Similarly, with the recovered private key \(S{{K}_{j}}\) of the offline user \({{U}_{v}}\) \((v\in {{I}_{offline}})\) and the public key \(P{{K}_{j}}\) of the user \({{U}_{j}}\) \((j\in [0,n-1],j\equiv v(\bmod ) 2, j<v)\), the cloud server can compute the secret value \({{\alpha }_{v,j}}=KA.agree(S{{K}_{v}},P{{K}_{j}})\) and recovers the random vectors \({{F}_{{{s}_{2}}}}({{\alpha }_{v,j}}\Vert R)\) \((v\in {{I}_{offline}}, j\in [0,n-1],j\equiv v(\bmod ) 2, j<v)\). Thus, the cloud server can remove the random vectors \({{F}_{{{s}_{2}}}}({{\alpha }_{v,j}}\Vert R)\) generated by the offline users \({{U}_{v}}\) \(({v \in {I}_{offline}})\) and the users \({{U}_{j}}\) \(({j \in [0,n-1]}, j\equiv v(\bmod ) 2)\) and the noises \({{F}_{{{s}_{2}}}}({{\beta }_{i}})\) as follows.

$$\begin{aligned}&\begin{aligned} A=&\sum \limits _{i\in {{I}_{online}}}{{{a}_{i}}'}-\sum \limits _{i\in {{I}_{online}}}{{{F}_{{{s}_{2}}}}({{\beta }_{i}})}\\&-\sum \limits _{v\in {{I}_{offline}}}{\sum \limits _{j\in {[0,n-1]},j\equiv v(\bmod 2),j>v}{{{F}_{{{s}_{2}}}}({{\alpha }_{v,j}}\Vert R)}}\\&+\sum \limits _{v\in {{I}_{offline}}}{\sum \limits _{j\in {[0,n-1]},j\equiv v(\bmod 2),j<v}{{{F}_{{{s}_{2}}}}({{\alpha }_{v,j}}\Vert R)}}\\ =&\sum \limits _{i\in {{I}_{online}}}{{{a}_{i}}}+\sum \limits _{i\in {{I}_{online}}}{{{F}_{{{s}_{2}}}}({{\beta }_{i}})}\\&+\sum \limits _{v\in {{I}_{offline}}}{\sum \limits _{j\in {[0,n-1]},j\equiv v(\bmod 2),j>v}{{{F}_{{{s}_{2}}}}({{\alpha }_{v,j}}\Vert R)}}-\\ \end{aligned}\\&\begin{aligned}&\ \sum \limits _{v\in {{I}_{offline}}}{\sum \limits _{j\in {[0,n-1]},j\equiv v(\bmod 2),j<v}{{{F}_{{{s}_{2}}}}({{\alpha }_{v,j}}\Vert R)}}\\&-\sum \limits _{i\in {{I}_{online}}}{{{F}_{{{s}_{2}}}}({{\beta }_{i}})}\\&-\sum \limits _{v\in {{I}_{offline}}}{\sum \limits _{j\in {[0,n-1]},j\equiv v(\bmod 2),j>v}{{{F}_{{{s}_{2}}}}({{\alpha }_{v,j}}\Vert R)}}\\&+\sum \limits _{v\in {{I}_{offline}}}{\sum \limits _{j\in {[0,n-1]},j\equiv v(\bmod 2),j<v}{{{F}_{{{s}_{2}}}}({{\alpha }_{v,j}}\Vert R)}}\\ =&\sum \limits _{i\in {{I}_{online}}}{{{a}_{i}}}=\sum \limits _{i\in {{I}_{online}}}{({{\omega }_{i}}+{{\pi }_{{{s}_{1}}}}(R))}.&\end{aligned} \end{aligned}$$

Similarly, the cloud server aggregates \(b_{i}'\) \(({i\in {I}_{online}})\) as follows:

$$\begin{aligned} \begin{aligned} \sum \limits _{i\in {{I}_{online}}}{{{b}_{i}}'}=&\sum \limits _{i\in {{I}_{online}}}{{{b}_{i}}}+\sum \limits _{i\in {{I}_{online}}}{{{F}_{{{s}_{2}}}}({{\beta }_{i}})}+\\&\sum \limits _{i\in {{I}_{online}},j\in [0,n-1],j\equiv i(\bmod 2),j>i}{{{F}_{{{s}_{2}}}}({{\alpha }_{i,j}}\Vert R)}-\\&\sum \limits _{i\in {{I}_{online}},j\in [0,n-1],j\equiv i(\bmod 2),j<i}{{{F}_{{{s}_{2}}}}({{\alpha }_{i,j}}\Vert R)}\\ =&\sum \limits _{i\in {{I}_{online}}}{{{b}_{i}}}+\sum \limits _{i\in {{I}_{online}}}{{{F}_{{{s}_{2}}}}({{\beta }_{i}})}+\\&\sum \limits _{i\in {{I}_{online}},j\in {{I}_{online}},j\equiv i(\bmod 2),j>i}{{{F}_{{{s}_{2}}}}({{\alpha }_{i,j}}\Vert R)}+\\&\sum \limits _{v\in {{I}_{offline}}}{\sum \limits _{j\in {[0,n-1]},j\equiv v(\bmod 2),j>v}{{{F}_{{{s}_{2}}}}({{\alpha }_{v,j}}\Vert R)}}-\\ \quad&\sum \limits _{i\in {{I}_{online}},j\in {{I}_{online}},j\equiv i(\bmod 2),j<i}{{{F}_{{{s}_{2}}}}({{\alpha }_{i,j}}\Vert R)}-\\ \quad&\sum \limits _{v\in {{I}_{offline}}}{\sum \limits _{j\in {[0,n-1]},j\equiv v(\bmod 2),j<v}{{{F}_{{{s}_{2}}}}({{\alpha }_{v,j}}\Vert R)}} \end{aligned} \end{aligned}$$

\({{F}_{{{s}_{2}}}}({{\alpha }_{i,j}}\Vert R)\) and \({{F}_{{{s}_{2}}}}({{\alpha }_{j,i}}\Vert R)\) generated by the users \({{U}_{i}}\) \(({i \in {I}_{online}})\) and \({{U}_{j}}\) \(({j \in {I}_{online}})\) can cancel each other out. \({{F}_{{{s}_{2}}}}({{\alpha }_{v,j}}\Vert R)\) between the offline users \({{U}_{v}}\) \(({v \in {I}_{offline}})\) and the users \({{U}_{j}}\) \(({j \in [0,n-1]}, j\equiv v(\bmod ) 2, j>v)\), \({{F}_{{{s}_{2}}}}({{\alpha }_{v,j}}\Vert R)\) between the offline users \({{U}_{v}}\) \(({v \in {I}_{offline}})\) and the users \({{U}_{j}}\) \(({j \in [0,n-1]},\) \(j\equiv v(\bmod )2, j<v)\), and the \(\sum \limits _{i\in {{I}_{online}}}{{{F}_{{{s}_{2}}}}({{\beta }_{i}})}\) cannot be cancelled out. Therefore,

$$\begin{aligned} \begin{aligned} \sum \limits _{i\in {{I}_{online}}}{{{b}_{i}}'}=&\sum \limits _{i\in {{I}_{online}}}{{{b}_{i}}}+\sum \limits _{i\in {{I}_{online}}}{{{F}_{{{s}_{2}}}}({{\beta }_{i}})}+\\&\sum \limits _{v\in {{I}_{offline}}}{\sum \limits _{j\in {[0,n-1]},j\equiv v(\bmod 2),j>v}{{{F}_{{{s}_{2}}}}({{\alpha }_{v,j}}\Vert R)}}-\\&\sum \limits _{v\in {{I}_{offline}}}{\sum \limits _{j\in {[0,n-1]},j\equiv v(\bmod 2),j<v}{{{F}_{{{s}_{2}}}}({{\alpha }_{v,j}}\Vert R)}} \end{aligned} \end{aligned}$$

The cloud server can recover the noise \({{\beta }_{i}}\) \((i\in {{I}_{online}})\) and the private key \(S{{K}_{v}}\) \((v\in {{I}_{offline}})\) based on the secret shares provided by more than t users. With the recovered private key \(S{{K}_{v}}\) of the offline user \({{U}_{v}}\) \((v\in {{I}_{offline}})\) and the public key \(P{{K}_{j}}\) of the user \({{U}_{j}}\) \((j\in [0,n-1],j\equiv v(\bmod ) 2, j>v)\), the cloud server can compute the secret value \({{\alpha }_{v,j}}=KA.agree(S{{K}_{v}},P{{K}_{j}})\) and recovers the random vectors \({{F}_{{{s}_{2}}}}({{\alpha }_{v,j}}\Vert R)\) \((v\in {{I}_{offline}}, j\in [0,n-1],j\equiv v(\bmod ) 2, j>v)\). Similarly, with the recovered private key \(S{{K}_{j}}\) of the offline user \({{U}_{v}}\) \((v\in {{I}_{offline}})\) and the public key \(P{{K}_{j}}\) of the user \({{U}_{j}}\) \((j\in [0,n-1],j\equiv v(\bmod ) 2, j<v)\), the cloud server can compute the secret value \({{\alpha }_{v,j}}=KA.agree(S{{K}_{v}},P{{K}_{j}})\) and recovers the random vectors \({{F}_{{{s}_{2}}}}({{\alpha }_{v,j}}\Vert R)\) \((v\in {{I}_{offline}}, j\in [0,n-1],j\equiv v(\bmod ) 2, j<v)\). Thus, the cloud server can remove the random vectors \({{F}_{{{s}_{2}}}}({{\alpha }_{v,j}}\Vert R)\) generated by the offline users \({{U}_{v}}\) \(({v \in {I}_{offline}})\) and the users \({{U}_{j}}\) \(({j \in [0,n-1]}, j\equiv v(\bmod ) 2)\) and the noises \({{F}_{{{s}_{2}}}}({{\beta }_{i}})\) as follows.

$$\begin{aligned} \begin{aligned} B=&\sum \limits _{i\in {{I}_{online}}}{{{b}_{i}}'}-\sum \limits _{i\in {{I}_{online}}}{{{F}_{{{s}_{2}}}}({{\beta }_{i}})}\\&-\sum \limits _{v\in {{I}_{offline}}}{\sum \limits _{j\in {[0,n-1]},j\equiv v(\bmod 2),j>v}{{{F}_{{{s}_{2}}}}({{\alpha }_{v,j}}\Vert R)}}\\&+\sum \limits _{v\in {{I}_{offline}}}{\sum \limits _{j\in {[0,n-1]},j\equiv v(\bmod 2),j<v}{{{F}_{{{s}_{2}}}}({{\alpha }_{v,j}}\Vert R)}}\\ \quad =&\sum \limits _{i\in {{I}_{online}}}{{{b}_{i}}}+\sum \limits _{i\in {{I}_{online}}}{{{F}_{{{s}_{2}}}}({{\beta }_{i}})}\\&+\sum \limits _{v\in {{I}_{offline}}}{\sum \limits _{j\in {[0,n-1]},j\equiv v(\bmod 2),j>v}{{{F}_{{{s}_{2}}}}({{\alpha }_{v,j}}\Vert R)}}\\&-\sum \limits _{v\in {{I}_{offline}}}{\sum \limits _{j\in {[0,n-1]},j\equiv v(\bmod 2),j<v}{{{F}_{{{s}_{2}}}}({{\alpha }_{v,j}}\Vert R)}}\\&-\sum \limits _{i\in {{I}_{online}}}{{{F}_{{{s}_{2}}}}({{\beta }_{i}})}-\\&\sum \limits _{v\in {{I}_{offline}}}{\sum \limits _{j\in {[0,n-1]},j\equiv v(\bmod 2),j>v}{{{F}_{{{s}_{2}}}}({{\alpha }_{v,j}}\Vert R)}}+\\&\sum \limits _{v\in {{I}_{offline}}}{\sum \limits _{j\in {[0,n-1]},j\equiv v(\bmod 2),j<v}{{{F}_{{{s}_{2}}}}({{\alpha }_{v,j}}\Vert R)}}\\ =&\sum \limits _{i\in {{I}_{online}}}{{{b}_{i}}}=\sum \limits _{i\in {{I}_{online}}}{({{\omega }_{i}}\cdot {{\pi }_{{{s}_{1}}}}(R))}. \end{aligned} \end{aligned}$$

If the equation \(A-|{{I}_{online}}|\cdot {{\pi }_{{{s}_{1}}}}(R)=B\cdot \frac{1}{{{\pi }_{{{s}_{1}}}}(R)}=\sum \limits _{i\in {I}_{online}}{{{\omega }_{i}}}\) holds, all online users are convinced that the cloud server correctly aggregates all users’ encrypted gradients. \(\square\)

Theorem 2

(Gradient privacy) The cloud server cannot obtain the users’ local gradients from the encrypted gradients sent by the users.

Proof

In our scheme, we adopt double gradient blinding and encryption method to blind and encrypt the local gradient \({{\omega }_{i}}\) as follows:

$$\begin{aligned} \begin{aligned} a_{i}'=&{{a}_{i}}+{{F}_{{{s}_{2}}}}({{\beta }_{i}})+\sum \limits _{j\equiv i(\bmod 2), j>i}{{{F}_{{{s}_{2}}}}({{\alpha }_{i,j}} \Vert R)}\\&-\sum \limits _{j\equiv i(\bmod 2), j<i}{{{F}_{{{s}_{2}}}}({{\alpha }_{i,j}}\Vert R)}\\ b_{i}'=&{{b}_{i}}+{{F}_{{{s}_{2}}}}({{\beta }_{i}})+\sum \limits _{j\equiv i(\bmod 2),j>i}{{{F}_{{{s}_{2}}}}({{\alpha }_{i,j}}\Vert R)}\\&-\sum \limits _{j\equiv i(\bmod 2),j<i}{{{F}_{{{s}_{2}}}}({{\alpha }_{i,j}}\Vert R)}, \end{aligned} \end{aligned}$$

where \({{a}_{i}}={{\omega }_{i}}+{{\pi }_{{{s}_{1}}}}(R)\) and \({{b}_{i}}={{\omega }_{i}}\cdot {{\pi }_{{{s}_{1}}}}(R)\), \({{\pi }_{{{s}_{1}}}}(R)\) is a random vector produced by the user based on the current iteration number R. The local gradient \({{\omega }_{i}}\) is blinded by the random vector \({{\pi }_{{{s}_{1}}}}(R)\). Then, the blinded gradients \({{a}_{i}}\) and \({{b}_{i}}\) are encrypted by the random vectors \({{F}_{{{s}_{2}}}}({{\alpha }_{i,j}}\Vert R)\) and \({{F}_{{{s}_{2}}}}({{\beta }_{i}})\), where the secret value \({{\alpha }_{i,j}}=KA.agree(S{{K}_{i}},P{{K}_{j}})\) can be calculated based on the user \({{U}_{i}}\) \((i\in [0,n-1])\)’s private key \(S{{K}_{i}}\) and the user \({{U}_{j}}\) \((j\in [0,n-1],j\equiv i(\bmod 2),j\ne i)\)’s public key \(P{{K}_{j}}\) and the noise \({{\beta }_{i}}\) is randomly generated by the GM.

The cloud server receives the encrypted gradients \(a_{i}'\) and \(b_{i}'\) from the online users \({{U}_{i}}\) \((i\in {{I}_{online}})\) and aslo receives the encrypted gradients \(a_{j}'\) and \(b_{j}'\) from the the users \({{U}_{j}}\) \((j\in {{I}_{latency}})\) with network latency. In the aggregation phase, the cloud server is able to recover the private keys \(S{{K}_{j}}\) of the users \({{U}_{j}}\) \((j\in {{I}_{latency}})\) with network latency and the noise \({{\beta }_{i}}\) of all online users \({{U}_{i}}\) \((i\in {{I}_{online}})\) based on the received secret shares. However, the cloud server cannot recover the private keys \(S{{K}_{i}}\) of online users \({{U}_{i}}\) \((i\in {{I}_{online}})\) and the noise \({{\beta }_{j}}\) of the users \({{U}_{j}}\) \((j\in {{I}_{latency}})\) with network latency since the cloud server cannot collude with more than t users to recover \(S{{K}_{i}}\) \((i\in {{I}_{online}})\) and \({{\beta }_{j}}\) \((j\in {{I}_{latency}})\). As a result, the cloud server cannot caculate the random vectors \({{F}_{{{s}_{2}}}}({{\beta }_{j}})\) of the user \({{U}_{j}}\) \((j\in {{I}_{latency}})\) with network latency without the noises \({{\beta }_{j}}\) \((j\in {{I}_{latency}})\) and aslo cannot compute the online user \({{U}_{i}}\) \((i\in {{I}_{online}})\)’s secret value \({{\alpha }_{i,j}}=KA.agree(S{{K}_{i}},P{{K}_{j}})\) \((j\in [0,n-1],j\equiv i(\bmod 2),j\ne i)\) without the private key \(S{{K}_{i}}\) \((i\in {{I}_{online}})\). Further, the cloud server cannot caculate the random vectors \({{F}_{{{s}_{2}}}}({{\alpha }_{i,j}}\Vert R)\) \((i\in {{I}_{online}},j \in [0,n-1],j\equiv i(\bmod 2),j\ne i)\). Thus, even if the cloud server can obtain the random vectors \({{F}_{{{s}_{2}}}}({{\beta }_{i}})\) of all online users \({{U}_{i}}\) \((i\in {{I}_{online}})\), without the random vectors \({{F}_{{{s}_{2}}}}({{\alpha }_{i,j}}\Vert R)\) \((i\in {{I}_{online}},j \in [0,n-1],j\equiv i(\bmod 2),j\ne i)\), it still cannot obtain the blinded gradients \({{a}_{i}}\) and \({{b}_{i}}\) from the encrypted gradients \(a_{i}'\) and \(b_{i}'\) sent by the online users \({{U}_{i}}\) \((i\in {{I}_{online}})\), let alone the local gradients \({{\omega }_{i}}\) \((i\in {{I}_{online}})\). In addition, even if the cloud server can calculate the random vectors \({{F}_{{{s}_{2}}}}({{\alpha }_{j,i}}\Vert R)\) \((j\in {{I}_{latency}},i\in [0,n-1],i\equiv j(\bmod 2),i\ne j)\) of the user \({{U}_{j}}\) \((j\in {{I}_{latency}})\) with network latency based on the recovered private key \(S{{K}_{j}}\) \((j\in {{I}_{latency}})\), without the noises \({{\beta }_{j}}\) \((j\in {{I}_{latency}})\), it still cannot obtain the blinded gradients \({{a}_{j}}\) and \({{b}_{j}}\) from the encrypted gradients \(a_{j}'\) and \(b_{j}'\) from the users \({{U}_{j}}\) \((j\in {{I}_{latency}})\), let alone the local gradients \({{\omega }_{j}}\) \((j\in {{I}_{latency}})\). \(\square\)

Theorem 3

(Immunity from replay attacks) In PPFLV, the cloud server is not able to pass the verification of the users by utilizing the previous aggregated gradients.

Proof

We prove that PPFLV can resist replay attacks through the following game. Specially, in the \({{R}_{2}}\)-th iteration, the user \({{U}_{i}}\) \((i\in [0,n-1])\) sends the new encrypted gradients \(\{a_{i}^{*},b_{i}^{*}\}\) to the cloud server, which are different from the previous encrypted gradients \(\{a_{i}',b_{i}'\}\) in the previous \({{R}_{1}}\)-th iteration. Then, the cloud server transmits the previous aggregated encrypted gradients \(\left\{ A,B \right\}\) to the user \({{U}_{i}}\) \((i\in [0,n-1])\), where \(\left\{ A,B \right\}\) are the aggregated encrypted gradients corresponding to the previous encrypted gradients \(\{a_{i}',b_{i}'\}\). During the verification phase, if \(\left\{ A,B \right\}\) are able to pass the verification of the users, the cloud server wins this game; otherwise, it fails.

For the previous aggregated encrypted gradients \(\left\{ A,B \right\}\) in the \({{R}_{1}}\)-th iteration, the following verification equation holds based on the iteration number \({{R}_{1}}\):

$$\begin{aligned} \begin{aligned} A-|{{I}_{online}}|\cdot {{\pi }_{{{s}_{1}}}}({{R}_{1}})=B\cdot \frac{1}{{{\pi }_{{{s}_{1}}}}({{R}_{1}})}. \end{aligned} \end{aligned}$$
(10)

In the new \({{R}_{2}}\)-th iteration, if the cloud server can use \(\left\{ A,B \right\}\) to pass the verification, then the following equation also holds:

$$\begin{aligned} \begin{aligned} A-|{{I}_{online}}|\cdot {{\pi }_{{{s}_{1}}}}({{R}_{2}})=B\cdot \frac{1}{{{\pi }_{{{s}_{1}}}}({{R}_{2}})}. \end{aligned} \end{aligned}$$
(11)

\(\square\)

From the above two verification equations (10), (11), we have

$$\begin{aligned} \begin{aligned} A&=B\cdot \frac{1}{{{\pi }_{{{s}_{1}}}}({{R}_{1}})}+|{{I}_{online}}|\cdot {{\pi }_{{{s}_{1}}}}({{R}_{1}})\\&=B\cdot \frac{1}{{{\pi }_{{{s}_{1}}}}({{R}_{2}})}+|{{I}_{online}}|\cdot {{\pi }_{{{s}_{1}}}}({{R}_{2}}) \end{aligned} \end{aligned}$$

Further, we have \({{R}_{1}}={{R}_{2}}\), which is in contradiction with the assumption that \({{R}_{1}}\ne {{R}_{2}}\). Therefore, the cloud server cannot win this game. In VerSA [11], if the online users in any two rounds are the same, then the parameters of the verification equation will become the same. In this case, the cloud server has the opportunity to launch a replay attack. The difference from VerSA [11] is that the equation parameters used to verify the correctness of the aggregate gradient in any round of PPFLV are different. This ensures that the cloud server does not have any chance to launch a replay attack in PPFLV.The PPFLV is able to resist the replay attacks.

Theorem 4

(Unforgeability) In the PPFLV scheme, if the cloud server does not correctly aggregate the users’ encrypted gradients, it cannot pass the verification of the users.

Proof

If AB are the correct aggregated encrypted gradients sent by the cloud server, then the following verification equation holds: \(A-|{{I}_{online}} |\cdot {{\pi }_{{{s}_{1}}}}(R)=B\frac{1}{{{\pi }_{{{s}_{1}}}}(R)}\). Assume that the cloud server forges aggregated encrypted gradients \({A',B'}\) which are different from AB. If the cloud server is able to pass the verification of the users, we have: \(A'-|{{I}_{online}} |\cdot {{\pi }_{{{s}_{1}}}}(R)\overset{{}}{\mathop {=}}\,B'\cdot \frac{1}{{{\pi }_{{{s}_{1}}}}(R)}\).

Further, we can deduce that \(A'\) must be satisfy \(A'=nu{{m}_{fake}}+|{{I}_{online}}|\cdot {{\pi }_{{{s}_{1}}}}(R)\) and \(B'\) must satisfy \(B'=nu{{m}_{fake}}\cdot {{\pi }_{{{s}_{1}}}}(R)\), where \(nu{{m}_{fake}}\) is a random vector chosen by the cloud server. It means that if the cloud server can forge successfully, it needs to know the secret seed \({{s}_{1}}\) of the pseudo-random function \({{\pi }_{{{s}_{1}}}}(\cdot )\). Only knowing \({{s}_{1}}\), the cloud server can compute \(A'=nu{{m}_{fake}}+|{{I}_{online}}|\cdot {{\pi }_{{{s}_{1}}}}(R)\) and \(B'=nu{{m}_{fake}}\cdot {{\pi }_{{{s}_{1}}}}(R)\), which can make the equation \(A'-|{{I}_{online}} |\cdot {{\pi }_{{{s}_{1}}}}(R)\overset{{}}{\mathop {=}}\,B'\cdot \frac{1}{{{\pi }_{{{s}_{1}}}}(R)}\) hold. However, the secret seed \({{s}_{1}}\) is randomly selected by the GM, which is kept secret from the cloud server. In the finite field \(\mathbb {Z}_{q}^{*}\), the probability of the cloud server obtaining the correct secret seed is \(\frac{1}{q}\), which is negligible since q is large prime. Therefore, it is computationally infeasible for the cloud server to forge the aggregated encrypted gradients to pass the verificaiton. \(\square\)

7 Performance evaluation

In this section, we evaluate the performance of the PPFLV in terms of classification accuracy, computation overhead and communication overhead. The simulation experiment is conducted on a Linux server with Intel(R) Core(TM) i9-10980XE, 3.0GHZ, and 32GB memory. All experiments are implemented using Pytorch.

7.1 Classification accuracy

We use two datasets (CIFAR10 and MNIST) to evaluate the classification accuracy of two models :

  • CIFAR10 [45] is a dataset consisting of three-channel RGB color images categorized into 10 classes. The images in this dataset have a size of 32 \(\times\) 32 pixels. It contains a total of 60,000 images. We pick 50,000 images for training, while the remaining images are reserved for test.

  • MNIST [46] is a handwritten digital dataset. It contains a total of 70,000 images. Each image in this dataset has a size of 28 \(\times\) 28 pixels and features handwritten numbers ranging from 0 to 9 in white color against a black background. We select 60,000 images for training and the rest for test.

We select FedAvg [47], which is a plaintext federated learning scheme without privacy protection, as a benchmark for comparison with the proposed PPFLV in terms of classification accuracy. To evaluate the performance of the proposed PPFLV, we choose two well-known classical networks: Multilayer Perceptron (MLP) [48] and Convolutional Neural Networks (CNN) [49]. In our experiment, MLP consists of an input layer, two hundred hidden layers and an output layer. CNN trained with the CIFAR dataset is composed of two convolutional layers, one pooling layer and three fully connected layers. The CNN trained with the MNIST dataset is composed of three convolutional layers and two fully connected layers. We split the MNIST dataset into IID (independent and identically distributed) dataset and non-IID (non-Independent Identically Distribution) dataset.

Fig. 3
figure 3

Classification accuracy comparison of PPFLV and FedAvg [47] a CNN using MNIST dataset under IID, b CNN using MNIST dataset under non-IID, c MLP using MNIST dataset under IID, d MLP using MNIST dataset under non-IID

As depicted in Fig. 3a and c, when utilizing the MNIST dataset under IID, the classification accuracies obtained by PPFLV using both CNN and MLP neural networks for training exceed 90%. Furthermore, from Fig. 3a and c, we can find that, the classification accuracy of PPFLV is similar to that of FedAvg [47]. Figure 3b and d show that two model accuracy in MNIST non-IID database, the proposed PPFLV achieves comparable accuracy to the plaintext FedAvg [47]. Hence, data heterogeneity is connected to federated learning itself, but it does not impact the security design of our scheme. Thus, compared to plaintext federated learning scheme, our PPFLV hardly losses the classification accuracy while maintaining data privacy protection.

7.2 Computation overhead

To evaluate the performance of the proposed PPFLV on the user side, VerSA [11] and VCD-FL[50], which are the state-of-the-art verifiable federated learning schemes with privacy preserving, are selected as the benchmarks. We give the comparison of PPFLV, VerSA[11] and VCD-FL [50] in terms of users’ computation overhead for gradient encryption and verification.

Fig. 4
figure 4

Comparison of gradient encryption computation overhead a with different number of gradients per user, b with different number of users

Fig. 5
figure 5

Comparison of verification computation overhead a with different number of gradients per user, b with different number of users

We set the number of gradients per user to vary from 1000 to 10000, and the number of users to vary from 100 to 1000. The size of each gradient entry is 64bit. Figure 4 shows the computation overhead comparison of encrypting gradients among the proposed PPFLV, VerSA [11] and VCD-FL [50] for different number of gradients per user and different number of users. Most of the computation overhead of the user for encrypting gradients is generated by the pseudo-random function and the key agreement. The pseudo-random function is used to generate the random vectors and the key agreement is utilized to generate the secret values between the users. Figure 4a and b show that the computation overhead of gradient encryption increases linearly with the number of users and the number of gradients per user in the proposed PPFLV, VerSA [11], and VCD-FL [50]. The computation overhead of gradient encryption in the proposed PPFLV is much lower than that in VCD-FL [50].

We also evaluate the computation overhead of the user during the verification phase. Both the proposed PPFLV and VerSA [11] only require to perform the lightweight calculation to verify the correctness of aggregated gradient. Figure 5a and b show that the computation overhead of verification in the proposed PPFLV, VerSA [11], and VCD-FL [50] is proportional to number of users and the number of gradients per user. In the phase of verification, the computation overhead of the proposed PPFLV is much lower than that in VCD-FL [50], and approximately the same as that of VerSA [11]. However, VerSA [11] cannot resist the replay attack in the verification phase. Thus, the proposed PPFLV is able to achieve efficient verification while resisting replay attack.

To evaluate the aggregation performance of the cloud server, we set the number of users to 500 and the gradient entries of each user to 5K and 10K, respectively. The size of each entry is 64bit.

Fig. 6
figure 6

Computation overhead of aggregating gradients for all users online

Figure 6 shows the computation overhead of aggregating gradients on the cloud server side when all users are online. In Fig. 6, we have the observation that as the number of iterations increases, the computation overhead of aggregating gradients grows linearly. Furthermore, the computation overhead of aggregating gradients is also related to the number of gradient entries of each user, which increases with the number of gradient entries of each user.

Fig. 7
figure 7

Computation overhead of aggregating gradients for different user offline rates a 5K-entry gradients per user, b 10K-entry gradients per user

We set the user offline rate from 10% to 50%. As discussed in Sect. 5.2, the cloud server needs to recover the private keys of the offline users when the users are offline. Figure 7a and b show that in PPFLV and VerSA [11], the computation overhead of aggregating gradients is affected by the number of gradient entries of each user when the user offline rate is fixed. The computation overhead of aggregating gradients in PPFLV and VerSA [11] grow linearly as the user offline rate increases. Furthermore, the computation overhead of aggregating gradients in PPFLV is significantly lower than VerSA [11]. This advantage becomes increasingly evident as the user offline rate increases. When the user offline rate reaches 50%, the computation overhead of aggregating gradients in PPFLV is just under half that of VerSA [11]. Thus, we can conclude that the performance of the proposed PPFLV surpasses that of VerSA [11] on the cloud server side.

7.3 Communication overhead

We compare the total communication overhead of our scheme with VerSA [11] and VerifyNet [4]. VerSA [11] and VerifyNet [4] are the state-of-the-art privacy-preserving and verifiable federated learning schemes. The communication overhead mainly comes from the phases of initialization, aggregation and verification. The keys and seeds are distributed in the initialization phase. The encrypted gradients are uploaded in the aggregation phase and the aggregated encrypted gradients are downloaded in the verification phase.

Figure 8a shows the communication overhead comparison of PPFLV, VerifyNet [4] and VerSA [11] by gradually increasing the number of gradients per user with a fixed number of 100 users. Figure 8b illustrates the communication overhead comparison of PPFLV, VerifyNet [4] and VerSA [11] when the number of users increases and the number of gradients per user is fixed at 1000 entries. From Fig.8a and b, we can find that the communication overhead of PPFLV, VerifyNet [4] and VerSA [11] increase linearly as the number of gradients per user and the number of users increases. Furthermore, with an increasing number of gradients per user, the communication overhead of PPFLV is significantly lower than that of VerifyNet [4], and is essentially comparable to VerSA [11]. As the number of users grows, the communication overhead of PPFLV is lower than that of VerifyNet [4] and VerSA [11].

Fig. 8
figure 8

Communication overhead comparison of PPFLV, VerSA [11] and VerifyNet [4] a with different number of gradients per user, b with different number of users

8 Conclusion

To solve the problems of the users’ private data leakage and the aggregated gradients verification in federated learning, in this paper, we propose PPFLV, a privacy-preserving federated learning scheme with verifiability. In PPFLV, the double gradient blinding and encryption method is used to blind and encrypt the users’ local gradients and guarantee the users’ privacy. The double gradient verification method is utilized to verify the correctness of the aggregated encrypted gradients calculated by the cloud server. Each user can independently verify the correctness of the aggregated encrypted gradients and recovers the aggregated gradient. The experiments show that PPFLV is efficient in terms of privacy protection and secure verification.