4

I have an EXE file on Windows that I have to distribute around. It's based on tclkit so an adversary could unpack it, change some tcl script inside and repack the exe.

I would like to know if this ever happen, so that if anyone complains about what they received I can check if the file is really the one I sent or if anyone modified it.

I plan to use a self-signed certificate to sign the exe, expecting that nobody would be able to sign it again without having my private key.

Is my reasoning correct? Or there could be a way to change the file and still make it appear as if it was signed by me?

Improve this question

6 Answers 6

Reset to default
4

It's important that the person receiving the file checks it against your public key. Anyone can create a self-signed certificate, and you can put whatever meta-data you want into it. So, two self-signed certificates can look and behave identically, the only thing that differentiates them is the key pair used to sign it.

In other words, and answering your comment on Jeff's answer, you can't visually distinguish between a legit and a forged certificate, if for instance the OS or browser or whatever pops up a window showing its details. Certificates signed by a trusted authority, OTOH, will be shown together with a name/link that is harder (nigh impossible?) to be forged.

But if your public key is published/sent to your customers, they can verify (or you can later prove) whether or not the file is legit. Since nobody else know your private key, they can't create a certificate (self signed or not) that matches it, even if the meta-data look the same.

Improve this answer
3
  • 1
    Good answer, but I'll add the caveat that how you get your public key to your customers becomes a concern. If you are afraid that somebody might perform a man-in-the-middle attack on your customers, then that same attacker may also be able to intercept your public key and supply their own public key instead. If you really need security, you should distribute the keys in some other way -- such as physically handing it to them on a USB drive.
    – Mark E. Haase
    Apr 1, 2012 at 19:01
  • "Since nobody else know your private key, they can't create a certificate (self signed or not) that matches it, even if the meta-data look the same." - If the certificate was created the wrong way this might not be true. If it can happen to Microsoft it could happen to pretty much anyone. As time goes by the cost to recreate the attack goes down.
    – Ramhound
    Jun 19, 2012 at 11:20
  • @Ramhound MS lost a certificate? The only thing I heard of is that they were acting as CA and were signing bad certificates. So I don't think that this can happen to pretty much anyone. It can only happen to CAs.
    – CodesInChaos
    Jun 19, 2012 at 12:17
2

Who do you want to prove the integrity of the executable?

If it is to yourself you can simply keep a copy of the executable you sent out and compare it.

If it is to someone else a self signed certificate will not help at all. Anyone who changes the executable can also generate a self signed certificate with properties identical to yours and re-sign the executable.

Improve this answer
3
  • 1
    If it is to prove to yourself, what if every user of the system has a custom executable and you have thousands of users? If it is to someone else, you can give that someone else your public key through some secure channel. Then they can be assured of the validity of the executable.
    – mikeazo
    Mar 31, 2012 at 18:56
  • It's for me to prove to others that the exe was modified. I'm little worried about the statement "Anyone [...]can also generate a self signed certificate with properties identical to yours". Is it really the case? Shouldn't the two certificates being distinguishable (even if self-signed)?
    – Remo.D
    Mar 31, 2012 at 20:04
  • @Remo.D, they won't be exactly the same, so yes they would be distinguishable. Specifically, the modulus would be different. Easy for a computer to detect, potentially harder for a human to detect though.
    – mikeazo
    Apr 1, 2012 at 13:28
1

I would like to know if this ever happen, so that if anyone complains about what they received I can check if the file is really the one I sent or if anyone modified it.

I'll answer on this side-question. Checksum of file (published) will give your and customers less headache with comparable level of protection, even more - nobody will be able to get the same SHA2 hash on modified file, as on unmodified.

Improve this answer
7
  • I wouldn't sue MD5 or SHA1. Both are considered broken by the cryptography community. Use any of the SHA-2 family instead.
    – mikeazo
    Apr 1, 2012 at 13:26
  • 1
    @mikeazo, SHA1 is not broken.
    – D.W.
    Apr 1, 2012 at 18:44
  • @D.W., depends on your definition of broken I guess. I certainly wouldn't use it for new applications after reading a summary of attacks on wikipedia (en.wikipedia.org/wiki/SHA-1#SHA-1). Schneier declared it broken in 2005 (schneier.com/blog/archives/2005/02/sha1_broken.html)
    – mikeazo
    Apr 1, 2012 at 19:40
  • @mikeazo - I hate empty loud statements. Unless you show, how "broken" MD5 can be exploited in discussed case (my file, not specially crafted, and default, not pre-patched, md5sum on client) I still think you are pompous windbags
    – Lazy Badger
    Apr 1, 2012 at 20:12
  • 1
    Can we calm things down a bit, and de-escalate? Everyone here has a reasonable point. Lazy Badger has a reasonable point: in this setting, second preimage resistance probably matters more than collision resistance, and there are no known serious second-preimage attacks against the security of MD5 or SHA1. Mikeazo has a reasonable point: for new designs, it is arguably safer to use a modern hash with no known weaknesses, like SHA2 or SHA256, because it just takes some risks out of the equation. Also, there may be some (less likely) scenarios where collision attacks could be a threat.
    – D.W.
    Apr 2, 2012 at 1:35
0

Your idea sounds correct. No one should be able to change the file and have the signature still work. And no one should be able to create another digital signature without your private key.

Improve this answer
0

A signature proves that the object was signed by the owner of the certificate. Nothing more. If that certificate can be readily traced back to you, then it proves that it was signed by you.

Now, if someone that the user trusts (say Microsoft, Verisign, etc.) signs your certificate, then that proves.. that they signed your certificate. Presumably they'll only do so if they trust you.

So you theoretically have a chain of trust all the way back to the user, each one trusting the next, and therefore the user implicitly trusts you.

If, on the other hand, your certificate isn't signed by anyone (i.e. a self-signed certificate, since all certificates have a signature), then the user does not implicitly trust your signature, but if they have some way of verifying that the certificate is yours (e.g. you give it to them in person), then your certificate can become another anchor of trust, just like the certificates provided by Verisign or Microsoft.

Improve this answer
0

so that if anyone complains about what they received I can check if the file is really the one I sent or if anyone modified it.

The traditional way of checking if a file is modified is to use the "md5sum" utility, or the (probably superior) "sha256sum" utility.

Many organizations use this technique to verify that files, downloaded from "mirror sites" that are conveniently nearby (and therefore faster than downloading from the "original site" on some other continent), haven't been maliciously or accidentally modified somewhere on the path from the original, to the mirror site, to the final destination. a b c d e

Using those utilities, someone with the original version of the file generates a short md5 hash or a short sha256 hash (or both) of the original file, and stores that short hash in some text file somewhere. (Typically on the "original site" and on every mirror site).

Later, someone with a questionable file runs the same utility, producing a fresh hash value. If the fresh hash value is identical to the hash produced from the original file (that hash is typically obtained from the "original site", possibly using a web browser and https and TLS), then you can be confident that the questionable file is, in fact, identical to the original file.

Some paranoid people download the hash sum from several different "mirror sites" and other sources. (This is quick, because the hash sum is very short; much faster than re-downloading the entire file from all those sources). The likelihood that all those sources have been subverted becomes more and more unlikely as more sources are consulted.

(Since you are generating the original executable, be aware that recompiling exactly the same source files using exactly the same compiler usually produces a slightly different executable file, resulting in a completely different hash. See "How do you verify that 2 copies of a VB 6 executable came from the same code base?" for details).

There are many utilities that build on top of md4sum or sha256sum.

  • md5deep and hashdeep can make a "summary" of an entire folder at one point in time -- perhaps your home directory, or the /bin directory, or the root folder of an entire hard drive. Then later it can tell you exactly which files have been added, deleted, or changed since that summary was made. When the hashes match, you can be sure executable files haven't been infected by a virus after the original snapshot -- this even detects new viruses that are not yet recognized by any virus scanner. (Virus scanners are still useful to detect files that were infected by a virus before the original snapshot).

  • bittorrent uses sha1 to confirm that pieces of a file downloaded from completely untrusted machines are identical to the original pieces of that file.

  • rsync uses md5sum to quickly check if the local file is identical to the master copy of a file on some remote file server. If they are different, it assumes the local copy is some obsolete version, and automatically downloads the differences between the two files, modifying the local file until it becomes identical with the remote master file.

I'm pretty sure some protocol could be developed using a self-signed certificate that would work just as well as using sha256sum; but I don't see how this new protocol would give any advantages over the commonly-used sha256sum check.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .