Will it improve security if I place both SHA1 and SHA256 signatures inside codesigned binary on Windows?

Question

My application targets platforms starting with Windows 7 32bit. Many of them aren't up to date (i.e. may be missing many recommended updates from Microsoft).

Given the constraints I must use SHA1 signature inside my userspace and kernel binaries. However, will it make the attacker's life harder if I also embed SHA256?

I'm concerned, because I'm trying to imagine what an attacker may do. As an attacker, my goal would be to substitute binary without breaking making Windows to notice that. I'm not sure how Windows verifies signatures, but the idea is to remove SHA256 signature at all and make my replacement binary to have the same SHA1 signature. Then when Windows will verify app's binaries, it will compare their SHA256 signatures for all but my binary, which only has SHA1 signature.

Note: my public certificate only has a SHA1 signature embedded by the issuer.

Answer 1

Technically, using SHA-256 won't make things really harder for the attacker. Unless you are the attacker.

The concerns about SHA-1 are about collisions. SHA-1 is believed to be somewhat weak in that respect (generating a SHA-1 collision is still very expensive, to the point that it has not been done yet even once, but we have strong theoretical reasons to think that the collision-finding methods that have been designed to attack SHA-1 would succeed in finding a collision in substantially less effort than the 2⁸⁰ expected from a "perfect" hash function).

When you sign a piece of data, you begin by hashing it, and the hash value is then used throughout the rest of the signature generation and verification algorithms. To leverage a collision, one must imagine that there are two distinct versions of the same software, the second one being malicious and doing evil things on the client system, but such that both yield the same value when hashed with SHA-1. If two such files can be created, then a signature (with SHA-1) computed on the first file would also apply to the second one, and vice-versa. This helps the attacker only in a context where the attacker gets to choose the file that is signed in the first place.

In your case, the original file (the normal, honest one) is the one that you produce yourself. If a collision helps the attacker, then you are the attacker.

If you are not the attacker, then what an attacker has to do is to find a second preimage: the attacker sees the honest, non-malicious file (that you signed), and tries to make a modified file that hashes to the same value. This is not at all the same problem. A collision is about finding m and m' such that m ≠ m' but h(m) = h(m'). A second preimage is the same thing except that m is not chosen by the attacker. This is much harder, and (as far as we know) infeasible with SHA-1. There is no known, even theoretical, weakness of SHA-1 that would allow an attacker to do that.

Correspondingly, switching from SHA-1 to SHA-256 would not improve things. If the attacker can make a malicious file with a valid signature from you, then this means that the attacker can actually make you sign code of his choosing (e.g. the attacker compromised your own development computers), and under these conditions, SHA-256 does not block the attacker any more than SHA-1.

---

However, client systems may have another opinion on the subject. From the point of view of a client, the signature process may go thus:

• Somebody submits to the signer (you) some data to sign.
• You audit the data to be signed, and sign it if you find it good and appropriate. E.g., for software, you look at the source code and do the compilation yourself.

In this model, the attacker may craft some code that looks good but, when compiled, yields a binary that collides with some malicious code that the attacker also crafted. Under this specific model, collisions are an issue, because the attacker is in position to choose both the honest and the malicious versions of the software.

Most probably, you do not follow this model -- when you sign a piece of software, it is a piece of software that you developed yourself, not something submitted from potential attackers. You know that. But Microsoft is not so sure, and might decide that it would be too risky to use a hash function that might allow collisions to happen.

So you still probably want to switch to SHA-256, not because SHA-1 would be too vulnerable (this is not the case in your situation), but because Microsoft may decide to remove SHA-1 support.

Microsoft policy is explained here, with the particular excerpt:

Code signed with SHA-1 certificates that are time stamped before 1 January, 2016 will be accepted until 14 January 2020 (when Server 2008 extended support ends), at latest. This date may be moved earlier if Microsoft decides SHA1 is vulnerable to pre-image attack.

Note the final sentence: the problem is really about pre-images, not collisions.

You will also want to buy a code-signing certificate such that the signature on the certificate, and on all CA certificates in the chain, use SHA-256, because it seems that Windows is becoming increasingly allergic to SHA-1. For about the same reasons as above, this anathema on SHA-1 may be qualified as overkill, but Microsoft has no choice: Google is intent on killing SHA-1, and Microsoft must follow; otherwise, they will be mocked and laughed at.

Answer 2

My short answer: Changing from SHA1 to SHA256 for file signatures will barely increase your security, the only good reason would be to keep current with best practices.

The concern with SHA-1 and the potential for collisions is that potential decryption may take place. This has to do with decrypting hashes after the fact: for example, passwords in a database could be looked up via a rainbow table, and this process might be accelerated through collisions.

However, you're using SHA for a different purpose -- verifying file integriy. Due to the avalanche effect in hashing algorithms, despite SHA1's age it would still be near impossible for an attacker to insert malicious code or other modifications while maintaining the previous signature.

So, for SSL sessions which may be stored and decrypted after the fact, moving to SHA256 makes sense. However, for file integrity validation, it will likely make little difference. It might make sense to supply both SHA1 and SHA256 hashes just for sake of best practices, but I don't know of any foreseeable attack method that could exploit SHA1 to allow one to modify files and maintain their previous signature.

Answer 3

If you are concerned about the security of SHA-1 then you must know that SHA-1's use on the Internet has been deprecated since 2011 and just to give you a hint:

HTTPS sites whose certificate chains use SHA-1 and are valid past 1 January 2017 will no longer appear to be fully trustworthy in Chrome’s user interface.

But there is no successful complete collision attack known by the date you asked this question on SHA-1 - but may be that wouldn't be the case during the few coming years regarding the growing calculations speed of computers - whereas SHA-256 is totally collision-resistant. So yes, your option is much better than relying on SHA-1 only.