1345528 - signtool is hardcoded to use a SHA1-based signature algorithm

Status: NEW

(NSS :: Tools, enhancement, P3)

Description

[Kai Engert (:KaiE:)]

As part of bug 1345106 I've investigated which changes are required to change signtool to no longer use SHA1 by default, but change it to use SHA256.

signtool signs a directory, by creating digest information for each file, adds those to a manifest file, and then creates a detached signature for the manifest file.

It already uses both MD5 and SHA1 to create multiple hashes for each file. It's trivial to expand that add extra lines for SHA256, and also have code that compare those.

However, the detached signature is more problematic.

As of today, signtool is hardcoded to use SHA1 as the digest when creating the signature, and also, when it verifies a signature.

If we simply changed the default to use SHA256 when creating the signature, and old versions of signtool would be unable to verify new archives.

If we changed the default of verification to expect SHA256, then new versions of signtool would be unable to verify old archives.


signtool calls SEC_PKCS7VerifyDetachedSignature, which expects the caller to know what kind of signature algorithm it expects.


I've looked at some documentation and found an example signed jar file.

I'm guessing that we should look at information stored in file META-INFO/*.SF file, to decide what kind of signature to expect.


This means, we cannot simply change the default.

We must enhance signtool to write information into the META-INFO/zigbert.sf file, and also to read from that, which can be used to derive what signature algorithm we can expect.


But we probably shouldn't make that decision completely on our own. I'm assuming that we should do it in a way that is compatible with other software.

In an example, I found the headers
Signature-Version: 1.0
SHA-256-Digest-Manifest-Main-Attributes: something-a something-b
SHA-256-Digest-Manifest: something-c


So, before this can be fixed, I think more research is required.

Comment 1

[Kai Engert (:KaiE:)]

I did more experiments, and I think, we cannot change the output of signtool without the risk of breaking today's compatibility.

OpenJDK jarsigner today is able to verify the packages created by signtool.

Any change/enhancement that I tried to improve signtool resulted in jarsigner being unable to verify what signtool produced.

Apparently jarsigner expects that signtool creates SHA1 digests in the manifest and sf files, and expects that the created signature uses SHA1.

I'm afraid that prior to deploying an improved version of signtool, we'd have to create documentation for how we'd like to enhance our files, and talk to today's major consumers, and wait for them to be compatible with out new plans.

Comment 2

[Kai Engert (:KaiE:)]

Attachment: backup of experiments v2

Comment 3

[Kyle Hamilton]

http://docs.oracle.com/javase/7/docs/technotes/tools/windows/jarsigner.html

Particularly, note the use the Supported Algorithms (and defaults).  DH keys get SHA1withDSA, RSA keys get SHA256withRSA, EC keys get SHA256withECDSA.

It probably would not be too much trouble to make it work.  Whether it's still appropriate given that there are alternative toolchains (per https://groups.google.com/forum/#!topic/mozilla.dev.tech.crypto/N4e5JQbTyMU) is another question entirely.

Comment 4

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

Bulk change per wleung.