Client-Side Hashing

The following describes various options for performing the hashing on the client-side instead of making all the steps in the signing on the server-side. Client-side hashing is also sometimes referred to as "hash signing" and the main advantage is that the original file does not need to be sent to the server.

CMS Detached Signatures

Detached signatures allow the signature to be placed in a separate file next to the original file, and thus the original file does not have to be updated. With CMS signatures, what is covered by the signature is a set of attributes (unless it is a direct signature) where one of the attributes is called messageDigest, which is the hash of the original file. This means that in order to create a CMS detached signature, it is sufficient to get the hash of the original file as input.

The CMS Signer is for instance configured to accept a hash as input by setting CLIENTSIDEHASHING=TRUE, or by allowing the client to specify if the input is the original file or a hash of it, by configuring ALLOW_CLIENTSIDEHASHING_OVERRIDE=TRUE.

When the client sends the request, the following properties need to be provided as request metadata:

• USING_CLIENTSUPPLIED_HASH=true

• CLIENTSIDE_HASHDIGESTALGORITHM=SHA-256

where SHA-256 should be replaced with the name of the hash algorithm used to digest the data. The algorithm must be one of those configured in the signer with the ACCEPTED_HASH_DIGEST_ALGORITHMS property.

The following commands can be used to create a detached CMS signature using this mode with a CMSSigner set up to default to consider requests as client-side computed hash (using the CLIENTSIDEHASHING property) (assuming a GNU/Linux, or Unix-like system is used):

Plain Signatures

For plain signatures (as produced by the Plain Signer), generally the whole file is sent to the signer and returned is the small signature. However, as the plain signature schemes involve a hash operation, it is possible to perform that on the client-side.

SignServer supports the following two options of using plain signatures with client-side hashing:

1. Explicitly specifying client-side hashing using request metadata properties: Works with algorithms RSASSA-PKCS1_v1.5, RSASSA-PSS, and ECDSA, for known hash algorithms and is the recommended option as of SignServer version 5.9. See Explicitly using Request Metadata Properties.
   
2. Implicitly using client-side hashing without request metadata properties: Supported for RSASSA-PKCS1_v1.5 and ECDSA but not for RSASSA-PSS. The input may also need special encoding, see Implicitly and With Encoding Depending on Algorithm.

recommended Explicitly using Request Metadata Properties 

We recommend explicitly specifying client-side hashing using request metadata properties. This is achieved by configuring the Plain Signer with CLIENTSIDEHASHING=true and SIGNATUREALGORITHM set to one of the NONEwith... signature algorithms and letting the client supply the CLIENTSIDE_HASHDIGESTALGORITHM request metadata property in addition to the hash value as data.

This configuration works with algorithms NONEwithRSA (RSASSA-PKCS1_v1.5), NONEwithRSAandMGF1 (RSASSA-PSS), and NONEwithECDSA, for known hash algorithms and is recommended as of SignServer version 5.9.

When the client sends the request, the following properties need to be provided as request metadata:

• USING_CLIENTSUPPLIED_HASH=true (unless the signer is configured with CLIENTSIDEHASHING=true)
• CLIENTSIDE_HASHDIGESTALGORITHM=SHA-256

where SHA-256 is replaced with the name of the hash algorithm used to digest the data. The algorithm must be one of those configured in the signer with the ACCEPTED_HASH_DIGEST_ALGORITHMS property. For descriptions of available properties, see Plain Signer and for algorithm support, see Plain Signer Algorithm Support.

Example for RSASSA-PKCS1_v1.5

Example for RSASSA-PSS

legacy Implicitly and with Encoding Depending on Algorithm

The legacy way of accomplishing client-side hashing is to configure the Plain Signer with a signature algorithm with the word NONE instead of the name of the hash and then let the client take care of sending in the input data encoded in the way expected by that signature algorithm.

In this case, CLIENTSIDEHASHING is set to false, or ALLOW_CLIENTSIDEHASHING_OVERRIDE is set to true, and the request specifies USING_CLIENTSUPPLIED_HASH=false.

Using this configuration, the hash is sent in differently depending on the algorithm:

• NONEwithECDSA (ECDSA): Send in the hash value.
• NONEwithRSA (RSASSA-PKCS1_v1.5): The input should be a DER encoded DigestInfo structure. Please refer to RFC 3447 and specifically page 42 for examples on the exact encoding. Alternatively, if the DigestInfo/ASN.1 structure is not wanted it could be left out when calling the signer.
  
• NONEwithRSAandMGF1 (RSASSA-PSS): Not supported. Use the option Explicitly using Request Metadata Properties instead.
  

For descriptions of available properties, see Plain Signer and for algorithm support, see Plain Signer Algorithm Support.

Example for ECDSA

Embedded Signature Formats

For signature formats where the signature is to be placed within the original document, additional logic has to be implemented on the client-side in order to, typically, first prepare the document for signing, compute the digest and send it to the server, and then finally embed the signature within the file.

On the client-side, support has been implemented for "client-side hashing and construction" for various signature formats (see below) for instance for Java Archives (.JAR, .APK,...) and for Authenticode signing of Portable Executable (PE) files (i.e. EXE, .DLL,..), Windows Installer files (.MSI) etc. Support for other file types such as PDF may also be implemented.

On the server-side, typically a CMS Signer is needed but since Authenticode and JAR signing are producing slightly different variants of the CMS signatures, different implementations are available for use. For instance for Authenticode, there is the MS Authenticode CMS Signer, and for JAR signing the JArchive CMS Signer.

Authenticode Signing

enterprise

When using the client-side hashing and construction for Authenticode file signing using the MS Authenticode CMS Signer the following options are available. Note that the MS Authenticode Signer supports the following formats:

• PE: Portable Executable files (.exe, .dll, ...)
• MSI: Windows Installer files (.msi)
• PS1: PowerShell (.ps1, .psd, .psm)
• CAB: Cabinet archives (.cab)

Another signer is available for signing of AppX/MSIX. See the APPX Signing section.

Sample Usage

JAR Signing

enterprise

When using the client-side hashing and construction for JAR file signing using the JArchive CMS Signer, the following options are available.

Sample Usage

OpenPGP Signing

enterprise

When using the client-side hashing and construction with OpenPGP using the OpenPGPPlainSigner, the parameters key ID and key algorithm (when using a key with an algorithm other than RSA) need to be specified with the request using the -extraoption options.

Sample Usage

Debian Dpkg-sig Signing

enterprise

When using the client-side hashing and construction with Dpkg-sig using the OpenPGPPlainSigner, the key ID, key fingerprint, and key algorithm (when using a key with an algorithm other than RSA) need to be specified with the request using the -extraoption options.

Algorithm Support

Note that specifically for DSA signatures in client-side mode, other algorithms than SHA1 may not be supported due to the underlying implementation.

Sample Usages

The key ID is the hex-encoded representation, and the key algorithm can be specified as either a name (RSA, DSA, or ECDSA) or using one of the PGP constant values (for example 19 for ECDSA).

DNSSEC Signing

enterprise

When using the client-side hashing and construction for DNSSEC zone file signing using the ZoneHashSigner, the following -extraoption options should be provided on the command line in addition to the required request metadata property specifying which keys to use.

Sample Usages

APPX Signing

enterprise

When using the client-side hashing and construction for Appx file signing using the Appx CMS Signer, the following options are available.

Sample Usages

APK Signing

enterprise

When using the client-side hashing and construction for Android Package Kit (APK) file signing using the APK Hash Signer, the following -extraoptions can be used.

Algorithm Support

SignClient assumes the server-side signer is configured with either NONEwithECDSA, or NONEwithRSA as signature algorithm. SignClient currently supports SHA1, SHA-256, SHA-384, and SHA-512 with RSA and SHA1, SHA-224, SHA-256, SHA-384, and SHA-512 with ECDSA. DSA is not supported.

Sample Usages