Advanced Electronic Signature and Mobile ID

What are Advanced Electronic Signatures?

An advanced electronic signature (AdES) is an electronic signature that meets the requirements defined by the EU Regulation No 910/2014 on electronic identification and trust services for electronic transactions. This regulation is under a standard framework known as eIDAS-regulation and the most important standards for Mobile ID services are CAdES and XAdES.

For an electronic signature to be considered as advanced, it must meet several requirements:

1. The user that has signed a document (signatory) is uniquely identified and linked to the signature. This is done with signatory’s certificate.
2. The signatory has sole control of the signature creation data i.e. a private key is used to create the electronic signature and the private key is protected with a signatory’s PIN.
3. The signature can identify if its accompanying data has been tampered with after the message was signed. This property is provided by CMS standard and asymmetric cryptography.
4. If the signed data has been changed, the signature verification fails. This property is provided by CMS standard and asymmetric cryptography.

Advanced electronic signatures are based on one of the Baseline Profiles that have been developed by the European Telecommunications Standards Institute (ETSI). These are:

• XAdES, XML Advanced Electronic Signatures is an extensions to W3C XML-DSig. XML-DSig uses Cryptographic Message Syntax (CMS) for signature
• CAdES, CMS Advanced Electronic Signatures is also an extensions to signed data defined in CMS.
• ASiC Baseline Profile. ASiC (Associated Signature Containers) specifies the use of container structures to bind together one or more signed objects with either advanced electronic signatures or time-stamp tokens into one single container (a zip file).

Additionally eIDAS regulation defines digest formats and special signature application standards like PAdES for pdf-document signing.

How to create Advanced Electronic Signatures with Standard Conformance?

Standard conformance requirements have been defined in the document like Electronic Signatures and Infrastructures (ESI); CAdES Baseline Profile (ETSI TS 103 173).

B-Level

Mobile signatures have B-Level (basic level) conformance fulfilling profiles:

• CAdES-BES when the signature-policy-id attribute is not present and
• CAdES-EPES when the signature-policy-id attribute is present.

This is the base profile Kiuru MSSP uses by default. Therefore we can claim that Kiuru MSSP default configuration is conformant to CAdES B-level.

T-Level

T-Level can be achieved in two ways: Application Provider uses external Trusted Time Provider or MSSP (as a Trust Service Provider) generates a time-stamp token. The time token proves that the signature itself actually existed at a certain date and time. This time-stamp is included into the signed data.

MSSP acting as a Trusted Service Provider can be done by connecting Kiuru MSSP with a trustworthy time source aka Time Stamping Authority. In this case Kiuru MSSP can claim T-Level (Trusted time for signature existence) conformance.

Other

Additionally CAdES Baseline Profile defines two more advanced profiles, which are LT-Level (Long Term level) and LTA-Level (Long Term with Archive time-stamps) conformance. Currently these are out of Kiuru MSSP product’s scope.

How to create Advanced Electronic Signatures with Mobile ID?

Advanced electronic signatures basic profiles are CMS signatures with well-specified attributes. The only attribute which may need some extra work for the B-level is the signatory identifier (certificate). Typical Application Provider XAdES software implementation requires a complete certificate chain beforehand and therefore the certificate chain should be available.

This means that before you can request a CAdES or XAdES signature, you need to either authenticate the user with user’s signing key or request user’s signing certificate by other means. Anyhow, this is not a problem for the most of use cases.

For the T-level implementation, the trustworthy time provider is the key challenge. Typical solution is that the MSSP integrates a common timestamp provider for all application providers.

So the advanced electronic signature is requested by preparing signature data and by requesting a standard mobile signature for the data to be signed (DTBS). The MSSP sends the DTBS to the WPKI applet and you can sign the request similarly as a normal authentication request. For your convenience we have added an example XAdES implementation to the Laverca MSSAPI library (GITHUB).

Written and Edited by: Eemeli Miettinen & Jarmo Miettinen