Server signatures are specified in the protection profile (PP) DIN EN 419241-2:2019. The PP describes the basic processes, the requirements for an identity provider, the components involved, and the possible scope for decision making during implementation. The following figure shows the basic structure of a server signature solution based on this:
Figure 1: Server signing that meets the SCAL2 requirements
A system as the one shown in the previous figure is called 'trustworthy system supporting server signing' (TW4S) in the context of server signatures and the protection profile (PP) DIN EN 419241-2:2019. This provides remote digital signatures as a service and ensures that the signer's signature keys are only used for their intended purpose under the sole control of the signer in question.
The TW4S uses a cryptographic module to generate the signature key and produce the digital signature value. The system basically consists of a local and a remote environment. The signer resides in the local environment and interacts with the Server Signing Application (SSA) in the remote environment. The Signer Interaction Component (SIC) used for this purpose can be provided conceptually and depending on both the signer's side and on the remote side of the TW4S.
The purpose of the interaction between the signer and the SSA is to enforce the use of a specific signature service addressed by the SSA. The signature process is performed using what is known as the Signature Activation Protocol (SAP), which requires the provision of Signature Activation Data (SAD) using the SIC.
The SAD combines three elements that are essential for the provision of a remote signature: the signer authentication (performed according to [EN419241-1] SCAL.2), the signature key chosen by the signer for the signature process and the data to be signed (DTBS/R(s)).
To ensure that the signer has sole control over his signature keys, the signature operation must be authorized. This task is performed by a Signature Activation Module (SAM) that can process an endpoint from SAP, verify SAD, and activate the signature key within a cryptographic module. Both the cryptographic module and the SAM must be located within a dedicated protected environment. SAD verification here means that the SAM verifies the binding between the three SAD elements as well as the authentication of the signer. This binding of the SAD components is ensured, among other things, by the signer using a temporary key created in its environment, which is introduced into the signer authentication data in the form of an ID token on the one hand and is used to sign the SAD on the other.
The signer is authenticated by means of indirect authentication by the SAM. In this process, an authentication service in the form of an identity provider verifies the signer's authentication factors and then issues an assertion stating that the signer has been successfully authenticated. The SAM verifies the assertion issued by the identity provider or the Identity Token contained therein. In doing so, it must be able to rely on the assertion or the service issuing it.
The signer may use a user interface to display documents. The Signer Interaction Component (SIC) is accessed by the signer through the user interface. The SIC, in turn, is used to communicate with the Server Signing Application (SSA). The SSA forwards communication from the SIC to the QSCD. Within the QSCD, the SAM receives the messages. Once the SAM module has verified the SAD, it can authorize the activation of the signature key within the cryptographic module and generate a digital signature value. The value is given via the SSA to the SIC, which packs the value into a signature container and returns it to the signer via the user interface.
The SAM also generates audit logs. In addition, a TW4S relies on other services:
-
signers are identified and registered.
-
Signature keys are certified by a certification authority.
-
The signature creation application is responsible for creating the signed document using the signature values provided by the TW4S.
Together with the CC certified and eIDAS compliant Utimaco HSM of the model family 'CryptoServer Se-Series Gen2 CP5' (CC certificate [CCertCP5]), the proNEXT SignatureActivationModule v1.0.0 (CC certificate [ CCertSAM]), which is also CC certified, forms the QSCD to be used in the context of remote signature.