Mutual authentication

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search

Mutual authentication or two-way authentication (not to be confused with two-factor authentication) refers to two parties authenticating each other at the same time in an authentication protocol. It was previously referred to as “mutual entity authentication,”[citation needed] as two or more entities verify the others' legality before any data or information is transmitted.[1] It is a default mode of authentication in some protocols (IKE, SSH) and optional in others (TLS).

Mutual authentication is a desired characteristic in verification schemes that transmit sensitive data, in order to ensure data security.[1][2][3] Mutual authentication can be accomplished with two types of credentials: usernames and passwords, and public key certificates.

Mutual authentication is often employed in the Internet of Things (IoT). Writing effective security schemes in IoT systems can become challenging, especially when needing schemes to be lightweight and have low computational costs. Mutual authentication is a crucial security step that can defend against many adversarial attacks,[4] which otherwise can have large consequences if IoT systems (such as e-Healthcare servers) are hacked. In scheme analyses done of past works, a lack of mutual authentication had been considered a weakness in data transmission schemes.[5]

Process steps and verification[edit]

Schemes that have a mutual authentication step may use different methods of encryption, communication, and verification, but they all share one thing in common: each entity involved in the communication is verified. If Alice wants to communicate with Bob, they will both authenticate the other and verify that it is who they are expecting to communicate with before any data or messages are transmitted. A mutual authentication process that exchanges user IDs may be implemented as follows:[citation needed]

  1. Alice sends an encrypted message to Bob to show that Alice is a valid user.
  2. Bob verifies message:
    1. Bob checks the format and timestamp. If either is incorrect or invalid, the session is aborted.
    2. The message is then unscrambled with Bob's secret key and Alice's ID.
      1. Bob checks if the message matches a valid user. If not, the session is aborted.
  3. Bob sends Alice a message back to show that Bob is a valid user.
  4. Alice verifies the message:
    1. Alice checks the format and timestamp. If either is incorrect or invalid, the session is aborted.
    2. Then, the message is unscrambled with Alice's secret key and Bob's ID.
      1. Alice checks if the message matches a valid user. If not, the session is aborted.
  5. At this point, both parties are verified to be who they claim to be and safe for the other to communicate with. Lastly, Alice and Bob will create a shared secret key so that they can continue communicating in a secure manner.

To verify that mutual authentication has occurred successfully, Burrows-Abadi-Needham logic (BAN logic) is a well regarded and widely accepted method to use, because it verifies that a message came from a trustworthy entity. BAN logic first assumes an entity is not to be trusted, and then will verify its legality.[1][2][6][7]


Mutual authentication supports zero trust networking because it can protect communications against adversarial attacks,[8] notably:

  • Man in the middle attack: Man-in-the-middle (MITM) attacks are when a third party wishes to eavesdrop or intercept a message, and sometimes alter the intended message for the recipient. The two parties openly receive messages without verifying the sender, so they do not realize an adversary has inserted themselves into the communication line. Mutual authentication can prevent MITM attacks because both the sender and recipient verify each other before sending them their message keys, so if one of the parties is not verified to be who they claim they are, the session will end.[9]
  • Replay attacks: A replay attack is similar to a MITM attack in which older messages are replayed out of context to fool the server. However, this does not work against schemes using mutual authentication[10] because timestamps are a verification factor that are used in the protocols.[11][12] If the change in time is greater than the maximum allowed time delay, the session will be aborted.[12] Similarly, messages can include a randomly generated number to keep track of when a message was sent.[11]
  • Spoofing attacks: Spoofing attacks rely on using false data to pose as another user in order to gain access to a server or be identified as someone else. Mutual authentication can prevent spoofing attacks because the server will authenticate the user as well, and verify that they have the correct session key before allowing any further communication and access.[12]
  • Impersonation attacks: When each party authenticates the other, they send each other a certificate that only the other party knows how to unscramble, verifying themselves as a trusted source. In this way, adversaries cannot use impersonation attacks because they do not have the correct certificate to act as if they are the other party.[6]

Mutual authentication also ensures information integrity because if the parties are verified to be the correct source, then the information received is reliable as well.[6]


By default the TLS protocol only proves the identity of the server to the client using X.509 certificates, and the authentication of the client to the server is left to the application layer. TLS also offers client-to-server authentication using client-side X.509 authentication.[13] As it requires provisioning of the certificates to the clients and involves less user-friendly experience, it's rarely used in end-user applications.

Mutual TLS authentication (mTLS) is more often used in business-to-business (B2B) applications, where a limited number of programmatic and homogeneous clients are connecting to specific web services, the operational burden is limited, and security requirements are usually much higher as compared to consumer environments.

mTLS is also used in microservices-based applications based on runtimes such as Dapr, via systems like SPIFFE.[8]

Lightweight schemes vs. secured schemes[edit]

While lightweight schemes and secure schemes are not mutually exclusive, adding a mutual authentication step to data transmissions protocols can often increase performance runtime and computational costs.[2] This can become an issue for network systems that cannot handle large amounts of data or those that constantly have to update for new real-time data (e.g. location tracking, real-time health data).[2][10]

Thus, it becomes a desired characteristic of many mutual authentication schemes to have lightweight properties (e.g. have a low memory footprint) in order to accommodate the system that is storing a lot of data.[4] Many systems implement cloud computing, which allows quick access to large amounts of data, but sometimes large amounts of data can slow down communication. Even with edge-based cloud computing, which is faster than general cloud computing due to a closer proximity between the server and user,[6] lightweight schemes allow for more speed when managing larger amounts of data. One solution to keep schemes lightweight during the mutual authentication process is to limit the number of bits used during communication.[4]

Applications that solely rely on device-to-device (D2D) communication, where multiple devices can communicate locally in close proximities, removes the third party network. This in turn can speed up communication time.[14] However, the authentication still occurs through insecure channels, so researchers believe it is still important to ensure mutual authentication occurs in order to keep a secure scheme.[14]

Schemes may sacrifice a better runtime or storage cost when ensuring mutual authentication in order to prioritize protecting the sensitive data.[2][12]

Password-based schemes[edit]

In mutual authentication schemes that require a user's inputted password as part of the verification process, there is a higher vulnerability to hackers because the password is human-made rather than a computer-generated certificate. While applications could simply require users to use a computer-generated password, it is inconvenient for people to remember. User-made passwords and the ability to change one's password are important for making an application user-friendly,[15] so many schemes work to accommodate the characteristic. Researchers note that a password based protocol with mutual authentication is important because user identities and passwords are still protected, as the messages are only readable to the two parties involved.[16]

However, a negative aspect about password-based authentication is that password tables can take up a lot of memory space.[15] One way around using a lot of memory during a password-based authentication scheme is to implement one-time passwords (OTP), which is a password sent to the user via SMS or email. OTPs are time-sensitive, which means that they will expire after a certain amount of time and that memory does not need to be stored.[17]

Multi-factor authentication[edit]

Recently, more schemes have higher level authentication than password based schemes. While password-based authentication is considered as "single-factor authentication," schemes are beginning to implement smart card (two-factor)[15] or biometric-based (three-factor) authentication schemes. Smart cards are simpler to implement and easy for authentication, but still have risks of being tampered with.[15] Biometrics have grown more popular over password-based schemes because it is more difficult to copy or guess session keys when using biometrics,[7] but it can be difficult to encrypt noisy data.[17] Due to these security risks and limitations, schemes can still employ mutual authentication regardless of how many authentication factors are added.[7]

Certificate based schemes and system applications[edit]

Mutual authentication is often found in schemes employed in the Internet of Things (IoT), where physical objects are incorporated into the Internet and can communicate via IP address.[11] Authentication schemes can be applied to many types of systems that involve data transmission.[14] As the Internet's presence in mechanical systems increases, writing effective security schemes for large numbers of users, objects, and servers can become challenging, especially when needing schemes to be lightweight and have low computational costs. Instead of password-based authentication, devices will use certificates to verify each other's identities.

Radio networks[edit]

Mutual authentication can be satisfied in radio network schemes, where data transmissions through radio frequencies are secure after verifying the sender and receiver.[12][18]

Radio frequency identification (RFID) tags are commonly used for object detection, which many manufacturers are implementing into their warehouse systems for automation.[19] This allows for a faster way to keep up with inventory and track objects. However, keeping track of items in a system with RFID tags that transmit data to a cloud server increases the chances of security risks, as there are now more digital elements to keep track of.[19] A three way mutual authentication can occur between RFID tags, the tag readers, and the cloud network that stores this data in order to keep RFID tag data secure and unable to be manipulated.[19]

Similarly, an alternate RFID tag and reader system that assigns designated readers to tags has been proposed for extra security and low memory cost.[20] Instead of considering all tag readers as one entity, only certain readers can read specific tags. With this method, if a reader is breached, it will not affect the whole system. Individual readers will communicate with specific tags during mutual authentication, which runs in constant time as readers use the same private key for the authentication process.

Many e-Healthcare systems that remotely monitor patient health data use wireless body area networks (WBAN) that transmit data through radio frequencies.[12] This is beneficial for patients that should not be disturbed while being monitored, and can reduced the workload for medical worker and allow them to focus on the more hands-on jobs. However, a large concern for healthcare providers and patients about using remote health data tracking is that sensitive patient data is being transmitted through unsecured channels,[9] so authentication occurs between the medical body area network user (the patient), the Healthcare Service Provider (HSP) and the trusted third party.

Cloud based computing[edit]

e-Healthcare clouds are another way to store patient data collected remotely.[2] Clouds are useful for storing large amounts of data, such as medical information, that can be accessed by many devices whenever needed. Telecare Medical Information Systems (TMIS), an important way for medical patients to receive healthcare remotely, can ensure secured data with mutual authentication verification schemes.[14] Blockchain is one way that has been proposed to mutually authenticate the user to the database, by authenticating with the main mediBchain node and keeping patient anonymity.[21]

Fog-cloud computing is a networking system that can handle large amounts of data, but still has limitations regarding computational and memory cost.[22] Mobile edge computing (MEC) is considered to be an improved, more lightweight fog-cloud computing networking system,[22] and can be used for medical technology that also revolves around location-based data. Due to the large physical range required of locational tracking, 5G networks can send data to the edge of the cloud to store data. An application like smart watches that track patient health data can be used to call the nearest hospital if the patient shows a negative change in vitals.[6]

Fog node networks can be implemented in car automation, keeping data about the car and its surrounding states secure. By authenticating the fog nodes and the vehicle, vehicular handoff becomes a safe process and the car’s system is safe from hackers.[10]

Machine to machine verification[edit]

Many systems that do not require a human user as part of the system also have protocols that mutually authenticate between parties. In unmanned aerial vehicle (UAV) systems, a platform authentication occurs rather than user authentication.[2] Mutual authentication during vehicle communication prevents one vehicle's system from being breached, which can then affect the whole system negatively. For example, a system of drones can be employed for agriculture work and cargo delivery, but if one drone were to be breached, the whole system has the potential to collapse.[2][23]

See also[edit]

External links[edit]


  1. ^ a b c Chen, Yulei; Chen, Jianhua (2020). "A secure three-factor-based authentication with key agreement protocol for e-Health clouds". The Journal of Supercomputing. doi:10.1007/s11227-020-03395-8. S2CID 221146362.
  2. ^ a b c d e f g h Chen, Liquan; Qian, Sijie; Lim, Ming; Wang, Shihui (2018). "An enhanced direct anonymous attestation scheme with mutual authentication for network-connected UAV communication systems". China Communications. 15 (5): 61–76. doi:10.1109/CC.2018.8387987. S2CID 49333360.
  3. ^ doi:10.1371/journal.pone.023227
  4. ^ a b c Jan, Mian Ahmad; Khan, Fazlullah; Alam, Muhammad; Usman, Muhammad (2019). "A payload-based mutual authentication scheme for Internet of Things". Future Generation Computer Systems. 92: 1028–1039. doi:10.1016/j.future.2017.08.035. hdl:10453/117906.
  5. ^ Amin, Ruhul; Islam, SK Hafizul; Vijayakumar, Pandi; Khan, Muhammad Khurram; Chang, Victor (2018). "A robust and efficient bilinear pairing based mutual authentication and session key verification over insecure communication". Multimedia Tools and Applications. 77 (9): 11041–11066. doi:10.1007/s11042-017-4996-z. S2CID 13674284.
  6. ^ a b c d e Chen, Chin-Ling; Chiang, Mao-Lun; Hsieh, Hui-Ching; Liu, Ching-Cheng; Deng, Yong-Yuan (2020). "A Lightweight Mutual Authentication with Wearable Device in Location-Based Mobile Edge Computing". Wireless Personal Communications. 113: 575–598. doi:10.1007/s11277-020-07240-2. S2CID 218934756.
  7. ^ a b c Sahoo, Shreeya Swagatika; Mohanty, Sujata; Majhi, Banshidhar (2020). "Improved Biometric-Based Mutual Authentication and Key Agreement Scheme Using ECC". Wireless Personal Communications. 111 (2): 991–1017. doi:10.1007/s11277-019-06897-8. S2CID 208125038.
  8. ^ a b "Mutual TLS: Securing Microservices in Service Mesh". The New Stack. 2021-02-01. Retrieved 2021-02-20.
  9. ^ a b Sasikaladevi, N.; Malathi, D. (2019). "Energy Efficient Lightweight Mutual Authentication Protocol (REAP) for MBAN Based on Genus-2 Hyper-Elliptic Curve". Wireless Personal Communications. 109 (4): 2471–2488. doi:10.1007/s11277-019-06693-4.
  10. ^ a b c Dewanta, Favian; Mambo, Masahiro (2019). "A Mutual Authentication Scheme for Secure Fog Computing Service Handover in Vehicular Network Environment". IEEE Access. 7: 103095–103114. doi:10.1109/ACCESS.2019.2931217. S2CID 199509951.
  11. ^ a b c Melki, Reem; Noura, Hassan N.; Chehab, Ali (2020). "Lightweight multi-factor mutual authentication protocol for IoT devices". International Journal of Information Security. 19 (6): 679–694. doi:10.1007/s10207-019-00484-5. S2CID 209340123.
  12. ^ a b c d e f Narwal, Bhawna; Mohapatra, Amar Kumar (2020). "SEEMAKA: Secured Energy-Efficient Mutual Authentication and Key Agreement Scheme for Wireless Body Area Networks". Wireless Personal Communications. 113 (4): 1985–2008. doi:10.1007/s11277-020-07304-3. S2CID 216529906.
  13. ^ <>, Tim Dierks. "The Transport Layer Security (TLS) Protocol Version 1.2". Retrieved 2016-04-22.
  14. ^ a b c d g. Lopes, Ana Paula; Gondim, Paulo R. L. (2020). "Mutual Authentication Protocol for D2D Communications in a Cloud-Based E-Health System". Sensors. 20 (7): 2072. doi:10.3390/s20072072. PMC 7181216. PMID 32272675.
  15. ^ a b c d Karuppiah, Marimuthu; Saravanan, R. (2015). "Cryptanalysis and an Improvement of New Remote Mutual Authentication Scheme using Smart Cards". Journal of Discrete Mathematical Sciences and Cryptography. 18 (5): 623–649. doi:10.1080/09720529.2015.1013693. S2CID 62591965.
  16. ^ Karuppiah, Marimuthu; Das, Ashok Kumar; Li, Xiong; Kumari, Saru; Wu, Fan; Chaudhry, Shehzad Ashraf; Niranchana, R. (2019). "Secure Remote User Mutual Authentication Scheme with Key Agreement for Cloud Environment". Mobile Networks and Applications. 24 (3): 1046–1062. doi:10.1007/s11036-018-1061-8. S2CID 64720667.
  17. ^ a b Sharma, Mohit Kr; Nene, Manisha J. (2020). "Two‐factor authentication using biometric based quantum operations". Security and Privacy. 3 (3). doi:10.1002/spy2.102.
  18. ^ Choudhary, Karanjeet; Gaba, Gurjot Singh; Butun, Ismail; Kumar, Pardeep (2020). "MAKE-IT—A Lightweight Mutual Authentication and Key Exchange Protocol for Industrial Internet of Things". Sensors. 20 (18): 5166. doi:10.3390/s20185166. PMC 7570918. PMID 32927788.
  19. ^ a b c Anandhi, S.; Anitha, R.; Sureshkumar, Venkatasamy (2020). "An Authentication Protocol to Track an Object with Multiple RFID Tags Using Cloud Computing Environment". Wireless Personal Communications. 113 (4): 2339–2361. doi:10.1007/s11277-020-07330-1. S2CID 219070999.
  20. ^ Guo, Fuchun; Mu, Yi; Susilo, Willy; Varadharajan, Vijay (2017). "Privacy-Preserving Mutual Authentication in RFID with Designated Readers". Wireless Personal Communications. 96 (3): 4819–4845. doi:10.1007/s11277-017-4430-x. S2CID 207264759.
  21. ^ Liu, Xiaoxue; Ma, Wenping; Cao, Hao (2019). "MBPA: A Medibchain-Based Privacy-Preserving Mutual Authentication in TMIS for Mobile Medical Cloud Architecture". IEEE Access. 7: 149282–149298. doi:10.1109/ACCESS.2019.2947313. S2CID 204863294.
  22. ^ a b Liu, Xiaoxue; Ma, Wenping; Cao, Hao (2019). "NPMA: A Novel Privacy-Preserving Mutual Authentication in TMIS for Mobile Edge-Cloud Architecture". Journal of Medical Systems. 43 (10): 318. doi:10.1007/s10916-019-1444-9. PMID 31522286. S2CID 202570185.
  23. ^ Sharma, Abhishek; Basnayaka, Chathuranga M.Wijerathna; Jayakody, Dushantha Nalin K. (May 2020). "Communication and networking technologies for UAVs: A survey". Journal of Network and Computer Applications. 168: 102739. arXiv:2009.02280. doi:10.1016/j.jnca.2020.102739. S2CID 221507920.