SecureBlackbox 2020 C++ Builder Edition

Questions / Feedback?

Signing with external keys

Signing with External Keys

While built-in support for keys managed by CryptoAPI, PKCS#11 drivers, KMIP and Azure Vault covers the majority of signing scenarios, in some cases signing keys cannot be accessed via those standard mechanisms. Among the exceptions are devices or services that use proprietary signing APIs, or those located in isolated environments and requiring specific access route.

SecureBlackbox allows you to leverage such keys by utilizing one of its two external signing facilities. Each of the options is tailored for specific signing scenarios. Read on to learn more about each option and find out which one would be appropriate in your circumstances.

The simpler, synchronous option is based on the SignExternal() method, and works as a simple wiretap into the signing routine. This method follows exactly the same procedure as Sign() does, but when it comes to performing the actual signing it fires off the OnExternalSign event and requests the signature from your code, instead of calculating it by itself. It then incorporates the signature into the document and completes the operation.

Since this method works sychronously, it requires the signing service/device to be accessible at the time of signing, and be capable of returning the signature within the same execution context. This method may be an optimal choice if your signing device or service is accessible in real time. Most hardware devices and signing services offering REST/SOAP connectivity satisfy this requirement.

This option is supported by the majority of SecureBlackbox components, including PDF, Office, XAdES and CAdES signers, TLS-capable clients and servers (for certificate-based authentication), MailWriter, and DCAuth.

The more sophisticated, asynchronous option is based on the SignAsyncBegin()/SignAsyncEnd() pair of methods. The asynchronous signing method consists of three isolated steps:

  • On the first, pre-signing stage you set up your signing component (e.g. PDFSigner) as required and call its SignAsyncBegin() method. This method outputs a pre-signed document (think of a document with a placeholder for the future signature), and an async request which contains the hash that needs to be signed. At this point you may release the signing component and terminate the pre-signing process.
  • On the second, hash signing stage you use the DCAuth component to process the async request. This may happen on the same system where you performed the pre-signing step, or on a different system. DCAuth extracts the hash from the async request and signs it with the designated key, producing the async response which contains the signature.

    The signing key can be taken from one of the standard locations (a file, PKCS#11 device or CryptoAPI store), or used externally via the DCAuth.OnExternalSign event.

  • On the final, completion stage, you instantiate your signing component (PDFSigner) again, and pass the async response produced by DCAuth earlier, together with the pre-signed document that you obtained on the pre-signing stage, to its SignAsyncEnd() method. SignAsyncEnd() extracts the signature from the async response and embeds it into the pre-signed document, thus producing a fully signed document.

The asynchronous method is more appropriate for scenarios which need to run in different execution contexts. Two examples of such scenarios are where there is some user interaction involved (e.g. the user needs to type in a PIN or authenticate to a web site with a browser), or where the signing result is not available immediately (e.g. is submitted asynchronously to a separate web endpoint).

This option is supported by most of SecureBlackbox signing components: PDFSigner, XAdESSigner, CAdESSigner, and ASiCSigner.

Copyright (c) 2022 /n software inc. - All rights reserved.
SecureBlackbox 2020 C++ Builder Edition - Version 20.0 [Build 8154]