For more information and all parts of the series visit Introduction to eIDAS package for SignServer.
Digital seal is an electronic version of a company seal. Representation of the data to be signed is bound to the identity of the signatory as a legal person, typically a company.
From the technology perspective, it works the same as an digital signature. Therefore it is considered as a version of a digital signature for legal entities. However, there is a difference between advanced and qualified implementation of digital sealing.
You should be aware that digital seals do not:
- establish the exact time of the document being sealed;
- ensure the meaningfulness of the sealed content;
- confirm the receipt of the sealed message.
Advanced vs. Qualified seal
‘creator of a seal’ means a legal person who creates an electronic seal;
Qualified Electronic Seal Creation Device (QSCD)
Advanced Electronic Seal
Advanced electronic seal means an electronic seal, which meets the following requirements:
- it is uniquely linked to the creator of the seal;
- it is capable of identifying the creator of the seal;
- it is created using electronic seal creation data that the creator of the seal can, with a high level of confidence under its control, use for electronic seal creation; and
- it is linked to the data to which it relates in such a way that any subsequent change in the data is detectable.
Qualified Electronic Seal
Qualified electronic seal means an advanced electronic seal, which is created by a qualified electronic seal creation device, therefore based on a qualified certificate for electronic seal;
Qualified electronic seal creation device (QSCD) a hardware component used to create an electronic seal. It’s a hardware security module that meets the requirements of the eIDAS regulation and is certified according the Common Criteria Protection Profile EN 419 221-5 “Cryptographic Module for Trust Services”.
Such a QSCD can be used in a company to produce qualified seals. But keep in mind that there is a difference between operating sealing solution in-house and outsourcing it from a third party. You can achieve qualified sealing in-house by implementing the QSCD and obtaining a qualified certificate for sealing from a qualified trust service provider.
However, when the qualified sealing is done on behalf of the company, which is a common scenario, it must be also operated by a qualified trust service provider.
For specific QSCD eIDAS requirements , see the requirements listed in the eIDAS Annex II.
Legal implications of qualified seal
As stated in eIDAS, a qualified electronic seal provides the presumption of integrity of the data and of correctness of the origin of that data to which the qualified electronic seal is linked.
A qualified electronic seal based on a qualified certificate issued in one Member State shall be recognised as a qualified electronic seal in all other Member States.
Where are digital seals used
The European Union Agency for Cybersecurity (ENISA) has released Security guidelines on the appropriate use of qualified electronic seals. The guidelines states that the digital seals are most often seen coming in addition to other identification and/or trust services as part of a broader solution.
The following properties are key for the use cases:
- to establish the origin of a sealed document (and support the non-repudiation of having sealed document);
- to provide integrity of a sealed document.
Typical applications and use cases
Financial institutions and services
Telecommunication and operator services
Enterprise and Corporate
Typical use cases are:
- Mass communication e.g. notifications, bank statements and policy updates;
- Patients’ hospital records;
- Legal documents;
- Authentication when gaining the access to financial services in accordance with the EU’s regulation regarding PSD2 payment services;
- Official company documents e.g. contracts and commercial offers and order confirmations;
- Electronic invoices, bills, order and delivery confirmations;
- Electronic correspondence, smart scanning with document integrity confirmation.
Sealing with the SignServer
SignServer supports digital sealing of any data. Based on the different modules and open source interfaces, it is possible to create custom data format to seal. To support the eIDAS use cases SignServer works with the PAdES, XAdES, CAdES, and ASiC signature formats. See the eIDAS SignServer: AdES signature formats for more information.
When you would like to start the use of digital sealing, you need to follow these general steps:
- Create a CryptoToken. CryptoToken is a representation of a hardware security module and provides access to the private key that will be used for sealing. When you would like to create qualified seals, it must be a QSCD as discussed above.
- Generate a key pair for CryptoToken. Key pair is generated inside the secure boundary of an HSM and the private key will never exist outside of it. This is for security and compliance reasons. However, one CryptoToken can host multiple key pairs.
- Issue certificate for digital sealing and register it in the CryptoToken. The certificate represents identity of the legal person. The certificate issuing procedure may differ for various providers and use cases. Certificate needs to be imported to CryptoToken to start sealing of the data.
- Create a Signer and assign the CryptoToken. Signer connects together signature algorithm, keys and certificates, formats, authorization, and other attributes in order to perform signing operation. In this case digital seal. Signer defines the behavior that is applied in case of the sealing request.
When the CryptoToken and Signer are created and appropriately configured, you are ready to start sealing your documents or data!
As an example, let’s take a look on how to create a CryptoToken as a representation of the TRIDENT QSCD.
TRIDENT HSM has successfully achieved Common Criteria EAL 4+ certification meeting the requirements of the Protection Profile for Cryptographic Module for Trust Services (EN 419221-5) and the Protection Profile for QSCD. Based on its Common Criteria certification the TRIDENT HSM became a Qualified Signature (and Seal) Creation Device (QSCD) under eIDAS regulation.
Working with the SignServer, we need to create a CryptoToken to start using the TRIDENT HSM as QSCD. Following is a typical configuration of TridentQSCDCryptoToken:
The stated implementation class for the TridentQSCDCryptoToken is
This means that it should use the PKCS#11 interface for the communication with the Trident HSM and cryptographic operations.
In connection with the PKCS#11, you can configure properties of the CryptoToken which defines the access to the cryptographic keys (SLOT, LIBRARY, PIN), or assign attributes to objects and algorithms used (ATTRIBUTES).
For more information about the configuration of CryptoToken, see the SignServer documentation.