Security Comparison Clause Samples

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 ▇▇▇▇▇▇▇ and ▇▇▇▇▇▇▇▇▇▇▇ is a group password-based key agreement [15]. • Protocol #2 proposed by ▇▇▇▇▇ and Barua is a group password-based authentication key agreement [16]. • Protocol #3 proposed by ▇▇▇ et al. is a group key agreement [3]. • Protocol #4 proposed by ▇▇▇▇ and ▇▇▇▇▇ is a group key agreement [17]. • Protocol #5 proposed by ▇▇▇ et al. is a group password-based authentication key agreement [8].
View SourceView Similar (2)
Security Comparison. In this section, we compare the security performance of ▇▇▇▇▇ et al.’s scheme [27], ▇▇▇▇▇ 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], ▇▇▇▇▇ et al.’s scheme does not provide identity anonymity and it cannot provide defense against impersonation attack. We find that the ▇▇▇▇▇ 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.
View Source
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 ▇▇▇-▇▇▇ [4] No Yes Yes No No No No No No No ▇▇▇ et al. [24] No Yes Yes No Yes Yes No No No No ▇▇ et al. [21] No No Yes No Yes Yes No No No No ▇▇-▇▇▇▇ [22] Yes No Yes No Yes Yes No No No No ▇▇▇▇ et al. [28] Yes Yes Yes No Yes Yes No No No No ▇▇-▇▇▇▇▇ [29] Yes Yes Yes No Yes Yes No No No No ▇▇▇▇ et al. [30] Yes Yes Yes No Yes Yes No No No No ▇▇▇ 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.
View Source

Related to Security Comparison

  • Security Controls Annually, upon Fund’s reasonable request, DST shall provide Fund’s Chief Information Security Officer or his or her designee with a summary of its corporate information security policy and an opportunity to discuss DST’s information security measures, and a high level and non-confidential summary of any penetration testing related to the provision of in-scope services . DST shall review its Security Policy annually.

  • Security Cameras Security cameras have been installed throughout the Facility; however, they will not routinely be used in areas where there is an expectation of privacy, such as restrooms or patient care areas.

  • Security Management The Contractor shall comply with the requirements of the DOD 5200.1-M and the DD Form 254. Security of the Contractor’s electronic media shall be in accordance with the above documents. Effective Program Security shall require the Contractor to address Information Security and Operations Security enabled by the Security Classification Guides. The Contractor’s facility must be able to handle and store material up to the Classification Level as referenced in Attachment J-01, DD Form 254.

  • Security Contact Operator shall provide the name and contact information of Operator's Security Contact on Exhibit F. The LEA may direct security concerns or questions to the Security Contact.

  • Security Systems The Service may not be compatible with security systems. You may be required to maintain a telephone connection through your local exchange carrier in order to use any alarm monitoring functions for any security system installed in your home or business. You are responsible for contacting the alarm monitoring company to test the compatibility of any alarm monitoring or security system with the Service.