How we built a PKI and a TSA and got them certified in 6 months
Part 1: Context and problem

Dani Jimenez
Feb 18, 2019 · 7 min read

NOTE: Even though this is a tech blog, I’ve tried to write this post in a way that the not tech-savvy can understand everything. Even with that, there are some things that are left unexplained, so you might want to take a look at:

Digital Signature, Public Key Infrastructure, Timestamping, CRL, OCSP, HASH

Context

Signaturit is a Qualified Trust Service Provider which has a SaaS platform that offers services that guarantee the legal security of all your digital transactions. One of its main features are the digital signatures. These digital signatures are performed complying with the eIDAS regulation.

What is the eIDAS regulation?
eIDAS is an EU regulation that specifies a set of standards for electronic identification and trust services for electronic transactions in Europe and it applies from 1st July 2016

The eIDAS regulation specifies three levels of digital signatures:

Simple which is defined as…

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”
Which in practice can be something like a scanned signature, writing your name under an email, or performing a click on an “I accept” button.

Advanced which must comply with the following requirements:

  • Uniquely linked to the signer
  • Capable of identifying the signer
  • Created using signature creation data that the signer can use under their sole control
  • Linked to the signed data in such a way that any subsequent change in the data is detectable

Qualified which is the only electronic signature type being legally equivalent to a hand written signature, and which must comply with these requirements:

  • Meet all advanced electronic signature requirements
  • Created by a qualified signature creation device (QSCD)
  • Based on a qualified certificate for electronic signatures

What is a Qualified Electronic Creation Device?
A QSCD is typically a combination of a hardware device and software that has been certified and approved to perform Qualified Electronic Signatures (QES).
Ultimately, a QSCD must use and rely on a Hardware Security Module (
HSM) which is a hardware device specifically designed to safeguard and manage cryptographic keys.

What is a Qualified Certificate?
A qualified certificate is a public certificate that has been issued by a Qualified Trust Service Provider (QTSP). That means it’s been issued by a natural or legal entity that’s been certified for the services it provides related to electronic identification.

Besides the different security levels for digital signatures, eIDAS also specifies different standards with which digital signatures must comply with depending on the format of the original data to be signed. For example:

  • For a PDF file, the PDF Advanced Electronic Signatures (PAdES) specifications must be followed
  • For a XML file, there’s the XML Advanced Electronic Signatures (XAdES) extensions
  • For a CMS message, there’s the Cryptographic Message Syntax Advanced Electronic Signatures (CAdES)

Out of all these definitions, types and acronym, we will focus on the Advanced and Qualified signatures using PAdES specifications for PDF documents, which is the proper format for human-readable documents and the one that Signaturit is specialized on.

Initial scenario

Focusing on the digital signatures service provided by Signaturit…

The purpose of a digital signature, in this case applied to a document, is to provide a digitally supported method to be able to validate the authenticity and integrity of that document. Put it simple:

If I receive a digitally signed document, I must be able to verify the identity of the signer (authentication), with enough assurance that the signer is the one who performed that signature (non-repudiation), and that the document was not modified after the signature was applied (integrity).

Validating a digital signature

So, if I want to validate a digitally signed document I should proceed with the following verifications:

  • Verify that the digital identity specified in the certificate matches the expected signer. For example, verify the certificate’s distinguished name data including signer’s name, surname, national id number, etc.
  • Verify that the certificate chain leads to a recognized Certification Authority.
  • Verify the status of the certificates that compose the certificate chain. That is:
    - Verify that the root CA is still a trusted CA and certificate has not expired
    - Verify, for each intermediate CA in the chain that each certificate has not expired and also none of them have been revoked, this can be verified by means of a CRL or OCSP service
    - Verify that the signer’s certificate has not expired and is not revoked

But, what happens if…

  1. Bob, who is a user that’s in possession of a perfectly valid certificate issued by a trusted CA, performs a digital signature on a document.
  2. One year later, Bob’s private key associated with that certificate is compromised, therefore that certificate is revoked.
  3. One year after that, Alice receives the original document that Bob signed two years ago. Alice, who is a smart girl, performs the steps to verify the digital signature, and on the last verification she receives a message from the OCSP service for the intermediate CA that issued Bob’s certificate saying that that certificate is revoked.

So is the digital signature performed by Bob valid?

Well… it should be right? Because, when the signature was performed, the private key related to Bob’s certificate had been protected securely…
But it’s not, it’s not valid because Alice does not have irrefutable proof of when the document was signed.

So how can we verify a signature that was performed correctly, even if its certificate was revoked afterwards, or even after its certificate has expired?

The solution for that is called Long Term Validation (LTV) of digital signatures.

Long Term Validation (LTV)

The goal is to be able to verify, at any time in the future, that a digital signature was valid at the time it was performed.

So how do we achieve that?

The first thing we need is a digital evidence that the document and the digital signature applied to it existed at a given point-in-time and have not been modified since.

That’s clearly the use case for a digital timestamp.

What is a digital timestamp?
A digital timestamp is basically a digital signature performed by a trusted Time Stamping Authority (TSA) and applied to a bunch of data that represents the “fingerprint” of a document in this case, along with a time reference obtained from a trusted time source.

The way it works is:

  1. The client requesting the timestamp performs a hash on the data it wants to timestamp, and sends this hash representing the “fingerprint” of the document to the TSA.
  2. The TSA concatenates the document hash along with a time reference obtained from a trusted time source which has a high reliability providing the correct time
  3. The TSA performs a digital signature on the concatenated data along with some other metadata that references the operation, this constitutes the time stamp token that’s returned to the client

Ok, so we have a method for verifying the contents of a document at a given point-in-time. From now on, any modification on the document would modify the hash that was sent to the TSA and therefore the time stamp would not be validated.

The second thing we need to achieve the goal of a LTV of digital signatures is to be able to verify that the certificate used in the digital signature was not revoked at the time of the signature.

To achieve this, the procedure consists on obtaining a certificate validation response (CRL or OCSP response) from the CA that issued the certificate at the time of the signature and embedding it before digitally signing it.

This way the non-revoked status of the signing certificate can be validate even if the CA that issued it has disappeared and has no active OCSP or CRL available.

The problem

Now, coming back to the beginning of the story…

We know about Advanced and Qualified security levels and know about LTV of digital signatures, which are the really COOL digital signatures!

But, the thing is Signaturit was already performing really cool Advanced LTV signatures, so… What is the problem then?

Well, the “problem” is that, as we explained, in the process of performing the cool digital signature we need to request a time stamp, and this time stamp was being requested to a third party, it was not performed by Signaturit, which… is not cool at all, right?

So our real goal was set up, we want to build our own Time Stamping Authority.

How did we do that?

If you want to know, follow us on the second part of this blog post!

About Signaturit

Signaturit is a trust service provider that offers innovative solutions in the field of electronic signatures (eSignatures), certified registered delivery (eDelivery) and electronic identification (EID).

Open Positions

We are always looking for talented people who share our vision and want to join our international team in sunny Barcelona :) Be a SignaBuddy > jobs

Signaturit Tech Blog

Signaturit Tech Blog