Click here to Skip to main content
15,907,687 members
Please Sign up or sign in to vote.
5.00/5 (1 vote)
I have a question for all those security boffins out there.

I am developing a Tcp/Ip based client/server system that needs to be VERY secure.

I'd like to know if there are any obvious vulnerabilities in the way the system works.

Each communication is initiated by the client, the server sends a response and the connection is closed. Much like HTTP, - The connection must be re opened for each transaction. Session state is handled via session-id parameters in the messages from the client.

The client and server create and exchange public keys, - these keys are particular to the client and server (ie the server keeps the public key sent from the client, and a private key for that client (of which it sends the public part))

Once public keys have been exchanged, it uses the RSA asymmetrical algorithm to exchange a pair of AES key + IV byte arrays (generated for/from the Rijndael Algorithm). The server sends data using one key, and receives using another.

Each message is signed using RSA and checked against the IP address recorded for that session, to prevent a third party attempting to imitate either the client or server. Although, if one party was fake from the start, I don't think this helps.

All further communication is encrypted using the Rijndael algorithm.

Authentication occurs at this point, and the client sends username/password information to the server, which generates a hash from the password and checks it against the hash stored against the username.

All messages are exchanged by serializing a class through a compression stream into a network stream. The formatter is given a custom binder that scrambles the assembly and type names.
The serialized bytes are not encrypted, instead the contents of the message are (the class being serialized has a Message property, that will contain the encrypted data)

Apart from being easier, (correct me if I am wrong here) I think it is more secure. By encrypting the contents of the message, and not the whole serialization, it means that commonly known, easily guessable serialization headers are not encrypted, so they cannot be used to assist with breaking the key.

The only thing I can think that might go wrong, is if someone was able to re-route packets to their own copy of the server, and therefore sniff username/password data from a client attempting to authenticate.

Assuming a malicious third party is able to redirect Tcp/Ip packets, How would you go about validating the identity of a server? it that even possible?
bbirajdar 20-Jan-12 3:58am    
I think it is not secure NOW since I know how your system works... :)
Simon Bridge 21-Jan-12 1:55am    
You have to assume that your potential attackers have full access to the software and the source code when building a secure system. Especially when developing in .NET
CdnSecurityEngineer 11-Jul-13 10:58am    
I think there are people, like security engineers ;), whom do this analysis for a price. You're asking some detailed questions here and analysis, based on a description. It's real easy to describe how something is supposed to work, and say is it secure? Well perhaps the design is secure but the implementation can be anything but. Therefore it's really difficult to truly understand what you're trying to accomplish here and what you're after. I'd be more then happy to discuss in further detail and help you out if you're interested.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900