2.4.1. Fast AKA Schemes Including ECQV-Based AKA
In certificate-based AKA, an implicit certificate is received after a user is registered by a CA in the form of a certificate. In ECQV-based AKA, authentication is performed by verifying the public key of the implicit certificate. However, ownership of the public key remains unknown. Because ECQV does not verify the integrity of a signature by reference to the digital signature of the public key like PKI, but performs authentication by calculating the public key of the implicit certificate, public key replacement and man-in-the-middle attacks are possible. This problem is the same for CL-AKA. The ECQV implicit certificate is small and efficient, but some problems are apparent. First, unlike an explicit certificate that explicitly validates another certificate, a signature, and a message, the ECQV system verifies a certificate and a public key by calculating the public key from another certificate without verifying the transmitted message; there is no signature function. Replay and spoofing attacks are also possible. The sender requests an implicit certificate from the CA. As this is being transmitted for authentication, the attacker seizes and retransmits it, thus pretending to be a legitimate sender. Therefore, an implicit certificate should not be used alone; additional key agreement should be ensured using a key calculated from the implicit certificate.
Recently, many AKA schemes that use the ECQV to protect against KGC masquerade and key replace attacks have been proposed. In both 2015 [17
] and 2017 [18
], Sciancalepore et al. developed efficient, ECQV-based, implicit certificate-based AKA protocols for IoT environments. However, the work of [17
] has a problem in that the session key generation information is exposed and there is no nonce in the message authentication code (MAC) value for the session information, so an external attacker could generate the session key by intercepting the transmitted data. Using this session key, masquerade attack was also possible. The work of [18
] solved the problem of generating a session key, as described above, but there was a problem that the transmitted data could be retransmitted and used.
In addition to this, many AKA schemes that are performed quickly are proposed, including [19
]. Abdmeziem et al. [19
] propose an end-to-end key management protocol for e-health applications. The authors of [19
] propose a protocol to ensure secure communication between constrained and unconstrained nodes using third parties. However, if a third party has malicious intent, there is a possibility of the session key being stolen and session hijacking through a man-in-the-middle attack.
Challa et al. [20
] proposed an AKA scheme for cloud-assisted cyber-physical system (CPS) in 2018. The authors of [20
] proposed a secure protocol for CPS environments such as smart grid through a trust authority, but a user masquerade attack is possible because the cloud server does not check the validity of the authentication request. In addition, there is a problem that communication can be performed without generating a session key.
Wazid et al. proposed [21
] in 2018. The authors of [21
] propose an authentication and key management protocol for a generic IoT network. A process in which a user performs a sensing node and lightweight AKA through a smartcard is proposed. They [21
] do not use public keys, only exclusive or (XOR) operation, hash operation, and symmetric key encryption/decryption. Therefore, compared with the public key schemes, it is more efficient in terms of operation time, but only provides safety depending on the symmetric key. In addition, there is the problem that a malicious intermediate object can pretend to be a node and a user.
The work of [22
] proposes an authentication and key management protocol for a cloud-assisted body area sensor network. A process in which a user executes a personal server and lightweight AKA through a mobile device is proposed. As in [21
], it is a scheme that uses only XOR, hash operation, and symmetric key encryption/decryption, but it is an improved scheme by reducing unnecessary communication processes in intermediate objects. However, because the public key is not used, non-repudiation is not provided, and safety of parameters needs to be considered. Until recently, Wazid proposed authentication and key management schemes for various environments such as cloud-based IoT [23
], fog computing services [24
], Internet of Drones (IoD) [25
], and implantable medical devices deployment [26
]. The basics of these schemes are the similar to [21
], and satisfy the security requirements in a specific environment.
2.4.2. CL-AKA Schemes
Generally, CL-AKA schemes feature the following six algorithms. The Set-Secret-Value, Set-Private-Key, and Set-Public-Key algorithms are employed by the user to set the secret and public key pair. In the key agreement phase, users A and B create a common session key required for encryption via message exchange.
Setup: the KGC generates a public parameter and a master secret key (security parameter inputs).
Partial-Key-Extract: the KGC generates a user’s partial private and public keys using the public parameter, master secret key, and user’s ID, and delivers it to the user.
Set-Secret-Value: the user creates secret information by inputting the public parameter and his/her ID.
Set-Private-Key: the user sets a private key by inputting the public parameter, partial private key, and secret information.
Set-Public-Key: the user sets a public key by inputting the public parameter, his/her partial public key, and secret information.
Key Agreement: users A and B generate messages using their IDs, public keys, and temporary keys. After exchanging messages, a common session key is generated using secret information. If the protocol is successful, the session keys generated by the two communicators will be identical.
CL-PKC-based authentication key agreement protocols without pairing were developed by Geng et al. [27
] and Hou et al. [28
] to increase computational efficiency. However, the public key used for AKA cannot be confirmed to be the public key of the sender, as described above. Efforts have been made to resolve this problem. Since then, many CL-AKA schemes have been proposed [29
]. There are two common security requirements for CL-PKC technologies. First, because the public key and identifier must be verified without a certificate, a replacement attack on the public key is possible, unlike the existing PKI-based cryptographic technology. This is an attack performed by an attacker by replacing the user’s public key with a value generated by the attacker, and occurs because there is no certificate that serves as a signature for the public key. In addition, in CL-PKC, KGC generates partial secret keys to users, and attacks performed using partial secret keys should be considered. Therefore, CL-AKA should also consider public key replacement attacks and partial private key attacks by malicious KGC.
Yang et al. [29
] proposed a certificateless key exchange scheme that does not use pairing operation in 2011. Although we propose AKA based on Diffie–Hellman key exchange between users who generated ID-based partial private keys through KGC, they are vulnerable to public key replacement attacks. The attacker can perform the authentication and key agreement process by being disguised as a legitimate participant through public key replacement, and can also generate the session key.
Kim et al. [30
] proposed efficient CL-AKA between two objects in 2013. However, it is possible to perform a masquerade attack by retransmitting a value for generating session key as public key replacement attack.
Farouk et al. [31
] proposes a two-party CL-AKA for the grid computing environment, but masquerade attack is also possible through public key replacement attack, and there is the problem that an attacker can legitimately generate a key. In addition, Xie et al. [32
] and Park et al. [33
] proposed pairing-free CL-AKA in 2016, but both schemes can perform masquerade attacks through public key replacement.
In Sun et al. [34
] and Simplicio Jr et al. [35
], because the partial key generated by KGC contains only the information of the user’s identifier and the verification tag, only the identifier can actually be checked. Later, Xie et al. [36
] and Daniel et al. [37
] solve this problem by including the information of verification public key generated by the user and the identifier in the partial key generated by KGC. However, public key replacement attacks are also possible in [36
]. The authors of [37
] argued that there was no problem even if the partial key generated by KGC was transmitted publicly. However, if a partial key is transmitted publicly, anyone can create values that are used as input when performing hash operation on the value to be authenticated. Therefore, it is necessary to consider parameter safety.