0

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?

nikitablack
  • 307
  • 1
  • 2
  • 7
  • @apsillers My question is how to be sure that when the user double clicks on the downloaded exe he runs my program and not a virus. If I sign a file, how can he check it without running? – nikitablack Nov 10 '14 at 17:44
  • @nikitablack You don't execute the file when you compute the file signature and check it against the one provided by the trusted authority. Also don't only write a comment but instead edit your question to address exactly what you are asking. – go2 Nov 10 '14 at 18:01

2 Answers2

3

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:

Windows executable confirmation pop-up, with "Publisher" field of "WinZip Computing"

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.

Windows executable confirmation pop-up, with "Publisher" field of "Unknown Publisher"

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.

apsillers
  • 5,820
  • 28
  • 33
  • Is it possible that man in the middle replaces my file with his signed file (a virus)? – nikitablack Nov 11 '14 at 09:23
  • 2
    @nikitablack Sure, a malware author could sign a virus with any private signing certificate that he has. The benefit of a signature is knowing who signed it. If you download a file from "Good Guys, Inc." but the file is signed by "Mysterious Suspicious Corp.", you know the file didn't come from Good Guys, Inc. It seems pretty dumb to sign your malware, though: after a few reports, Windows (or the CA) will send around an update not to open files signed by Mysterious Corp. (Of course, if someone steals the private signing key from Good Guys, Inc., that's an entirely different matter...) – apsillers Nov 11 '14 at 15:24
1

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)."

Community
  • 1
Cameron Does Things
  • 592
  • 3
  • 10
  • From this I understood that if I provide a way to check a hash value for the user he can do all the ckecks by himself. And even better, if I the user downloaded my file from https, this guarantees that the file is not corrupted, right? – nikitablack Nov 10 '14 at 17:42
  • The simple answer is that it is a way of checking to make sure the data you are receiving is not corrupt or possibly altered from the original. If someone caught that file in relay and attempted to change the file or possible do something with malicious intent, a hash check would be able to tell you if there was an change made in that file as the MD5 woul

    A hash is a "fingerprint" of data unique to that data. The hash check compares that fingerprint to the reference hash (fingerprint) in the file or exe and if they are different, discards the data. If they are the same, the data is accepted.

     – Cameron Does Things Nov 10 '14 at 18:05
  • A good reference model: http://www.howtogeek.com/67241/htg-explains-what-are-md5-sha-1-hashes-and-how-do-i-check-them/

    https doesn't really guarantee that the file is not malicious or possible compromised and hash check would still allow for the integrity of the file to be ensured. it only creates a secure tunnel between the server and the destination. It can still be caught in relay from a SSL protected root. Though normally that type of attempts at attacking a SSL protected tunnel isn't always worth it so its easily seen as a deterrent.

     – Cameron Does Things Nov 10 '14 at 18:06
  • Yes, that's part I understand. But how can user check this "fingerprint"? Assume that the user is a housewife and doesn't know anything about command line and 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? – nikitablack Nov 10 '14 at 18:11
  • I am not a dev. but from what I gather, you can implement a hash check in the exe before its packaged that checks the original file on the server to the local copied file and ensure it is correct. That would require some explanation I cannot give. but I do know there is what I believe they call framework that allows you to make this a function. Again, sorry if I am not using the right jargon, I am in no way a developer. – Cameron Does Things Nov 10 '14 at 18:34