Security Comparison. The overall comparison between PL-GAKA and related approaches are shown in Table 2. We refer to [8] for considering the following protocols: • Protocol #1 proposed by Xxxxxxx and Xxxxxxxxxxx is a group password-based key agreement [15]. • Protocol #2 proposed by Xxxxx and Barua is a group password-based authentication key agreement [16]. • Protocol #3 proposed by Xxx et al. is a group key agreement [3]. • Protocol #4 proposed by Xxxx and Xxxxx is a group key agreement [17]. • Protocol #5 proposed by Xxx et al. is a group password-based authentication key agreement [8].
Security Comparison. In this section, we compare the security performance of Xxxxx et al.’s scheme [27], Xxxxx et al.’s scheme [28], Li et al.’s scheme [29] and our scheme. Let S1, S2, S3, S4, S5, S6, S7, S8, S9 denote mutual authentication, session key agreement, identity anonymity, identity traceability, perfect forward security, resistance of replay attack, resistance of mam-in-the-middle attack, resistance of impersonation attack and resistance of tampering attack, respectively. The compar- isons are shown in Table I. According to Amin and Biswas [36], Xxxxx et al.’s scheme does not provide identity anonymity and it cannot provide defense against impersonation attack. We find that the Xxxxx et al.’s scheme does not provide identity anonymity and identity traceability. We also find that Li et al.’s scheme does not achieve identity traceability. However, our scheme can provide all of the security requirements in the Table I.
Security Comparison. In Table 3, we have tabulated an overall security comparison among our scheme and other related DBAKA schemes [4, 21-22, 24, 28-32]. Table 3 shows that the proposed scheme has removed the vulnerability of DBAKA protocols in [29-32], e.g. known key attacks. None of these schemes in [4, 21-22, 24, 28-32] provide communication confidentiality. Furthermore, the existing DBAKA protocols always require that VLR and HLR must share secrets in advance. It is inconvenient for the delegation-based authentication protocols. For each HLR, there are always a great many of VLRs in global mobility networks. In order to provide roaming registered mobile users with access service, each HLR has to share a secret with as many as VLRs, some of which are far geographically from HLR, even in different countries. In addition, since HLR also works as a VLR, HLR (as a VLR) must store shared secrets. Our DBAKA protocol does not require VLR and HLR to share any secret key in advance. Table 3. Comparison of security features among different schemes Scheme F1 F2 F3 F4 F5 F6 F7 F8 F9 F10 Xxx-Xxx [4] No Yes Yes No No No No No No No Xxx et al. [24] No Yes Yes No Yes Yes No No No No Xx et al. [21] No No Yes No Yes Yes No No No No Xx-Xxxx [22] Yes No Yes No Yes Yes No No No No Xxxx et al. [28] Yes Yes Yes No Yes Yes No No No No Xx-Xxxxx [29] Yes Yes Yes No Yes Yes No No No No Xxxx et al. [30] Yes Yes Yes No Yes Yes No No No No Xxx et al. [31] Yes Yes Yes No Yes Yes No No No No Hwang-You [32] Yes Yes Yes No Yes Yes No No No Yes Ours Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes F1: whether withstands denial-of-service attack or not; F2: whether withstands request replication attack or not; F3: whether withstands impersonation attack or not; F4: whether withstands known-key attack or not; F5: whether provides mutual authentication or not; F6: whether provides non-repudiation or not; F7: whether provides weak un-traceability or not; F8: whether provides communication confidentiality or not; F9: whether provides key confirmation or not; F10: whether requires no secrets pre-sharing or not. It is observed that our scheme outperforms other recently proposed existing DBAKA schemes as our scheme is secure and supports extra features.
