Network Security Conundrum

Alrite, so I'm ready to use the Capicom encryption component from microsoft to secure some messages between a client app and a server app. I plan on having them send certain messages back and forth that are often times identical, but their quantity is important. Anyways, here is the security hole i can't figure out a way to stop.

Client connects to server.

Client sends encrypted message to server.

Hacker sniffs this encrypted message, and although it still looks encryped to him, he then masquerades as the client and sends the same message to the server.

The server has no way of knowing that the message didn't come from the client, and things get all messed up!

Any ideas on how to stop this?

Thanks,
WeezelDS

I assume the server and the client share a common key/password under which messages are encrypted, correct?

indeed...

i'm thinking i can't do this very securely w/o a certificate authority, cuz if i sent the password in either plain text or encrypted w/ a predetermined key, the hacker could sniff that too

That's more or less true. Since the Crypto API supports RSA, here what I would do:

1. The server creates RSA public/private key pairs and assigns them to clients. These would have to be physically transported to the client via a file.
2. The server also assigns a key pair to itself.
3. Client connects to the server and presents its public key. If the key is valid, the server responds with its own public key, otherwise it terminates the connection.
4. The server creates a random key for DES/Triple DES encryption, encrypts it under the clients public key and sends the encrypted random key to the client.
5. The client decrypts the random key and then encrypts it again using the server's public key, then sends it to the server.
6. The server decrypts the random key. If it matches the original random key it generated then all is in order and then the data conversation can continue encrypted under the new random key.

Even if this is sniffed, the hacker won't be able to replay the conversation to the server because every time the conversation key is random. Of course, this doesn't stop the hacker from playing "man in the middle". Also, if the TCP session is hijacked after the conversation key exchange takes place, the hacker still won't know the conversation key's clear value in order to continue the conversation.

Hope this all makes sense. :)

yeah, I understand how real security works, i was hoping there was an easier way out :)

for some reason i was thinking that capicom couldn't do all that...but since its just a wrapper for the CryptoAPI, i guess it should be able to....

now to find good documentation for capicom...

If you decrypt the message and then encrypt it again and send it back, it will appear different, yet still be decryptable using the original key. if you do it on both sides, and it is sent back in the original form, it will be spoofed, right?

Quote:

---

Originally Posted by dglienna

If you decrypt the message and then encrypt it again and send it back, it will appear different, yet still be decryptable using the original key. if you do it on both sides, and it is sent back in the original form, it will be spoofed, right?

---

? :ehh: ?

ack....microsoft's documentation for capicom sucks :(

i had to wait half an hour for the stupid sdk to install too just to find crappy docs....

See maven's posts about it.

Client connects to server.

encrypted

Client sends encrypted message to server.


decrypt, and re-encrypt


Hacker sniffs this encrypted message, and although it still looks encryped to him, he then masquerades as the client and sends the same message to the server.
can't re-encrypt as he won't have the key

Quote:

---

Originally Posted by dglienna

See maven's posts about it.

Client connects to server.

encrypted

Client sends encrypted message to server.


decrypt, and re-encrypt


Hacker sniffs this encrypted message, and although it still looks encryped to him, he then masquerades as the client and sends the same message to the server.
can't re-encrypt as he won't have the key

---

He doesn't need it: the point is that he can just connect to the server and simply replay the sniffed conversation. The weak point of such a simple challenge is just that, if the encrypted conversation is recorded it can simply be replayed.

Quote:

---

Originally Posted by WeezelDS

ack....microsoft's documentation for capicom sucks :(

i had to wait half an hour for the stupid sdk to install too just to find crappy docs....

---

Here's something I used in my VB6 days. It's a combination of article and sample code ammended by myself. This will allow you to play a bit with RSA. With .Net available, all this now seems quite a hack :rolleyes: and it is.