# ML-AKA: An Authentication Protocol for Non-Standalone 5G-Based C-IoT Networks
## 7 Simulation and Protocol Performance Analysis
### ML-AKA Protocol Computational Cost  
End-to-end communication involves three kinds of system entities:  
* Devices (\(D_{i}\)). * Access Points (\(AP_{i}\)). * eNodeB. In the system setup model, the different networks arrange the common secret parameters for device-to-device communication, and the computation cost of ML-AKA protocol depends on the size of the security parameters, e.g., \(len_{p}\). Figure 8: Simulation result of ML-AKA protocol using AVISPA tools. Figure 9: Outcome of protocol variation with the help of ProVerif tool. \begin{table}
\begin{tabular}{l l l l} \hline \hline
**Protocol Name** & **Parse Time (Tp)** & **Search Time (Ts)** & **Visited Nodes** & **Depth** \\ \hline EPS-AKA & 0.031 s & 2.22 s & 1360 nodes & 10 plies \\ UAKA-D2D & 0.043 s & 1.73 s & 1360 nodes & 10 plies \\ ML-AKA & 0.01 s & 1.40 s & 1360 nodes & 10 plies \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Comparison between different protocols. In the roaming registration stage of devices, eNodeB calculates the roaming key and all the authentication information, while AP calculates and generates the device-to-device (D2D) fun key. We have taken the authentication information generation time cost as \(T_{AI}\), while \(T_{r}\) represents the random operation generation, \(T_{Kasme}\) is the roaming key generation, and \(T_{KD2D}\) is the D2D fun key. While generating the session key for D2D, the AP uses the rand function and computes the \(N_{i}\) which uses an XOR function to compute the pre-shared secret \(N_{i}\). Then, each device (\(D_{i}\)) conducts the following exponentiation operation and two HMAC operations:  
\[T_{Ks}=T_{r}+T_{XOR}+2T_{modExp}+2T_{HMAC} \tag{13}\]  
where one XOR fun is used to calculate \(K_{m}\), two modular exponentiation processes are implemented for the session key and hint calculation, and two HAMC fun operations are used for the validation and mac generation process. The communication cost of the ML-AKA protocol is analyzed in Table 4 and the calculated result of security system parameters generation and session key generation operations is shown in Figure 10. The results show that when the size of the security key length increases, the cost in terms of time also increases for all operations. Exceeding a length of 128 bits results in a linear increase in time cost. The validation result of ML-AKA also shows that, despite the larger size of \(len_{p}\), the session key generation time and MAC verification time should be approximately constant. Furthermore, to assess the performance of the proposed ML-AKA, it is compared with various existing protocols in terms of attack mitigation techniques. Table 5 outlines the ability of different protocols to mitigate various types of possible attacks in C-IoT networks. In the table, a \(\check{\check{\vee}}\) indicates capability, while a \(\times\) denotes incapability. From the table, it was observed that ML-AKA can able to mitigate DDoS, spoofing, MiTM, and reply attacks. Whereas other considered protocols are only able to mitigate some selective attacks. \begin{table}
\begin{tabular}{l l l} \hline
**Device Name** & **Phase** & **Time** \\ \hline Devices (\(D_{i}\)) & Phase 2 & \(2T_{KDF}\) \\  & Phase 3 & - \\  & Phase 4 & \(T_{r}+T_{xor}+2T_{modExp}+2T_{HMAC}\) \\ \hline Access Points (\(AP_{i}\)) & Phase 2 & \(T_{r}+T_{KDF}\) \\  & Phase 3 & - \\  & Phase 4 & \(T_{r}+T_{xor}\) \\ \hline eNodeB & Phase 2 & \(T_{r}+T_{xor}\) \\  & Phase 2 & - \\  & Phase 4 & - \\ \hline \end{tabular}
\end{table} 
Table 4: Communication cost computation of ML-AKA protocol. \begin{table}
\begin{tabular}{l l l} \hline  & **EPS-AKA** & **UAKA-D2D** & **ML-AKA** \\ \hline DDoS Mitigation & \(\check{\check{\vee}}\) & \(\check{\check{\vee}}\) \\ \hline Spoofing Attack & \(\times\) & \(\check{\check{\vee}}\) & \(\check{\check{\vee}}\) \\ \hline MIMT Attack & \(\times\) & \(\times\) & \(\check{\check{\vee}}\) \\ \hline Reply Attack & \(\check{\check{\vee}}\) & \(\check{\check{\vee}}\) & \(\check{\check{\vee}}\) \\ \hline \end{tabular}
\end{table}