0

The process involves two interested parties A (client) and B (server) and the attacker M. M is capable of intercepting all the communication between A and B (Man in the Middle) and even modify it. However A's private key has not been compromised.

Success of authentication process depends on A's capacity to sign an arbitrary packet sent by B with it's private key.

The authentication process proceeds as following:

  1. A establishes TCP connection with B.

  2. B calculates a nonce and associates it with the incoming connection from A.

  3. B already has A's public key.

  4. M connects with A.

  5. B calculates a nonce and associates it with the incoming connection from M.

  6. M initiates authentication process, B generates a new nonce based on the nonce generated in step 5 and some internal state and sends it to M.

  7. M sits idle and waits for A to initiate the authentication process.

  8. A initiates the authentication process, B generates a new nonce based on the nonce generated in step 2 and some internal state and sends it to A.

  9. M intercepts the communication B -> A in step 8 and replaces the nonce with the one it received in step 6.

  10. A signs the the packet and sends back to B.

  11. M intercepts the packet A -> B of step 10, blocks it from going through and replays it as it's own.

  12. B verifies the nonce and the signature and identifies M as A.

  13. M masquerades as A.

What can be done to prevent M from becoming A in eyes of B?

  • I'm not sure what you are trying to achieve. All you try so far is to find out if the expected party is involved in the communication. And it is even if there is also a man in the middle (on the internet there is always something in the middle, like routers). You don't try to protect sensitive application data against sniffing and/or modification so it is not clear what you want from the knowledge that the expected party is involved in the communication (among others). If you instead want to have an authenticated data exchange and maybe also protected against sniffing use TLS. – Steffen Ullrich Nov 5 '18 at 16:37
  • @SteffenUllrich you are correct, the purpose is to establish that an expected party is involved in the communication. There is no greater goal. – amitkriit Nov 5 '18 at 16:52
  • Obviously the party A is involved in the communication. It might not be involved in the direct TCP connection from B but since messages are used from A within the connection one can hardly deny that it is involved in the communication. – Steffen Ullrich Nov 5 '18 at 17:01
0

My understanding is that both A and B have a private key that is incorporated into the final shared key at both the beginning and end of the handshake process. This means that if you try to jump into the middle of the handshake, that you will still be lacking A's private key. So, while you can trick B into thinking you are A, the data you get will still be encrypted and you will not have A's private key to be able to finish the decryption. Since you can't decrypt it, you can't change it to any new meaningful values even if you successfully make yourself the man in the middle.

The real issue comes into play when you can trick A into thinking you are B because then you can pose as a fake version of B long enough to collect login credentials, then pass them along to the real B. That way you can login as A with a new connection using your own private key. The only thing I know of that would sort of prevent this is to have B send A a verification method the first time you connect that is able to verify that B is B, but that is not always practical depending on your use case.

  • Although this is not the answer I was exactly looking for, it gave me a viable idea. – amitkriit Nov 12 '18 at 9:23

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.