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!
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.
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?
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?
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
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.
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 and it is.
Network Security Conundrum
Reply With Quote
Originally Posted by dglienna
?
and it is.
