Is it possible to have SHA1-Digest in a Java manifest file without actually using a key

Question

We are currently using jarsigner to sign our banquet. Then we show some SHA1-Digest values ​​for some specific classes to prove to the external auditor that the code has not changed between versions.

We use only the META-INF/xxx.SF for digest information, and we never use the META-INF/xxx.DSA signature block file.

Since we only need the digest calculation in our code, I was wondering if it is possible for the .SF file .SF be generated using some Java tool without actually using the key.

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

Answer 1

It should be possible. The MANIFEST.MF file contains SHA-1, encoded by Base64, of the corresponding class file.

From the doc:

 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, iterating over all class files, calculate the SHA-1 format, which as it appears in MANIFEST.MF, then the hash and the format as it appears in the SF file.

There is no key associated with the calculation.

Example: consider "jce1_2_2.jar" (or whatever you correctly signed). It contains

• MANIFEST.MF form entries

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

• which are Base64 (SHA1-1) "KeyAgreement.class" (the path does not matter). Pay attention to the third empty line. The ends are CRLF (Windows).

• Recording META-INF / 4JCEJARS.SF

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

which is not a file hash, but from those three lines above.

Answer 2

Signature verification will fail ...

Why?

Checking JAR files → Check the signature of the .SF file itself.

That is, verification ensures that the signature stored in each file of the signature block (.DSA) was actually 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 file (.SF), and therefore the .SF file has not been modified.

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