Server side code signing

Question

I'm currently implementing a couple of security improvements to a crypto currency trading website that handles all data client-side and uses a static file approach.

One of the things I've been asked to do was to add a mechanism to allow users to check whether the page had been modified by a third-party server-side. Please note that I'm not referring to server<->eve<->client-type tampering, as CSP, HSTS and other protections are in place.

My first approach to this was to sign every file with a private key (that never gets into prod servers) and distribute the public key using a different channel. The signed hash would then be hosted in the same directory as the file, with the filename being something like .key. Alternatively, all files could be hashed and signed in block. The checks would have to be manually performed by the user (this is not an issue).

I know a server watchdog can be used to check for file-changes, but from what I understood the hosting conditions are extremely volatile.

Finally, I'm not allowed to create a standalone app for this.

Is this reasonable? Is there any proposed solution to this request?

Answer 1

This becomes a difficult problem because of the two concurrent requirements that an attacker may control the server, and the content being served (that is, the pages generated by the application) are not finite and static (I'm assuming).

If you only had a few files to host, you can distribute a checksum file out of band, or in the same channel but signed with a trusted PGP key. This is pretty common with installers distributed through a CDN or mirrors. But you want to verify that the code that dynamically generates the served files is some constant.

If the user is running code on their own machine, they can download source code (possibly that has been signed, either as above or with git gpg support or similar) and compile it themselves. But in your situation they have to trust an entire network service infrastructure controlled by an adversary.

It's easy for someone controlling the server to add an intermediary MitM that modifies your requests to the app, or to just ask the app to make a signature for whatever the attacker has already generated. I'm starting to think of methods to combat these (ok, let's sign every request from the user, and the verified app checks that before issuing a response), but they're all going to be plugging holes - and complex security systems are vulnerability breeding grounds. It seems much more honest to me to not try and make this claim to your users.