2
$\begingroup$

Lets say there is mutual authentication between a client which connects to a server on an otherwise unsecured TCP channel. Both parties create a random challenge and the other side answers with a keyd-hash, based on a pre-shared symmetric key.

$$C\rightarrow open \,\, connection \rightarrow S$$ $$C\rightarrow challenge_C \rightarrow S$$ $$C\leftarrow challenge_S \leftarrow S$$

$$C\rightarrow H_K(challenge_S) \rightarrow S$$ $$C\leftarrow H_K(challenge_C) \leftarrow S$$

$$C \leftarrow authenticated \rightarrow S$$

However, an adversary "man-in-the-middle" could listen on the network by whatever means. Whenever a client C is going to establish a TCP connection to the server, MitM could at the same moment establish another adversary client session C' and inject all communication he listens between C and S into the session between C' and S, so C' gets authenticated against S.

It seems too simple - so where is my mistake?

Improve this question
$\endgroup$

1 Answer 1

Reset to default
4
$\begingroup$

It's not really that C or C` gets authenticated such that from then on S can trust data appearing to originate from C or C' in a general sense. If that were true, S would trust any plaintext unauthenticated information that appeared to be sent from C to S. That would clearly be liable to a man-in-the-middle attack, that just waited for the initial challenge-response steps to complete prior to then meddling with the information being communicated.

What's really happening in a secure protocol is that C and S mutually authenticate as part of a process to establish a symmetric session key that they then both use to communicate using authenticated symmetric encryption. This is what proves they are genuinely still talking to one another, and not a man-in-the-middle attacker.

If you don't care about having a per-session symmetric key so that there is forward secrecy, and if both sides maintain a long-term counter (to prevent replay attacks), then if you have a pre-shared symmetric key you could just jump directly to communicating via authenticated encryption (which uses and increments the counter with each message sent) without the need for the challenge-response steps you've outlined in your question.

Improve this answer
$\endgroup$
3
  • $\begingroup$ "If you don't care...": That was what always surprised me: a session is set up, but within this a pre-shared key is used without agreeing on a session key. What is the point of this session then? Yes, in the protocol I talk about there is the option to use a session key, but it is not mandatory and we don't use this option. Everything depends on not accepting double initialization vectors for GCM/GMAC. $\endgroup$
    – MichaelW
    Dec 6, 2021 at 10:47
  • 1
    $\begingroup$ @MichaelW if your IV for authenticated symmetric encryption is based on the challenges or challenge responses, then that would bind the encrypted channel to the challenge/response interchange that just occurred, and would protect you from a replay attack. $\endgroup$
    – knaccc
    Dec 6, 2021 at 11:29
  • 2
    $\begingroup$ @MichaelW if you both reliably maintained a list of previously used IVs, then that would prevent replay attacks where the server had already seen that IV. However, a MITM attacker could steal the IV and message and not let it reach the server, and then replay the message by hijacking a session that happens in the future. That is why if you're not cutting corners, the session should be bound to the challenge/response sequence either via an IV based on those challenges or via a newly determined session key based on the PSK and those challenges. $\endgroup$
    – knaccc
    Dec 6, 2021 at 12:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.