## 8 NS2 Simulation Study
### Simulation Parameters  
The specifics of the network parameters used in the NS2 simulation are given in Table 5. The simulation time was 30 min (1800 s). \(S_{j}\) and \(CS_{j}\) respectively represent the \(j\)th sensor node and cloud server, whereas \(U_{i}/D_{i}\) represents the \(i\)th user/IoT smart device respectively in LDAKM-EIoT and other schemes [3; 21]. Moreover, we took one gateway node \((GW)\)/edge node \((EN)\) in all the compared schemes. The communication range of smart device or sensor was taken as 100 m. The messages  
\begin{table}
\begin{tabular}{c c c c c c c} \hline \hline
**Feature** & **[PERSON] et al. [21]** & **[PERSON] et al. [3]** & **[PERSON] et al. [18]** & **[PERSON] and [PERSON] [39]** & **[PERSON] et al. [41]** & **LDAKM-EIoT** \\ \hline \(FSF_{1}\) & \(\times\) & ✓ & ✓ & \(\times\) & ✓ & ✓ \\ \(FSF_{2}\) & \(\times\) & ✓ & \(\times\) & \(\times\) & \(\times\) & ✓ \\ \(FSF_{3}\) & \(\times\) & ✓ & \(\times\) & \(\times\) & ✓ & ✓ \\ \(FSF_{4}\) & \(\times\) & ✓ & \(\times\) & \(\times\) & ✓ & NA \\ \(FSF_{5}\) & ✓ & ✓ & ✓ & ✓ & ✓ & ✓ \\ \(FSF_{6}\) & \(\times\) & ✓ & \(\times\) & ✓ & \(\times\) & NA \\ \(FSF_{7}\) & ✓ & ✓ & ✓ & ✓ & \(\times\) & ✓ \\ \(FSF_{8}\) & ✓ & ✓ & ✓ & ✓ & \(\times\) & ✓ \\ \(FSF_{9}\) & ✓ & ✓ & ✓ & ✓ & \(\times\) & ✓ \\ \(FSF_{10}\) & ✓ & ✓ & ✓ & ✓ & ✓ & ✓ \\ \(FSF_{11}\) & ✓ & \(\times\) & \(\times\) & ✓ & ✓ & ✓ \\ \(FSF_{12}\) & ✓ & ✓ & ✓ & ✓ & NA & ✓ \\ \(FSF_{13}\) & ✓ & ✓ & ✓ & ✓ & \(\times\) & NA \\ \(FSF_{14}\) & ✓ & \(\times\) & ✓ & ✓ & NA & ✓ \\ \(FSF_{15}\) & NA & ✓ & \(\times\) & \(\times\) & \(\times\) & NA \\ \(FSF_{16}\) & ✓ & ✓ & \(\times\) & ✓ & ✓ & ✓ \\ \(FSF_{17}\) & \(\times\) & ✓ & \(\times\) & \(\times\) & \(\times\) & NA \\ \(FSF_{18}\) & \(\times\) & ✓ & ✓ & \(\times\) & \(\times\) & ✓ \\ \hline \hline \end{tabular} Note: \(FSF_{1}\): the property to make the user or smart IoT device anonymous; \(FSF_{2}\): protection for privileged-insider attack; \(FSF_{3}\): protection for off-line password guessing attack; \(FSF_{4}\): protection for stolen smart card or mobile device; \(FSF_{5}\): protection for denial-of-service attack; \(FSF_{6}\): protection for user impersonation attack; \(FSF_{7}\): protection for replay attack; \(FSF_{8}\): protection for man-in-the middle attack; \(FSF_{9}\): achieves mutual authentication; \(FSF_{10}\): achieves session key agreement; \(FSF_{11}\): property to make messages untraceability; \(FSF_{12}\): protection for sensor node/sensor/smart IoT device physical capture attack; \(FSF_{13}\): presence of server independent password update phase; \(FSF_{4}\): protection for sensor node/sensing device/smart IoT device impersonation attack; \(FSF_{15}\): support biometric update phase; \(FSF_{16}\): provide formal security verification using the automated software verification tool; \(FSF_{17}\): presence of the smart card revocation phase; \(FSF_{18}\): protection for session-key security under the CK adversary model. \(\times\): insecure against a “specific attack” or a “particular feature” is not there; ✓: secure against a “specific attack” or a “particular feature” is present; NA: not applicable.  
\end{table}
Table 4: Comparison of functionality and security features.  
exchanged among different communicating entities along with their communication costs (in bits) for different schemes are depicted in Table 6, which were used in the simulation for exchanging the packets (messages) among the entities. We applied the ad hoc on-demand distance vector (AODV) [58] as the routing protocol. All other parameters used in the simulation were taken as standard ones.