Remote (digital) signatures and eIDAS regulation

We thought we solved the problem, but it seems we just have created a new one.

Alice signs a document with her private key and Bob can verify Alice’s signature using her public key.

This post addresses the concerns related with remote (digital) signature services in the context of the eIDAS regulation. I start by introducing the concept of digital signatures and their requirements within the context of eIDAS. Then the high-level overview of the concept of remote signature service is defined, as well as its main implementation flavours. In the end I explain why I consider that the remote signature services (as described here) should not be used to provide signatures that aim at replacing handwritten ones.

Digital signatures

Encrypted hash

Digital signature is a concept that derives from cryptography. As a handwritten signature, its (main) goal is to prove the authenticity of a certain document, transaction or procedure. Digital signatures bind the identity of a given entity to a piece of data.

A digital signature provides non-repudiation. This typically means that when a signature is produced, the signatory cannot deny knowing the content of the document, or having performed such transaction. Basically, a digital signature ensures that:

• the signatory has knowledge of what he/she is signing
• uniquely authenticates the signatory

The term “encrypted hash” to refer to digital signatures became very popular, because in way, it represents an easy way to explain the mathematical operations underlying a digital signature. In order to perform a digital signature, the signatory needs a public/private key pair. The signature is then created by:

1. First (cryptographically) hashing the document, transaction or procedure;
2. Then “encrypting” the hash value with the private key;

If the public key of the signatory has been authenticated by some 3rd party (e.g.: a Certificate Authority), then one can use the public key of the signatory to check:

1. That the signature belongs to designated signatory (authentication)
2. That the document or transaction has not been modified

To make sure that the signatory cannot deny having performed the signature, the signatory must be the only one in possession (and with the knowledge) of the private key. Once the private key is not in sole control of the signatory, one can never prove that the designated signatory performed the signature.

Digital signatures and the eIDAS regulation

More than 20 years ago, digital signatures were recognised by the European Commission as a legally valid alternative to handwritten signatures (1999/93/EC directive). Nevertheless, due to a set of technical constrains, digital signatures usage was never widely implemented. In order to boost its usage, in 2014, the European Commission decided to revise the 99 directive and define a new regulation for electronic signatures — the eIDAS regulation. eIDAS provides the regulatory environment related with electronic signatures, by defining three different types of signatures:

Electronic signature. “data in electronic form which is attached to or logically associated with other data in electronic form and which is used by the signatory to sign” (definition)

These electronic signatures are created by an electronic signature creation device (ESCD), which is defined in the eIDAS Regulation as “a configured software or hardware used to create an electronic signature by means of an ‘electronic signature creation data’ (i.e. “a unique data which is used by the signatory to create an electronic signature”)”.

Advance electronic signature (AdES). It’s an electronic signature (as defined above) that shall meet the (additional) following requirements (eIDAS regulation art. 26):

• it is uniquely linked to the signatory and 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/her 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 signature (QES). It’s an AdES with an enhanced level of assurance on the signature creation by requiring:

1. Qualified Signature Creation Device (QSCD), i.e., a certified eIDAS device to create the electronic signature

2. Qualified Certificate attesting the authenticity of the public key, issued by a certificate authority (CA) that is a Qualified Trust Service Provider (QTSP). The QTSP is an eIDAS certified CA.

A QES provides the highest assurance level of the three signature schemes and has the equivalent legal effect of a handwritten signature.

Remote Signature Services for AdES and QES

When the eIDAS regulation became effective in 2016, the IT industry saw in it a big opportunity to offer electronic signature solutions. Over the last couple of years a panoply of software solutions for eIDAS compliant electronic signatures have emerged in the market.

Although the architecture of these solutions tends to vary, an emerging amount of them relies on the remote signature pattern (i.e., server-side signature). In fact this pattern has been standardised (in ETSI TS 119 432) as being the default solution for electronic signatures.

High-level architecture of the remote signature services

A remote signature service (RSS) has three main building blocks:

1. A Hardware Security Module (HSM) — this is a device that is able to perform cryptographic operations and securely protect private/secret keys (used to create the signature);
2. An Identity Provider (IdP) — this is the system that is responsible for managing digital identities and provides authentication services to the applications in the network. E.g.: of IdPs are Google, Facebook, iDIN, etc.
3. The Remote Signature Service (RSS) — this is the service that given a document (or any piece of data in a digital form) and a valid identity, provides a digital signature of the document on behalf of the identified individual using the keys protected by the HSM connected (and managed) to the service.

Remote signing architecture

This signing service typically works in the following way:

1. The user that wishes to sign a document using a browser application, for instance, starts by uploading the document to the browser; then the user sends a request to RSS, which redirects the user to the IdP for proving his/her identity;
2. If the IdP is able to authenticate the user, the user is provided with proof of his/her identity in the form of a digital token called authentication token. The user is then is redirected to the RSS where he/she uploads the document to be signed and the authentication token;
3. The RSS validates the authentication token of the user and verifies if the user is allowed to use the private key to sign the document. In case the authorisation succeeds, the RSS creates a hash value of the digital document (and some metadata) and sends it to the HSM;
4. The HSM, given the hash value of the document, outputs a digital signature that is created with the private key associated to the user’s identity;
5. The RSS then bundles the document (together with some metadata) and the digital signature and sends it back to the user.

Implementation flavours of Remote Signature Services

The previous paragraph presents a high-level description of how most of the remote signing services work nowadays. Nevertheless, each vendor may implement a variant of this architecture:

Implementation flavours of RSS

A. A single key pair for all the documents and users. E.g.: let’s consider that company A integrates this solution in its IT landscape. Then a single key for all the documents to be signed under the scope of company A use the same key pair to sign all the documents. This means that if company A has clients/users using the signing service then all of them will use the same key (pair) to sign the document. The key pair identifies, in this case, the company A and not the users requesting the signature in the document.

B. One key pair per user. E.g.: the difference with the previous one is that each user/client is assigned a key pair that is valid for a period of time (normally 1 year). Each user then signs with the key pair associated to his/her identity. In this case the key pair aims at identifying the user that signed the document. Each user has a single key associated to its identity.

C. One key pair per digital signature. E.g.: some RSS are even more dynamic and generate a key pair per each document to be signed. So the key pair is then aimed to identify the document which is being signed. The key pair is tied to the identity of user that requested the signature, but mostly to the document that is meant to sign. In this case each user has associated to his/her identity a set of keys — one per document they wish to sign.

Pitfalls of Remote Signing Services

Despite most remote signature services are becoming widely implemented across Europe (and the world), these services, when used in the context of eIDAS have some pitfalls that may lead to legal disputes between the signatory and the service for which the signature is required.

Lack of sole control of the keys by the signatory.

If you recall the requirements for AdES and QES schemes:

the signature should be created using electronic signature creation data that the signatory can, with a high level of confidence, use under his/her sole control;

This means that the private key of the signatory should be in his/her sole control. However, when using a remote signing service (RSS), the private key is stored (and managed) by the RSS. Whoever is in control of the RSS can control the keys and without proper consent, sign on behalf of the signatory. Moreover, the RSS relies on the IdP to unlock the signing process by the signatory. But, by relying in a 3rd party to grant access to the keys, the RSS may put the power of forging signatures in the hands of the IdP itself.

The definition of control in AdES and QES is open to so many interpretations, that according to the legislation, the general principles of RSS are indeed correct. However, signatures created in this way raise so many questions on who has signed what, that make them redundant and perhaps useless, as it’s very difficult to prove if they are indeed valid. In fact, the signatory can repudiate the signature.

A single key (pair) for all signatures.

Having a single key pair to sign all the documents and transactions actually goes against the very first requirement of AdES and QES.

it is uniquely linked to the signatory and is capable of identifying the signatory;

If you use a single key to sign all the documents of all your customers, how can you link the signature to the signatory itself? Moreover, how can you prove that a particular signatory did request the creation of that particular signature?

Some final remarks and conclusions

The eIDAS regulation has indeed improved the situation we had in the past with regards to digital signatures. However, (as usual) it didn’t establish the limits with regards to possible interpretations of what is technically right or not, leading to technical solutions that do not bring any added value. When you need to prove non-repudiation of the signatory, these remote signature services do not provide you with a suitable signature.

Although this might be quite obvious for some, it’s important to highlight that the digital signatures provided by the remote signature services (as described in this post) should never be used as a replacement of handwritten signatures. Note that the market does offer other solutions that do provide the right level of assurance and can indeed be used as a possible replacement of handwritten signatures. However, these solutions are by nature more expensive and difficult to maintain.

So, if you aim at investing in a service that works like the one described in this post, with the goal of creating digital signatures that replace the handwritten ones, then don’t. These might seem compliant for now, service vendors might even convince you that they are, but, trust me, they’re not future proof. In order to make the right investment from the beginning you should be empowered with the right knowledge and information, and I hope this post has contributed for that.