# GSFedSec: Group Signature-Based Secure Aggregation for Privacy Preservation in Federated Learning
## 4 Security Analysis of the Proposed Algorithm
### Security Proof through Simulation  
This section presents a security analysis of the proposed protocol, as realized using the AVISPA simulation tool. This tool provides results based on the goal of ensuring security. The entire HLPSL code for the various algorithm functions is provided in Appendix B. It includes six basic entities: Server, Client 1, Client 2, Client 3, Client 4, and Admin. First, the admin sends a GS to all four clients, and the clients send an FL training request to the server. The server responds by selecting three clients from the original set of four. Then, all selected clients respond with updates based on their system knowledge. This simulation focuses on the secrecy of sensitive data and the sender's privacy. The goals of the algorithm are as follows:  
goal secrecy_of sec_A2_C1,sec_A2_C2,sec_A2_C3, sec_A2_C4,sec_S_C1,sec_S_C2,sec_S_C4 authentication_on rand1_auth,rand2_auth, rand3_auth,rand4_auth end goal  
The abovementioned secret function has three parameters: (1) the data we want to keep secret, (2) the name of the protocol we refer to in the code, and (3) the set of members who know the secret data. Other than the members referred to in the third parameter, no other entity should have access to the confidential data. The GS is a sensitive entity, and only the valid group members should know the signature. This is represented using _Gsign_ and it must be kept secret between the clients (C1, C2, C3, C4) and the issuing authority (\(A2\)). Client data can be shared only between the server and the client; to this end, all secrets should be protected. The AVISPA tool checks for each mentioned member and determines whether the algorithm fulfills all goals. Figure 5 shows the knowledge of the intruder at the end of the simulation. As shown in Figure 6, the simulation concludes that the algorithm is safe. This means that our algorithm fulfills all the goals mentioned in the goal section. Therefore, the keys are secret, the intruder cannot identify any secret information, and we have correctly authenticated each entity before communicating with them. Table 3 lists the possible attacks and the algorithms that can prevent these attacks. As can be seen in the table, our algorithm is safe from various possible attacks.  
\begin{table}
\begin{tabular}{l c c c c c} \hline \hline \multirow{2}{*}{**Attack**} & \multicolumn{5}{c}{**Algorithm**} \\ \cline{2-6}  & **[24]** & **[1]** & **[5]** & **[23]** & **[22]** & **Proposed** \\ \hline
1. Privacy Attack & \(\times\) & \(\times\) & \(\times\) & \(\times\) & \(\times\) & ✓ \\
2. Inference Attack & ✓ & ✓ & ✓ & \(\times\) & \(\times\) & ✓ \\
3. Impersonation Attack & \(\times\) & \(\times\) & \(\times\) & \(\times\) & \(\times\) & ✓ \\
4. Sybil Attack & \(\times\) & \(\times\) & \(\times\) & \(\times\) & \(\times\) & ✓ \\
5. Honest-but-Curious Attack & ✓ & ✓ & ✓ & ✓ & ✓ & ✓ \\
6. Possible Collusion by Clients & \(\times\) & \(\times\) & \(\times\) & \(\times\) & \(\times\) & ✓ \\ \hline \hline \end{tabular}
\end{table}
Table 3: Prevention from various security attacks.