How to sign a digest file created by signtool /dg?

[obones]

Hello,

I'm trying to automate the triple signature mechanism required for Microsoft Office files (XLA/XLAX...) and am thus using the OfficeSIPS package provided by Microsoft.
The issue is that it's only usable with signtool, and while it works when using a certificate whose private key is stored on a physical usb token (Yubikey), I'm struggling to get this working with a private key hosted at Googe Cloud.
I don't see how jsign would be able to use those "Subject Interfaces" and so am trying to figure a way to integrate jsign in the process only at the signature step.
Here are the steps that I'm trying:

1. get the file digest by using the /dg option

    signtool sign /q /f "%CertificatePublicKeyFilename%" /du %SignatureUrl%  /fd sha256 /dg . "%FileToSign%"
   

2. Sign the generated digest with the jsign --detached option

    java -jar jsign-0.5.jar --detached --storetype GOOGLECLOUD --storepass file:%TOKEN_FILENAME% --keystore %GoogleCloudKeyStore% --alias %GoogleCloudKeyNameAndVersion% --certfile "%CertificatePublicKeyFilename%" "%DigestFile%"
   

3. Integrate the signed digest with the /di option

    signtool sign /q /f "%CertificatePublicKeyFilename%" /di . "%FileToSign%"
   

4. Timestamp the generated signature

    signtool timestamp /q /tr %SignatureTimeStampURL% /td sha256 "%FileToSign%"
   

Steps 1, 3 and 4 use the above SIPS under the hood to properly handle the Office file formats.

The %DigestFile% is of the form MyFile.xla.dig and contains 44 characters in the following form:

PJIzVGX0ZUiADHd/9dxP7w/7Q7p4XTDDvFH5JQnqVX0=

Unfortunately, the above jsign command fails with a clear error message:

jsign: Unsupported file: MyFile.xla.dig

Note that I tried replacing %DigestFile% with %FileToSign% but this gives me this more than expected error message:

jsign: The document is really a XLS file

Obviously, I have misunderstood what the --detached option is for, but then I'm not quite sure what option I could use, if any, to get jsign to just sign the digest file, generating a .sig file usable by the /di option from signtool.

Do you think there is a way to achieve what I'm trying to do with jsign?

Thanks for your help

[ebourg]

The .dig file contains the base64 encoded digest of the file to sign, and the .dig.signed file contains the digest encrypted by the private key, also base64 encoded.

Jsign doesn't know how to sign such files. I have to think if it could be implemented, but it wouldn't bring much benefit compared to a direct API call to the cloud provider to get the signed hash.

On the other hand, Jsign could directly support the Microsoft Office files, that would be much easier.

[obones]

Jsign doesn't know how to sign such files. I have to think if it could be implemented, but it wouldn't bring much benefit compared to a direct API call to the cloud provider to get the signed hash.

Well, in my case it would help greatly as the Microsoft Office files format is not supported.

On the other hand, Jsign could directly support the Microsoft Office files, that would be much easier.

I don't know anything about what's needed to support both formats (XLA/XLAX) but I do know that there are 3 signatures to apply, in three different places/formats and that they are cumulative.
The readme file from Office SIPS gives some details as to why it's done like this:

8. The best practice when signing VBA projects in Office files involves creating all three signatures.
   However, the Windows cryptographic stack only supports creating one of these signatures at a
   time. To accomplish signing with three signatures, begin with a document with an unsigned VBA
   project and run signtool.exe (or other tool of your choice) the first time to sign the project.
   This will generate the legacy format signature. Running the tool again on the same file will
   add the second agile signature. Running the tool for the third time on the same file will add the
   newer, more secure, signature. Note that if a file already has both legacy and agile signatures,
   any new attempts to sign the file will produce (or overwrite) the third signature. In order to
   sign a file from scratch again, including the legacy and agile signatures, the existing signatures
   must first be removed (see below).

However, I could not find any documentation about technical details for these three signatures.
I did find a detailed explanation as to how to create a SIP but it's for the PNG file format: https://vcsjones.dev/subject-interface-packages/
But I'm not sure it would help with office files.

[ebourg]

I got a quick look at the Office SIPS and the signature produced for OOXML files. There are indeed 3 signatures generated (vbaProjectSignature.bin, vbaProjectSignatureAgile.bin and vbaProjectSignatureV3.bin), and their structure is documented.

However it isn't clear what content is hashed exactly. I don't know if the vbaProject.bin is hashed as is, or if some info is extracted from the file and hashed. I also don't know if other entries besides the VBA code is hashed.

I'd bet that the oldest format (vbaProjectSignature.bin) simply hashes the whole vbaProject.bin entry, and the more recent variants include more elements into the hash (such as [Content_Types].xml which is also hashed when signing APPX files). If someone has more information about the hashing process I'm very interested.

I haven't looked at the older MS Office formats such as .xla. I guess most people now use the new formats, so I'd rather focus on these.

[ebourg]

I also note that Office SIPS comes with the Visual Basic Environment (vbe7.dll), so the vbaProject.bin entry is probably processed in some way. Either some info is extracted from the VBA macro, that should be easy to replicate, or the macro is recompiled (I imagine a case where a macro is only provided in source form, and the signing process expects to sign both source and binary forms) and that would be difficult to implement.

[obones]

Side note : I understand your willingness to concentrate your efforts on the OpenOffice formats (pptx, xlax...) but for various historical reasons, that's not the format I'm currently using, but it could be changed if need be.

When I use the Office SIPS, it does not require the source code form, it only works with the XLA file and what's inside it. But maybe it can extract the source from the XLA just like what Excel is doing when showing it in the developer form.