For more information and all parts of the series visit Introduction to eIDAS package for SignServer.
In the eIDAS SIgnServer: Advanced and qualified sealing, we’ve been discussing the digital sealing, its applicability, and how it can be used with the SignServer technology.
Digital signature is an electronic version of a hand-written signature. Representation of the data that is signed is bound to the identity of the signatory as a physical person.
Digital signature does not:
- establish the exact time on when the document was signed;
- necessarily provide the commitment of a potential legal entity behind the signatory;
- confirm delivery of the signed message.
Advanced vs. Qualified signature
‘signatory’ means a natural person who creates an electronic signature;
Advanced Electronic Signature
Advanced electronic signature means an electronic signature, which meets the following requirements:
- it is uniquely linked to the signatory;
- it is capable of identifying the signatory;
- it is created using electronic signature creation data that the signatory can, with a high level of confidence, use under his sole control; and
- it is linked to the data signed therewith in such a way that any subsequent change in the data is detectable.
Qualified Electronic Seal
Qualified electronic signature means an advanced electronic signature that is created by a qualified electronic signature creation device, and which is based on a qualified certificate for electronic signatures;
Qualified Electronic Signature Creation Device (QSCD)
Qualified electronic signature creation device means configured software or hardware used to create an electronic signature. It is hardware security module that meets the requirements of the eIDAS regulation and is certified according Common Criteria Protection Profile EN 419 221-5 “Cryptographic Module for Trust Services”.
Such QSCD can be used in conjunction with the qualified certificate to produce qualified signature. You can achieve qualified signature by using the QSCD and issuing a qualified certificate for signing from a qualified trust service provider.
However, when the qualified signature is done on behalf of person, which is a typical remote signing service, it must be operated by a qualified trust service provider. Remote signing is described in more detail below.
For specific eIDAS requirements for QSCD, see the requirements listed in the eIDAS Annex II.
Legal implications of qualified signature
As stated in eIDAS, a qualified electronic signature shall have the equivalent legal effect of a handwritten signature.
A qualified electronic signature based on a qualified certificate issued in one Member State shall be recognized as a qualified electronic signature in all other Member States.
Qualified signature properties
Signing with the same legal value as with a handwritten signature
“Signature” by a legal person
Granting that the content of the signed data is meaningful, fair or true
Data origin authentication
Non-repudiation of signing
Secure identification of the signatory
Creating huge amount of signatures and/or signatures on huge data
Signing with a signature that is understood and verifiable worldwide
Signing "in quality of"
Management of delegation
The European Union Agency for Cybersecurity (ENISA) has released Security guidelines on the appropriate use of qualified electronic signatures. The guidelines states that the digital signature are most often seen coming in addition of other identification and/or trust services as part of a broader solution.
The following properties are key for the use cases:
- to establish the originator of a signed document;
- to provide integrity of a signed document;
- to provide non-repudiation of having signed document.
Signing with the SignServer
eIDAS compliant signing with the SignServer implementation differs based on the required assurance level. In this article we’ll focus on the advanced assurance level. For a qualified remote signing, see the eIDAS SignServer: Qualified remote signing.
Advanced remote signing using the SignServer follows a standard pattern of connecting the HSM / QSCD as a CryptoToken, generating key pair, issuing certificate, and configuring required Signer type.
Important part of the configuration of the Signer is the Alias Selector. This is the main difference between producing seals and signatures. Alias Selector will select and activate private key based on a proper authentication of the user. This means that the user must be identified before the signature can be produced.
For more information on Alias Selectors, see the official SignServer documentation.
The following diagrams shows a typical process of signing with the SignServer:
Key management options
You have 2 options how to manage private keys:
Long-term private key – private key is generated when the user is registered and a certificate with the long-term validity period is issued, for example 2 years. Associated private key must be stored inside the HSM for the validity period and regenerated during the renewal of the certificate. With this approach you need to follow IAM procedures for provisioning and decommissioning of the users and their private keys.
Short-lived private key – private key and certificate are created on request. Based on the authentication, new key pair is generated, CSR signed, certificate issued with a short validity, that is sufficient just for the signing operation required, for example 10 minutes. After the signing operation, the private key is immediately destroyed, so there is no risk of compromise. In this approach there is no need to implement IAM procedures for provisioning and decommissioning certificates and private keys.
Sample properties of the Signer
The following is a sample properties of the Signer implementing the username-based alias selector:
How it works:
- Based on the authorization type, user is identified and its username is extracted (AUTHTYPE)
- The username is then passed as the alias to the CryptoToken implementation (ALIASSELECTOR + ALIAS_PREFIX)
- (in case of short-lived private key) The key pair is generated in the CryptoToken, CSR is signed by the private key, and certificate is issued by the certification authority. The certificate is imported back to the CryptoToken. (the process is automated)
- CryptoToken will use the private key based on the alias and perform the signing operation
- (in case of short-lived private key) The private key is destroyed
org.signserver.server.aliasselectors.AuthorizedUsernameAliasSelectorimplementation. it will extract the username from the authorized request to sign.
If configured, it will prefix the username with the specified value.
The result of the ALIAS_PREFIX + ALIASSELECTOR is alias that is used by the CryptoToken to select the private key and perform the signing operation.