Score:1

Crypto

Is this kind of mutual Authentication safe?

MichaelW

4/4/23, 12:16 PM

The following is a real-world problem. In a standardized protocol clients can connect to a server using mutual 4-pass authentication on an otherwise unsecured TCP channel:

pass-1: Client send random Challenge C to server
pass-2: Server answers by sending random challenge S to client
pass-3: Client prepares res(S, K) and send it to S
pass-4: Server answers to client with res(C, K)

res(.) is GCM-GMAC tag that depends on a symmetric key K (in fact AES128, but this might not be relevant here)

Once mutual authentication is successful, client and server can continue to communicate under a so called "association", e.g. client can request some data from server.

However, what happens if an attacker (not having the key) is listening on the network and starts a man-in-the-middle as well as a malicious client (red). When the real client starts pass-1 and sends C1 to server, at the same time the bad client sends C2. The server responds to both requests, but MitM manages to inject S2 to be sent to the good client, which prepares res(S2) and send it over to the server. But MitM captures res(S2) and inject it as pass-3 to be sent to the server. Now the server authenticates the bad client and sends back res(C2), which is just ignored by the bad-client. So a seemingly mutually authenticated connection has been established between the bad client and server.

I wonder, whether this kind of mutual authentication is really effective.

0 + 0

authentication

challenge-response

Maarten Bodewes

4/4/23, 12:31 PM

In above schemes the keys are missing. I don't think your MitM attack is possible with the right key management. Worse, without the key management part the question can probably not be answered fully, and I don't like it when users have to guess which and what type of keys could be used. Please [edit] your question to include the keys.

knaccc

4/4/23, 1:49 PM

You should use a session key that is based on random data from both client and server, so that you are not vulnerable to a replay attack. You should also think about establishing and rotating the session key over time (if sessions are long-running) so that you have forward secrecy.

MichaelW

4/4/23, 7:25 PM

@Maarten Bodewes: I updated the pictures with the Key. It is just a pre-shared AES128 key from which by GCM-GMAC a tag is produced: Res(S, K) = GMAC(S, K, IV), with a initialization vector which is always incremented .

MichaelW

4/4/23, 7:30 PM

@knaccc: This protocol is neither my "invention" nor possible to change. I want just understand.

knaccc

4/4/23, 7:44 PM

@MichaelW are you saying that the 128-bit key K is directly used as the encryption/decryption key for the session, where encryption is performed using AES128?

MichaelW

4/4/23, 7:49 PM

@knaccc: yes, K is used for generating the tag which is used for mutual authentication, as well for encryption/authentication of messages after such session has been established. Maybe I don't understand your question.

knaccc

4/4/23, 7:53 PM

If K is directly used as the AES128 key for session communication, rather than creating a new symmetric key based on K and C1 and S1, then a MITM attack can simply wait for a session to become fully authenticated and then mount a replay attack where it sends a copy of a previously observed encrypted request in order to trick the server into doing something. I'd therefore not consider session communications to be properly authenticated.

MichaelW

4/4/23, 7:59 PM

@knaccc: request messages can optionally be attached with an authentication tag; this tag depends on an initialization vector which must be different each time and not repeated (in fact there is a counter which increases each time). So a simple replay would be blocked by the server.

knaccc

4/4/23, 8:13 PM

If you're not binding the session key to the authentication challenges and not using authenticated encryption, then you're violating the Cryptographic Doom Principle https://moxie.org/2011/12/13/the-cryptographic-doom-principle.html

MichaelW

4/4/23, 8:32 PM

hmmm...after setup of authenticated session the same pre-shared key is always used. However, there is a so called frame counter, which must be increased every time and which flows into the initialization vector for GCM-GMAC. This is a little bit aside my original question, but anyway, I'll read the article because it looks interesting.