Digital signature, time stamping and encryption of documents
Continuing with our REALSEC’s cybersecurity prescribers campaing, today We want to share this interesting article about digital signature, encryption of documents and time stamping, writting by the expert in cybersecurity Luis Martin, from whom We published previously one article about encryption of communications.
Digital signature is defined as the set of electronic data that go with or are associated with an electronic document and is based on the 59/2003 Law of 19 December about Electronic Signature, indicating that the recognized “electronic signature” must fulfill the following properties or requirements:
- Identify the signer.
- Verify the integrity of the signed document.
- Ensure non-repudiation at origin.
- Have the participation of a trusted third party.
- Be based on a qualified electronic certificate.
- Must be generated with a secure signature creation device.
The joining of encryption (already discussed in a previous article) and digital signature provide three features in Internet communication: unmistakable identification of the signer, data integrity and non-repudiation, and these are part of the three requisites demanded by law.
Data integrity means we can be sure that what we send is what the receiver receives and viceversa. In other words, what we receive is what the issuer sent.
Non-repudiation means that the issuer, after having sent the message (or file or e-mail, what is sent signed) cannot claim that he did not send it, nor that the signature is not his. In other words, there are no chances of saying that they have “falsified our signature” through the digital signature.
Unmistakable identification of the signer is achieved through the digital certificate and the public key infrastructure, which was already discussed in a previous article. This public key infrastructure includes the so-called Certification Authorities (CA), which are the “trusted third party” and of which the Law refers.
The use of secure devices refers to the use of a secure identification document such as an electronic ID or a FNMT cryptographic card. They are necessary for the delivery of signed documents to the Administration, but it does not have to be necessary in order to exchange signed documents between companies or individuals.
The digital signature document, as we will see ahead, is a document which only provides the principle of integrity. The rest are achieved through other technologies that go with the signature: encryption, public key infrastructure, or cryptographic cards.
There are many practical applications of the digital signature which are intended to perform operations on the Internet that require a signature to validate them in everyday life as in the following examples:
- Submit Income Tax Files over the Internet.
- Applications in the electronic administrative records.
- Request for work history.
- Reception of electronic notifications.
- email signature.
- Electronic invoice signature.
Digital Signature Process
A digital signature is obtained by calculating a “hash” value, which is a unique value that changes every time a document is modified (a blank space implies a completely different hash value). That hash value is appended to the end of the document and is encrypted so no one can read it but the receiver.
This way the receiver of the message or document decodes the hash, calculates the “hash” of the message or document and checks if they are the same. If they are different, he will warn the user that there could have been a modification of the message during the transit.
You can sign all kinds of documents (PDFs, TXTs, DOCs, JPGs, etc.), as well as emails and anything else that you want to send over the Internet.
Summing up, the signature process is as follows:
1.- We create the document that we want to sign, whether it is a PDF document, or whatever you want. In this example we will use a PDF document.
2.- We obtain the hash value, the only one of such document. There are different Hash functions (MD5, SHA1, SHA-256, etc). The most widely used is SHA-256. SHA-256 generates a 256 bits value (with this aspect in hexadecimal: c6b6b0c4147befff952eabfdb9bdc0a0c25bc8204378aadf8e9c52f2b30cc3c1) and it is unique for that document. I added a blank space to the previous document and I obtained the SHA-256 hash 20dc443a2071c615d6e90594043af06357de8fa8f53eb39f03e11516508f8dd5. As we can see, they do not resemble at all.
From this value onwards, it is impossible to obtain any information about the original document, but if we calculate it (if we have not modified the document), it will bring us the same hash value.
3.- With our private key this SHA-256 hash obtained from the PDF is encrypted. The text may be similar to:
It is the digital signature of the PDF document. This is usually saved in a small file.
If we also want to encrypt the document to guarantee confidentiality and non-repudiation, the following steps will take place:
4.- The original PDF document is encrypted by using the issuer’s private key.
5.- The PDF document already encrypted is encrypted again, but this time using the recipient’s public key.
If you only want to sign the document (for example, we want to make the document public but to see what we have signed), in the email (or by whichever means), the PDF document will be sent as well as the digital signature file.
In contrast, if confidentiality and non-repudiation is desired, the following three documents will be joined into a single document and they will be sent via email (or by whichever method):
– Doubly-encrypted PDF document.
– The file with the signature of the original document.
– The issuer’s public key (this is not necessary since public keys are public, and are available in key servers).
This process is described in the following diagram:
Why is this long process necessary? Well, let’s have a look at all the steps:
- Digital signature (steps 1-3) is a hash that varies with the minor modification of the document, and that hash has been signed with the issuer’s private key. So, the receiver ensures that the document has not been modified since the issuer signed it. This is called integrity.
- First PDF encryption (step 4), done with the issuer’s private key, can only be decoded with the issuer’s public key. The receiver can be sure that document was encrypted by the person who sent the document. This is called non-repudiation.
- Second PDF encryption (step 5), done with the receiver’s public key, can only be decoded with the receiver’s private key. The issuer ensures that only the receiver can read the encrypted document. This is known as confidentiality.
Although the process is very long, a computer does that in milliseconds. In the case of a large original document, an encryption may take a few seconds but not more.
The following illustration shows a decryption process and signature verification:
In short, the document is encrypted twice, using the receiver’s private key first and then the issuer’s public key. In this case, we ensure confidentiality and non-repudiation. If we want to check the integrity of the sending, we will have to perform the same process that was carried out at the time of the creation of the digital signature and compare the signature obtained with the one received by email. If they are the same, we are sure about the integrity of the sending.
The same thing done with a PDF document, we can sign emails, or instant messages. Both emails and messages are small files which can be coded also signed.
If a document has multiple authors and we wish to have them all sign, the process would depend on whether the document is encrypted or not.
If the document is not encrypted, the process consists in calculating the hash of the original document and have everyone sign separately with their respective private keys. All signers encrypt the original hash of the document and in the document finally generated, there will not be just one signature, but corresponding to the number of signers.
For example, you may need a signed document by two managers and then by an auditor who bears witness that this document is real and has been signed by the two managers.
In this case, the hash of the document will be signed by both managers, therefore obtaining two signatures. These two signatures will join in a single document which would be subsequently signed by the auditor. The document will be received unencrypted as well as another signature document that should be decrypted using the public key of the auditor to obtain the two digital signatures of both managers.
If we talk about encryption of multisigned documents (or messages), in this case the order is important. Thus, we must decode first with the public key of the latter which encoded (and signed) the document. And how do we know which one is the last one? In these cases, along with the “multicoded” document, the digital signature is the only one received, and we can find out who the signer is. The signer will also be the coder. We must use the public key of the coder.
When decrypting the document using this public key, another document (encrypted) and another digital signature are generated, corresponding to another signer. We will use the second signer’s public key to decrypt both the document and the digital signature. The same procedure goes on with all the signers.
The electronic signature verification process should have the possibility of repetition at any time in the future, even years after its generation.
Along the time, the encryption algorithms can become vulnerable, having the possibility to obtain private keys if the algorithm is vulnerable.
In broad terms, the solution to these problems is to include a time stamping in the signature so that this date will not be included by the signer itself but by a time stamping certification authority (TSA).
On the other hand, it is necessary to check that the signer’s certificate has not expired during the signing process. This is achieved by carrying out an OCSP request to a key server which guarantess the validation of the certificate.
For this reason the signing process becomes a little complicated because two previous steps to the signing are added:
0.1.- Request for an OCSP certificate validation to a key server
0.2.- Request for a time stamp to a TSA
One of the concerns that appeared after the implementation of the digital signature was that, for example in Europe, a digitally signed document in a Member Country of Europe, should be as valid in any other Member Country.
The interoperational level should be established using open standards and there ought to be different levels of security and confidentiality according to the importance of the document. All of this was gathered in the European Board 1999/93/CE.
This was solved from a technical point of view by establishing an open signature format.
As we have seen, a digital signature is a file (or several) containing information about the original document, the signer, the date of signature, algorithms used and signature expiration.
Sometimes this signature file is embedded in the original document and others are a separate file.
The way in which this information within the signature file (the order of that information within the file, tags that indicate when a field begins and ends, the options of those fields, etc.) are structured, it is determined by the format in which the signature is sent. There are different formats such as CMS, CAdES, PAdES, XAdES, etc.
CMS (Criptographic Message Syntax) was the first standard for cryptographically protected messages and was based in PKCS#7, which is the standard for messages encryption and signing in a PKI infrastructure.
CMS is a general framework for the signing of documents digitally, such as E-Mail (S / MIME), PDF or any other type of documents.
CAdES (CMS Advanced Electronic Signatures). This format, from 2000, is the evolution of the CMS format. It is appropriate to sign large files, especially if the signature contains the original document because it optimizes the space of information.
Shortly after creating CMS
In the framework of this guidelines, CAdES specifies 6 precise profiles of signed data for its use with advanced electronic signature.
This means, that for practical purposes, the format of the signature using each profile is different, the receiver must detect which profile the signature file has and be able to extract the signature itself.
In 2001 appears XAdES (XML Advanced Electronic Signatures). It was about an evolution in parallel with CAdES. While CAdES is based on CMS, XAdES is based on XML-DSIG. With XAdES, the result is an XML text file. Documents obtained tend to be larger than in the case of CAdES. Therefore, it is not suitable when the original file is very large. XAdES also incorporates adaptations and extensions of 1999/93/CE Directive, creating their own profiles, incompatible with CAdES. Applications such as eCoFirma of the Ministry of Industry and Trade, just sign in XAdES.
In 2009 PAdES comes out and is based directly on PKCS#7 and 32000-1 standards, which establish a framework for the signing of digital documents. PAdES incorporates the same features of CAdES and XAdES, but only for PDF files. For this reason, it is the most suitable format when the original document is of this type.
With PAdES, the addressee of the signature can easily check the signature and the signed document, because it is a visible and legible signature for the human being. With the previous formats this was not possible without using external tools.
The digital signature document structure is different in each of these formats, and within each format it is different depending on the profile used, including more or less information in each case.
The aim of this article is not the format description of each of these standards. Most current solutions support all these formats.
The 59/2003 Law of 19 December about Electronic Signature establishes the three main requirements that a digital signature must comply; identify the signer, verify the integrity of the signed document and ensure non-repudiation.
The signing process is based on a hash value of the document and the encryption of that hash that is to be sent along with the document. However, this signature only guarantees the integrity. Other objectives are achieved by encrypting both files (document and signature) with the issuer’s private key and the receiver’s public key.
In order to verify that a document signature has been made on a specific date, and that this signature is valid, two more steps have been included to the process: a request for the certificate validation to the key server and a request for a time stamp to a time certifying entity.
It is worth mentioning, finally, that there are different formats of digital signature (CAdES, XAdES, etc.), and signature validation applications must be prepared for verification.