Tag: digital signature

Digital Signatures: Under the Hood

The basic requirements of a digital signature are that it must uniquely identify the signatory, it must be independently verifiable, and it must be invalidated if the signed data has changed. To understand how these objectives are achieved, let’s start with the foundation of modern digital signature technology: public key encryption and the public key infrastructure, or PKI.

In public key encryption, a “key pair” consists of two parts: a public key and a private key. In simplistic terms, the public key is mathematically derived from the randomly generated private key using an algorithm known as a “one way function”. A one way function makes it easy to calculate a public key if the private key is known, but extremely difficult to deduce the private key if the public key is known. The end result is a secret private key and an openly shared public key that are mathematically related in such a way that the public key can be used to decrypt data that was encrypted with the private key, and the private key can be used to decrypt data that was encrypted with the public key.

This interesting property of such a key pair gives rise to a number of useful capabilities. In the case of digital signatures, the act of signing data is essentially nothing more complicated than encrypting the data with a private key. If the data can be decrypted successfully with the signer’s public key, then only the signer’s private key could have been used to do the encrypting. In practice, this process is simplified so that the signer encrypts only a secure hash, or checksum, of the data to be signed. The recipient then calculates the hash from the raw data and compares the result with the “signed” hash after it is decrypted. If the values match, the digital signature and data are validated.

For this process to work properly, there need to be standard ways to package information about the algorithms used, and to provide important information about the keys themselves. This need is fulfilled by digital certificates. A digital certificate is a file or block of memory containing a public key along with ancillary data about the key and its owner. The certificate is itself digitally signed by the entity, usually a mutually trusted third party, that issued the certificate. This enables users to verify that the public key is valid and trustworthy.

A digital ID is the private key component of a key pair. Normally the private key is not stored together with the public key, but instead is stored in a separate physical location for security, usually requiring a password to access it. A key manager maintains links between the digital certificate and its associated private key. In many cases, it is convenient to use the term “digital ID” to mean both the public and private keys, even though they are physically separated.

It is almost always a good idea to time stamp digital signatures. Time stamping involves sending the digital signature to a time stamp authority, who then creates and returns a digitally signed time stamp that is uniquely and securely associated with the original digital signature. The time stamp can then be verified by third parties in the future by using exactly the same technique used to verify a digital signature.

I think these important terms deserve a review. A “digital certificate” is a public key, which is itself digitally signed by a mutually trusted third party. Your digital certificate represents your public digital identity, and it should be made freely available to anyone who wants or needs it. A “digital ID” is a digital certificate and the private key associated with the digital certificate. It isn’t difficult to create your own self-signed digital ID, but a digital ID is only as good as the issuing authority that signs it. When you purchase a digital ID from a third party like VeriSign or Thawte, their reputation makes your digital ID more trustworthy.

Digital Signatures: Philosophically Speaking

There is nothing magical about digital signatures. They are simply an electronic mark used to signify a promise and to cement faith in the document or transaction to which that promise is attached. Some day digital signatures will be as commonplace among CAD professionals as the human readable “wet stamp” is today. However it must also be said that, just as CAD did not make architects more creative, digital signature technology will not make engineers more trustworthy.

The technology to use digital signatures has been around for well over 20 years, and a wide variety of software tools exist today that make digital signatures easy to use on almost any platform. So why is the use of digital signatures not more widespread? Primarily because the utopian dream of a paperless world has yet to materialize.

So long as hardcopy on paper is regarded as the authentic “record” version of a document, digital signatures are virtually useless. Even if new buildings are designed completely in CAD, an architect’s digital signature simply won’t mean anything if downstream consumers of the building design require a paper blueprint. The true benefits of a paperless world simply can’t be realized until every link in the chain has joined the digital club. So long as even a single node on the distribution tree requires a human readable method of verifying authenticity, the architect is forced to use a handwritten wet signature on paper blueprints from the very start.

Handwritten signatures can be scanned into an electronic format, but then they lose their putative value because a digital facsimile is so easily reproduced. Therefore only original and unique handwritten wet signatures are trustworthy in a human readable form. Digital signatures do not translate to paper because they are not human readable. Therefore digital signatures only have value for a document in electronic form. This maxim is fundamental to a proper understanding of the emerging digital signature technology: digital data can only be securely signed by computers; and human readable documents can only be securely signed by humans.

I see many people in the CAD industry looking for a hybrid solution to this paper vs. digital dilemma by using a “digitized signature” (i.e. handwritten on paper, then scanned into electronic format) so that printed output contains this digitized signature. This cannot even remotely be considered a digital signature! There is simply no such thing as a secure printed digitized signature. Yes, you can digitally sign a document that has an embedded digitized signature, but once it is printed, that digitized signature is not worth the paper it’s printed on. Not only could that signature be stolen from the document and used maliciously, there is no way to tell from the signature alone whether or not it has already been stolen and used maliciously.

The only hybrid approach that is practical and legally sound is to use digital and wet signatures in parallel. Using an architect as an example, this would mean creating and disseminating two sets of signed documents: the CAD model of a building (perhaps converted into a common 2D format like PDF, DWFx, or XPS) with the architect’s digital signature and paper blueprints with the architect’s individually handwritten wet signature.

A number of companies claim to sell some sort of hybrid solution involving the creation of a secure digitized signature. This is simply capitalism — selling something useless just because there is a market for it. A digitized signature is only secure if it is never used. I’ve heard the rationalization that the digitized signature printed on paper meets a psychological need for people accustomed to seeing one, even if it has no legal value. In my opinion, such pandering borders on deception and serves only to further alienate digital signature technology from those who would benefit from it. This sort of abuse is typified by an emailed PDF file consisting of a scanned document with a handwritten signature. In such cases, checking the sender’s email address likely becomes the most reliable way to verify the document’s trustworthiness. Spam filters bear witness to the fact that the sender’s email address is the most important — and often only — criteria we use in determining the level of trust to place in emailed documents. This is an important point to keep in mind.

The act of applying a digital signature requires the use of a secure private encryption key, but the digital signature alone does not provide security in any way. Digitally signing a document does not prevent it from being modified or stolen. In that respect it is no different than a handwritten wet signature. However, unlike a wet signature that cannot be easily duplicated, a digital signature does not prevent a signed document from being copied. This does not make digital signatures inferior. On the contrary, making copies is necessary and commonplace in the digital world, so the fact that exact copies of digitally signed documents are still trustworthy is a huge benefit over handwritten signatures.

There are other notable differences between a digital signature and a handwritten signature. Digital signatures can be time-stamped, thus providing reliable evidence that a document was signed on or before a certain time. A disadvantage of digital signatures is that they are only as reliable as the digital ID used to create them. To combat this problem, a public clearinghouse of compromised digital IDs must be maintained, and auditing systems must be in place to immediately detect and report suspicious activity. Time stamped digital signatures created before a digital ID is compromised can be easily and certainly distinguished from compromised signatures if properly designed and competently managed infrastructure is in place. This is necessary to ensure that previously existing digital signatures survive a compromising event.

In conclusion, adequate technical solutions and time tested safeguards already exist for successfully using digital signatures in a professional environment, but digital consumers still need to learn how to work within the limitations of the technology. Building an acceptable comfort level with a technology that must by its nature completely replace something as significant and culturally ingrained as the handwritten signature will not be easy or quick, but it is inevitable.

Digital Signatures: Prelude

For many, the word “encryption” has a mysterious quality that invokes images of math virtuosos in secret bunkers working feverishly during wartime to break the enemy’s coded communications. My first exposure to encryption came in 1996 when I began working with Paul Kohut on the first version of CADLock software for locking AutoCAD drawing files. After overcoming my initial struggle to understand the terminology and get a handle on the mathematics behind encryption, I realized that it wasn’t nearly as mysterious and complicated as it first appeared.

I knew it would take a long time for encryption terminology to become standardized and commonly understood by laypersons. From the first days of CADLock, we recognized that the key to success for our software was going to be our ability to educate consumers about our technology, it’s possibilities and its limitations, its strengths and its weaknesses, what it could do and what it could not do. I felt that we needed to be realistic and patient while we waited for the market to catch up with our technology at its own pace. In the meantime, we needed to resist any temptation to needlessly bandy about sexy buzzwords like “encryption” lest we delay our mission by further muddying the waters in an already crowded ocean of technical jargon.

This recognition of the need for patience and perseverance has led me on a personal crusade to prevent encryption terminology from being perverted or hijacked by overeager marketing departments and uninformed experts. I’ve also tried to nudge the learning process along by adding my two cents whenever the opportunity arises. With this last goal in mind, I have prepared the following three part essay about digital signatures, tailored for the CAD industry. This is not written to academic standards, nor do I claim to be the final authority on the subject. Let me be clear about my agenda: I hope that furthering the common understanding of encryption related technology such as digital signatures will indirectly help sell more CADLock software!

What time is it?

AutoCAD 2004 introduced the ability to digitally sign drawing files when they are saved, but very few people use this feature. Even fewer use the time stamp feature that goes along with it. Time stamping a digital signature is important when it’s not only important to know *who* signed it, but also *when* they signed it.

For time stamping to be reliable and trustworthy, you need an independent (and trustworthy) third party to provide the time stamp, along with a verifiable receipt so that anyone can verify the authenticity of a claimed time stamp in the event of a future dispute.

Since the inception of the digital signature feature, AutoCAD has included three default time servers for this purpose. Unfortunately, none of the three are accessible any more. If you need to digitally sign drawing files with a time stamp, you’ll have to modify this list of time servers.

The list of time servers is maintained in a file named timesrvr.txt in the AutoCAD installation folder. You can edit the file with notepad, and the format is obvious and straightforward when you view the file.

If you just want to play around with time stamps, try adding the following to the end of the file (you do not need to restart AutoCAD to see the new servers):
NIST A [Maryland] (time-a.nist.gov)
NIST B [Maryland] (time-b.nist.gov)

As of this writing, both of these NIST servers are available and working, but you get what you pay for. For officially incorporating time stamped digital signatures into your workflow, I recommend subscribing to a commercial time service with guaranteed uptime and a web based time stamp verification console. I can’t recommend one, because I have never used a commercial time service myself, but a good place to start is the list of public time servers maintained by NTP.org at http://support.ntp.org/bin/view/Servers/.