Is it possible to have SHA1-Digest in java Manifes

Question

Currently we use jarsigner to sign our jar. We then display some SHA1-Digest values for some specific classes to prove to an external auditor that the code has not changed between releases.

We only rely on the META-INF/xxx.SF file to get the digest information and we never use the META-INF/xxx.DSA signature block file.

As we only need the digest calculation in our code, I was wondering if this is possible to have the .SF file generated with some java tool without actually using a key.

I read http://docs.oracle.com/javase/6/docs/technotes/tools/windows/jarsigner.html but it looks like the key is mandatory.

Answer 1

This should be possible. The MANIFEST.MF file contains a Base64-encoded SHA-1 of the respective class file.

From your document:

In the manifest file, the SHA digest value for each source file is the
digest (hash) of the binary data in the source file. In the .SF file,
on the other hand, the digest value for a given source file is the
hash of the three lines in the manifest file for the source file.

So, iterate over all class files, compute the SHA-1, format that as it appears in MANIFEST.MF, then hash that and format as it appears in the SF file.

There is no key involved with the computation.

Example: consider "jce1_2_2.jar" (or whatever you have properly signed). This contains

1. MANIFEST.MF entries of the form

   Name: javax/crypto/KeyAgreement.class
   SHA1-Digest: c2p0JimzpV0dG+NChGLl5cI7MuY=
   <empty line>
   

2. which are the Base64(SHA1-1) of "KeyAgreement.class" (path is not relevant). Note the third empty line. Line endings are CRLF (Windows).

3. META-INF/4JCEJARS.SF entry

   Name: javax/crypto/KeyAgreement.class
   SHA1-Digest: whGBXE+AvYO6wAoVCdnocOPIrsE=
   

which is the hash not of the file, but of those three lines above.

Answer 2

Signature verification will fail...

Why?

JAR File Verification -> Verify the signature of the .SF file itself.

That is, the verification ensures that the signature stored in each signature block (.DSA) file was in fact generated using the private key corresponding to the public key whose certificate (or certificate chain) also appears in the .DSA file. It also ensures that the signature is a valid signature of the corresponding signature (.SF) file, and thus the .SF file has not been tampered with.

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