# Provably Secure ECC-Based Anonymous Authentication and Key Agreement for IoT
## 7 Conclusions  
To begin, we reviewed the existing ECC-based AKA schemes. Then, we pointed out that the existing schemes failed to provide user anonymity and PFS and had no resistance to typical attacks (such as ESL, IM, MIM, KCl, etc.) with key escrow problems. The high computational and communication costs also made some of these solutions unsuitable for resource-limited IoT. Furthermore, the security proofs were conducted in the Random-Oracle model. It is widely recognized that cryptographic schemes proven secure in the Random-Oracle model may not necessarily provide the same level of security when implemented in real-world systems. We propose a security-enhanced AKA protocol for connecting IoT devices to servers to remedy the existing challenges. The session key security of the proposed scheme is rigorously proven under the eCK model with the elliptic curve encryption computational assumptions. The session key confidentiality and authentication properties are verified with ProVerif. Based on the performance comparison, it is found that the proposed scheme offers user anonymity, PFS, mutual authentication, and resistance to typical attacks such as ESL, IM, MIM, and KCl. Additionally, the proposed scheme has minimal computational and communication overhead compared to the existing schemes.  
Conceptualization, S.H., S.J. and Q.M.; methodology, S.H. and F.Y.; software, W.Z.; validation, S.H. and P.D.; formal analysis, S.H. and S.J.; investigation, S.H., S.J. and Q.M.; resources, S.H.; data curation, Q.M.; writing--original draft preparation, S.H. and F.Y.; writing--review and editing, S.H., S.J., Q.M., F.Y., W.Z. and P.D.; visualization, S.H.; supervision, S.H.; project administration, S.H.; funding acquisition, S.H. All authors have read and agreed to the published version of the manuscript.  
This research was supported in part by the Natural Science Foundation of China (No. 62072319).  
The data presented in this study are available on request from the corresponding author. The data are not publicly available due to privacy.  
The authors declare no conflicts of interest.  
The following abbreviations are used in this manuscript:  
\begin{table}
\begin{tabular}{c c c c c c c c c c c c c c} \hline \hline
**Scheme** & **SF1** & **SF2** & **SF3** & **SF4** & **SF5** & **SF6** & **SF7** & **SF8** & **SF9** & **SF10** & **SF11** & **SF12** \\ \hline
[22] & \(\times\) & \(\times\) & \(\surd\) & \(\times\) & \(\surd\) & \(\surd\) & \(\surd\) & \(\times\) & \(\surd\) & \(\surd\) & \(\times\) & \(\surd\) & \(\surd\) \\
[24] & \(\times\) & \(\times\) & \(\surd\) & \(\times\) & \(\surd\) & \(\surd\) & \(\surd\) & \(\surd\) & \(\surd\) & \(\surd\) & \(\surd\) & \(\times\) \\
[25] & \(\surd\) & \(\surd\) & \(\surd\) & \(\surd\) & \(\surd\) & \(\surd\) & \(\times\) & \(\surd\) & \(\surd\) & \(\surd\) & \(\surd\) & \(\times\) \\
[27] & \(\surd\) & \(\times\) & \(\surd\) & \(\surd\) & \(\surd\) & \(\surd\) & \(\surd\) & \(\surd\) & \(\surd\) & \(\surd\) & \(\times\) \\
[28] & \(\surd\) & \(\times\) & \(\surd\) & \(\surd\) & \(\times\) & \(\surd\) & \(\surd\) & \(\surd\) & \(\times\) & \(\surd\) & \(\surd\) & \(\surd\) \\
[29] & \(\surd\) & \(\surd\) & \(\surd\) & \(\times\) & \(\surd\) & \(\surd\) & \(\surd\) & \(\surd\) & \(\times\) & \(\surd\) & \(\surd\) & \(\surd\) \\ Ours & \(\surd\) & \(\surd\) & \(\surd\) & \(\surd\) & \(\surd\) & \(\surd\) & \(\surd\) & \(\surd\) & \(\surd\) & \(\surd\) & \(\surd\) & \(\surd\) \\ \hline \hline \end{tabular}  
* SF1: IM attack resistance; SF2: MIM attack resistance; SF3: Mutual authentication without the help of TA; SF4: ESL attack resistance; SF5: KCl attack; SF6: IoT nodes capture attack resistance; SF7: Anonymity; SF8: Unknown key share attack resistance; SF9: Perfect forward secrecy; SF10: Formal security proof; SF11: Replay attack resistance; SF12: No key escrow issue; \(\surd\): Secure or supportive \(\times\): Insecure or unsupported.  
\end{table}
Table 7: Performance comparison.