-2

Let us assume that there is a man in the middle who can read (not modify) all the data that's being transferred between a client and the server. We want the client to be able to log in without exposing their credentials.

We will be using asymmetric encryption here.

When the client wants to login, client will send a signal to the server to initiate the process and generate a key pair and send the public key to server, The server will create a session and generate a key pair for itself and return the public key to client. Now, both have key pairs, so any data transfer between them can be encrypted and there is no way the man in the middle will be able to read the data.

Thus, the client can send encrypted login credentials to server and, server can return encrypted login data.

Our assumption that the man in the middle can't modify data is mostly wrong, and thus, if the middleman replaces the keys with the ones he generated, then he will be able to read all the data.

Is there any scope in this proposal?

Would love to hear feedback from fellow cybersecurity engineers

schroeder
  • 123,438
  • 55
  • 284
  • 319
Abhishek Choudhary
  • 111
  • 4
  • You need root of trust. TLS is the solution. – defalt Aug 16 '20 at 07:21
  • 3
    I don't understand the intention of the question. You make a proposal, show its weakness and then ask if the proposal can somehow be used anyway despite the known weakness? Why should it, especially since there are ways to achieve what you want without this weakness? – Steffen Ullrich Aug 16 '20 at 07:53
  • 1
    Does this have any advantage over [Diffie–Hellman key exchange](https://en.wikipedia.org/wiki/Diffie–Hellman_key_exchange) (which is normally coupled with some sort of secure authentication, to handle the case of an active MitM)? – Gordon Davisson Aug 16 '20 at 08:02
  • Your focus is on the "log in" process, but that's too far down the path, and too late if already compromised. You need to secure the initial connection. And once you do that, then any proposal needs to show benefit over and above TLS. How does this address the weaknesses, if any, in TLS? – schroeder Aug 16 '20 at 08:10
  • Is this just an academic exercise in protocol design? As presented, this scheme has all the weaknesses of anonymous Diffie-Hellman key exchange, but requires additional steps to actually exchange a key suitable for bulk traffic. There already exist protocols for secure remote authentication and session establishment, and some of them are secure even in the face of an attacker who can modify traffic, too (look up Secure Remote Password protocol, for a modern example). – CBHacking Aug 16 '20 at 09:06
  • @schroeder Presumably the intended advantage over TLS-PKI is that it doesn't require having an entire public key infrastructure already exist and your server have a cert. On the other hand, anonymous cipher suites and clients that don't validate server certs both exist (although they're a bad idea to use). This approach also appears to be decidedly worse than, say, TLS-SRP or SSH (with either password or public key auth). – CBHacking Aug 16 '20 at 09:13

1 Answers1

1

Your key exchange lacks authentication. That's why someone in a MitM position can easily establish encrypted sessions with both parties and they can't tell the difference from communicating directly with each other.

  • With TLS it's typical that the server is authenticated using public-key cryptography with public key infrastructure (PKI), where the keys are signed by trusted 3rd party certificate authorities, but it's also possible to authenticate both parties with mutual authentication (client certificates).

  • It would also be possible that the trust has been established by sharing the keys beforehand or using a separate trusted channel.

  • If you don't know in advance the public key of the other party or can't authenticate it using PKI, your scheme doesn't have protection against MitM attacks at all.

Asymmetric encryption is slower than symmetric encryption. You don't want to use asymmetric encryption for the data, but only to secure the key exchange for the symmetric keys used during the connection. This is exactly how this is done in Transport Layer Security (TLS), and also PGP uses symmetric encryption for the data.

Essentially this is about... Why shouldn't we create our own security schemes?

Esa Jokinen
  • 16,100
  • 5
  • 50
  • 55