Digital Signature Technology

Secure Your E-Commerce Documents

Exchanging documents over the Internet is common in e-commerce. Such documents often contain sensitive information—for example, legal contracts, information concerning technological innovation, financial transactions. To prevent hackers from intercepting and reading e-commerce documents traveling through e-space, you must encrypt those documents. If you want your documents to be truly secure, however, you must sign them digitally. A digital signature on an e-commerce document serves as a guarantor of data origin, integrity, and nonrepudiation. When a customer digitally signs an online purchase order, for example, the merchandiser—through the document's digital signature—can identify the customer who originated the order, can verify that no one tampered with the contents of the order in transit, and has proof that a particular customer made a specific order.

Digital signatures have been with us since 1976, when Diffie and Hellman introduced the digital signature as an application of public key cryptography. Only recently, however, have businesses and governments started to use digital signature technology to protect sensitive documents on the World Wide Web. In September 1998, President Bill Clinton and Irish Prime Minister Bertie Ahern digitally signed an intergovernmental e-commerce document that is the world's first such document to use digital signature technology. Microsoft used digital signature technology to develop Authenticode technology, which secures Web-downloadable codes.

As the need for digital signature technology grows, several software companies, including Entrust Technologies and Network Associates, have delivered commercial security software that lets users employ digital signatures to secure e-commerce documents. In this article, I'll explain digital signature technology. I'll also discuss some currently available digital signature software products and offer guidelines to help you plan your company's digital signature solution.

What Is a Digital Signature?
Digital signature technology grew out of public key cryptography. In public key cryptography, you have two keys: a private key and a public key. When you send a document to someone, you use your private key to sign the document. When recipients receive the signed document, they use the sender's public key to authenticate the document.

Figure 1 illustrates the digital signature process. Suppose you want to send a digitally signed document to John. After you create the document, you pass it through a message hash algorithm. The algorithm generates a hash of the document that is a checksum of the contents of the document. You then encrypt the message hash with your private key. The result is a digital signature. You append this digital signature to the document to form a digitally signed document, then send it to John.

When John receives the document, he passes the document contents through the same message hash algorithm that you used, and creates a new hash. At the same time, John uses your public key to decrypt your digital signature, thereby converting the signature to the original hash. John then compares the newly generated hash and the original hash. If the hashes match, John can be sure that the document he received is really from you and that no one altered it during transmission. If the hashes don't match, John knows that tampering or a transmission error changed the document contents.

The most commonly used message hash algorithms are Message Digest 5 (MD5) and Secure Hash Algorithm 1 (SHA-1). MD5 can produce a 128-bit hash, and SHA-1 can produce a 160-bit hash. The hash algorithm is a one-way function that generates a one-way hash. Therefore, no one can derive original document contents from a message hash. The chance that two documents will have the same hash is almost zero. For example, the possibility that MD5 will output the same hash for two different documents is 1/2¹²⁸. (2¹²⁸ translates into about 1,500 documents for every square meter of the earth's surface.)

A digital signature is superior to a traditional handwritten signature. A skilled forger can alter the contents of a document with a handwritten signature or move a signature from one document to another without being detected. With digital signature technology, however, any change in a signed document—such as content modification or signature replacement—causes the digital signature verification process to fail.

Public Key Trust Models
The private key that you use to sign documents belongs to you alone. You need to keep your private key secure: For example, you can encrypt a private key in your computer or store it in a password-protected smartcard. In contrast, you need to publish your public key so that recipients of documents you send can use your public key to verify your signature. You might publish your public key in your company directory, so that other users can access it, or you might send your public key directly to other users, who will store it in their computer.

Before users who receive documents from you can verify your digital signature, they must have a way of knowing that your public key is genuine. Without assurance that a public key is legitimate, trusting whether a signed document and its accompanying public key are from the purported sender can be risky. A hacker can use your name to generate a false public key pair, create a document and use the false private key to sign it, then send the signed document and false public key to John. Therefore, you and John must establish a public key trust relationship before exchanging documents.

There are two public key trust models: direct trust and third-party trust. In the direct trust model, you and John know and trust each other directly and exchange public keys personally or securely. In the third-party trust model, you and John might not know each other directly, but you both trust a third party or middleman to exchange your keys. For example, if you and John both trust Peter, then you and John can trust each other. When Peter gives your public key to John, John can believe the key is really yours. The direct trust model works for small groups or companies in which people know and can contact one another directly. The third-party trust model is more suited to large companies and intercompany relationships in which people might not know one another or can't contact one another directly.

Certificate Authorities
The third-party model introduces the Certificate Authority (CA). A CA is a trustworthy organization that certifies public keys. A CA can be an internal organization in your company, such as your information security department, or a CA can be an external entity called a public CA, such as VeriSign (http://www.verisign.com). CAs certify public keys by issuing users a digital certificate that contains the user's identity, public key, and key expiration date. The CA uses its own private key to sign the digital certificates it issues, which is another digital signature application. Each CA makes available a certificate containing the CA's public key, which anyone can use to verify a certificate the CA issues.

John can trust your public key if he trusts your CA and has verified your certificate. To verify your certificate, John extracts your CA's public key from the CA certificate and uses the digital signature verification procedure I described above to verify the CA's signature. In addition, John examines your certificate expiration in the expiration date field. John also verifies your certificate's validation by checking the Certificate Revocation List (CRL). If the CRL lists your certificate, you are using an invalid certificate. CAs revoke certificates and publish the revoked certificates in the CRL when users compromise their private key or leave their company, or when their certificate expires. A CA can append a reason for revocation to the revoked certificate in the CRL. Currently, no standard exists for locating and distributing CRLs. Finding a certificate's CRL depends on the CA's proprietary CRL implementation.

Time Stamping
Under certain circumstances, John might receive documents—for example, an old financial statement—that you signed before your certificate expired or was revoked. If your certificate expires after you send a document, the recipient will reject the document. However, if you attached a time stamp to your document, the recipient can use your expired or revoked public key to verify your old signature and will trust the document if the signature verification succeeds. Time stamping can not only guarantee your signed documents' validity for future use but is crucial for legal and financial documents. For example, time stamping electronic payment of your credit card bill can protect you from incurring interest charges by proving that you paid the bill on time.

In November 1997, researchers proposed a time-stamp protocol to the Internet Engineering Task Force (IETF) as an Internet draft (draft-adams-time-stamp-00.txt). Several companies, including Microsoft, have adopted thistechnology and are using it in their products (e.g., Authenticode).

When you need to time stamp a document, you can request a time-stamp authority (TSA) to provide time stamping. The TSA must be a trustworthy organization. TSAs can be a public time-stamp service provider, such as VeriSign, or an internal time-stamp server on your intranet. When the time-stamp server receives your request, the server time stamps the document with its private key and returns the document to you. If you send the time-stamped document to John, John can use the TSA's public key from the TSA certificate to verify the time stamping. The time-stamping and time-stamp verification process is similar to the digital signing and signature verification process.

Digital Signature Software
Several software companies have incorporated digital signature functionality into their security software and applications requiring high security: for example, Entrust Technologies' Entrust/Solo and Entrust/Entelligence, Microsoft's Certificate Server in Outlook, Network Associates' Pretty Good Privacy (PGP) for email and files, and SynData Technologies' SynCrypt. (John Green reviews SynCrypt 1.1 in a May 1998 Windows NT Magazine Lab report.) All these products support encryption in addition to digital signature. The products are easy to use and do not require users to understand digital signature technology in depth. Screen 1 shows Entrust/Solo's GUI for digitally signing a document. You can classify the digital signature functions in digital signature software into three categories: email only, files only, and both email and files. For example, Outlook supports digital signature for email only, Entrust/Solo for files only, and Entrust/Entelligence for both email and files.

Digital signature software can fall into the public key direct trust or third-party trust model. For example, Entrust/Solo belongs to the direct trust model, and Entrust/Entelligence belongs to the third-party trust model. Let's take a brief look at these two products.

With Entrust/Solo, you create a user profile for yourself, and the software generates a pair of public keys for digital signature and another pair of public keys for encryption. The software password-protects your profile containing the public key pairs and stores the profile in your local computer. You can export your public keys to a key file and give the file to users to whom you will send your signed documents. Those users save your public keys by importing the key file into an address book in Entrust/Solo in their computer.

When you want to sign a file, you choose the file and the sign option from Entrust/Solo, as Screen 1 shows. If you want to encrypt a file when you sign, you need to identify in your address book the recipient to whom you will send the file—John, for example. Entrust/Solo will use John's public key to encrypt the file (if you have imported John's public key into your address book), which lets John decrypt the file with his private key.

When John receives your signed document, he uses the verification option in Entrust/Solo to verify your signature. The verification function will automatically locate your public key in John's machine and run all the signature-verification processes. If the verification succeeds, John will have a readable file that is identical to the file you sent. If the verification fails, John will receive an error message.

Entrust/Entelligence includes all the functions Entrust/Solo includes, but Entrust/Entelligence uses certificates to verify people's public keys. The product is a component of Entrust/PKI, a public key infrastructure (PKI) suite. PKI is a collection of public key technologies, including public key cryptography, CA, certificate management, related cryptographic applications, and security policies. (To learn more about PKI and its Microsoft implementation, see "Public Key Infrastructure in Windows 2000," January 1999.)

To use Entrust/Entelligence, you have to install Entrust/PKI in your network. You can use the CA function in Entrust/PKI to issue, publish, revoke, and renew certificates. Entrust/Entelligence installed in a client computer can find a particular user's certificate that the CA function publishes in a directory on the network, which eliminates the necessity of storing users' certificates locally. If you and John obtain certificates from the same CA or from CAs that trust each other in Entrust/PKI, you and John will trust each other and can find each other's certificate from the network directory. After John verifies your signature in the document you send to him, Entrust/Entelligence in his computer automatically locates your certificate in the network directory and checks its status in the CRL. Entrust/Entelligence also lets you import certificates issued by some other CAs into your address book. Entrust/Entelligence can locate a certificate in your local address book, even if that certificate is not in the directory. In addition, you can export your certificate to a certificate file to send to users outside your CA domain.

Entrust/Entelligence in Entrust/PKI for Windows NT and Windows 95 provides a time-stamp option. The Entrust/Time Stamp service running on an NT server can time stamp documents and verify a time stamp.

Commercial digital signature software should meet most of your requirements. However, sometimes you might need a special-purpose digital signature function built into your custom application. For example, you might want to sign a message in a Microsoft Message Queue Server (MSMQ) application. PKI vendors, including Baltimore Technologies, Entrust Technologies, and Microsoft, provide APIs to let you develop cryptographic applications. To sign the e-commerce document in Ireland in 1998, President Clinton and Prime Minister Ahern used a special-purpose Baltimore Technologies digital signature application to digitally sign the intergovernmental document, using their smartcard-secured private keys.

Delivering Digital Signature Technology with PKI
Before you deliver a digital signature solution for your company's e-commerce transactions, you need to decide which public key trust model fits your business and applications. If you implement digital signatures for a small, designated group of people and your company has no intention to implement a PKI infrastructure over the short term, products that follow the direct trust model (e.g., Entrust/Solo, SynCrypt) are suitable for you. However, if you conduct e-commerce in a public environment (e.g., over the Internet), you need a product that falls under the third-party trust model. If you have not implemented PKI in your company, digital signature technology following the third-party trust model can be a killer application that drives you to support other certificate-enabled applications such as encryption, Secure Sockets Layer (SSL) Web communication, and smartcard logon. Implementing a PKI infrastructure is not an easy task. You need to carefully plan your project and examine vendor solutions. Here are some basic questions to ask yourself or vendors you evaluate, as you plan your PKI and digital signature solution.

Outsource or in-source? You can outsource your PKI and certificate management through a public CA. The public CA will handle certificate management for your company, and you won't need to host and maintain an in-house CA system. However, you will lose the ownership of your certificates and pay a fee for each certificate the CA issues to your company.

As an alternative to contracting a third-party CA, several software companies offer commercial CA products and comprehensive PKI solutions. Some examples are Baltimore Technologies' UniCERT, Entrust Technologies' Entrust/PKI, Microsoft's Certificate Server, and Netscape's Certificate Server. Using these products, you can build a CA system to issue and manage certificates and establish CA trust relationships with your business partners.

A recent study by Giga Information Group, an information technology advisory company, compared the costs of different application scenarios using Entrust Technologies and VeriSign. According to the report (available at Entrust Technologies' Web site), implementing a solution using a commercial PKI product is cheaper than outsourcing CA services.

Which PKI vendor? If you implement PKI, you need to decide which PKI solution to use. Microsoft includes Certificate Server 1.0 in Internet Information Server (IIS) 4.0 and will deliver a comprehensive CA service in Windows 2000 (Win2K—formerly NT 5.0). Microsoft supports digital signature and encryption in Outlook email but does not implement digital signature technology for files; however, Win2K will include Encrypting File System (EFS). You can develop digital signature functionality for your files and base it on your application requirements by using Microsoft's CryptoAPI.

Entrust Technologies is a strong Microsoft competitor. Entrust Technologies has been developing PKI products for many years and has a substantial presence in large companies. Entrust/PKI running on multiple platforms offers a complete PKI solution. And there are other vendors from which to choose. The decision you make should reflect your technical requirements and business strategy.

Which directories? A CA publishes its issued certificates in a directory. For example, Microsoft's Certificate Server in Win2K publishes certificates in Active Directory (AD). Netscape's Certificate Server publishes certificates in Directory Server. Baltimore UniCERT can publish certificates in any X.500 directory, such as ISOCOR GDS. Entrust/PKI can publish certificates in its directory, Entrust/Directory; in an X.500 directory, such as an ICL i500 directory; or in a Lightweight Directory Access Protocol (LDAP) directory, such as Netscape Directory Server. Entrust Technologies is working with Novell to incorporate Entrust/PKI into Novell Directory Services (NDS). If you are planning an enterprise certificate directory or meta-directory, your PKI implementation will affect your enterprise directory choice.

Which CA trust relationship? When you practice e-commerce with your business partners, your CA and your partners' CAs need to establish a trust relationship so users in different companies can trust one another. Today, two trust-relationship models exist: hierarchy certification and cross-certification. In hierarchy certification, partner companies trust a common root CA, which signs the companies' CA certificates. In cross-certification, partner companies certify and sign one another's CA certificates. If you have many business partners, cross-certification will become very complicated. Today, Microsoft's Certificate Server supports only hierarchy certification; Entrust/PKI supports hierarchy and cross-certification.

How about interoperability? No real interoperability exists today among different digital signature software products, except in standard Secure MIME (S/MIME) email. Don't expect to use one vendor's software to verify your business partner's signatures in files created by another vendor's software. For now, companies that want to use digital signature technology must use the same digital signature software that their business partners use.

What about government regulation? The US government doesn't regulate digital signature technology, but it does forbid exporting encryption larger than 56-bit. Be sure to examine the kinds of encryption the vendor you're evaluating supports.

No Falsification in E-Commerce
In September 1998, a group of hackers attacked the New York Times Web site and falsified its contents to retaliate against a Times writer for his reporting about the hackers. Had the New York Times applied digital signature technology to its Web contents, the newspaper would not have left its Web site open to sabotage. Digital signature technology is important for data integrity and authentication. When you implement digital signature technology and PKI, you greatly reduce the threat that forgery and document tampering pose to your e-commerce documentation.