| Literature DB >> 28046075 |
Jaewook Jung1, Dongwoo Kang1, Donghoon Lee1, Dongho Won1.
Abstract
Nowadays, many hospitals and medical institutes employ an authentication protocol within electronic patient records (EPR) services in order to provide protected electronic transactions in e-medicine systems. In order to establish efficient and robust health care services, numerous studies have been carried out on authentication protocols. Recently, Li et al. proposed a user authenticated key agreement scheme according to EPR information systems, arguing that their scheme is able to resist various types of attacks and preserve diverse security properties. However, this scheme possesses critical vulnerabilities. First, the scheme cannot prevent off-line password guessing attacks and server spoofing attack, and cannot preserve user identity. Second, there is no password verification process with the failure to identify the correct password at the beginning of the login phase. Third, the mechanism of password change is incompetent, in that it induces inefficient communication in communicating with the server to change a user password. Therefore, we suggest an upgraded version of the user authenticated key agreement scheme that provides enhanced security. Our security and performance analysis shows that compared to other related schemes, our scheme not only improves the security level, but also ensures efficiency.Entities:
Mesh:
Year: 2017 PMID: 28046075 PMCID: PMC5207724 DOI: 10.1371/journal.pone.0169414
Source DB: PubMed Journal: PLoS One ISSN: 1932-6203 Impact factor: 3.240
Fig 1Integrated EPR information system.
Fig 2Li et al.’s authentication scheme.
Notations.
| Notations | Description |
|---|---|
| User | |
| EPR information system server | |
| Identity of | |
| Password of | |
|
| New password of |
| Number of times | |
| Biometric information of | |
| Secret number generated by | |
| Secret number generated by | |
| Secret key of | |
| Random number generated by | |
| Random number generated by | |
| One-way hash function | |
| Bio-hash function | |
| Concatenate operation | |
| ⊕ | XOR operation |
Fig 3Our proposed scheme.
Notations.
| Notations | Description |
|---|---|
| Condition | |
| Condition | |
| ♯( | It makes a fresh |
|
| |
| < | Combine condition |
| ( | Perform the hash operation on |
Security comparison of the proposed scheme and other related schemes.
| Features | Hao’s | Jiang’s | Chaudhry’s | Irshad’s | Wu’s | Das’s | Li’s | Proposed |
|---|---|---|---|---|---|---|---|---|
| Proposition 1. | √ | √ | √ | √ | × | √ | √ | √ |
| Proposition 2. | √ | √ | √ | √ | × | × | × | √ |
| Proposition 3. | √ | √ | √ | √ | √ | √ | √ | √ |
| Proposition 4. | × | × | √ | √ | × | × | × | √ |
| Proposition 5. | × | × | √ | √ | × | × | × | √ |
| Proposition 6. | × | × | √ | √ | × | × | × | √ |
| Proposition 7. | √ | √ | √ | √ | √ | √ | √ | √ |
| Proposition 8. | × | × | √ | √ | × | × | × | √ |
| Proposition 9. | × | √ | √ | × | × | × | × | √ |
| Proposition 10. | √ | √ | √ | √ | √ | √ | √ | √ |
| Proposition 11. | × | × | × | × | √ | √ | √ | √ |
| Proposition 12. | √ | √ | √ | √ | √ | √ | × | √ |
| Formal security proof | × | × | √ | √ | × | √ | √ | √ |
Algorithm .
| 1. Eavesdrop login request message 〈 |
| 2. Call the Reveal oracle. Let |
| 3. Eavesdrop login request message 〈 |
| 4. Call the Reveal oracle. Let |
| 5. Computes |
| 6. |
| 7. Accepts |
| 8. Call the Reveal oracle. Let |
| 9. |
| 10. Call the Reveal oracle. Let |
| 11. Computes |
| 12. |
| 13. Accept |
| |
| 14. |
| 15. |
| 16. |
| 17. |
| 18. |
| 19. |
| 20. |
| 21. |
| 22. |
| 23. |
Fig 4Architecture of AVISPA tool.
Fig 5Role specification in HLPSL for the user U.
Fig 6Role specification in HLPSL for the server S.
Fig 7Role specification in HLPSL for the session, environment and goal.
Fig 8Simulation results under the OFMC and CL-AtSe back-ends.
Performance comparison of the proposed scheme and other related schemes.
| Phases/Schemes | Lee et al. | Das | Mir et al. | Li et al. | Proposed |
|---|---|---|---|---|---|
| Registration phase | 4 | 4 | 5 | 4 | 4 |
| Login phase | 2 | 3 | 7 | 3 | 5 |
| Verification phase | 10 | 11 | 10 | 11 | 9 |
| Password change phase | 3 | 7 | 5 | 8 | 3 |
| Total cost | 19 | 25 | 27 | 26 | 21 |
| Execution time | ≈ 3.8ms | ≈ 5.0ms | ≈ 5.4ms | ≈ 5.2ms | ≈ 4.2ms |