Secure Transmission

[Zanthos]

For my game I'm currently developing I have been considering implmenting some form of security for the data transmission between all the clients and the server, preferably not using any high security DES3 or RSA tricks ;). I came up with a couple of possible ideas, and was wondering if anybody has any knowledge that i could add to the list :)

First one is simple shoddy ASCII encryption using a key, ok, not the best in the world, but the principle is..
1. Server sends clients encrypted encryption key
2. Client decrypts encryption key using hard coded decryption key
3. Server & Client use the decrypted encryption key for data transfer
This is more obfuscation than encryption, but would keep most casual hackers at bay :)

The second method uses a key which changes every 4 frames(1 second) of the game, this would produce a changing encryption/decryption key and would prevent players being able to send packets through a packet sniffer without lots of added effort in working out the changing key and synching correctly with the server and client.

I had ideas about message CRC and frame counters encrypted inside the network message, but haven't tested this for speed yet :)

[Michalson]

An unchanging encryption key is not going to be of much help. One of the main things you are trying to prevent with packet encryption is hackers gaining private information and prevent them from spoofing messages. With a single encryption system all a hacker would need to do is sample the packet sent when he did a particular action (without needing to know what the contents actually meant), and then have a program spoof that packet on command (this is how Soldat was hacked, someone wrote a program that detected shoot messages and duplicated them, making all weapons rapid fire).

The better approach, even if your encryption is trivial (such as a basic XOR) is to have a constantly changing key. In the best situation you would determine an initial key (hopefully without having to ask for it, which could be done by generating the key from the servers name or other unique value known to both parties) and then change it each time a message is sent (using predicatable random numbers for instance). Of course you are likely using UPD, and so you can't be guaranteed that all packets will reach their destination or in what order.

To work around UPD you could use this system:

Each message contains all the information needed to decrypt it. While this may seem bad at first, it can actually be very good at preventing a hacker from poisioning or reading packets without understanding exactly how your whole system works (most hackers are trying to understand a very small part of your system and exploit it).

One example would be to have a packet structure like so:

Random key needed to decrypt message. The key itself is encrypted using the length of the message.
Message
Random amount of padding, designed to make all packets fall within the same size range (so that you can't tell what the packet is for based on size)

In this manner no two packets are alike, requiring the hacker to understand your whole program rather than just the part he is after. To increase security each packet should contain within the message section (which is encrypted) a packet number. This packet number is unique to each packet sent, so if the server recieves more than one packet with the same number it will be rejected (this prevents packet sampling and spoofing)

I've got to go now, but I'll come back later and post some more ideas. If you read this in the mean time give me some feedback and maybe some details of what kind of game it is (or more accuately what information the client has and what information the server has, and what needs to be passed back and forth)

[Zanthos]

The game is a real time space strategy game, the network system I'm implementing is similar to that of AOE in its sending what the players are doing and replicating their actions on each of the clients. And implementing what Warcraft3 did and have it so all clients are constantly kept in synch with a strict PING packet system.

I'm using TCP as the transport layer so all packets are guaranteed to be delivered, it isn't a frantic game and is intended for LAN play so the slight speed hit with TCP over UDP is minimal.

Assuming the player clicks on a squad of cruisers, and points them, say at coordinates 18012,12022.. a message is constructed, example:

* the message code 4Bytes
* message data xBytes (depends on message)
* frame number 6Bytes

The maximum size for a message is about 265( for a chat message 255 characters long).

Each user in the game is assigned an ID for logging purposes, each is unique(almost like a GUID in appearance), the ID's can easily be obtained using an EXE available with the game, and are used for resuming a saved network game, statistics logging, etcetc. creating a hash of the servers ID and the clients ID would provide a basis for the encryption key, this could be then changed using some bit manipulation which would change the key for each packet.
This would then hamper the hackers ability to spoof a message as the server noticing any duplicate packet ID, undeciperable message(meaning duplicated encryption) drops the user.
* The packets would be non-duplicatable due to changing encryption key
* Packets duplicated or inserted would cause an inconsistency in incoming packet frame numbers

Other information you might need:

* All nodes (clients and server) store an image of the game in progress
* Server tell clients what "the buttons the other clients are pressing"
* Random actions are broadcasted to prevent random seed errors
* The server sends a frame update packet roughly 4 times every second.

Information such as squads moving is not sent across the connection, as this can be determined easily from a message such as "move squad z to coordinates x, y"

Anyway, thats all for me for tonight, thanks for the ideas :)