Explore the possibilities of code signing for improved security / integrity verification

[nmlgc]

Code signing

Description

Marking as both a bug and an enhancement because it may become really scary one day.

First of all, I must admit that I am a total newbie to this concept, and I'd like to thoroughly understand anything (and, most importantly, why it works or doesn't work) before implementing it.

This is disquieting not mainly because the patcher executables may be tampered with, but because every patch can contain self-updating binary hacks.

Everyone with write access to the JSON files of a patch can have code execution in the context of the game process. While this openness is certainly one of the main aspects about this project, it can just as easily be abused.

The main problem here is that we want to keep a low barrier of entry for this whole patching thing on the technical side too (even though this is hardly used), yet also want to ensure security somehow.

Once we have a working system in place, we can also have patches that come with self-updating plug-in DLLs.

Prerequisites

• Probably requires Flagged Revisions on the wiki side, combined with a way to automatically sign a patch file upon flagging, to really work.
• If automatic signing based on wiki logins even is a good idea in the first place.

Implementation

• Provide two separate versions of thcrap on thpatch.net: A regular version with all the code signing enabled, and a developer version that doesn't have these features. The latter will have a big "this version may pose a security risk, only use it if you know what you're doing warning.

[nmlgc]

How about just encrypting the CRC32 with the private key of each patch, verifying that on updating (see #22) and not storing the file locally if it doesn't match?

[tirr-c]

GnuPG provides signing with generated private keys, and verifying with public keys.

[mokou]

Ed25519.

[brliron]

I can think of 2 things to think about, regarding this:

• How the patches will provide the signatures?
• How thcrap will know the public keys for these signatures?

For the 1st point, we have several possibilities. As nmlgc suggested, we could replace the CRC32 with an encrypted version of it in files.js. But that may break the auto-update for one build. Because we would change the files.js to include the checksums, and we would change the global.js to trigger the thcrap update. Then, a thcrap client will try to download, first, the files.js. It won't recognize the entries, so it won't be able to download the global.js and so it won't know it have to download a new build.

We could add a new file, say files_signatures.js, containing the files signatures. It would work and wouldn't break backward compatibility.

And for the 2nd point, I think the public keys have to be embedded in thcrap, like my public key is embedded in the current release of thcrap. I think we shouldn't download those public keys from a server, because they might be modified as well (at least I suppose, I don't know a lot of things about network security). I think having a common key used by everyone to sign their files is the worst idea we could have, because we lose all control on this key, and the private key might end up being uploaded on a public place.
On the other side, publishing a new release containing a new public key each time we have a new patch developer appears can be quite annoying, and I think it may prevent new people from creating patches. For example, I don't think someone would bother doing that for something like the bitch patch.

What I thought about is that we could enforce the signature checks only for the dangerous files. That is, for .dll, <game_id>.js etc. And files like *.png, *.jdiff, or even <game_id>/ wouldn't need this check. With this, a lot of patch developers wouldn't need to have their public key in thcrap (I even think my public key would be enough with the current patches).

[mokou]

I think the easiest way to implement this is with a new repo format and website designed with crypto in mind rather than extending the current format. For now we can easily enable HTTPS for the repo, but anything beyond that is (IMO) wasted effort.

[brliron]

I don't really see how a new repo format would be better than extending the current one. Do you have any example in mind?