Encryption and E-Commerce

5 November 1999
Without encryption, e-commerce is nearly impossible. When you buy something online and use a "secure server," this means that your private information is being encrypted before it's sent over the Internet. Similarly, when you do Internet banking, your bank uses encryption to make your private financial information unreadable to anyone, but your bank.

"Encryption" is a set of complex mathematical formulae that permit anyone transmitting electronic information to scramble the message so that only the intended recipient can decode and thus understand it.

Encryption is essential for e-commerce because e-commerce largely takes place over the Internet, which is an open network. As a practical matter, this means that somebody other than the intended recipient of your information can intercept it and read it. Encryption protects your credit card number and all other private information you send.

There are several ways to learn whether your browser is encrypting your information. For example, when you purchase something online using Netscape's browser, if the picture of a lock in the lower left-hand corner is in the locked position with a glow around it, you're using encryption. You can also look at the Internet address of where your browser is. If it starts with "https" instead of just "http," it means that you're using a secure server that uses encryption.

The Inner Workings of Encryption

The basic concept of how you encrypt information is simple. You use a computer program, which uses an encryption algorithm (essentially a mathematical equation). This algorithm or equation converts the intended data (confidential files, credit card number, etc.) into an encoded message using a key (think of the "key" as your password for decoding or deciphering the message). The result of the encryption process is that your plain text message comes out the other end unreadable because it looks like gibberish.

Encryption comes in two basic flavors. One uses a single key (or password) and the other uses dual keys.

With single key encryption, you use the key to encode information, which you then send to your intended recipient. Your recipient then uses this same key to decipher the encrypted message. This means that you have to share the secret key with the recipient. The biggest problem with this is that you need a secure way to share the key. This limits the usefulness of single key encryption in e-commerce because it's rarely practical to whisper the key into someone's ear when you're doing business online.

Dual key encryption is the fuel of e-commerce. With this system, you have two mathematically related keys at work.

One key is called your "public key" and the other key is called your "private key." Your public key is a key that you can and should announce to the world. You can post it on your website and put it in an ad in the New York Times if you like. It's not a secret.

When somebody wants to send you a confidential message that only you should read, they encrypt it using your public key. If you want to send your credit card number to ReputableMerchant.com, your browser might encrypt it using ReputableMerchant.com's public key.

The interesting part of this is that if a thief intercepts your credit card number over the Internet and tries to decode it using ReputableMerchant.com's public key, it won't work. The beauty of a dual key system is that the public key is a one-way key. It encrypts information, but it won't decrypt it. That's why it's not important for you to keep it a secret.

When ReputableMerchant.com is ready to read your credit card number, its software will use ReputableMerchant.com's private key to decrypt or decode the information. The private key is the key that must remain absolutely secret. It's the one that lets somebody read messages intended only for them that were encrypted using their public key.

The Politics of Encryption

While strong encryption is essential for e-commerce, the United States government has traditionally been a world leader in encouraging encryption controls around the world. It's used economic and political pressure on other countries to encourage them to adopt restrictive policies. The problem is that while encryption is good for e-commerce, it's also good for criminals and espionage. After all, it's more difficult to convict a bookie of bookmaking if the books are encrypted.

Recently, the Electronic Privacy Information Center (www.epic.org) did a survey on encryption laws in other countries. In commenting on domestic controls it said that, "Most countries do not restrict the domestic use of encryption by their citizens. Of the handful of countries around the world that do, few are democracies and most have strong authoritarian governments. The countries include Belarus, China, Israel, Kazakhstan, Pakistan, Russia, Singapore, Tunisia, Vietnam, and Venezuela. In many of those countries, the controls do not appear to be enforced."

In the United States, there aren't any restrictions on the manufacture, use, or sale of encryption technology within the country. We've treated exports quite differently.

Until the end of 1996, export of encryption technology was governed by the Arms Export Control Act, which was administered by the State Department. This meant that encryption software was considered "ammunition." If you wanted to export it, the same laws that regulated nuclear missiles and tanks regulated you.

Since then, there has been a trend toward liberalizing those export restrictions. It's a trend that culminated in a recent White House announcement that said that export controls would be largely eliminated. The change will greatly simplify the Commerce Department's complex licensing requirements for the export of encryption software.

A ban on exporting encryption technology to terrorist countries, Iran, Iraq, Libya, Syria, Sudan, North Korea and Cuba will remain.

This policy change finally recognizes that while we can limit export of strong encryption products from the United States, we can't change the fact that other countries already have strong encryption software. This policy only served to hurt American companies that couldn't compete in the global marketplace with others who had and could sell strong encryption software.

The Law Enforcement Perspective

In an attempt to balance this liberalization of export controls with the concerns of law enforcement, the White House also announced that it would support legislation to do several things to help the police cope with strong encryption.

The first step is committing $80 million over four years for a research center to help law enforcement agencies learn how to crack encryption.

This legislation would also create a legal framework that would allow the police to have access to "back-doors" under certain conditions. These "back-doors" are basically spare keys that the police can use to decode encrypted information. It goes without saying that the idea of a back door is especially controversial.

In addition, the proposed law would ensure that sensitive investigative techniques and industry trade secrets remain useful and secret by protecting them from forced disclosure in criminal and civil litigation. This essentially means that the police can decode your private information and not be compelled to explain how they did it. The alternative would appear to be that criminals would know too much about what code cracking capabilities the police had.

It all comes back to e-commerce requiring strong encryption. The Federal Government is finally getting this point and liberalizing its policies accordingly. Now we have to search for that fine balance between privacy and the need for the police to have access to proof of criminal activity. This debate is destined to go on for years.




Mark Grossman's "TechLaw" column appears in numerous publications. Mark Grossman has extensive experience as a speaker as well. If you would like him to speak before your group or corporate meeting, please call (305) 443-8180 for information.

You can find a TechLaw archive at: www.DeWittGrossman.com.

If you have any comments, please send them to MGrossman@DeWittGrossman.com.

Disclaimer: The advice given in the TechLaw column should not be considered legal advice. This newsletter only provides general educational information. You must never rely upon the advice given here. Your individual situation may not fit the generalizations discussed. Only your attorney can evaluate your individual situation and give you advice.

Except as provided below, you may feel free to forward, distribute and copy the TechLaw column if you distribute and copy it without any changes and you include all headers and other identifying information. You may not copy it to a Web site.