eIDAS Definitions
This page describes the abstract requirements that the various eIDAS-related standards define. It outlines the main components (CM, SAM) and how the standards require them to work. Together, they achieve a secure remote signing architecture where signers can produce Qualified Signatures.
In other words, this page is a short summary of the eIDAS standards. The language and definitions introduced here will then be used in the subsequent Securosys SAM article. It will explain how the SAM implementation in Primus HSM works and how the concrete Securosys concepts map to the abstract eIDAS concepts.
Types of Trust Services
As described in the overview, a Qualified Trust Service Provider (QTSP) builds and operates Trust Services. Such signing services include:
- Qualified Electronic Signature (QES)
- Qualified Electronic Seal (QSeal, QES)
- Qualified Electronic Timestamp
- Qualified Website Authentication Certificate (QWAC)
The focus in this guide is on personal signatures and company seals (QES). In these use cases, the individual or the employees are the signers. Since the signatures are legally binding, only the legitimate signers must be able to produce valid signatures. This "sole control" is ensured using technical and operational controls (more on that below).
Architecture
As introduced in the overview, eIDAS envisions both local signing deployments (using USB tokens and smart cards) and remote signing deployments (using HSMs). This guide focuses on remote signing.
The core parts of a remote signing architecture are:
-
Signer Interaction Component (SIC)
The SIC is the component that the human signer uses to interact with the trust service. This can be a website or a mobile app. It runs locally in the signer's environment, under their physical control. The SIC is developed and published by the QTSP.
-
Server Signing Application (SSA)
The SSA is the backend application that connects to the QSCD, requesting keys to be created and signatures to be made. The SSA runs in the TSP environment (usually, in a data center). However, it is not tamper-protected and has lower security requirements than the QSCD. From the view of Primus HSM, the SSA is a normal business application that accesses an HSM Partition through one of the standard APIs (REST, JCE, PKCS#11). The SSA is developed and deployed by the QTSP.
-
Qualified Signature Creation Device (QSCD)
The QSCD is the secure, tamper-protected device that generates and stores the signing keys, and uses them to create qualified signatures. In a remote signing environment, a QSCD consists of a Cryptographic Module (CM) and a Signature Activation Module (SAM). (In a local signing environment, a CM is enough to form a QSCD.) Primus HSM functions as the QSCD.
Together, this architecture allows signers to create Qualified Signatures that are legally recognized.
Qualified Signature Creation Device (QSCD)
In a remote signing architecture, Primus HSM is the QSCD. It consists of a CM and a SAM.
Cryptographic Module (CM)
The CM contains the private signing keys. It generates the keys using a true random number generator, stores them, and performs the signing operations. It must be tamper-protected, to protect against extracting or copying of the private keys. To validate that these protections are properly implemented, CMs are certified according to EN 419221-5.
Secure key generation, storage, and usage is exactly what traditional HSMs are designed for. However, traditional HSMs have one limitation: they lack fine-grained per-key access control. While HSMs are strong at preventing physical access to the key storage, traditionally their logical access control is limited to a username/password combination. This means that a connected backend application can access the entire key store and use all of the keys!
This is problematic for the "sole control" of a signer over their remote signing key: if the backend application is compromised, it could maliciously create signatures on behalf of a signer.
Signature Activation Module (SAM)
This is where the SAM comes in. Its purpose is to authorize the use of the signing key in a remote signing architecture, to ensure that the human has sole control over their keys.
The SAM controls access to using the signing keys, thus ensuring that the backend application (operated by the QTSP) can only use a signing key for signing documents explicitly authorized by the signer. In other words, the SAM ensures that the backend application cannot sign arbitrary data without a signer's consent.
Because the SAM is such an important component, it must also be physically tamper-protected and certified (like the CM). SAMs are certified according to EN 419241-2.
The QSCD is the core of a trust service with a remote signing architecture. It authorizes and creates all signatures.
Sole Control
eIDAS requires that signing keys remain under the sole control of the human users that they belong to. Therefore, EN 419241-1 defines two assurance levels (Section 5.4 "Sole control assurance levels"):
- Sole Control Assurance Level 1 (SCAL1):
- The signing key is used under the sole control of the signer with low confidence.
- Authorizing the signer's use of the key is done by the Server Signing Application (SSA).
- Sole Control Assurance Level 2 (SCAL2):
- The signing key is used under the sole control of the signer with high confidence.
- Authorizing the signer's use of the key is done by the Signature Activation Module (SAM) in a tamper-protected environment, using the Signature Activation Data (SAD).
In SCAL1, the signer authenticates against the SSA. The SSA then "activates" the signing key in the QSCD, allowing it to be used for signature operations. Note that the signer only needs to authenticate. The signer does not need to explicitly approve every single document (every single signature operation). SCAL1 does not need a SAM.
In SCAL2 on the other hand, the SAM "activates" the signing key after verifying the SAD. Among other things, the SAD binds the signer authentication together with the document to be signed (DTBS). This means that the signer must explicitly approve every signature operation (possibly as a batch). It also means that the SSA on its own cannot activate a signing key, since it cannot create a valid SAD.
The SIC creates the SAD (or at least is required for its creation). The SIC runs locally inside the Signer Environment (that is, outside of the TSP environment), and is thus under the "sole control" of the signer. Therefore, the SIC enforces a link between the signer and the signature operation.
SCAL2 is required to create Qualified Electronic Signatures.
SCAL2 ensures that signers have sole control over their signing key, even though the QSCD is in a remote environment that signers do not physically control (unlike in local signing). In particular, this means that TSP staff must not be able to abuse their privileged operator access to the TSP environment to maliciously create signatures on behalf of signers.
Signature Activation
Signature activation is the process of "activating" a signing key, and allowing it to be used to sign a specific piece of data. This is performed by the Signature Activation Module (SAM). The SAM receives the SAD and checks that it is valid (see below). Only if these checks pass, does the SAM activate the signing key, thus allowing the CM to create the signature.
Signature Activation Data (SAD)
The Signature Activation Data (SAD) is what the SAM receives and verifies. A valid SAD must (cryptographically) bind together three elements:
- Signer authentication
- Signing key to be used
- Data to be signed (DTBS)
In other words, the SAD binds together all important metadata representing a signature operation.
Signature Activation Protocol (SAP)
The Signature Activation Protocol (SAP) is what produces the SAD. Usually, the SAP is a simple interaction of two protocol participants (SIC and SAM):
- SIC creates SAD.
- SIC sends SAD to SAM.
- SAM receives SAD.
The SIC must always participate in the SAP, because the SIC provides the link to the signer, ensuring sole control. The SAP should be designed so that without the SIC it is impossible to create a valid SAD.
This is important because the SAM provides only one end of the SAP. The other end (the SIC) and any other participants (such as a delegated party, see below) are part of the overall system architecture. Therefore, the system architecture must be designed so that this requirement of the SAP is satisfied. It should not be possible for an attacker to submit a malicious SAD that is accepted by the SAM.
Signature activation — executed inside a tamper-proof, certified SAM — ensures sole control of signers over their keys. Nobody else can activate the signing key.
Signer Authentication
Recall that Qualified Electronic Signatures are legally binding. Therefore, the system needs to establish the signer identity and link every signing key (and thus every signature created by this key) to a human signer.
This signer authentication can happen in one of three ways (as defined by EN 419241-11):
- Directly: The SAM authenticates the signer.
- Indirectly: An external party authenticates the signer, and issues an assertion of the signer's identity. The SAM verifies the assertion.
- A combination of the above.
Observe that signer authentication is a weak link in the security architecture: If an attacker can impersonate another signer towards the authentication service (for example, by stealing their authentication credentials), the attacker can access the rest of the system to create a malicious signature.
Therefore, SRA_SAP.1.1 in section 6.4.2 of EN 419241-1 defines strict requirements on the identification and authentication of signers. Additionally for the "indirect" case, section 5.7.4.3 of EN 419241-1 clarifies that: "The TSP SHALL ensure that the authentication process delegated to the external party meets the requirements specified in SRA_SAP.1.1."
Primus HSM uses indirect authentication, by delegating to a trusted, QTSP-configurable certificate authority.
Signer authentication establishes the link to a signer's legal identity.
Summary
This section introduced the basic concepts of an eIDAS remote signing architecture in general and the SAM in particular. You should now be familiar with the following terms: SAM, SAD, SAP, SSA, SIC, SCAL2. You can look up the terms in the glossary.
The next section gives an overview of the EN standards that define the concepts explained in this article. Afterwards, the Securosys SAM section explains how the Securosys SAM implements these abstract concepts (like SAD and SAP).