Blog, Trixi

Digital signatures – verification in practice

We live in the 21st century, we communicate electronically and generally we don’t trust each other. Hence we need and sometimes even must use digital signatures to prove ourselves to be trustworthy. One would say there must be plenty of tools for digital signing and signature verification. Unfortunately it is not that easy. While signing a document is relatively straigtforward, the reverse process of signature verification is quite complicated. And it is exactly the digital signature verification I am going to talk about. Specifically I want to explain several advanced aspects of verification of digital signatures based on PKI (Public Key Infrastructure).

Simply put, I want to tell you how to implement the verification and not what it teoretically does. But you should be aware that there may me additional requirements on a digital signature creation/verification coming from real-life sources like for example your company security policies or even from a government/laws.

Dates and a signature

Every signature is always verified against a particular date. When we decide on signature validity we must also say to which date we do it. At least these dates come into play:

Date of Signature
- when the document was originally signed
- the date is part of the signature itself

Timestamp Date
- may or may not be present as a part of the signature
- proves that the signature had already existed when the timestamp was created

Date of Verification
- when the actual signature verification of the is done
- it’s simply today’s date

Checked Date
- the date we check the signature validity against
- verifying the signature means deciding whether the signature was valid on this date
- this is the most important date for verification

Example (signature without timestamp):
The document was signed on 1.1.2010. ( = date of signature)
Today – 13.7.2012 – we need to verify its signature. ( = date of verification)
But we want to know whether the signature was valid on 5.5.2011. ( = checked date)

Timestamp rule

The rule is used to correctly determine the Checked date.

The signature contains a valid timestamp => use Timestamp Date as Checked Date
The signature lacks a valid timestamp => use Date of Verification as Checked Date

It is generally much easier when the signature contains the timestamp. It means there is no doubt the signature (and the signed document too) existed in the Date of timestamp. Otherwise you must be cautios. The Date of Signature cannot be trusted because there is no guarentee it was not altered when signing the document. The simplest way of altering the Date of Signature is quite simple – you just change the system time on the signing computer.

When the Date of Verification is used as Checked Date it brings complications. We must verify the signature the same way as if the document has been signed recently.

  1. Current CRL must be downloaded and may be considered obsolete because it is highly probable that the CRL is older then the signature. Hence it is possible the CRL does not contain all the revoked certificates and it may be neccessary to wait a little bit to get some later CRL.
  2. Certificates on the certification path could already be expired. There is no clear solution to this and the signature must be marked as invalid.

Accredited certification authorities (in Europe)

When verifying a signature it is essential to check the certification path of the signer’s certificate. Every valid certification path starts with a certificate issued by trusted certification authority (trust anchor). This authority is a guarantee of the signer’s certificate origin. Simple certification path verification defines the trust anchor as any certificate placed in a trusted anchors list. It is perfectly good to create your own home-made certificate and put it to the trusted anchors list. The problem with such a trust anchor is that not everybody may trust it. It certainly can be used to verify signatures but the verification result will not be generally trusted because the trust anchor is not universally acknowledged.

And that is why the certification authorities needs some more classification.

Certification authority
- any authority, even your home-made one

Qualified certification authority
- issues qualified certificates usable for signing
- some terms of its operation defined by national laws

Accredited qualified certification authority (EU specific)
- issues qualified certificates usable for signing
- is registered and monitored by the national government
- is the only type of certification authority that is trusted by the government
- list of all these authorities is called TSL and is online for download

EU member states and its governments are required to be able to verify signatures based on certificates issued by any accredited authority from any member state. If you work for EU governments you’ve probably met TSL’s closely. So – happy XML parsing…

In the next article I want to tell you about:

  • CRLs (certififate revocation lists) – how to get it, use it, cache it
  • Archivation of signature verification results
  • Signature long term verifiability

Posted in programming

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>