Written as an addendum to Minting Cybermoney: Jobs, Electronic Commerce, and Opportunity for Vermont, by S.D. Shepard and G.C. Kessler, published in conjunction with the Vermont Business Roundtable. It is also offered in support of H.609, Uniform Electronic Transactions, introduced in the Vermont House of Representatives on Jan. 6, 2000.
There are several differences between commerce in the real world and in the cyber world, and perhaps one of the most fundamental is that of trust. When Alice walks into a store to purchase goods, she presents herself and her payment method to Bob, the storeowner.1 Repeat business is rewarded by less hassle and fewer questions when Alice uses a personal check. Even mail order houses will learn more about Alice as she places more orders.
In cyberspace, however, both the customer and the vendor have difficulty proving their identity to each other with certainty, particularly during a first transaction. How does the buyer securely transmit sensitive information to the seller? How does the seller know that this is a legitimate purchase order? How do both parties know that a nefarious third-party hasn't copied and/or altered the transaction information?
These questions, and others, describe the problems affecting commercial transactions over the Internet, or any public network. Customers (clients) need to be sure that:
Vendors (servers), on the other side of the transaction, need to be sure that:
All of the concerns listed above can be resolved using some combination of cryptographic methods. But cryptography by itself is not enough; we still have the issue of trust as it applies to sharing and managing the keys we needs for cryptography to work. The solution to this problem is to use certificates.
The cryptographic algorithms and protocols to perform the functions necessary for secure electronic commerce (e-commerce) have existed, and have been employed, for many years. What is needed specifically for Internet-based e-commerce is the end-to-end infrastructure to support secure and trusted communication. The sections below will describe the interrelated topics of cryptography (in particular, secret key and public key cryptography), certificates, and trust.
A Brief Review of Cryptography
Cryptography -- the art of secret writing -- is an ancient art, probably dating back to when people first started writing. There are many ways in which to perform cryptography, but this section will concentrate on only two general methods: secret key cryptography (SKC) and public-key cryptography (PKC).
Secret key cryptography
Secret key cryptography is the oldest type of method in which to write things in secret. As children, most of us played with some form of SKC when we exchanged secret notes with our friends using alphabet substitution -- i.e., an A would be represented by a T, B with a K, C with a D, etc., so that the word CAB would be encrypted as TDB.
Alphabet substitution is an example of SKC and demonstrates the primary use of this type of encryption; namely, privacy (or confidentiality). in SKC, both sender and receiver share the secret key; in this case, the secret is the relationship between the plaintext characters (A, B, C, ...) and ciphertext characters (T, K, D, ...).
The secret key encryption schemes used with today's digital computers, of course, are far more complex than alphabet substitution. The most widely used SKC scheme today is called the Data Encryption Standard (DES, pronounced "dezz"). DES employs a 56-bit secret key and a series of permutations to transform a block of plaintext into ciphertext.
In SKC schemes, size does matter and the length of the secret key is significant. A 56-bit key means that there are 256 (over 70 quadrillion) possible key choices. Assuming that the cryptographic algorithm is solid, a large size key means that there are too many possible key choices for an attacker to possibly guess the correct key in a reasonable amount of time.2
In fact, DES uses a solid cryptographic algorithm and the proof of this is the fact that it has withstood the test of time (it is still in use 22 years after development) and many other SKC schemes use DES-like procedures. In addition, the U.S. government has continuously insisted that a 56-bit key length is sufficient against key-guessing attacks. All of this changed in 1998, when a computer was built that could guess a DES key in an average of 4.5 days. So while DES is still used, alternatives are starting to be employed, such as Rivest Ciphers 2, 4, and 5 (RC2, RC4, and RC5), with key sizes up to 128 bits; Triple-DES (3DES), with a 168-bit key; and other schemes employing key sizes of 256 bits and larger.3
A major consideration with the actual use of DES and other SKC schemes is sharing the secret key between two communicating parties. Historically, armed guards and/or couriers could be employed to distribute the keys. In an Internet e-commerce environment, this distribution scheme is clearly nonviable; when Alice arrives at Bob's e-commerce site and is ready to buy something, she wants to buy it immediately and not have to wait a few days (or even hours) to exchange the SKC key.
Public-key cryptography
Public-key cryptography was developed to solve the secret-key distribution problem. PKC was first publicly described in 1976 by Stanford University professor Martin Hellman and graduate student Whitfield Diffie. The first implementation, designed by MIT mathematicians Ronald Rivest, Adi Shamir, and Leonard Adleman, came the following year. For obvious reasons, PKC is generally known as Diffie-Hellman and the most widespread PKC implementation today is called RSA.
PKC represents one of the most significant new developments in cryptography in, some say, several hundred years. PKC uses two different, but mathematically related, keys. One of the keys is used to encrypt the data and the second key is used to decrypt. It does not matter which key is employed first and, even more importantly, knowledge of one key cannot be used to derive the second key. What the Stanford and MIT teams were able to do was to find a mathematical way to build this system.
By way of analogy, consider this scenario of a secret way to read hidden text on a piece of paper. Suppose Alice and Bob use a scheme whereby the writing will only be recognizable if a particular color filter is placed over a paper that contains the "secret" writing. Suppose further that they employ two filters; color A and color B, where the "secret color" is the combination of A and B. When Alice and Bob want to read a document, each must apply their filter so that the writing becomes visible.
This system has three noteworthy characteristics:
The analogy above only demonstrates the power of having two separate keys. Even though the keys are mathematically related by a well-known formula, the calculations are sufficiently complex that an attacker doesn't have sufficient information with which to learn the value of the second key by knowing the first.
In RSA and other PKC schemes, then, Alice chooses a pair of keys. She then advertises one of the keys as widely as possible, calling this her Public Key. The second key remains a secret, which is called her Private Key. If Bob wants to send a message to Alice, he can encrypt the information using Alice's public key; only Alice will be able to decrypt the message using her private key. Alternatively, if Alice wants to send a message to Bob and prove that she sent it, she can "sign" it with her private key; when Bob decrypts the signature, he uses Alice's public key and, therefore, knows that only she could have encrypted this transmission.
PKC seems like a great idea for encrypting the data of e-commerce but, unfortunately, it is not. To encrypt a given block of data, PKC methods take about 1000 times longer than SKC methods. Thus, the primary application of PKC is to encrypt the secret key for the SKC method that will be used for the actual data encryption. So, for example, suppose Alice wants to send secret information to Bob encrypted using DES:
Certificates
In an e-commerce environment, a combination of SKC and PKC will be employed when customer Alice wants to make a secure purchase from vendor Bob. Getting Bob's public key is easy; it will be advertised. But how does Alice know that a site advertising Bob's public key is really representing Bob?
This is the role of a certificate. Certificates bind identity, authority, public key, and other information to a user. Certificates are digital documents, the credentials and bona fides in the cyber commercial world.
Certificates have many analogs in the real world. Consider Alice's SCUBA4 certification and Bob's driver's license:
Bob's license is also accepted outside of Vermont. In other states, a Vermont driver's license is accepted because all of the states in the U.S. have agreed to accept each other's licenses. Some countries outside of the U.S., such as Canada and Australia, also accept the Vermont driver's license for driving and identification. This is not because these other countries recognize Vermont, per se, but they do recognize that the U.S. has acceptable rules for issuing driver's licenses. This concept -- another country recognizing the U.S. rules which in turn recognize Vermont, as opposed to other countries having to recognize each state individually -- is known as the chain of trust.
This certificate concept extends to cyberspace. For most Internet e-commerce applications, certificates using a format defined in International Telecommunication Union Telecommunication Standardization Sector (ITU-T) Recommendation X.509 are employed. An X.509 certificate contains such information as the:
Certificate authorities (CAs) are repositories for public-keys and can be any agency that issues certificates. A company, for example, could issue certificates to its employees, a college or university to its students, a store to its customers, an Internet service provider to its users, or a government to its constituents.
Since a CA can be any agency that issues certificates, how does the receiver of a certificate really know that the sender is legitimate? That is, when Alice receives Bob's certificate, how does Alice know that Bob really is Bob and really is a bona fide vendor versus someone just saying that they're Bob? The answer to this is to look at the certificate issuer. Just like governments are (generally) trusted to issue money, some CAs are known, trusted issuers of certificates because of the procedures they take both in verifying the identity of certificate holders and in how they protect their private keys. Some of the better-known trusted (aka root) CAs are AT&T, BBN, Canada Post Corp., CommerceNet, GTE Cybertrust, Nortel EnTrust, the U.S. Postal Service, and VeriSign. Thus, when Alice gets Bob's certificate, she looks to see who issued it and that helps her determine whether she trusts the certificate or not.
In today's e-commerce environment, buyers may get personal certificates to prove their identity to a Web site but it is the vendor sites that really need to have certificates to prove their identity to buyers. It is Bob's certificate at www.bob.example.com that proves that this is the correct site to Alice; if Alice's payment method is valid, Bob is probably willing to believe that she is who she says she is even in the absence of a certificate.
An E-Commerce Transaction
To put all of these topics together, let's look at a sample e-commerce transaction as Alice visits Bob's web site to buy an item. The general flow of the visit, the purchase, and the secure transaction would run roughly as follows:
One last comment about certificates is necessary and that relates to the process by which Alice verifies the validity of Bob's certificate. Bob's X.509 certificate includes information about the certificate issuer (e.g., BBN, GTE CyberTrust, or VeriSign), including Bob-specific information encrypted with the issuer's private key. Alice merely decrypts that information using the issuer's public key to confirm that this certificate is, in fact, Bob's.
But from where does Alice obtain the root CA's public key? The answer is that it was probably shipped with her browser. The figure below shows the GTE CyberTrust certificate as included in Netscape Communicator. This browser is configured to accept the CyberTrust certificate to certify network sites, e-mail, or software downloads. Alice will accept as valid any certificate issued by GTE CyberTrust because it is signed by a root CA that she trusts (even if she doesn't know whether she can trust Bob).
Clearly, if CyberTrust's private key is lost, stolen, or otherwise compromised, every site that is guaranteed by their certificates are now suspect. In that eventuality, three events are sure to happen. First, CyberTrust's public key will be placed on their Certificate Revocation List (CRL). Any site that checks the CRL before using the key will see that it is invalid. Second, CyberTrust will widely announce the breach so that users can alter their browser configuration to not accept their certificates anymore. Third, in a very short period of time, CyberTrust will generate a new private key so that Netscape and the other browser vendors can distribute a new version of their browsers containing an updated CyberTrust certificate.
Summary
Cryptography is necessary for the success of e-commerce to ensure the privacy ad integrity of transactions and other communications, as well as to assure both parties that they are communicating with whom they think they are. Secret key cryptography is essential to keeping messages private, but a priori key exchange keys in the hit-and-run mode of Internet transactions would be impossible. Public key cryptography solves the key exchange problem by allowing the purchaser and vendor to exchange this information. But in the cyberworld, how do we verify the identity of those with whom we exchange public keys?
The answer to the last question is with certificates. Certificates provide not only the information with which to conduct secure electronic transactions, but also the additional information necessary to build the trust relationship between buyer and seller.
Readers must keep clear, by the way, the precise function of a certificate. Certificates provide proof of identity, not trust. A certificate is like a digital fingerprint, nothing more. My fingerprints prove that I am Gary Kessler; it is through our interpersonal relationship and business dealings that you determine whether I am honest and trustworthy.
Some Legal Issues
In June 1999, the U.S. Senate Committee on Commerce, Science, and Transportation approved the Millennium Digital Commerce Act, a bill specifically aimed at facilitating e-commerce by encouraging the use of digital signatures. One of the interesting aspects of this bill is that it was also designed to preempt state law (or lack thereof) to ensure that digital contracts in electronic form are as binding as written contracts on paper. This is, ostensibly, an interim measure until states enact uniform standards which are consistent with the federal Uniform Electronic Transactions Act (UETA).
And there lies the next challenge for e-commerce in the U.S. (and the rest of the world). Most of the states have not yet adopted laws that clearly define and/or protect digital signatures, certificates, and e-commerce. And the laws that have been passed vary greatly in detail and sophistication: Utah's law, for example, defines digital signatures, cryptography, and digital contracts in great detail, and even defines a legal framework for the development of a system of CAs; other states have digital signature legislation that allows a faxed signature (a digitized signature) to carry the same weight as an original, hand-written signature.
Laws governing digital signatures are necessary because:
A digital signature is a technical concept. The legal significance of a digital signature will depend on whether it constitutes a signature under the applicable law. Under current law, the legal effect of a digital signature would be determined by looking at the circumstances surrounding a transaction, including whether the party applying the digital signature intended to be legally bound. Although it is possible that a digital signature would be found to be a legally binding signature under either current common law or statute, the result is very uncertain.
"Digital Signature Legislation," M.S. Dorney
in Understanding Digital Signatures, G.L. Grant
But a law that makes a digital signature as binding as a written one is not sufficient. Once such a law is passed, the repositories of the certificates and the keys become a powerfully tempting target for cybercriminals and pedestrian hackers alike. Once digital signatures are accepted as the very core of electronic commerce, laws need to be in place to answer many questions, such as:6
Digital signature legislation must address these, and other, questions. As complex as the technology and mathematics appear, they are the relatively easy part of this equation.
ADDITIONAL INFORMATION
FOOTNOTES