views:

212

answers:

5

I'm using RSA to encrypt communication between a server and a client. Lets say we have 2 Asymetric keys, key 1 and key2.

The server has key1 (Private) from the start and the client has the key1(public)

So here is the scenario:

  1. the client generates key2
  2. client connects to the server
  3. sending key2(public) encrypted with key1(public)
  4. from now on the server will send all data encrypted with the key2(public)
  5. the client sends some random data to the server
  6. the server sends back the same data hashed
  7. the client verifies that the data is right

As far as I can see this should prevent a man-in-the-middle attack, or am I missing something? At point 7 the client should know if someone is trying to give the server the wrong key to encrypt with, as no one else but the server can decrypt key2(public).

If there is anything that can be done to improve the security please tell me.

+14  A: 

The best thing you can do to improve the security is to use an existing design and not try to reinvent the wheel. I'm not saying that what you've done is necessarily wrong, but just that many people much smarter than you and me have spent a lot of time thinking about this problem. Use TLS instead.

Greg Hewgill
+1  A: 

As long as key1 (private) has not been intercepted somehow by a third-party, your scenario looks secure.

I think I saw this somewhere in a paper actually. In it, Alice gave Bob an unlocked box (key 1 public), then Bob put a bunch of his own boxes (key 2 public) in it, locks it and sends it back to Alice. Alice then opens the box(key 1 private), and now she can securely seal the boxes that Bob just gave her.

Despite the box analogy, that's essentially what you're doing, so I'd say its secure.

samoz
+1  A: 
erickson
To the extent that you're right, your putative MITM could do that in any case, without the client.
MarkusQ
well sure he could but then he would loose the client and well then there is no point in doing a MITM as there is nothing to peek on..
Petoj
+1  A: 

I agree, just use TLS.

Also, what value do steps 5 through 7 provide? A MITM wanting to do an attack that would work after steps 1-4 (e.g. DoS of some sort by passing n transactions through and then stopping, forcing a retry from the start) could do so just as well after 5-7. What do they add?

-- MarkusQ

MarkusQ
A: 

Hi, Petoj,

I will agree with Greg that you are reinventing the wheel. What you are essentially describing is some basic form of key exchange. Incidentally, in order to ensure that it is secure against man-in-the-middle attacks you must also be certain of the server's identity, i.e. ensure that the client can know with certainty that what it believes to be public(key1) really is the server's and not the man-in-the-middle's (e.g. using a CA or having the server's public(key1) in secure storage on the client side.)

Moreover, there are additional considerations you must be aware from a systems standpoint, such as:

  • asymmetric key encryption is slower than symmetric key encryption, which is one of the reasons why existing solutions such as TLS will use asymmetric key encryption only to negotiate a temporary symmetric key, which is then used for channel encryption.
  • if traffic analysis by a third-party succeeds in cracking a temporary symmetric key, you have not compromised you asymmetric key pair. You are encouraged to re-negotiate the temporary key relatively often for this reason. Arguably, generating a new key2 in your scenario would mitigate this aspect.

Cheers, V.

vladr
the idear is that the public(key1) would be hardcoded into the client or some thing like that, if a hacker would be able to change that well then a MITM is of no use as he could just implant a logger of some kind, thanks for the tip about that asymetric encryption is slow didnt know that!
Petoj