Reputation: 3277
I am writing an auto update client. It's a very simple app that:
1) Checks a central server to see if an update exists for some application
2) Downloads the install program from the server if a newer version exists
3) Runs the setup program
Other than server-side concerns (like someone hacking our site and placing a 'newer' malicious application there), what client-side security concerns must I take into account when implementing this?
My current ideas are:
1) Checksum. Include the checksum in the .xml file and check that against the downloaded file. (Pre or post encryption?)
2) Encrypt the file. Encrypt the file with some private key, and let this program decrypt it using the public key.
Are both or either of these necessary and sufficient? Is there anything else I need to consider?
Please remember this is only for concerns on the CLIENT-SIDE. I have almost no control over the server itself.
Upvotes: 3
Views: 220
Reputation: 31685
If I can compromise the server that delivers the patch, and the checksum is on the same server, then I can compromise the checksum.
Encrypting the patch is mainly useful if you do not use SSL to deliver the file.
The user that executes a program is usually not authorized to write to the installation directory (for security reasons; this applies to desktop applications as well as e.g. PHP scripts on a web server). You will have to take that into account when figuring out a way how to install the patch.
Upvotes: 1
Reputation: 6554
If you retrieve all of the information over https and check for a valid certificate then you can be sure that the data is coming from you server.
Upvotes: 2
Reputation: 120576
The checksums are only as strong as the site from which they're downloaded. If you use an asymmetric signature, so that the auto-update client has the public key, then you can sign your updates instead, and it won't matter if someone hacks your website, as long as they don't get the private key.
Upvotes: 1