Encrypted connection without SSLStream?

Question

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.

Answer 1

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).

Answer 2

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.

Answer 3

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.