## 6 Security Analysis and Performance Evaluation
### Performance of the Multi-Level ACE-Based IoT Knowledge Sharing Algorithm  
We implement the multi-level ACE algorithm with Java to evaluate the practical performance of the IoT knowledge sharing approach we proposed in HBCE-FL. The communication process between local clients, edge servers, and cloud servers is essentially the process of encrypting, sanitizing, and decrypting transmitted messages. The program is executed on a Windows 10 64-bit operating system, utilizing an Intel(R) Core(TM) i7-8565U CPU clocked at 1.80 GHz and 16 GB of RAM. The cyclic group \(G\) of the ACE algorithm is implemented using elliptic curves constructed over a 128-bit finite field, based on an elliptic curve of Type-A. This implementation is facilitated by the JPBC framework, a Java library that ports the Pairing-Based Cryptography (PBC) library. The size of the element in the \(\mathbb{Z}_{p}\) is 20 bits. We did not consider communication delay in order to focus on the running time of the ACE algorithms. We employ ACE\({}^{1}\) to assess the algorithm's performance. The runtime of each algorithm component, using a 1024-bit plaintext as input, is detailed in Table 3. The time overhead of **Setup** primarily involves initializing the cyclic group \(G\), \(\mathbb{Z}_{p}\), and a primary exponential operation. **Enc** and **San** exhibit similar time overheads, given their identical number of exponential operations and a comparable number of multiplications. **Dec** features a straightforward structure with only one exponential operation. The **KeyGen** performs solely assignment operations, rendering its runtime negligible. The performance of ACE algorithms is influenced by the number of clients and the length of the plaintext. We consider the number of clients and plaintext length as variables \begin{table}
\begin{tabular}{c c c c c} \hline \hline
**Algorithm** & **Setup** & **Enc** & **San** & **Dec** \\ \hline Time (ms) & 10.97 & 46.02 & 47.81 & 9.66 \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Running time of ACE\({}^{1}\) algorithm. to assess the performance of our ACE algorithm. Figure 3 illustrates the time and space overhead of each part of the ACE algorithm. Specifically, Figure 3a,d depict the relationship between the time and space overhead of each algorithmic component and the plaintext length when there is only one client in the system. It can be seen from Figure 3a that the knowledge encryption, sanitization, and decryption time all exhibit a linear increase with the growth of the length of the input knowledge plaintext, albeit the change is minimal. The computation time for each part of the algorithm is essentially in milliseconds, which is negligible for clients and servers capable of performing FL training tasks. Figure 3d indicates that the length of the two ciphertexts is linearly correlated with the length of the input plaintext. In practical scenarios, we implement a simulation of the HBCE-FL framework with three security levels. The distribution of users across security levels follows a ratio of 1:4:5, with fewer users at higher security levels. Each message has a plaintext length of 1024 bits. The client encrypts a message, which is sanitized and sent to all cloud servers by the edge sanitizer. Consequently, the client executes ACE\({}^{n}.Enc\) only once for each communication round, and the number of clients in the system does not impact an individual client's encryption time. For clients at different security levels, lower-level clients possess more encryption keys, resulting in more encryption operations. Conversely, higher-level clients experience shorter encryption times. As depicted in Figure 3b, the client's level exhibits a linear relationship with encryption time. The encryption time is within the millisecond range, rendering it negligible compared to the local training time. Figure 3e illustrates how the total edge sanitization time and the decryption time of a single cloud server vary with the number of clients in the system.