How to be sure that downloaded file is correct? [duplicate]

Question

Last week I read a lot about security. I have a basic understanding how public keys or private keys works. But I still have a lot of questions I can't find an answer. Right now I'm interested in checking an executable file I downloaded. Let's assume I sign a file, send it to user, but some bad guy in the middle change my file to malware. So when the user double clicks downloaded exe, how can he be sure that he actually launches a correct file and not a virus?

Upd.: Assume that the user of my program is a housewife and she doesn't know anything about command line and she will not download special GUI programs for checksum comparison. And at the same time I, as a developer, want to be sure that she runs my program but not corrupted. How?

Answer 1

Any self-verification mechanism included in the executable file could be replaced or removed by the attacker who intercepts the file. Therefore, we must leave signature verification to a system external to the downloaded executable, for example, the operating system.

There are three possible outcomes such a verification system can produce:

1. The signature is definitely valid (the signature and data match)
2. The signature is definitely not valid (the signature and data do not match)
3. There is no signature provided (the executable is not signed)

In Windows, you may have seen pop-up confirmation windows like this when you try to run an executable:

Here, the executable has been signed and Windows has both

1. verified the signature on the executable, and
2. verified the identity of the public verifying key's owner, using a chain of trust based on one of the operating system's trusted certificate authorities.

We know with cryptographic certainty that an entity named WinZip Computing signed this executable, exactly as it exists right now on our hard drive. That's case #1, above.

That's how a security-conscious user can verify that something is definitely unmodified since its original publication. Similarly, the operating system can detect case #2 very easily: it attempts to verify the signature and finds a mismatch instead of a match. In that case, the operating system can sternly tell the user not to run the software because it is incredibly untrustworthy.

However, you want to know how to prevent a user from running something that has undergone arbitrary modifications. It's easy for an attacker to generate case #3 (no signature): simply replace your signed executable with an unsigned modified executable.

In this case, it's up to the user (or a very strict policy on the operating system) to decide never to run any software that does not have a signature. The user must expect a signature for your software and be alarmed at its absence (or otherwise always expect the worst and be deeply mistrustful of any unsigned software). There is no general way to distinguish between software that "should" have a signature but doesn't and software that simply was never given a signature at all (e.g. because the publisher just couldn't be bothered to do it). An attack cannot fake a modified executable so that it matches your signature, but they can produce a modified executable with no signature at all.

Of course, if your transmission method provides integrity (as TLS does) you can be sure that the executable that arrives on the client's computer is the same as the one sent from the server. If you control the server and distribute using TLS (e.g., through HTTPS), you (the distributor) can be sure that your clients are receiving your original software. If you also sign your software, the security conscious users can be sure they are running your original software, but this does nothing for security-unaware users, who don't understand the significance of a cryptographic signature.

Answer 2

Sounds to me like you looking more at the integrity of the actual file or data. When it comes to checking to ensure it is not infested with a possible virus, that where your Antivirus comes into play, or a UTM on your Firewall. For instance; a Sonicwall Firewall appliance would be able to ensure the safety of that file. but the actual integrity of the file or .exe would require what is mentioned below.

This was discussed before here: How can I check the integrity of the downloaded files?

I will also provide the most reliable answer below from a fellow SE:IS

"Integrity is defined only relatively to an authoritative source which tells what the "correct" sequence of byte is. Hash functions don't create integrity, they transport it. Basically, if you have: a file; a hash value, presumed correct; then you can recompute the hash function over the file and see if you get the same hash value. You still have to start somewhere. Some software distributors provide, along with the software, a "checksum" (or "md5sum" or "sha1sum") file, which contains the hash values. Assuming you got the correct checksum file, this allows you to verify whether you downloaded the right file, down to the last bit; and this works regardless of how you downloaded the possibly big file (even if it came over some shady peer-to-peer network or whatever; you cannot cheat hash functions). Now this does not solve the integrity problem; it just reduces it to the problem of making sure that you got the right hash value. Hash values are small (32 bytes for SHA-256) so this opens a lot of possibilities. In the context of downloading files from P2P systems, you could obtain the hash value from a HTTPS Web site (HTTPS uses SSL which ensures server authentication -- you have the guarantee that you talk to the server you intend -- and transport integrity -- what you receive is guaranteed to be what the server sent). In the context of exchanging PGP public keys with people, hash values (often called "fingerprints" or "thumbprints") are short enough to be transferred manually (printed on a business card, spelled over phone...). Digital signatures expand on the concept, but they too begin with hash functions. All digital signature algorithms sign not the message itself, but the hash of the message (which is equally good as long as the hash function is secure, i.e. resistant to collisions and preimages)."