This content is no longer maintained. Please visit our new website.

ACCC Home Page Academic Computing and Communications Center  
Accounts / Passwords Email Labs / Classrooms Telecom Network Security Software Computing and Network Services Education / Teaching Getting Help
The ADN Connection, March/April 1997 The A3C Connection
March/April 1997 Contents Coming Soon to a Code Near You Some Practical Encryption Systems Security for Web Service at UIC: Bluestem and Ness Domains and Auth Methods in Bluestem Introducing Network Operations About the ADN Connection

Some Practical Encryption Systems

News and Reviews

We'll consider three:

  • Kerberos, for client/server authentication;
  • PGP, for privacy and digital signatures in email; and
  • SSL, for authenticating Web servers and for encrypting communications with a Web server.
All of these systems can be used in other ways, and each has competitors. The following descriptions only give you their flavor. Not surprisingly, their actual implementation is significantly more involved.
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:

  1. It encrypts the session key using your personal password (which it finds in its identity-password tables, based on who you said you were).
  2. It encrypts the session key along with your name, twice: first using the print server's secret password (again from its tables), and then encrypting the result a second time using your password.
The Kerberos server sends these two encrypted items back to you as your initial Kerberos ticket. (I've left out a few details for clarity.)

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 messages.

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: )

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:

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:

  1. Your browser contacts the Web server, which sends you back its certificate, which has been encrypted with the trusted third party's private key.
  2. Since you know the trusted third party's public key, your browser decrypts the certificate it received from the Web Server with it. Successful decryption means that the certificate was originally encrypted by the third party, whom you trust.
  3. Inside the certificate is a description of who the Web server you're contacting really belongs to, along with the Web server's public key. (Your browser will let you look at the certificate if you want.) Your browser uses this public key to encrypt a session key, which it sends back to the Web server.
  4. The server receives your request, and of course it is the only possessor of its private key, so only the legitimate server can decrypt the session key you just sent it.
At this point, your browser and the Web server, which you now know is legitimate, share a session key, which you can now use to encrypt further communications.

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:
Bog Goldstein,
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

UIC Home Page Search UIC Pages Contact UIC