Securosys SAM

This page describes how the SAM feature in Primus HSM works and how this satisfies the requirements of EN 419241-2. This enables TSP system architects to build trust services around Primus HSM as the QSCD.

A Qualified Signature Creation Device (QSCD), consisting of a Cryptographic Module (CM) and a Signature Activation Module (SAM), forms the core part of every eIDAS trust service architecture (as explained in the eIDAS Definitions). Securosys Primus HSM is Common Criteria certified as both a CM and a SAM.

The CM part is straightforward, because a CM is basically a normal, industry-standard HSM. The SAM part, however, requires additional explanation, since this concept is very eIDAS-specific. This page explains how Primus HSM becomes a SAM.

Securosys has extended Primus HSM to provide a special "SAM mode". The SAM mode changes the behaviour of the existing Smart Key Attributes (SKA) feature to become SAM-compliant. This page explains how SKA and the SAM mode work, and why this results in a compliant SAM.

info

A core concept of eIDAS is "signature activation". "Activating a signing key" means "unlocking" the key and permitting it to be used to perform a signing operation. This means that the HSM enforces fine-grained, per-key access control.

Generally, this page assumes that you are familiar with the eIDAS concepts and terminology.

Smart Key Attributes

Securosys Smart Key Attributes (SKA) provide fine-grained, per-key access control. SKA is versatile and can be used to build trust services, crypto currency wallets, and more.

SKA allows users to build powerful multi-authorization policies. Every SKA key has an SKA policy attached. This policy specifies who is authorized to approve the use of the SKA key (for example, to sign with the SKA key). Such an approver is specified in the form of a certificate, which certifies the approver's public key. The approver locally holds the corresponding approver private key. The SKA key can only be used if the approver signs an approval statement with their approver private key. 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).

Signature Activation Data

In SKA, the concept of the Signature Activation Data (SAD) is implemented as the signed approval token. The Signature Activation Protocol (SAP) is the passing of the signed approval token from the client to the HSM.

A plain SKA approval token contains:

• Operation type (sign, block, unblock, modify).
• Key name. This name is a unique label to identify the key in the HSM partition.
• Signed timestamp. Optional. See below.
• Data to be authorized. For signature operations, this is the data to be signed (DTBS).

A signer (acting as the SKA approver) authorizes the signing operation by signing the approval token with their approver key.

The signed approval token consists of:

• An approval token.
• A signature over the approval token.
• An X.509 certificate.

Primus HSM verifies that:

• The signature is valid. This proves that the approval token has not been tampered with (integrity).
• The signature is verifiable with the public key in the X.509 certificate. This proves that the signature was created by the holder of the private key that the certificate attests to (authenticity).
• The certificate satisfies the signer authentication checks (see below).

Compliance

Therefore, the signed approval token fulfills the requirements of an SAD: The signature cryptographically binds together signer authentication (certificate), the signing key name, and the data to be signed.

Limiting the SAD validity time window

Optionally, an SKA policy can contain a timelock (minimum, lower bound) and/or a timeout (maximum, upper bound). With a timeout, authorizing a signing operation works as follows:

1. The client asks the HSM to provide a signed timestamp. The signature is over the data to be authorized and the current time.
2. The signature is created by the HSM itself, using a local trusted time source. The signature is returned to the client.
3. The client incorporates the signed timestamp into the approval token and signs the approval token.
4. The client asks the HSM to perform the actual signing operation.
5. The HSM verifies that the signed timestamp in the signed approval token satisfies the timelock and timeout (listed in the SKA policy) in relation to the current time. It also verifies that the data to be authorized in the signed timestamp and in the signed approval token match.

This ensures that after a timeout the approval token is no longer valid. This mitigates replay attacks.

Compliance

When using SKA as a SAM, it is highly recommended to define a short timeout in the SKA policy of every SKA key that you create.

Signer Authentication

To activate the signing key, the signer must be authenticated. Primus HSM delegates authentication to an external party. This external party acts as a Certificate Authority (CA). Certificates issued by this CA are the identity assertions that identify a human signer.

The (Partition) Security Officer (PSO/SO) of Primus HSM enables the "SAM mode" on the HSM partition and explicitly allow-lists one or more trusted CAs. The steps for this are described in the installation guide.

Compliance

The PSO and SO are privileged operator roles. Their access can be protected with 2FA (PIN + card) and split using 2-of-n.

Primus HSM then enforces that:

• An SKA policy must only contain valid certificates issued by one of the trusted CAs.
  • If this requirement is fulfilled and the SKA policy is valid, Primus HSM automatically sets the sam-approved = true key attribute (it cannot be set manually). This attribute is included in attestations, allowing auditors to verify it.
• An SKA signed approval token (SAD) must contain a certificate issued by one of the trusted CAs.
• The X.509 subject of the certificate in the signed approval token must match the X.509 subject of a certificate in the SKA policy.
  • This enforces that the identity of the signing key owner is the same as the identity of the signature operation requester.
  • Note that the certificate listed in the SKA policy does not need to match the certificate provided in the signed approval token. It can be a new certificate, either for the same public key or for a completely different public key.

From the view of a signer, the process works as follows:

1. The signer uses the SIC to (locally) generate an SKA approver key pair.
2. The signer sends a Certificate Signing Request (CSR) to the CA.
3. The CA authenticates the signer and issues a certificate.
4. The signer attaches the certificate to the signed approval token.

Using this process and using X.509 certificates as the technological basis, Primus HSM delegates signer authentication.

Compliance

By using indirect authentication, Primus HSM fulfills the signer authentication requirement.

warning

It is the responsibility of the TSP that is operating the Primus HSM to ensure that the delegated party (that is, the PKI and the CA) fulfills the requirements of EN 419241-1 SRA_SAP1.1. In particular, note that EN 419241-2 OE.DELEGATED_AUTHENTICATION states:

[...] the TSP shall ensure that the secret key material used to authenticate the delegated party to the TOE [here: Primus HSM] shall reside in a certified cryptographic module consistent with the requirement as defined in EN 419241-1 SRG_KM.1.1.

This means that the CA should use an HSM to store its signing key. For example, the CA can use a separate partition on the Primus HSM. For simplicity, this is not shown in the diagram.

Signature Activation Module

Taken together, this means that Primus HSM fulfills the requirements of a SAM, because Primus HSM only activates the signing key if the signing request satisfies the SKA policy that is attached to the key. As described in the previous sections, Primus HSM verifies that:

• The signed approval token (the SAD) is valid.
• The signer has been authenticated.

This makes Primus HSM (with SKA, in SAM mode) a compliant SAM product, usable to achieve SCAL2.

Normal SKA versus SAM SKA

To summarise: SAM mode introduces the following changes compared to normal SKA:

• Certificates only:
  • In normal SKA, approvers can be specified using certificates or using raw public keys.
  • In SAM mode, approvers must be specified using certificates only.
• Valid certificate chain:
  • In normal SKA, there are no CA certificates. Leaf certificates in SKA policies only serve as a holder for the public key.
  • In SAM mode:
    • CA certificates must be pre-loaded to the partition configuration by the (Partition) Security Officer.
    • Certificates in SKA policies and signed approvals must have a valid chain leading to one of the installed CA certificates.
    • If there is a valid chain, 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.
• Subject must match:
  • In normal SKA, the certificate in a signed approval must match a certificate in the SKA policy.
  • In SAM mode, the certificate in a signed approval may be a completely new certificate (and even a new approver key pair). Instead, the Subject in the certificate in the signed approval must match the Subject in a certificate in the SKA policy.

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

Comparison

The following table summarizes how the eIDAS concepts map to the Securosys implementation.

eIDAS concept	Securosys implementation
SAM	SKA subsystem
SAD	Signed approval token
SAP	Passing of the signed approval token from the client to the HSM
Signer authentication	Delegated to trusted CA