Protecting Widget Data: A Primer on Public-Key CryptographySkip other details (including permanent urls, DOI, citation information)
This work is protected by copyright and may be linked to without seeking permission. Permission must be received for subsequent distribution in print or electronically. Please contact email@example.com for more information. :
For more information, read Michigan Publishing's access and usage policy.
Cryptography, the stuff of spy movies and dramatic World War II victories, is also important to electronic publishing. It is the basic way electronic publishers protect their information from unauthorized reproduction. Simple encryption systems can keep legitimate readers from casually sending your copyrighted material to a hundred of their closest friends by e-mail. However, even the most sophisticated encryption cannot protect your copyrighted material from being reproduced by a determined, professional counterfeiter.
It is certainly easy to use modern encryption techniques to require users to pay to access your material; however, if they can then copy it and distribute it freely, then you will not be paid for every use, but merely for the first one. This means that one obvious use for on-line publishing is in specialized reference libraries, which are very large and constantly changing. The unauthorized reproduction of any one article in such a large collection is not a major problem; subscribers pay for the right to access the entire library. It would be prohibitively expensive for a counterfeiter to steal the entire library and keep it up-to-date, as they would need to pay to acquire every article. Not only is this sort of library protected by its very nature against data theft, but the speed of production and distribution in electronic publishing is an asset. Subscribers also want these storehouses of information to have as much indexing and cross-referencing as possible, again a clear win for electronic media. This niche for electronic publishing is already being exploited.
The techniques of modern electronic commerce, all based on cryptography, make possible a wide range of tools to control access to publications from newsletters to vast and complex online libraries. Cryptographic tools can give both publishers and their customers a level of availability, flexibility, and control beyond anything possible outside the electronic world.
Passwords and Pitfalls
Suppose that Bob's Press publishes all the information about widgets. There's a lot to know about widgets, and it changes daily. The employees of Acme Widgets Inc. need access to the most up-to-date information. Naturally, Acme subscribes to Bob's online library of widget information.
How might the subscription work? Technologically, the most simple way to control access is to allow anyone coming from an acme.com address to connect to the widget library. Many reference works, including the Encyclopedia Britanica and the Oxford English Dictionary, are currently available on the Web using that kind of site-license technology. However, as scholarly electronic publishers know, site licenses cannot precisely measure who uses the information; they are workable but often unsatisfactory solutions that trade imprecision for low maintenance cost.
If Bob wants to charge per use, instead of a blanket subscription fee, then Acme has no way of controlling who is and who is not allowed to use the service, nor of billing individual people or departments for their use, unless Bob gets into the accounting business. Bob could, of course, maintain a list of authorized users — say, by making people identify themselves with a name and password. Now Bob now has to maintain a complete list of who at Acme is allowed to use the library, adding and removing Acme employees as they move between departments or get hired or fired.
Acme employees also don't want to remember a password for each of the twenty reference sources they use. Half of them either have their password scribbled on a piece of paper stuck to the side of their computer or use the name of their cat. Any disgruntled ex-Acme employee probably knows half a dozen passwords that will keep charging to Acme's bill, and any malicious hacker can probably figure out someone's password in a weekend.
The Tools of the Trade
The cornerstone of modern cryptography — and the answer to Bob's and Acme's problem — is the public-key system. To understand its wonders, we need to contrast it with traditional cryptographic approaches.
A traditional (private-key) system can be thought of as a box with a lock and key. If Bob's Press wants to give information to Acme and keep someone else from stealing it along the way, Bob can put it in a box and lock it with his key, and the kid in the mail room at Acme just needs another copy of the key to unlock it at the other end.
That is a fine method for sharing information without someone stealing it, as long Bob can make a pair of matching keys for each of his customers and has a way to give one key to Alice Acme (the president of Acme Inc.) in the first place. Research into private-key systems is dedicated to making the box very strong and the lock hard to pick. Systems exist today in which the box is so strong that the only way in is through the lock, and the lock is so good that the only way to open it is with a key: An attacker might as well just try every key in the world to find one that works.
A public-key system differs in a subtle but important way. For this type of cryptography, we again have a box with a lock on it. But now the lock has two keys, labeled L and R. When you stick one into the lock, you can only turn it one click to the left; when you use the other, you can turn only to the right. The lock will only open in its original position: each turn left has to be canceled by a turn right or the box stays closed. (For one example of a public-key system, check PGP, Pretty Good Privacy, distributed free by the Massachusetts Institute of Technology to U.S. and Canadian citizens in their respective countries.)
Amazingly, if you have the L key, you can't turn the lock to the right: just because you can put something in this box doesn't mean you can take it back out again. Moreover, even if you have the L key, no locksmith can figure out what the corresponding R key looks like. The L and R keys have to be built at the same time, when the lock is first made.
There are some clear ways Bob's Press and Acme could use a public-key system to make their lives easier. Acme's staff locksmith could make such a box, and mail the L key to Bob. To send things to Acme, Bob just locks it in the box with his L key, and only the R key at Acme can get it out. The advantage over the earlier version is that it doesn't matter if other people see what Bob's L key looks like when Acme mails it to him: copying the L key won't let them steal anything.
"Even if Bob makes some articles available free, he can benefit from this technology"
Better yet, if Acme wants to order something from Bob, they can lock the order inside the box using the R key. Then Bob can unlock it and read the order (and so can anyone else who stole the L key, of course). But when he gets the order, Bob knows for sure that it really came from Acme: if his L key unlocks it, then Acme's R key must have locked it first! Bob likes this much more than asking Alice Acme for her mother's maiden name when he want to verify that the order really came from her, since no one can overhear her answer. Locking something using the R key is effectively Acme's signature: Bob can read the thing that was signed and can be confident that he knows who sent it.
Now, how do these tools make Acme's subscription to the electronic publications from Bob's Press work better? First of all, they enable Acme to maintain and control the database of who is allowed access to Bob's Press. If Carol wants to get some information, she lets Alice know. Alice approves the request, and signs her approval by locking it in box with her R key. Now Carol passes her request on to Bob, who unlocks the box with the L key, and checks that Alice has approved it. He can the send out the information and bill it to Acme's account. He knows Acme approved it, so he doesn't have to worry that some unauthorized person stole the access to Acme's account.
While the public-key system sounds like it could be a pain to deal with, it can really be automated easily. Acme's box with its special R key is, of course, all on the computer, and in fact the ability to sign messages in this way is already built in to most Web browsers (see Netscape's security page for some fairly technical information). Carol can just go off to www.bobspress.com, and enter her search. Her browser automatically gets in touch with Alice's machine, which approves requests. Assuming everything is legitimate, Alice's machine can automatically approve the request, and a second or so later, Carol has the information on her desktop.
One nice thing about this system is that Alice has approved exactly the request that Carol sent to her. Carol, no matter how clever and unscrupulous she is, cannot send off a request for some cheap little bit of information, get it approved, and then modify the approved request by adding on some very expensive item: Alice put the entire request into a locked box that Carol can't open. Similarly, any eavesdroppers or hackers can only see this one request. They can't use that information to order something on their own and charge it to Acme's account. Even a dishonest employee at Bob's Press would be unable to forge a request from Acme. This ability to sign a message, and to make it clear as part of the signature exactly what message is being signed, is one of the great breakthroughs made possible by public-key cryptography.
Of course, Acme has to decide how to approve or deny requests from its employees. Alice could decide to simply approve any request coming from one of Acme's machines, or from the account of one of her employees. However, that's really not a lot more secure for Acme than the password system described above, unless they have a secure way of protecting access to their machines. Alternatively, Acme could issue a lockbox and a key-pair to every employee. Then Carol has to sign her request to Alice. Alice (or her machine) reads the request, checks that it really came from Carol and that Carol is authorized to use the system, and sends along the approval. Bob doesn't care what system Acme uses; as long as he gets the signed request, he knows that he'll get paid if he sends the information out.
Even if Bob makes some articles available free, he can benefit from this technology, by preventing other people from stealing his good name. The articles that he publishes can be signed by him, in an unforgeable manner, just as Alice is signing her request to Bob. No one else could write an article and make it appear that Bob had agreed to publish it. Anyone who saw an article purportedly signed by Bob could easily check the signature by trying to "open" it with Bob's public key. If the article were a fake, the key wouldn't work.
Anatomy of a Lockbox
Fundamentally, lockboxes are mathematically chosen numbers. It is up to Acme to decide how to protect them. The keys could simply be stored as data on each person's computer. That's not a very secure method, as Acme needs to worry about controlling access to the computers, but it's certainly sufficient for many uses. Another drawback is that it's not very portable; if Carol is traveling, she may not be able to get through to Bob's Press because she can't sign her request. Her key is back on her desk computer.
If Acme is more concerned about security or about portability, it can issue the keys on Smart Cards to every employee who needs one — in fact, the Smart Card could be the same as the employee card. Smart Cards (or similar technology from other companies) look exactly like credit cards, except that they have a computer chip instead of a magnetic strip. Smart Card readers that connect to the computer are fairly inexpensive and quite small. The information on a card is as secure as the card itself. Alice doesn't have to worry that someone will break into her account, or discover her password, and start approving unauthorized requests. Carol can't just lend her account to a friend who is thinking of getting into the widget business. If she quits or is fired, then as soon as Acme gets her card back, she can no longer use the system at all.
Of course, none of that concerns Bob directly; as long as he's got the approved request, he's happy. He is, however, certainly better off knowing that there is a fairly high amount of security available to his customers. As long as his system is set up correctly — and there is simple, widely available software available to automate the entire process — Acme can't come complaining to him if it finds what it thinks are unauthorized charges on its bill. If it does, he can show the company his records, which prove that Acme authorized it. The company can check as well as he can that their system really did approve the request, in an unforgeable manner. Only the person with the special R key can sign the request, and Alice is the only person who has access to that key. Thus Bob can prove that the problem is on Acme's end, and not on his.
Public-key systems have many more applications than just this ordering method. They can be used very effectively to encrypt correspondences; in fact, every time you order something with a credit card over the net, your transaction is encrypted with such a system. Once you start thinking of applications for a secure electronic signature, it is hard to stop; the ramifications are vast enough that many people in the security and computer industries are fairly sure that public-key systems will be ubiquitous in the near future. Visa and MasterCard have already designed a system, SET [formerly http://www-s2.visa.com/av/news/PRmisc090198.vhtml], which will enable you to securely sign a credit card transaction in such a way that no one can steal your credit card number and charge something to your account. This article describes only one of many ways in which modern cryptography can, almost transparently, make possible secure, verifiable transactions over the Internet.
Jessica Polito received her Ph.D. in Mathematics from the University of California at Berkeley in 1998. Her dissertation was in the field of Number Theory, a branch of mathematics widely regarded as having no applications outside of the math world until it suddenly turned out to be the cornerstone of most modern cryptography. Jessica now lives in the Boston area, teaching math at Tufts University when not at home with her son Daniel, age 4 1/2 months. She can be reached at firstname.lastname@example.org.
PGP, Pretty Good Privacy, http://web.mit.edu/network/pgp.html
Visa and MasterCard's SET, [formerly http://www-s2.visa.com/av/news/PRmisc090198.vhtml].
Smart Cards, http://www.smart-card.com
Netscape's security page, http://browser.netscape.com/ns8/security/default.jsp
Jessica Polito may be reached by e-mail at email@example.com.