PyTom wrote:I think it should be possible to secure the save files against a malicious server operator. The way to do this would be to sign each savefile with information the server does not know, and hence can't forge.
Cryptographic signing would be an option, with the (big!) advantage of sticking the sanitization code in a single auditable place. The downside is that it introduces key generation/management problems, and, while it protects against a malicious server, it doesn't protect against the case where one of a player's computers has been compromised and the others are clean.
PyTom wrote:I'm wondering if a warning - perhaps each time you load a synchronized file - would be enough to deal with the security problem. I think it would be possible to place an identifier in each save file, which we can check to see if the file was created locally. If it wasn't, we could issue the warning: "This save was not created locally. If the person or computer creating this save file is malicious, it could damage your computer. Are you sure you want to proceed?"
A warning every single time you load a remote-created file isn't useful for save-sync systems, because then the normal user behaviour is going to be to click the big red PROCEED button for both saves produced on their other computers and saves injected by hostile third parties. You'd want each save to come with a public key and to cache the keys, SSH-style, so the scary warning only shows when trusting a new computer. This still leaves MITM vulnerability the FIRST time you trust each computer, but that can be alleviated with out-of-band key validation.
Elmiwisa wrote:playing only a new account with restricted access and no administrative privileges
Some of us do, but an awful lot of players play with the same account they used to buy the game and most UIs in common use are oriented towards the assumption that all your programs have access to everything on your user account. For example, Steam launches all games in the same account (and, on Linux, assumes users are willing to grant root privileges to that account), and so many Windows programs assume that all files are writable by everyone that Microsoft decided kludging per-user filesystem views into the OS was a better idea than returning 'permission denied' errors when a process tries to write something it shouldn't.
Elmiwisa wrote:Whenever the player install a new game on multiple device, they need to input some sort of encryption key, which is stored into that persistent variable; and the player is supposed to enter the same key on all their copy of the game. When a game is saved, it automatically encrypt with that key. Then when the file is synchronized, the updated file is stored in a new location first. When the game attempt to load the save file, it check to see if a new version is available, then attempt to decrypt it, and load it. If the decryption and loading is successful, it is assumed that the file have not been tampered with (it game will probably crash if the file were tampered with, since after decryption most likely it will be full of nonsense data), in which case the game overwrite the old version.
I like the notion of encrypting any save going over the network, but secure key generation and exchange is hard (in the sense of being a pain for players) - and, again, doesn't protect against the case where one of the computers producing saves is compromised.
Saves on the local machine probably should not be encrypted - I don't like the notion of losing my saves because I forgot my encryption key, that would suck.
I'm also not sure what legal restrictions would apply to distributing open-source encryption modules in conjunction with a closed source game from our respective countries. Anything we distribute has to be export-legal from both .us and .uk.
