Last update: March 19, 2001

My name is Alan. I work at Branch Office where I have an account on its computer (bo.com). I also have an account on the computer thousands of miles away at Head Quarters (hq.com).

It's deceptively easy for me to copy a file from one place to the other. I just use the "copy" command.

Isn't that dangerous! Where's the security?
• People on any of the networks involved in the (say) dozen stops along the way between bo.com and hq.com could be listening in!
• My fellow employees at bo.com could be listening in!
• My fellow employees at hq.com could be listening in!

There's a lot that actually goes on. This document is intended to give you a peek into that.

The idea is that the data sent back and forth between the two computers is garbled up in such a way that it is unreadable to anyone but the intended recipient. The technique used is called Public Key Encryption.

Public key encryption might be more adaptly called "public/private" key encryption. The idea is that I freely (ie: publicly) make available to you the ability to encrypt data. What I don't relinquish is the ability to decrypt. That's private.

It's like a box with two keys: one to lock it (the public key), another to unlock it (the private key). Imagine my safety deposit box was constructed in such a manner. I have no problem in allowing you to put things into my safety deposit box. But I don't want to allow you to get things out of it. In this case, the "box" is a packet of data.

Let's look at a conversation between bo.com and hq.com in slow motion. We start at the point where bo.com has made a connection to hq.com Neither one trusts the other. Here's the conversation between the two as they go about deciding if they should trust each other.

In this conversation, whenever HQ talks to BO, it encrypts its messages using BO's public key. The assumption is that only BO will be able to decipher those messages using its private key which nobody else in the world knows about.

The same sort of thing happens whenever BO talks to HQ. It encrypts its messages using HQ's public key. The assumption is that only HQ will be able to decipher those messages using its private key which nobody else in the world knows about.

BO	Hello hq.com This is bo.com calling.
HQ	Oh ya? Prove it.
BO	OK. Here's my public key
HQ	HQ looks at its public key ring. It does find a public key on file that is associated with BO. It compares that public key against the public key that BO has just sent. They match. But HQ is still suspicious. Oh ya? I'm not convinced. Yes, I confirm that you've sent me BO's public key. But that key is, after all, "public." Anybody could get that key! I'm going to encrypt a number using that public key and send it to you. If you really are BO then only you will be able to decipher it. If you can, send it back to me!
BO	BO is confident that it will be able to decipher that number from HQ. But it too is suspicious. It thinks it's contacted HQ but it wants to know for sure. Fine. Go ahead. Send me that number. While you're at it, send me your public key. (I'm not sure I believe you either.)
HQ	OK smartie. Here's that number encrypted with your public key and here's my public key as well.
BO	BO looks at its public key ring. It does find a public key on file that is associated with HQ. It compares that public key against the public key that HQ has just sent. They match. But BO is still suspicious. I've deciphered your number. Here it is. I've encrypted it using your public key.
HQ	HQ receives that number back from BO. It decrypts it using its private key. It's the same number that it had sent to BO. Only BO could have successfully decrypted that number. HQ is now convinced that it's talking to BO. I believe you.
BO	HQ may be happy but now BO also wants to be convinced. It it really talking to HQ? Hold on a moment! You may believe me, but I don't yet believe you! I've also come up with my own number. And I've encrypted it using your public key. Now it's your turn. If you really are HQ, then only you will be able to decipher my number and send it back to me!
HQ	Fair enough. I've received your number which you encrypted using my public key. I've decrypted it. I'll prove it. I'll encrypt it using your public key and send it back to you.
BO	BO gets the message back from HQ. It decrypts it. It contains the same number that BO had earlier transmitted to HQ. Only HQ could have derived that number. HQ must really be HQ after all. OK. I too am now convinced. I believe you too. Let's move on.
HQ	Agreed. Now that I, HQ know that you are BO, and vice-versa, we can proceed to the next step. Tell me, what user at BO wants to be authorized as what user here at HQ?
BO	User alan here at BO wants access to you under the name cohen there at HQ.

Believe it or not, we're about the repeat almost the same sort of thing all over again. This time, however, it won't be BO that needs to be convinced of HQ's legitimacy and vice-versa.

This time, it will be the specific user alan at BO that wants to be authenticated as cohen at HQ

It's not quite as much as the first go around.
This time, it's only HQ that needs to be convinced that it should allow somebody to gain access as cohen at HQ

The same sort of dialogue will ensue, but on a different level. Originally, it was the BO system as a whole that was legitimizing itself to HQ and vice-versa.

The BO system's private key was readable only by BO's root.
The HQ system's private key was readable only by HQ's root.

We are already engaged in a secure transmission. All that remains is for alan to login to the HQ system as user cohen. It could be done in the normal login fashion, ie: alan supplies a username for cohen and his password on the HQ machine.

However we can go a step further, providing just as much security without requiring alan to manually type a username and password for HQ.

In this second phase, we repeat the same sort of thing but instead use the public keys for alan at BO and cohen at HQ. If that exchange succeeds, it won't even be necessary for alan to engage in any manual intervention.

Alan's private key is readable only by user alan at BO.
Cohen's private key is readable only by user cohen at HQ.

It's true that this process of switching back and forth between keys is hard work. Once both parties are comfortable with each other, they can make things a little bit easier while still ensuring effective encryption and decryption.

Remember all those randomly generated numbers that each machine was using to challenge the other?

HQ	Now that we're both convinced, let's combine your numbers and my numbers and derive a new key which we can both use for encrypting and decrypting the rest of our conversation.
BO

The obvious Achilles heal in this scenario are the "private keys".
Are they really private? Perhaps they are today. Will they be tomorrow?

Less obvious are issues regarding public keys.
In our example, when HQ was contacted by BO, it consulted its "key rings" to see what, if any, public key it had on file as associated with BO. How did that information get into the key rings in the first place?

• HQ had to be convinced that BO was really BO
• BO had to be convinced that HQ was really HQ
• HQ had to be convinced that it was alan at BO who wished to be privileged to take on the identity of cohen at HQ
• It's not a perfect world. Take nothing for granted. Is it secure? Well... maybe.