For more information and all parts of the series visit Introduction to eIDAS package for SignServer.
In the previous articles, we have discussed eIDAS SignServer: Advanced and qualified sealing and eIDAS SignServer: Advanced and qualified signing. The concept is clear, however on important feature was omitted. Let’s talk about the remote signing, which is considered as a trend in the world of trust services.
The eIDAS regulation introduced remote electronic signatures. The idea behind the remote signing is that your private signing keys are protected and securely administered by a trust service provider (TSP) that provides you with the access to perform digital signing.
In this case the TSP operating remote signing service must ensure that:
- the user is properly authenticated before executing the signing operation
- the private key is securely generated and protected for each user
- the private key can be used only by the authenticated user to whom the private key belongs (sole control)
- the data to be signed keeps its integrity during the signing process
Remote signing provides the following benefits for users:
- easy and accessible way of signing documents and data
- outsourcing of complex security processes and procedures to TSP
- signing from any device, anywhere, anytime
There are two main standards related to the remote signing:
- EN 419 241-1: Trustworthy Systems Supporting Server Signing Part 1, General System Security Requirements.
- EN 419 241-2: Trustworthy Systems Supporting Server Signing Part 2, Protection Profile for QSCD for Server Signing. (generally known as Signature Activation Module (SAM))
Sole control assurance levels
EN 419 241-1 identifies two levels of sole control assurance:
Sole Control Assurance Level 1 (SCAL1):
- The signing keys are used, with a low level of confidence, under the sole control of the signer.
- The authorized signer’s use of its key for signing is enforced by the Server Signing Application Service Component which authenticates the signer. The activation of the signing key can remain for a given period and/or for a given number of signatures.
In case of SCAL1, user relies on the server signing application to ensure that the appropriate signing key is selected. The functionality supporting signature activation and ensuring sole control is implemented as part of the server signing application.
Sole Control Assurance Level 2 (SCAL2):
- The signing keys are used, with a high level of confidence, under the sole control of the signer.
- The authorized signer’s use of its key for signing is enforced by the signature activation module by means of signature activation data provided, by the signer, using a signature activation protocol, in order to enable the use of the corresponding signing key to sign specific documents.
SCAL2 provides greater assurance of sole control by requiring code within the HSM to implement signature activation, called signature activation module. This code is certified to the same security level as the HSM’s general cryptographic functions. The signature activation data passes, in protected form using the signature activation protocol, from the signer’s device to the HSM to ensure that the user’s signing keys can’t be abused, even if the TSP’s server signing application were to be compromised.
Remote signing with the SignServer
Remote signing using the SignServer and SCAL1 is very simple. It follows a standard pattern of connecting the QSCD as a CryptoToken, generating key pair, issuing certificate, and configuring required Signer type. This is the most common use case for in-house digital sealing (see the eIDAS SIgnServer: Advanced and qualified sealing). Sealing or signing on behalf should be more secured and higher level of assurance is required. Typically remote signing solution on behalf of user is operated by the TSP, and in such case SCAL2 comes into play.
Remote signing using with the SCAL2 and the SignServer is possible by integrating the SAM and the signing back-end of the remote signing solution. We call it SAMCryptoToken. It is a special implementation of the of the CryptoToken for the SignServer, which contains necessary functions and interfaces to communicate with the SAM and the user’s device.
What is happening when user would like to sign the data within the context of the SignServer and SCAL2? The typical signature process is as follows:
- Request to sign the data is triggered from the the client
- Signer prepares the Data To Be Signed and asks the signing back-end to confirm by the user
- User confirms the Data To Be Signed and activates the private key for the signing operation
- QSCD + SAM verifies the request and produces the signature
- Signer completes the operation and provides the result
Let’s take a look at a sample implementation of the SAMCryptoToken.
The TRIDENT SAM has successfully attained Common Criteria EAL 4+ certification (Evaluation Assurance Level EAL 4 augmented by AVA_VAN.5 and ALC_FLR.3 based on ISO/IEC 18045:2008) meeting the requirements of the Protection Profile for QSCD for Server Signing (EN 419241-2) with strict conformance. The underlying CM (Crypto Module) is a Qualified Signature (and Seal) Creation Device (QSCD) under eIDAS regulation.
Thus, together they enable Trust Service Providers to offer both Advanced and Qualified Remote Electronic Signature Services and Remote Electronic Seal Services to Trust Service clients with the highest security and compliance requirements.
Following is a typical configuration of the TridentSAMCryptoToken:
CryptoToken implementation class defines the behaviour of the CryptoToken. Trident SAM integration with the SignServer is implemented as
The implementation takes care about the processes of key management and signing operations.
Trident SAM properties
Trident SAM communicates through https and we need to properly configure the access to the SAM:
- TRIDENT_URL – URL and port where the Trident SAM listens
- TRIDENT CEISK – certificate for the communication encryption
- TRIDENT CSISK – certificate for the communication signature verification
After these properties are configured, TridentSAMCryptoToken is able to establish secure communication channel with the Trident SAM.
Properties of the TridentSAMCryptoToken must be configured in order to perform the process of signing, private key activation, and certificate identification:
- CERT_STORAGE_IMPLEMENTATION_CLASS – the Trident SAM does not store certificates. This needs to follow the implementation of the certificate repository, which is used for the certificate search. It can be a repository of certification authority or it can be a simple directory with certificate files stored. Additional properties related with the certificate storage implementation may be needed.
- SAD_PROVIDER_IMPLEMENTATION_CLASS – implementation of the interface to get the signature activation data based on what signing operation can be validated and performed. These are provided by the user and it contains the secured and encrypted package of data to be signed together with the activation data for the private key. Additional properties may be required based on the specific implementation of the SAD provider.