Hello gamedev:
First of all,
do those successful commercial MMORPGs use encryption for game data transmission?
I got an impression that many developers tend to not use encryption, because it can not prevent reverse engineering for cheating and making private server, but doesn't it effectively reduce the number of those?
Encryption also impacts performance, even just a little.
Good encryption does prevent network sniffering and man-in-the-middle, are these important for MMORPGs?
How about protecting chat messages for privacy concern?
How do you think?
PS: I'm talking about game data, not user/password, auth info need to be encrypted for sure.
[Edited by - lazyworm on November 29, 2010 1:59:58 PM]
Should MMORPGs use encryption?
As far as I know, yes they do use encryption, to minimise the effective use of auto-trainers and impersonation, for example(especially if a man-in-the-middle sends messages that can display text as if it came from another player or game staff). You'll be surprised what some people will do in order to get an in-game item.
Not just hacking the mechanics, but definitely encrypt the messaging system too, because some players will use this as readily as the likes of Windows Live Messenger, which an eavesdropper can easily skim useful information from.
Not just hacking the mechanics, but definitely encrypt the messaging system too, because some players will use this as readily as the likes of Windows Live Messenger, which an eavesdropper can easily skim useful information from.
Quote:Original post by WhiteCrane
Not just hacking the mechanics, but definitely encrypt the messaging system too,
If you plan on keeping the game in the US, that will work. Otherwise, it is against federal law to send encrypted "plain" text to destinations outside of the US. Which was a problem in the first XNA Game Studio as it would encrypt text. Now there is a flag to mark it as text so it won't encrypt it.
Can you back that up in any way? I'm not aware of there being any problems with using for example either ssh or https with any US servers.
If you plan on people from outside the US being able to play your game then pass on encryption. I really doubt you want to try to get an export license to ship encryption outside the US. This will be required for any encryption strong enough to make it worth using. Good encryption should prevent man in the middle, and network sniffing. No offense but game data is low value, getting between me and my ISP or between my ISP and the server is a costly proposition, and the costs don't justify the pay off.
It doesn't do anything for prevention of reverse engineering, end user cheating or making private servers. User cheating isn't impacted because they can hook your program before things get encrypted and inject data there then you happily encrypt it. As far as Reverse engineering and private servers go, it may take them a while to figure out which encryption protocol you use but with the ability to control what gets encrypted by the client makes it fairly easy to figure out.
I don't think I would bother with encrypting chat. It is a game, people aren't going to be using it to chat about their bank account details.
It doesn't do anything for prevention of reverse engineering, end user cheating or making private servers. User cheating isn't impacted because they can hook your program before things get encrypted and inject data there then you happily encrypt it. As far as Reverse engineering and private servers go, it may take them a while to figure out which encryption protocol you use but with the ability to control what gets encrypted by the client makes it fairly easy to figure out.
I don't think I would bother with encrypting chat. It is a game, people aren't going to be using it to chat about their bank account details.
Quote:Original post by ImgellingWait, are you saying that Amazon Inc is breaching federal law if I buy a book from them? Because the messages exchanged in confirming my delivery address and credit card etc. are SSL encrypted.
If you plan on keeping the game in the US, that will work. Otherwise, it is against federal law to send encrypted "plain" text to destinations outside of the US. Which was a problem in the first XNA Game Studio as it would encrypt text. Now there is a flag to mark it as text so it won't encrypt it.
EDIT: And, thinking about that, so is all traffic when I check my mailbox at googlemail.com.
Yeah, I'm not sure about these supposed anti-encryption laws to other nations. Citation? For one thing, how would the government even know that a particular encrypted message is plain text and not technical game data?
It certainly used to be the case that it was illegal to ship "high-grade" encryption software out of the US -- it was considered a munition and restricted. For a long time this meant that web-browsers were limited to 40-bit encryption because Netscape couldn't send the 128 bit version to anyone.
The simple solution was to develop the encryption part outside the US... which is what everyone did.
After 2000, the US de-restricted quite a lot of encryption. Anything open source is legal to export for example. Anything which uses encryption as authentication only (as in digital signing) is exempt from controls.
The remainder is restricted over certain keylengths -- IIRC 128 bit is fine but larger is still restricted.
However, export to a certain few countries (you can probably imagine which ones) is still illegal in case they use the encryption for terrorism.
The simple solution was to develop the encryption part outside the US... which is what everyone did.
After 2000, the US de-restricted quite a lot of encryption. Anything open source is legal to export for example. Anything which uses encryption as authentication only (as in digital signing) is exempt from controls.
The remainder is restricted over certain keylengths -- IIRC 128 bit is fine but larger is still restricted.
However, export to a certain few countries (you can probably imagine which ones) is still illegal in case they use the encryption for terrorism.
Using encryption is fine, and something I'd definitely recommend. Though use it with the intention of obfuscation, and don't ever rely on it actually hiding anything. From all standpoints of the development, you should continue to assume your messages sent over the network are 100% readable (as in understandable) by everyone.
Even something simple like a bitwise XOR encryption with a predefined set of rotating keys (or a single, mutating key) would work well enough to prevent the basic packet replaying, which is a pretty common form of basic hacking in multiplayer games. There is a huge step in technical difficultly between replaying packets and deciphering the encryption and sending encrypted packets. You won't stop the dedicated cheaters, but you will be able to stop most of the "script kiddies".
Though there are a few occasions where you actually want to encrypt for the sake of privacy. A common place is user credentials (namely the password). For this, if you want to keep it secure (which you should if its really a "massive" online game), use existing asymmetric key encryption techniques.
The reason you won't want to just set up asymmetric encryption for the whole session is because the encryptions are serving two totally different purposes in this case. The general encryption is intended to be cheap and introduce minimal (or preferably no) inflation, and has the purpose of obfuscating data for everyone. Encrypting private information, such as account credentials, has the purpose of hiding data from everyone eavesdropping - it isn't intended to hide anything from either of the endpoints.
Encryption can also be useful for authentication. For instance, if you have an in-game cash shop that can be purchased from at any time, some jerk might just start sending the "buy from shop" message to the server while pretending to be a different client. If they get lucky, then can make someone buy something by "injecting" that network message. But it will take more than a simple rotating key to protect against this.
Even something simple like a bitwise XOR encryption with a predefined set of rotating keys (or a single, mutating key) would work well enough to prevent the basic packet replaying, which is a pretty common form of basic hacking in multiplayer games. There is a huge step in technical difficultly between replaying packets and deciphering the encryption and sending encrypted packets. You won't stop the dedicated cheaters, but you will be able to stop most of the "script kiddies".
Though there are a few occasions where you actually want to encrypt for the sake of privacy. A common place is user credentials (namely the password). For this, if you want to keep it secure (which you should if its really a "massive" online game), use existing asymmetric key encryption techniques.
The reason you won't want to just set up asymmetric encryption for the whole session is because the encryptions are serving two totally different purposes in this case. The general encryption is intended to be cheap and introduce minimal (or preferably no) inflation, and has the purpose of obfuscating data for everyone. Encrypting private information, such as account credentials, has the purpose of hiding data from everyone eavesdropping - it isn't intended to hide anything from either of the endpoints.
Encryption can also be useful for authentication. For instance, if you have an in-game cash shop that can be purchased from at any time, some jerk might just start sending the "buy from shop" message to the server while pretending to be a different client. If they get lucky, then can make someone buy something by "injecting" that network message. But it will take more than a simple rotating key to protect against this.
Cheaters will, generally, have access to the raw memory of your game. They can read/write any quantity in the memory, which means that your game will happily encrypt and send whatever data they tell it to.
Encryption may be useful to prevent man-in-the-middle attacks, assuming key management is done right. The main cause for concern here is wireless access points, where anyone with the right key can read all traffic, pretty much. This leads to exploits like session hi-jacking for Facebook, Twitter, etc (and, if your game is big enough, your game).
The best solution for encryption is SSL. If you absolutely cannot use TCP for your game, you could log in using SSL, which creates a random, 256-bit AES key, which you then use for encrypting your UDP packets, using some nonce schedule to reduce the surface for known-plaintext attacks.
Pop quiz: If you send 25 kilobytes per second, and your memory bandwidth is 25 gigabytes per second, how many percent of available memory bandwidth is used by the encryption stage? You're allowed to use 1,000 for "kilo" and 1,000,000,000 for "giga."
Encryption may be useful to prevent man-in-the-middle attacks, assuming key management is done right. The main cause for concern here is wireless access points, where anyone with the right key can read all traffic, pretty much. This leads to exploits like session hi-jacking for Facebook, Twitter, etc (and, if your game is big enough, your game).
The best solution for encryption is SSL. If you absolutely cannot use TCP for your game, you could log in using SSL, which creates a random, 256-bit AES key, which you then use for encrypting your UDP packets, using some nonce schedule to reduce the surface for known-plaintext attacks.
Pop quiz: If you send 25 kilobytes per second, and your memory bandwidth is 25 gigabytes per second, how many percent of available memory bandwidth is used by the encryption stage? You're allowed to use 1,000 for "kilo" and 1,000,000,000 for "giga."
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
