Right now I have an automatic update server that signs the files it distributes before it sends them, so if anyone compromises my domain name all they can do with it is get "bad signature" messages bounced back at them unless they also steal my private key.

Currently it generates the signature right before sending the update file to the client, and thus has the private key on the server.

I was wondering: shouldn't I instead sign the update file before I even upload it to the server, so I can keep the key on a non web-exposed machine instead of my server? Or is there a downside to doing this that I haven't thought of?


As always, it depends on what you want to protect against.

If the threat is an attacker hijacking your domain name in some way and distributing malicious updates, your protection is good, signing files on your server does prevent that.

However, talking about the threat that an attacker compromises the update server itself, there is no protection in place currently. As the key must be accessible to the process that actually signs and sends out files, an attacker would also have access and could distribute signed, malicious content. In a sense it's even worse than if updates were not signed, because in such a scenario users would be assured by your signature that updates are in fact authentic when in reality they are not.

So yes, as you suggested, you should definitely keep signing keys offline (or at least well protected, not on the update server), and only upload already signed distributable updates. This would protect against the second threat mentioned above as well.

  • 1
    The point about bad signatures being worse than no signatures is quite relevant. – trognanders Nov 16 '16 at 6:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.