How It Works

This section describes the architecture of using a Securosys Primus HSM for eIDAS, how the workflows work, and what the acronyms mean. This background will help you better understand the installation guide and usage tutorials, which focus on step-by-step instructions. The information in this section will also help you make more informed decisions about the security requirements that come with operating an HSM for eIDAS.

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 on 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 is ensured using technical and operational controls.

Sole Control

eIDAS requires that signing keys remain under the sole control of the human users that they belong to. There are two assurance levels:

1. Sole Control Assurance Level 1 (SCAL1):
   • The signing key is under the sole control of the signer with low confidence.
   • The Server Signing Application (SSA) authenticates the signer in software.
2. Sole Control Assurance Level 2 (SCAL2):
   • The signing key is under the sole control of the signer with high confidence.
   • The Signature Activation Module (SAM) authenticates the signer in a tamper-protected environment.

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 two core parts of the security architecture are the following (further described below):

1. The Cryptographic Module (CM).
2. The Signature Activation Module (SAM).

Together, they are part of a Qualified Signature Creation Device (QSCD). A QSCD is necessary to create a QES. The QTSP will build services surrounding the QSCD, such as web interfaces or mobile apps that human signers can use to interact with the Trust Service. However, at the core will always be a CM and a SAM, as the components with the highest security.

The 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.

This use case is exactly what traditional HSMs are designed for. HSMs are not only secure, they are also high performance and have enough storage capacity for thousands of keys.

However, traditional HSMs have one limitation: lack of fine-grained per-key access control. While HSMs are strong at preventing physical access to the key storage, traditionally the logical access control is limited to a username/password combination. This means that an onboarded application can access the entire key store and use all of the keys! There is no fine-grained access control on a key-level; this has traditionally been delegated to the application.

The Signature Activation Module (SAM)

Having per-key access control is critical for ensuring sole control of the signer. This is why the technical standards for eIDAS define the SAM. The purpose of the SAM is to authenticate the signer in a remote signing architecture, to ensure that the human has sole control of the key. Therefore, even if the backend application (operated by the QTSP) has access to the entire key store, the SAM controls access to using the signing keys. Without the consent of the signer, signatures cannot be created.

Because the SAM is such an important component, it must also be physically tamper-protected and certified (like the CM).

Choosing a SAM

To become a QTSP, you need both a CM and a SAM. You can either develop them in-house, requiring you to maintain them and get them certified. Alternatively, you can purchase them, either separately from different vendors or from the same supplier.

Purchasing both the CM and the SAM from a single vendor (like Securosys) has the following benefits:

• Price: Cheaper than developing it yourself.
• Shorter time-to-market: The products are already certified.
• Scalability: Scales to hundreds of thousands of signatures per second. Simply add more HSMs to the cluster. The cluster automatically synchronizes all CM and SAM data.
• Single product: No need to deploy multiple products. A single tamper-protected box.
• Compatibility and single API: No need to integrate the CM and SAM from different vendors.
• Support: Ongoing support and updates.

Using Securosys Smart Key Attributes as a SAM

Securosys has long recognized the need for fine-grained, per-key access control as a modern HSM feature. Therefore, Securosys has developed Smart Key Attributes (SKA). SKAs are versatile, and can be used to build eIDAS Trust Services, crypto-currency wallets, and more.

SKA allows users to build powerful multi-authorization policies. These policies specify who is authorized to approve the use the SKA key (for example, to sign with the SKA key). Such an approver is specified in the form of a public key or a certificate. The SKA key can only be used if the approver signs an approval statement. The Primus HSM verifies the approval, and only if it is valid does the HSM allow the operation with the SKA key.

For personal QES, the SKA policy should specify a single approver (1-of-1). For organizational seals, the policy can specify groups of users and quorums (m-of-n). This can be used to build an SKA policy that matches the signatory power from the company register (in German: Zeichnungsberechtigung im Handelsregister). For example, some persons may have the right to sign on behalf of the company on their own (1-of-n), while other persons may sign in pairs (2-of-n).

Identifying Signers

Authentication is the process of verifying an identity. Authorization is the process of defining access rights to a resource. Identification is the process of establishing an identity in the first place.

In an architecture using Securosys SKA as the SAM, the SKA module in the Primus HSM authenticates users and checks whether they are authorized to use a given key. Identification is delegated to an existing Certificate Authority (CA). This can be a public CA or an organization-internal CA. Every user needs to be provisioned with a personal public-private key pair. This key pair will later act as the approver key pair. The job of the CA is to issue certificates to every user, after establishing the identity of the requesting user. This certificate is then attached to the SKA key, thus defining the approver.

The Primus HSM is provisioned with the CA certificate. This is a privileged operation, performed by the HSM administrator (the Security Officer (SO) or the Partition Security Officer (PSO)).

This allows the HSM to verify that an approver key belongs to a given identity, by following the certificate chain of the approver certificate.

SKA in SAM Mode

SKA is a general feature that goes beyond just eIDAS. For example, the fine-grained access control provided by SKA can be used to secure crypto currency wallets. However, to satisfy the extensive requirements of eIDAS, Primus HSM has a dedicated SAM mode that restricts the general SKA feature to comply with eIDAS.

SKA in SAM mode differs from normal SKA in the following regards:

• Public keys cannot be used in SKA policies.
  • In normal SKA, approvers can be specified using certificates or using raw public keys.
  • In SAM mode, approvers must be specified using certificates only.
• CA certificates must be pre-loaded to the partition configuration by the (Partition) Security Officer.
• Certificates in SKA policies must have a valid chain leading to one of the installed CA certificates.
  • Other than having a valid chain, the HSM does not look at the certificate. In particular, the HSM does not consider the subject name fields.
• If these requirements are fulfilled and the SKA policy is valid, the HSM automatically sets the sam-approved key attribute. It cannot be set manually. This attribute is included in attestations, allowing auditors to verify it.

SAM mode is enabled on a per-partition basis. This allows parallel usage of both SAM and non-SAM partitions on the same HSM.

Architecture with a Primus HSM

Overall, the architecture diagram looks as follows:

The HSM setup flow:

1. The HSM operator enables SAM mode (see below) on the partition.
2. The HSM operator loads the CA certificate onto the HSM.

The registration flow:

1. Signer downloads the Authorization App, and is provisioned with a public-private approver key pair.
2. The CA identifies the human user.
3. The CA issues an approver certificate, binding the user's name to their approver key pair.
4. The HSM generates a signing key for the user.
5. The approver certificate is attached to the SKA policy of the signing key.
   1. For personal signatures, the policy is 1-of-1. For organization seals, the policy is m-of-n.
   2. The HSM verifies that the certificate is signed by the CA. This links the SKA policy to an identity.

The usage flow:

1. The signer requests a signature to be made. This happens via some web application or mobile app (the Signer Interaction Component).
2. The Securosys Transaction Security Broker (TSB) recognizes that the signing key is protected by an SKA policy. The TSB sends a push notification to the Authorization App, asking it to approve or deny the operation.
3. If approved, the Authorization App signs the approval task, and returns the approval signature to the TSB.
4. The TSB collects all necessary approval signatures (especially in the m-of-n case), and forwards the request to the HSM.
5. The SKA module in the HSM verifies that the SKA policy is satisfied, and enough approvals have been given.
6. The CM executes the signing operation.

info

These flows are written with the Securosys Transaction Security Broker (TSB) in mind. The TSB is the easiest way to use SKA. QTSPs are free to write their own custom application, and modify the flows accordingly.

Operating a QTSP with Primus HSM and SKA

Even with the strong security of a Primus HSM, operating a QTSP is non-trivial. In particular, a QTSP needs to have processes for managing the HSM. This includes managing the (Partition) Security Officer (SO/PSO) roles, which administer the HSM. Backup and recovery procedures need to be in place. The HSM needs to be operated in an environment that is CC compliant. Finally, an external CA is needed for identifying users.

Nevertheless, the benefit of remote signing with HSMs is that these tasks are done by a professional QTSP, whereas local signing with USB security tokens or smart cards puts a lot of this burden onto the user. Local signing also increases the support burden on the service provider.

Best Practices and Things to Keep in Mind

• Individual SKA keys can never be exported from the HSM (not even wrapped). However, they are included in backups.
• Backups are critical. Take either device backups (as SO) or partition backups (as PSO), and store them offline in a secure location. Additionally, a cluster of geo-redundant HSMs can function as a form of online backup.

Supported APIs

Smart Key Attributes can be used with the following APIs that the Primus HSM exposes. These APIs allow QTSPs to integrate their existing software with the Primus HSM.

• REST
• Java JCE/JCA
• PKCS#11 (on request)

References

• SKA documentation
• SUDC talk about Qualified Electronic Signatures
• Securosys eIDAS White Paper
• Primus HSM Common Criteria Certification
• Primus HSM User Guide
• eIDAS Regulation (2014/910)
• eIDAS 2.0 Regulation (2024/1183)