How to protect the program updater from server compromise?

Question

Computer networks

There is a typical task, the software receives updates from the update server. Now everything is done simply - updates are downloaded via HTTP protocol, packed with ZIP. Some updates contain executable EXE/DLL files. Now we are thinking that if the update server is compromised, we can do trouble to all our clients.
How to properly organize the work of an updater so that he can distinguish his updates from others?
As far as I understand, here you need to either encrypt the update files so that the updater can decrypt them with a certain key, with which you cannot encrypt other data back by pulling this key out of the program. Or use some kind of digital signature embedded in files on the server and verified by the updater.
I like the first option better, but which algorithm to choose. I will need to encrypt the files with a public key, and sew the private key into the updater, but, as far as I understand, by pulling this private key out of the program, you can make it public and all protection loses its meaning.
The second option can be turned using gpg , but we would like to do without third-party utilities.
Could you tell me how to organize the whole process in the best way? The solution must be embedded, without the use of third-party utilities. Thank you in advance.

Answer 1

Restoring one of the keys of a pair from the other is a task that requires enormous time costs for serious keys (4096 bits and beyond).
In fact, you need to have a good public SSL certificate and use SSL to push updates. All the necessary functionality is implemented in SSL: -
Confirmation that the application has connected to a legitimate site
- Protection from MiTM by replacing the site.
-Protection of transmitted information.
You don’t need to build anything into the program, so it will be impossible to steal any key from it.
In cryptography , third-party utilities should be used, since it is extremely difficult to implement high-quality protection.

Answer 2

Here I seem to have found such a solution:
Create a signature with a private key (on our side), fill in the signature MyFile.sign and MyFile.Dat
openssl dgst -sha256 -sign private_key.pem -out MyFile.sign MyFile.dat
So (well, algorithmically) the updater checks
openssl dgst -sha256 -verify public_key.pem -signature MyFile.sign MyFile.dat The
private key is stored with us, the public key is sewn into the updater. Thus, an attacker, even having penetrated the update server, will not be able to sign files, because. the updater will not miss them.
Here, other problems with server spoofing, mitm and so on are solved right away.

Answer 3

Are you protecting the transmitted data or the server itself?
If the first - switch to an SSL connection and that's it. On the https server, on the client, checking the certificate using OS.
If you need server protection - then disk encryption, smart card login, and so on.

Answer 4

Just sign every update.
The public key is inside the program, the private key is only with the main programmer.
Although they will break your servers, the updater will immediately reject it when it sees that the update is incorrectly signed.