|Academic Computing and Communications Center|
Some Practical Encryption Systems
We'll consider three:
|Security for Oncampus Services: Kerberos|
Kerberos is a secure authentication client/server system that works over a distributed,
insecure network. It was developed at MIT as part of Project Athena and is named
after the three-headed dog that guarded the gates of Hades. Kerberos is an identification
scheme, strictly limited to secure authentication, which means proving
who you are. (This is distinct from authorization, which is the
decision, based on your authenticated identity, whether to grant permission to
use a service.)
You use Kerberos when you need a remote service, from a file server or print server, for example, or just to log onto a remote machine. The Kerberos server maintains a secure database with lists of people and of available registered services, each with their own secret key or, to use a more familiar term, password. The Kerberos server acts as a trusted third party, verifying both your and the remote server's identity without anyone sending their password over the network. The Kerberos server also produces a shared, secret session key that you and the remote server can use to secure your communication during that session.
Let's say that you want to use a print server to print something. You send a request to the Kerberos server for a Kerberos ticket for that print server. The Kerberos server generates a session key for your service and then:
Because both parts of the Kerberos ticket are encrypted using your Kerberos password, only you - well, really only someone who has your password - can decrypt them. Decrypting the first part of the ticket gives you your copy of the session key; you keep that. Decrypting the second part of the ticket gives you the session key/identity string, which is still encrypted for the print server with the print server's secret password. You send that to the print server. After the print server decrypts the second part of the ticket with its secret password, both you and the print server will possess a shared secret - the session key. And the distribution process has ensured that both you and the print server are authenticated to each other. And now that the print server knows who you are, it decides on its own whether to accept or deny your request to print. But that's authorization, as I said before, a completely different story.
Kerberos uses a symmetric encryption scheme, usually DES, and relies on the fact that everyone knows where the central Kerberos server is and that everyone trusts it. If the central Kerberos database and server are reliable and secure, the system works well.
Return to Contents.
|Security for Email: Pretty Good Privacy (PGP)|
Standard Internet mail uses the Simple Mail Transport Protocol (SMTP) and has
no built in security. This is quite reasonable, given that there is no way to
know beforehand who to trust. But it's no good when you want to send sensitive
Enter Phil Zimmerman, author of Pretty Good Privacy, a.k.a. PGP, a shareware (for private use) program that uses an efficient and secure combination of symmetric and asymmetric encryption. For efficiency, the plaintext file or message is symmetrically encrypted using a randomly selected secret session key, and for security, the session key itself is encrypted separately with the public key of the person who will receive the file. Both the encrypted ciphertext and the encrypted session key are sent to the recipient. To recover the file, the recipient decrypts the session key with his or her private key, and then uses the session key to decrypt the ciphertext.
You can run PGP as a stand-alone program, encrypting a file before you attach it to an email message or even encrypting sensitive files on your personal computer. Or it can be integrated into email software, where its use is more straightforward. (For example, Phil Zimmerman's Pretty Good Privacy, Inc., distributes PGPmail, a plug-in application for Eudora for Windows95 and Netscape mail; see: http://www.pgp.com/products/PGPmail.cgi )
PGP's most important feature, besides being perhaps the most widely used privacy-enhanced mail program, is that it doesn't depend on trusted third parties (such as a Kerberos server). PGP assumes you already have the public keys of the people you correspond with. You get these public keys however you can - directly, from a friend, off a Web page, or with finger or ph or some other directory service. A public key is, after all, public, and people with public keys try to make them so.
But this is also a major weakness: can you trust the source of the public keys you use? If a friend uses PGP to send you his friend's public key, can you trust it? Probably so. But what if your friend's friend sends you one? It's up to you.
The PGP Saga:The full story of PGP involves legal problems with the US export laws (the Feds were so worried about encryption that they classified certain encryption schemes as munitions!) and patent problems with RSA, Inc. (which possibly explains why the RSA's FAQ on cryptography doesn't have much to say about PGP).
Check it out in a recent Forbes magazine article, "Banned in Washington," at: http://www.forbes.com/forbes/97/0421/5908162a.htm
|Security for Web Servers: Secure Sockets Layer (SSL)|
Have you ever considered buying something you find on a World Wide Web site? Should
you send your credit card number over the Web? Well, maybe, if: (1) you're sure
that you're talking to the right Web site and not one "spoofed" by a bad guy,
and (2) you're sure that no one can eavesdrop on the transmission. The first condition
is one-way authentication - your assurance that the remote site is legitimate;
the second is to provide an encrypted communications link for the transaction.
How can your Web browser assure you of this? Kerberos-style authentication won't work, because that would require both you and the Web site to be registered in the same (or cooperating) Kerberos database. Given the number of Web sites there are today, there's not much chance for that!
Netscape, in the business of selling Web technology, promoted Secure Sockets Layer, SSL, to solve this problem. SSL's security takes place at a very low network level and can be used to protect almost any type of transaction. But its largest use is with the Web, because SSL is now built into Netscape Navigator and Microsoft Internet Explorer.
SSL uses the public-key encryption, plus a certificate from a trusted third party to ensure the legitimate distribution of public keys. And for efficiency, once the bona-fides are established, a randomly chosen session key is exchanged between you and the Web site, for efficient symmetric encryption of the remainder of the transaction.
SSL works like this:
Is SSL secure? The technology, if implemented well, is sound. But who is this "trusted third party" who provided the original certificate? VeriSign and Thawte are two of the companies that currently provide this third party trust. Web server administrators purchase certificates for their Web services from these companies, which in turn promise to investigate all certificate purchases and to only issue certificates to the legitimate owners. If they do their job, and if you trust them, then all is well. Netscape and Microsoft trust some of the trusted third party companies enough that they include their public keys in Navigator and Internet Explorer. You can add additional public keys to your own copies of these programs if you find additional companies that you decide to trust.
Version 3 of SSL goes a step further: you purchase a certificate that your browser submits to the Web server on your behalf. This allows 2-way authentication, so the server can also know who you are.
SSL neatly circumvents Kerberos's problem that both the server and the client must be registered in the Kerberos database (or in two cooperating Kerberos database servers). But it does not circumvent the need to trust someone! Without that central Kerberos server or trusted third party certificate, you really don't know who you are talking to.
How can you tell when your using SSL? SSL URLs begin with https:// and there are small changes in the browser's display; Figure 1 gives some examples.
Comments are welcome; send them to:Return to Contents.
|The ADN Connection, March/April 1997||Previous: Coming Soon to a Code Near You||Next: Security for Web Service at UIC: Bluestem and Ness|