Mutual authentication or two-way authentication is the simultaneous and reciprocal authentication of two parties. It is part of authentication protocols, default 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. 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 is challenging, especially when schemes are desired to be lightweight and have low computational costs. Mutual authentication is a crucial security step that can defend against many adversarial attacks, 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.
Process steps and verification 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:
Alice sends a message encrypted with Bob's public key to Bob to show that Alice is a valid user. Bob verifies the message: Bob checks the format and timestamp. If either is incorrect or invalid, the session is aborted. The message is then decrypted with Bob's secret key, giving Alice's ID. Bob checks if the message matches a valid user. If not, the session is aborted. Bob sends Alice a message back, encrypted with Alice's public key, to show that Bob is a valid user. Alice verifies the message: Alice checks the format and timestamp. If either is incorrect or invalid, the session is aborted. The message is then decrypted with Alice's secret key, giving Bob's ID. Alice checks if the message matches a valid user. If not, the session is aborted. 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.
Defenses Mutual authentication supports zero trust networking because it can protect communications against adversarial attacks, 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. Replay attack
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 because timestamps are a verification factor that are used in the protocols. If the change in time is greater than the maximum allowed time delay, the session will be aborted. Similarly, messages can include a randomly generated number to keep track of when a message was sent. Spoofing attack
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. Impersonation attacks
Impersonation attacks refer to malicious attacks where a user or individual pretends to be an authorized user to gain unauthorized access to a system while feigning permission. 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. 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.
mTLS 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. As it requires provisioning of the certificates to the clients and involves a less user-friendly experience, it is 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.
… excerpt ends here. Continue reading the full article.
