Why Secure Electronic Signature requires timestamp?

A digital signature is a mathematical representation and proof of the genuineness of digital messages, files, executables, documents, etc., in modern communication by employing strong cryptographic techniques such as encryption and hashing. Digital IDs or certificates (based on asymmetric or public key cryptography) are used for the creation of digital signatures and have a validity period. Digital certificates are issued by the CA (Certificate Authority). PKI (Public Key Infrastructure) and are a comprehensive and composite set of hardware, software, people, policies, and procedures all put together with an aim to create, manage, store, distribute, and revoke keys and digital certificates.

Public keys are openly distributed among the communicating entities, and the private keys are kept a secret with the signer and the standard being currently used for digital certificates is X.509v3. Digital signature generation is depicted in Figure 1.

Figure 1: Digital Signature Generation

Digital signatures deliver the following security services:

Sender/Source Authentication: A message/file is digitally signed by the private key of the sender and sent to the other party. The other party can only verify the signature from the sender’s public key; hence the authentication of the sender is achieved. Message Integrity: Since the sender created the digital signature and no-one else can alter or modify it during transit, it means that message integrity is maintained.

Non-Repudiation: Only the sender can create the digital signature, which is verified by its public key, so the sender cannot deny the signature.

Although the digital signature provides the above-mentioned services, it doesn’t provide the timestamp date or time of when the signature was created. There are two potential scenarios that involve the verification of the digital signature.

Expired Signer Certificate

If the signer certificate is expired, then the verifier (at a later stage) cannot assess that the signature was created while the certificate was valid. This makes the digital signatures susceptible and a verifier can reject them. A typical scenario that occurs mostly can be explained as follows:

A) CA issued the signer certificate which was valid from 1st of January 2018 to 1st of July 2017.

B) Signer creates a digital signature on 1th of March 2018.

C) When the verifier tries to validate the signature on 10th of August 2018, the signer certificate has been expired. Now the verifier has not enough information for the validity of the digital signature.

An illustration of the above explained scenario is shown in Figure 2.

Figure 2: Expired Signer Certificate

Revoked Signer Certificate

If the signer private key and certificate get compromised due to identity theft or loss etc., it notifies the CA about the identity loss and gets its certificate serial number published in CRL (Certificate Revocation List). CRL basically holds the serial numbers of the digital certificates which have been revoked. Now let’s suppose that the private key and certificate is being used by a malicious entity and successfully generates a digital signature by using the private key. The verifier has no information that the digital signature was created by the actual signer or the malicious entity. This critical scenario can be explained as follows:

A) CA issued the signer certificate which was valid from 1st of January 2018 to 1st of August 2018.

B) Signer private key and certificate are compromised on 1st of March 2018.

C) Signer reports the CA and gets its certificate serial number published in CRL on the same day i.e. 1st of January 2018.

D) Malicious entity creates a digital signature on 1th of March 2018.

E) When the verifier tries to validate the signature on 10th of August 2018, it can check from CRL that the certificate is revoked but it can’t verify that signature was generated before or after the certificate revocation.

An illustration of the explained critical scenario is shown in the Figure 3.

Figure 3: Revoked Signer Certificate

There is a probability that verifier may trust the digital signature created by the malicious entity.

“ROCA Vulnerability”: A Case Study

ROCA (Return of Coppersmith Attack) appeared on 30th August 2017. It dealt with the RSA key generation mechanism provided by the software library “RSALib” which is used by a lot of smart card vendors and TPM (Trusted Platform Module) implementations. Multiple countries such as Estonia and Spain were using National ID cards which used this library, so millions of users were affected due to this. This vulnerability permits the private key components of a hardware stored key pair to be recovered from the public key. Malicious entities such as hackers may use this information to decrypt encrypted data/communications and imitate key holders etc. 1024 and 2048-bit RSA keys generated thought this library were vulnerable.

“Compromised OCSP Server”: An Attack Scenario

OCSP (Online Certificate Status Protocol) defined in IETF (Internet Engineering Task Force) RFC 6960 is a protocol used for obtaining the revocation status of an X.509 digital certificate. OCSP servers return an encrypted response about a single certificate. Authenticating party determines the OCSP responder’s URL by inspecting the AIA (Authority Information Access) extension in the digital certificate. If the extension contains an OCSP server/responder URL and the client supports OCSP, the client can proceed with sending an OCSP request to the OCSP server. Let’s discuss a scenario that OCSP server gets compromised and falls under the control of a malicious entity. The attacker manipulates the server to provide forged and bogus certificate status responses. The incorporation of digitally signed timestamp can give the assurance that a particular OCSP response was generated before or after the revocation of OCSP certificate.

Timestamps Incorporated Digital Signatures

TSP (Time Stamping Protocol) was initially defined in IETF RFC 3161 and later updated in RFC 5816. It gives the concept of trusted timestamps which are generated in a secure environment through FIPS (Federal Information Processing Standards) compliant and tamper resilient hardware. Timestamping services are normally provided by TTP (Trusted Third Parties). Trusted timestamping gives a higher level of assurance about the correctness and genuineness of the timestamp.

The incorporation of the timestamp in a digital signature requires a timestamping server or TSA (Timestamping Authority). The working of TSA requires a digital certificate which is issued by a CA. The TSA certificates are normally issued for large time durations because timestamps have to be validated in the future as well even after the expiry of signer user certificate. When the TSA certificate gets expired, all the timestamps issued are considered expired as well. The workflows for creating a digital signature with timestamp are as follows:

1.    The fingerprint (hash) of the input file/message is calculated through a well-known hashing algorithm.

2.    The calculated hash is then encrypted by the private key of the signer. (As it is encrypted through the private key so a verifier can only validate it by decrypting from the corresponding public key).

3.    The encrypted hash is appended with the document and digital certificate of signer resulting in the digital signature.

4.    The hashing algorithm is again used to compute the hash of the digital signature.

5.    The hash of the digital signature is sent to TSA.

6.    TSA appends the on-going timestamp with the received hash and digitally signs it by using its private key. TSA also appends its digital certificate resulting in digital signature with a timestamp for verification.

Generation of digital signature with timestamp is depicted in the Figure 4.

Figure 4: Generation of Digital Signature with Timestamp

Conclusion

• The integrity of the digital signature is enhanced by the complement of timestamps making it more trustable.
• Some digital items need to be signed for a longer term such as documents and executables to ensure LTV (Long Term Validation). As we all know digital certificates are issued for a fixed duration. Due to this issue, the signature needs to be validated at later times in future. To cater this issue, the document/executable is timestamped because TSA (Time Stamping Authority) certificates are issued for a long time and serve the desired purpose.
• Time Stamping also provides an additional layer of non-repudiation because TSA encrypts the timestamp with its own private key.
• Reduces the dispute probabilities and the Time Stamping can be easily & quickly verified from the TSA.