by lrosenth

Created

December 16, 2008

This article is on the basics of digital signature technology. To start with we need to get up to speed on what is called PKI technology (Public Key Infrastructure) because that is what is used for PDF and most other digital signatures.

Some simple basics

The PKI is based, in large part, on the clever asymmetric public key cryptography. Keys are relatively small strings of data that are needed to encrypt and decrypt much larger strings of data. For us, those larger strings of data are PDF document files. The clever invention is to provide a user with two keys that are unique to that individual, one being a "private" key that only that person has and the other a "public" key that is openly given to others. The term "asymmetric" derives from the notion that if one key of a pair is used to encrypt something then the other key of that pair is what must be used to decrypt it. If the same key is used to both encrypt and decrypt then it is a "symmetric" key.

So for example, if I use the private key, of my asymmetric pair, to encrypt a PDF file then I can send that file and my public key to anyone and they will be able to decrypt it.  Why would I send a file and the means to decrypt it together? The answer is, if the file can be successfully decrypted with my public key then, with statistically high confidence, you know that I was the one, and the only one, that could have encrypted it because I am the only one in possession of my private key. Furthermore it cannot have been changed since I did the encryption, or the decryption would have failed. Keeping private keys private is, of course, fundamental to this whole business.

In the reverse direction, if you want to send me something that only I can open, you can encrypt it with my public key and given that my paired private key is only known to me, I am the only one that can decrypt it. Neat, huh!

So, if it were a perfect world, we would all have our pairs of keys, with our private key only held and known by us and our public key available and known to everyone. But two things complicate this picture. How do I associate you, the person with your public key, a string of bytes on my computer?  I could get them from you directly but I still have to worry about them being tampered with while in my possession (within my computer). And if you are a stranger to me, how can I associate your public key with you?   So now enter the "Infrastructure" part of Pubic Key Infrastructure.

What the industry has proposed and implemented is a system of automated notaries that run on (Internet) servers, called "Certificate Authorities" (CAs), or in the EU "Certification Service Providers" (CSPs).  A means to protect the public keys has also been invented using cryptographic documents called "certificates". This is the "infrastructure" part of PKI. The CAs "sign" the certificate documents containing my public key with their private keys just as I sign documents using my private key. The process is, of necessity, hierarchical since I can then ask how I know for sure that I am using the proper public key for that particular CA to check its signing. The answer is by using a certificate created by a higher authority CA that securely supplies me the lower level CAs public key. This stops at some root where I check the proper public key by some other, perhaps manual, means.

The second complication is that I might want to have more than one identity for different roles that I may need to play so I can have multiple key pairs and hence multiple certificates. There is also a spectrum of how strongly the CAs checks out who you are before giving you a certificate so I may have more than one for that reason.

This stuff is all in place and operational but user education seems to be a major obstacle. Each person has to obtain one or more certificates from an authority at a suitable level and establish trusted root authorities for checking other’s certificates. I also think that there are way to many options and choices which all fall to the users, who are mostly naive in this technology.

In a subsequent blog I will cover how all this works with PDF files.

Jim King (contact: jking@adobe.com)