Encrypted connection without SSLStream?

0
votes

I need to encrypt the data that will be sent/received, client <> server and vice-versa.

Since I can't use SSLStream right now, I am looking for other alternatives.

While thinking about the alternatives I have, I got stucked on how would I send the data to the client in a way it can't be read/intercepted.

Here is how I thinked of doing it:

  • Client/Server will have a RSA private key inside the application that will be loaded from a string to encrypt/decrypt the data received from the server.

  • After the initial connection request, the server will send a session id along with a inner AES key/iv.

  • From here on the client will communicate using both, the RSA and the AES.

I would like to hear from experienced people some new ideas or better ways to do what I need here which is:

Send encrypted data from client to server and vice-versa without using SSLStream and yet having a good level of security.

I understand that having the private key on the client is risk but I am yet to find a better solution.

3
c#encryptiontcpdata-protection
Do you need to authenticate the client? Or why do you need a private key in it? - CodesInChaos
CodeInChaos I need the private key because it was the only way I could think of to send the initial connection encrypted to get the inner communication AES key. Otherwise anyone using wireshark and a good understanding of it would be able to grab the AES going on plain text. I do understand that they can steal break into my app to get the string with the cert but then I could make that a lot more difficult for them with obfuscation, and other methods. - Prix
why do you need to distribute a private key with the client? That defeats the purpose of RSA. Why can't the client generate a random keypair and connect to the server, encrypting the connection using the server's public key? - axel_c
axel_c I dont see how that would be different from the above method except the fact I would not be able to further encrypt the data with an outer encryption on top of it. - Prix
I think you're not understanding how public key cryptography works here. I'll write an answer to explain my suggestion properly - axel_c

3 Answers

1
votes

If you really can't use SSL, you can build poor man's SSL yourself:

The client knows a RSA public key, the server knows the corresponding private key.

To communicate the client creates a random session key that can be used with AES. It encrypts it with the RSA public key, and sends it to the server. It encrypts the rest of the communication with the AES session key.

The server decrypts the first message with the RSA private key, and thus gets the session key. It uses this key for the rest of the communication.

That way the client doesn't contain anything secret, but the communication itself is private. The main thing that's lacking with this scheme is client authentication.

You should also use different nonces/IVs for the server->client and the client->server stream. You might also want to add integrity checking(MACs).

0
votes

The only way you can do this is using a shared secret: something both the client and the server know, but no-one else does.

Public key SSL works on the premise that a certificate (and hence a key-pair) is locked to a particular server/domain which can be independently confirmed via a third party (the signing authority).

As soon as you get rid of this premise, you are open to man-in-the-middle attacks with public key encryption because you cannot guarantee who you are talking to (or at least you cannot guarantee someone is not intercepting/relaying your messages).

If you use a shared secret, you don't need public keys, certificates or anything else - but if any unauthorised party discovers your secret, you're screwed.

0
votes

A possible approach:

-Server has a well-known public key and a private key no one knows (not even the clients)

-Client generates a 'handshake' packet and encrypts it with the server's public key. The handshake packet contains any initialisation/authentication stuff you need, plus a randomly generated passphrase + IV to use for AES encryption.

-Server decrypts handshake packet using its private key and now has access to the AES passphrase + IV. It responds with an 'ACK' packet indicating its ready.

-Now client can send data using the AES passphrase to encrypt symmetrically, and the server can decrypt, and vice versa.

There's no need for the client having any private key bundled with it. RSA is specifically designed for data exchange without the need for a shared key.