Crypto Protocol Evaluation - How about a server-side message with NO HMAC?

I have just adopted a secure protocol for a distributed multi-player game from

TLS/SSl,in which 1000+ players act in the same world. The Question is about the Hashed-MAC field in its message format.

The protocol works much like SSL/TLS. Firstly "Hello", secondly "Shake-Hand"

and "RSA Public Key",then "Pre-Master Secret" and "Cipher Algorithm Changed",at last comes the "Encrypted Game Msg".



The Format of "Encrypted Game Msg" includes
[1]Length
[2]Encrypted content
[3]Encrypted Hashed-MAC
[4]Encrypted Padding etc.
The protocol is symmetric:both client and server will generate and send Hashed-MAC in 16 bytes.

Yet, I really suspect if a server MAC is necessary in a game context. Because there are many cracked clients
or faked network message from the client to cheat. Instead, It is difficult to modify or crack the network message
of a server serving for 1000+ connections at once. Moreover, to modify such an output of server will not affect
the game logic running inside servers. At most, such a modification or forgery will cause some clients to crash.


So, my question is: What security vulnerabilities will happen if we omitted the HMAC of server? Is that affordable

in a Multi-Player Online Game? The saving of communication bytes and HMAC computation really tempts me :-P

Would you please give some hints about the question? Thanks in advance:-)

inventing protocols needs a "thar be dragons" warning.

I assume you really don't want or need real TLS, because its a lot more secure to use something proven over years. SSL is really expensive for initial session setup, but after that, its fairly efficient. The overhead is in the session setup, RSA stuff for the session key. Once you have the session key, its fast.

I don't see any value in enciphering the HMAC, why are you doing that?

Not clear to me if you plan to use the same packet both ways, or just server to client?

As long as you are using TCP/IP, you can let the lower layers handle transmission errors, retries, etc. and if you are using real session keys, separate for each session, its really all you need.

Just get a packet, try to decipher it, and if it makes sense, its good. If its not proper, its going to be all hosed anyway.

Yeah,in fact I want to use TLS/SSL indeed.

However,The game client is flash/action script based - deadly slow to support full SSL. Also, in a game world,servers are expected to be reliable while clients are untrusted. This idea differs greatly from TLS

So I just simplified some feature of TLS such as Encryption Parameter Negotiation--the server just requires the client to take the given parameter-- and so on to
get a smaller protocol much like TLS.
When it works in symmetric key encryption process,you may just consider it as some TLS implementation. As it comes to the encrypted MAC field, I just followed the TLS RFC Document. Anyway,it defines the HMAC to be "opaque".

Currently,the same packet format will be used for both server and client just like SSL.

The HMAC is important for client to server message because player may even fake a message from scratch like "I have picked up a big monster" or replay some recorded history messages. Although,we also do check in the game logic, it will be great if we can filter all this cheating by HMAC-check.

Yet,I do not think Server HMAC is useful since fake or modify a server message may just affect some few clients,right? If so, I may turn the message format asymmetric that makes server not to send any HMAC out

I'm not following the client to server HMAC. If you don't trust the client, you don't trust them, so you can't trust their signing of the message. All a HMAC is really is a signature of the message, so you can know that Client 123 sent it. But since you have a unique session key, if it decrypts, you know Client 123 sent it.

Replay attacks are a real problem, and they are part of what makes Thar Be Dragons.

In general, you should never trust the client, ever. Assume that a bad guy has taken over your client, or is spoofing you. When they tell you that they have +8 magic armor, don't believe them. Your server has to keep track of all this stuff.

You can let the client say "I'm changing from my +8 plate armor to my +1 magic leather so I can swing from this rope"
but even then, you have to have the +1 leather in your server's inventory for Client 123.

Clients lie.