0

Are all challenge-response (or other authentication) protocols vulnerable to on-line main-in-the-middle attacks?

Let's say Alice wants to setup a connection with Bob (e.g. she wants to login on a server). Bob sends her a random number, r. Alice then replies with a MAC of the random number, using her password. Bob knows that only Alice can do this and logs her into the server.

But what if, during all this time, there was an on-line adversary between Alice and Bob. He can intercept r and sent it to Alice himself. He could spoof the IP of the server so Alice thinks it's coming from Bob. Alice then sends her response and again the adversary intercepts it and sends it to the server. The adversary just forwarded the message so Bob still accepts it as correct and logs-in the adversary. He now has setup a connection with Bob, in the name of Alice.

Is my reasoning correct? I assume that, because of this, you will never use challenge-response protocols to login a user or start a session. If I'm not mistaking, using session keys protects against this attack and allows a safe connection.

Improve this question
2
  • certificates tend to protect this sort of thing
    – schroeder ♦
    Jun 5, 2017 at 11:50
  • @schroeder Do they? I don't see how. Certificates just authenticate a public key. Eve can still put herself between both Alice-Bob and Alice-CA. The only way I can think of to get rid of this vulnerability is by authenticating every single message to the server.
    – Thomas Vanhelden
    Jun 5, 2017 at 11:58

1 Answer 1

Reset to default
2

Your assumption is true if Alice and Bob must rely solely on this single communication channel and have no kind of knowledge about the other party before establishing the connection.

But consider the case that Alice has a key pair where the public key is public and thus known to Bob but the private key is only known to Alice. In this case of existing previous knowledge Bob can send a challenge to Alice which she can sign with the private key. This signature can be verified by Bob using the public key. A man in the middle cannot fake it since he has no access to the private key.

This mechanism can be made more flexible with a Public Key Innfrastructure (PKI) so that Bob does not need to know all the public keys of all possible Alice's but only need to trust a certificate agency which issues certificates for these Alice's. And this is basically the way the server is authenticated in SSL/TLS in order to detect man in the middle attacks.

Note that public key cryptography is not the only way previous knowledge could be used to defend against such man in the middle attacks. A secret shared between both sides of the communication would work too as long as the man in the middle attacker does not know the secret. But public key cryptography using a PKI scales better if many parties are involved.

Improve this answer
5
  • Yes, but I'm talking about an on-line attack (i.e. the attacker is active). The attacker, let's call her Eve, is positioned between Alice and Bob (e.g. a malicious router). It could then just relay Alice's response without knowing the private key. Anyway, I think I may have asked a silly question since this kind of authentication should be used for every transaction. I was assuming that it is only used for setting up a connection (e.g. logging in). But as long as this process is repeated for every (critical) transaction, Eve can't do any damage.
    – Thomas Vanhelden
    Jun 5, 2017 at 13:10
  • 1
    @ThomasVanhelden: in TLS the authentication of the server is only done once to defend against man in the middle attacks. But there is a protected key exchange and the resulting keys are used for encryption and for message protection (HMAC). This way the initial authentication in the handshake is extended to each message.
    – Steffen Ullrich
    Jun 5, 2017 at 13:13
  • Another attack could be waiting for the authentication to be successful, then interrupt the session and take it over. The solution to all this is authenticated key agreement. Run a mutual entity authentication protocol, establish a key and use this key to encrypt and authenticate all future message exchanges. I'll mark your answer as correct since my question was extremely vague.
    – Thomas Vanhelden
    Jun 5, 2017 at 13:14
  • @ThomasVanhelden: what you describe is exactly what is done with server authentication, key exchange and HMAC for each message within TLS.
    – Steffen Ullrich
    Jun 5, 2017 at 13:15
  • Yes, you're right. I wrote my comment before reading your reply.
    – Thomas Vanhelden
    Jun 5, 2017 at 13:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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