Encrypt java,Java加密日志

I am currently making a game. I have build logging facilities internally, and there are message types like general, log, exception, send, receive, debug.

The send and receive logs contain the raw logging information, so they really contain what I send over the network.

The game uses a client-server model and uses a SSL connection such that the network information cannot be altered. However for the logging I would be logging the text as plain text, and that obviously will cause trouble. Also I plan on simply masking (by *'s) any personal information (like passwords, etc.)

However I have a few concerns:

The client program contains the truststore to use with SSL and the server's hostname/IP and port are not really a secret either. So if a person knows what to send over the network, then he can act like he is the client, right?

If a person can see what the client sends and receives, then he might be able to make a bot very easily. (The game is a turn based 2D game, so by simply relying on all network data you should be able to play the game I think. There is no skill with the mouse required in any way.)

So all in all: How can I still log all information and write it to a file, but without anyone else being able to read, modify it or use it in any way?

All comments are greatly appreciated, and I would also appreciate concrete suggestions as how to implement such a system.

Regards.

解决方案

If you're worried about encrypting data on your server, then the easiest solution is a whole-partition encryption program like Truecrypt - this will protect the server data if somebody steals the machine / hard drive.

If you're encrypting data on the client's machine, then this means that the encryption key must also be somewhere on the client's machine (even if it's in main memory). Go ahead and encrypt or obfuscate the log information to make it more difficult for users to read it, but be aware that a user will still be able to read it if (s)he puts enough effort into it. That said, the best way to obfuscate the data is to encrypt it with a key that is never saved to disk - for example, when a user logs in then send them a fresh encryption key that their client app will use to encrypt log data; on your server, keep a record of what keys you've sent to the client and at what UTC timestamp. Store the logs with an unencrypted timestamp, so that when the user's client app sends log data you'll know which key to use to decrypt it. Obviously the user can easily change the timestamp, but this is equivalent to the user simply deleting the log data from their machine (which you can't prevent); meanwhile it is fairly difficult for the user to figure out what key was used to encrypt the data, so it's not easy for the user to read or forge log data (but again, the user CAN read / forge log data if they put enough effort into it).

You can take steps to obfuscate the encryption key in memory by e.g. storing it in multiple pieces. For example, assuming you're using AES 128, you can store the key in two 64-bit chunks that you concatenate before encrypting data, then wiping the concatenated key from memory as soon as you're done with it. Or you can store two 128-bit keys that are Xor'd together, again wiping the Xor'd key from memory as soon as you're done with it. A dedicated user can still figure out the key, but this will make it a bit more difficult for them.

Another step you can take is to use an encryption algorithm besides AES, e.g. any of the other AES finalists like Twofish or Serpent (don't implement your own encryption algorithm, you're better off broadcasting that you're using a strong algorithm like AES than you are using a weak obfuscated algorithm). Just remember to obfuscate the encryption library's class and method names to make it more difficult for the user to figure out what encryption algorithm you're using. (This is much more effective if you're compiling to machine code - it's probably not worth it if you're using Java, because the user can simply decompile your code and use your own decryption code to decrypt the log files.)

In terms of figuring out if a player is a human or a bot, not even games with much greater budgets than yours are able to reliably do this - all you can really do is boot the user or send them some sort of captcha if they exhibit "bot-like" behavior, but this isn't fool-proof, and you really ought to favor not annoying legitimate users over booting bots.