Qualified Electronic Signatures – Best Practice Implementation of the Signature Activation Module (SAM)

This article evaluates the implementation options for the Signature Activation Module (SAM) in the context of eIDAS 2. Based on this analysis we recommend placing the SAM inside the Cryptographic Module within the tamper-protected environment provided by the Qualified Signature Creation Device (QSCD).

The concept of a Qualified Electronic Signature (QES) is a key component of the eIDAS regulation (Regulation (EU) 2024/1183, amending Regulation (EU) No 910/2014 and briefly referred to as eIDAS 2.0). A QES bears the highest possible level of legal certainty and is considered the equivalent to a handwritten signature within the EU. eIDAS requires that Qualified Electronic Signature Creation Devices (QSCDs) are used in creating QESs. These QSCDs must use certified hardware and software to ensure with a high level of confidence that the signing keys are used under sole control of the signer (Article 26c). For remote QSCDs where the user does not have physical possession of the signature keys, the management of such devices as a qualified service shall be carried out only by a qualified trust service provider (QTSP).

Certification of QSCDs is valid up to a maximum of five years with vulnerability assessments to be carried out every two years. The reference standards, specifications and procedures for the management of remote QSCDs are still to be determined by means of Implementing Acts, by 21 May 2025 (eIDAS 2, Article 29a).

QTSPs shall be audited at their own expense at least every 24 months by a conformity assessment body (eIDAS 2, Article 19a paragraph 2(a)).

In view of to-be-published Implementing Acts and certain strong auditing requirements it is important to aim for an architecture that is rigorous by design and simplifies proof of compliance.

SAM Implementation by the Current Protection Profile

Currently, the protection profile for QSCDs operated by QTSPs is defined in CEN EN 419 241-2 (Trustworthy Systems Supporting Server Signing - Part 2: Protection profile for QSCD for Server Signing). Specifically, the CEN EN 419-241-2 Protection Profile’s target of evaluation (TOE) is the Signature Activation Module (SAM). Here we find:

“4.4.2 TOE type

The TOE is a software component, which implements the Signature Activation Protocol (SAP). It is either deployed within the tamper protected part of the Cryptographic Module or alternatively in a dedicated tamper protected environment, that is connected to the Cryptographic Module via a trusted channel.

It uses the Signature Activation Data (SAD) from the signer to activate the corresponding signing key for use in a Cryptographic Module.

Together the TOE and Cryptographic Module are a QSCD.”

By CEN EN 419 241-2, to obtain a QSCD, the SAM and the Cryptographic Module (CM) must be certified against CEN EN 419 221-5 (Protection Profiles for TSP Cryptographic Modules - Part 5: Cryptographic Module for Trust Services).

The text of Section 4.4.2 is interpreted towards different possible architectures, depicted in Figure 1 and Figure 2 below, with the red dashed lines highlighting the difference. Here, Figure 2 is identical with Figure 1 from CEN EN 419 241-2.

Figure 1: CEN EN 419 241-2 SAM deployment: Inside the tamper protected part of the Cryptographic Module that is certified against CEN EN 419 221-5. (‘Composite Certification’). (Type 1)

Abbreviations:

CM – Cryptographic Module

DTBS/R – Data To Be Signed/Representation (the hash of the document computed by the SCA)

HSM – Hardware Security Module

QES – Qualified Electronic Signature

QSCD – Qualified Signature Creation Device

SAD – Signature Activation Data (signer authentication along with signing key, hash of the data to be signed)

SAM – Signature Activation Module

SAP – Signature Activation Protocol

SCA – Signature Creation Application

SCD – Signature Creation Data (signing key)

SIC – Signer Interaction Component

SSA – Server Signing Application

Figure 2: A common interpretation of CEN EN 419 241-2 for SAM deployment: in a (general-purpose) server, which along with the Cryptographic Module (certified against CEN EN 419 221-5) is placed into a tamper protected environment that must also be certified against CEN EN 419 221-5. (Type 2)

In the following, we refer to the setup of Figure 1 above as Type 1, and the setup of Figure 2 as Type 2.

With the Implementing Acts for the eIDAS 2 regulation still pending, the implementation options (as per CEN EN 419 241-2) for the SAM need to be evaluated now.

SAM In or SAM Out? A Comparison

Here is a different view on the Type 1 and Type 2 implementations of the SAM:

Figure 3: Top: Type 1 -- SAM inside the CM: SAM Host OS = hardened custom OS; native dual-control access control for SAM administration; queuing depth = one. Bottom: Type 2 -- SAM outside the CM, inside the common tamperproof environment: SAM Host OS = hardened general-purpose OS; single-control access control for SAM administration; queuing depth = 2. Both: Databases for (wrapped) key material storage; some Type 2 implementations include key material storage inside the SAM.

eIDAS 2 Compliance Footprint

Rigorous QSCD design and simplicity of compliance are particularly important in view of the eIDAS 2.0-postulated audit requirements for QTSPs.

Both Type 1 and Type 2 architectures are certifiable, but the Type 2 compliance footprint is larger:

The Type 1 implementation is a turn-key solution and is compliant by design, with the SAM Host OS being a hardened custom OS. The certification can rely on the CM being certified to meet (some of) the CEN EN 419 221-5 requirements for physical protection.

With Type 2, the customer relies on a vendor-provided hardened version of the general-purpose OS (RedHat), or something else such that the security functional requirements in FPT_PHP.* of CEN EN 419 241-2 are met (cf. Application Note 69 of CEN EN 419 241-2).

Technical Footprint

The Type 2 implementation suffers from a larger technical footprint: its OS footprint is larger, with RedHat being a multipurpose OS requiring additional hardening, and it includes multiple (albeit standard) interfaces such as HTTP, SSH, Health. Meanwhile with Type 1 the SAM is deployed in a single-purpose appliance (e.g., HSM) and the SAM interface is a single proprietary interface.

Consequently, Type 1 represents a smaller attack surface than Type 2, see also Figure 4 below.

Maintenance Footprint

Also, the maintenance footprint of Type 1 is smaller: by the nature of a single-purpose appliance, minimal configuration, maintenance, patching and updating is required, implying minimal need for privileged access. On the other hand, a general-purpose appliance requires more logging, monitoring, and OS patching and updating in accordance with the corporate policy. Consequently, frequent privileged access is required.

In the case of need for privileged access, the access controls for Type 1 are dual control and MFA by design (by nature of HSMs). As for Type 2, general-purpose computers are typically by default configured with single control and single factor authentication.

The smaller maintenance footprint for Type 1 along with tightly controlled access imply reduced vulnerability. Whereas, deploying the SAM inside the CM leads to a reduced risk (cf. Figure 4).

Figure 4: With the SAM (the asset) deployed inside the CM (Type 1, right), the asset to protect becomes smaller, the system vulnerability is reduced and hence the attack surface and the risk are smaller than for Type 2 (left).

Scaling

For Type 1, the process for scaling up is easy and straightforward: just add a QSCD to the environment. Initialization of additional devices happens via existing admin credentials and the import of the master key. For Type 2, the complexity of scaling up depends on whether new CMs are added to the existing tamper resistant environment, or whether a completely new SAM is added.

By design, adding cluster members a dual control process for the Type 1; with Type 2, this likely is a single-control process. Whereas, Type 1 is architected for secure clustering.

In a clustered deployment (cf. Figure 5), Type 1 queue management happens at the SSA only; the SAM is single-threaded and first-in-first out (FIFO). Meanwhile, with Type 2, there are queue managers at both the SSA and the SAM. This difference implies a better CM resource use with Type 1 as the entire CM pool is available for the complete signing service. With Type 2, each CM pool attached to a SAM is available only to consumers of the individual SAM service. Here, an inconsistency in numbers of CMs for each SAM will likely lead to an imbalance in performance.

Figure 5: Scaling and Queueing. Top: Type 1. Bottom: Type 2. (With Type 2, some implementations involve key storage with in the SAM, requiring synchronization.)

Figure 5 may suggest that adding multiple CMs to a given SAM is cost-saving as the number of SAMs is less. However, this is not the case: that the CM is the pricey part, and licensing costs are just the same: With Type 1, licensing is per QSCD (SAM +CM) while with Type 2, licensing is per SAM or per CM whichever number is higher (based on indicative supplier).

Carbon Footprint

Finally, Type 1 has a lower carbon footprint than Type 2: The energy consumption of a dedicated appliance is optimized for single purpose, and load balancing ensures optimal use of computing resources. Meanwhile, with Type 2 the energy consumption depends on the choice of the host system and whether the CMs are connected as PCI cards or network-attached appliances. The use of compute resources in this case depends on the chosen architecture.

Summary of Type 1 – Type 2 Comparison

A comparison between the SAM implementation options (inside CM or outside CM) is summarized in the table below.

Conclusion

Based on our findings across core areas from eIDAS 2 Compliance, Technical Footprint, Maintenance Footprint, Scalability, to Carbon Footprint we see a clear argument for the Type 1 architecture, which is placing the SAM inside the CM/HSM.

In the QSCDs architected and implemented by Cryptomathic, the CM is a Utimaco CP5 Cryptoserver HSM, and the SAM sits inside the Utimaco HSM.