Saturday, January 28, 2006
Monday, January 23, 2006
[Techie] How Does Public Key Encryption Work?
Your bank says all your online transactions are safe. They prove it by showing this little icon in your browser:
So how do they keep the information safe? The answer is something called Public Key Encryption. The details of how it's done can be very complex, but the concept behind it is surprisingly simple.
Imagine I go to the hardware store today and buy a padlock. It's the kind you might buy for your gym locker, but this one is just slightly different. It has two keys instead of one. And the way it's designed, if the padlock is locked with one of the keys, it can only be unlocked by the other, and vice versa. So, let's call the keys A and B. If I lock the padlock with A, I can only unlock it with B. If I lock it with B, I can only unlock it with A. If I lock the padlock with A, I can't even unlock it with A. It only works if both keys are used. This is the mechanism behind Public Key Encryption. The magic is in how it's implemented.
So, what could I do with this crazy lock? Well, one thing I could do is set up a secure mailbox. For example, I could keep key A and give key B to my colleague. Then if I ever wanted to pass a confidential note, I could put it in the mailbox and lock it with A. I'll know that only my colleague can open it, because only he has key B. He could send me a note the same way. One of the problems with this implementation is that I'm going to have to create a key pair for everyone that I want to have secure communication with. Another problem is that I can't ensure the integrity of key B. For all I know, my colleague has created 100 copies of key B and is leaving them in insecure locations all over the place. If someone else gets hold of key B, I have to buy a new lock and key pairs.
Authentication and One-Way Encryption
So how about this: I take key A (or key B, it doesn't really matter), and I put it in my pocket. That is now my private key. No one even gets to look at it except me. Then I make 100 copies of the other key (my public key) and give them out to all my work team. Now I have security in either direction, but not both:
- I can put information in my locker (say, this week's work assignments) and lock it with key A, then anyone on my team (with key B) can get into that locker and get the information. The receiver of the information can be assured that I am the one who put the information in the locker, since I'm the only dude with key A. This is a form of authentication.
- Working in the other direction, anyone on my team can put a private message for me in the locker and lock it with key B, knowing that I'm the only person who can unlock the padlock, since I'm the only guy with key A. In information security terms, this serves the same function as encryption, since the information cannot be seen by others from the time it's locked until the time I unlock it.
Two-Way Authentication and Encryption
Now imagine that I modify the locker so that it can be secured with two locks. Each of my colleagues has their own version of the fancy padlock and their own pair of keys. We all have our own private key and we all have copies of each other's public keys. Now, if I want secure, authenticated two-way communication with any of my colleagues, all I have to do is lock the locker with my private key and with their public key. I can be assured that no one can get to the information except the intended recipient, and the recipient can be assured that no one could have sent the information but me. In addition, we can both be assured that no one else was able to get to the information from the time the locker was locked to the time it was opened.
Now the only problem is scalability. What if my team consists of hundreds or thousands of people? Am I going to have to create a new copy of my public key every time I meet someone I want to share information with? How am I going to manage if someone loses their private key and has to re-create their key pair? What about if I lose my private key? Am I going to have to create a thousand new copies of my public key and run around handing them out?
How about this: What if there's a single person that everyone trusts who will take on the job of keeping everyone's public key in a central place?

Now all I have to do is go to the trusted keymaster (or Public Key Server) to get anyone else's public key. My private key is still my own responsibility, but now whenever I create a new one, I just have to give my new public key to the keymaster. A system which involves a number of encryption partners and a Public Key Server is referred to as a Public Key Infrastructure (PKI).
This is Public Key Encryption in a nutshell. Of course the devil is in the implementation details. Web servers use a form of Public Key Encryption called Secure Sockets Layer (SSL). Email encryption uses something called Pretty Good Privacy (PGP), among other things. Network encryption uses something called IPSec. Each of these technologies implements Public Key Encryption in a unique way and uses unique terminology to describe what are essentially the same functions.
Secure Sockets Layer (SSL)
That little lock icon at the bottom of your browser window indicates that you have connected to a server using SSL, that the server has been identified, and that your communications are being encrypted. SSL uses the term "certificate" instead of "key," but the function is pretty much the same. Your browser, when connecting to an SSL server, first connects to a "Certificate Authority" (CA) (the keymaster, or Public Key Server) to verify the server's identity before proceeding with the SSL encryption methods. You can view some of these CAs in Internet Explorer by clicking Tools -> Internet Options -> Content -> Certificates.
After verifying the server's certificate, the client uses that certificate to send an encrypted request to the server to agree how to encrypt the rest of the communication. This is kind of like using the locker in the earlier illustration to pass a secret decoder ring from one person to another. The locker is used as a rudimentary way to pass the information which is used to do the actual encryption.
However, notice that the first step is really a one-way encryption. The client gets a copy of the server's key (certificate), but the server doesn't have a copy of the client's certificate. So the first step is really only to authenticate the identity of the server and provide a brief window of encrypted communication to decide how the real two-way encryption will work. It's a subtle but important distinction.
Pretty Good Privacy (PGP)
PGP works almost exactly like the locker illustration, and was one of the first widely-implemented consumer-grade versions of Public Key Encryption. It was first released in the wild by a guy named Phil Zimmermann in 1991 and was free for anyone to use for a long, long time. It was considered so secure that the U.S. government labelled the technology a "munition" and made it against the law to export the software overseas. Eventually, the software was purchased by some company and now it's not free anymore. But the same technology is still out there for free, going by the name of GNU Privacy Guard (GPG) (get it?).
IPSec
IPSec is an implementation of Public Key Encryption that allows private networks to encrypt data that flies across an untrusted network (such as the Internet). For example, a company that has offices in New York and San Francisco may create an IPSec connection using their existing Internet connections rather than install a very expensive private connection. This technology works similar to the SSL technology in that the partners use their keys to decide how to encrypt their data. In this case, however, the initial communication is encrypted both ways, usually using a Certificate Authority (public or private). IPSec is becoming more widely used, since the Internet is increasingly reliable, ubiquitous, and cheap. IPSec is now built into Microsoft's operating systems for securing communication between hosts.
Links for further reading:
What is public-key encryption?
What is SSL?
How does SSL work?
PGP Corporation
What is IPSec?
IP Security protocol suite
Saturday, January 21, 2006
Why I Hate TV
So I'm lumbering through this book Foucault's Pendulum by Umberto Eco, which is pretty much way over my head most of the time, but there's a part where Belbo is explaining to Casaubon that there are basically four types of people in the world: cretins, fools, morons and lunatics. Belbo has explained cretins and fools, and Casaubon asks:
"What about the morons?"
"Ah. Morons never do the wrong thing. They get their reasoning wrong. Like the fellow who says all dogs are pets and all dogs bark, and cats are pets, too, and therefore cats bark. Or that all Athenians are mortal, and all the citizens of Piraeus are mortal, so all the citizens of Piraeus are Athenians."
"Which they are."
"Yes, but only accidentally. Morons will occasionally say something that's right, but they say it for the wrong reason."
"You mean it's okay to say something that's wrong as long as the reason is right."
"Of course. Why else go to the trouble of being a rational animal?"
"All great apes evolved from lower life forms, man evolved from lower life forms, therefore man is a great ape."
"Not bad. In such statements you suspect that something's wrong, but it takes work to show what and why. Morons are tricky. You can spot the fool right away (not to mention the cretin), but the moron reasons almost the way you do; the gap is infinitesimal. A moron is a master of paralogism. For an editor, it's bad news. It can take him an eternity to identify a moron. Plenty of morons' books are published, because they're convincing at first glance. An editor is not required to weed out the morons."
Later in the same conversation, Casaubon states one of the laws of syllogisms:
"Universal conclusions cannot be drawn from two particulars."
If only more people realized this, American cable television news would be that much more boring and relevant, and American society would be that much more peaceful and pleasant.
Friday, January 20, 2006
Thursday, January 19, 2006
Quote of the Day
"When I read about the evils of drinking, I gave up reading."
- Henny Youngman
[Spotted on a chalkboard placard propped outside a Brooklyn pub]
P.S. If any of my homies out there play Counter-Strike, I've been running a server for a couple of months now. If you're interested, shoot me an email from the contacts page and I'll send the details. If you don't know what Counter-Strike is, then
"you didn't read anything."
Wednesday, January 18, 2006
[Techie] FTP 'ls' Command Disconnects Session
Watch this:
C:\>ftp ftp.someserver.duh
Connected to ftp.someserver.duh.
220 FTP Service
User (ftp.someserver.duh:(none)): someuser
331 Password required for someuser.
Password: somepass
230 User someuser logged in.
ftp> ls
Connection closed by remote host.
The red parts are what I typed in. Now why would the simple 'ls' (list) command cause the server to kill the connection? Well, the answer has to do with the way the FTP protocol works and how it is affected by NAT. The short answer is this: An active mode client (such as the ftp.exe that comes with Windows) will probably not work if it connects to a server through a dumb NAT device. By dumb, I mean something other than an intelligent application proxy or a stateful inspection firewall.
For the long answer, let's start by looking at a packet trace of the conversation above:
The interesting part of the trace is the last two lines. This is the part where I typed "ls" at the command prompt. But see what the client did? Instead of sending an "ls" command, it sent a "port" command. This indicates that the client is running in active mode for file transfers. This means that, in addition to connecting to the server on the TCP control connection (port 21), the client opens a listening port for the transfer and tells the server to actively push the data to that open port on the client side. This may sound confusing, so here's a step-by-step:
- The client connects to the server on port 21 (the control connection).
- The client opens a listening port on the local side (the data connection), which is kind of a like a reverse of the client-server relationship.
- The client tells the server which port is the listening port using the "PORT" command.
- The server connects to the client according to the information in the "PORT" command.
- The client tells the server which files to push across the data connection.
Because an "ls" is actually an ascii (text) file transfer, the FTP client treats it just like any other file transfer.
Now here's the pickle: My client is behind a simple NAT router, which changes (hides) my client's IP address en route from me to the server. So the client is telling the server to connect on an IP address that the server sees as different from the address the client is connected to on the control port. This can fail for any number of reasons:
- The NAT device doesn't allow incoming connections, such as in a Hide NAT scenario. In this case, the server fails to connect back to the client on the data port.
- The FTP server sees the active mode request as an attempt to hijack the FTP session - a security threat. The FTP server kills the connection in response. This looks like what happened in the trace above, since the server immediately issued a TCP Reset (RST) packet as soon as it received the PORT command.
So how to resolve? A couple of ways. The easiest is to change the FTP client's transfer mode from active to passive. Passive mode FTP works the opposite of active mode. In passive mode, the client tells the server to open a listening port (
Another way to make this work is to upgrade to a more intelligent NAT device. Most modern firewalls actually use an application proxy or stateful inspection for FTP connections. In other words, they watch the FTP conversation and when they see the PORT command, they modify it on the fly and then dynamically open the firewall to allow the reverse connection on the client's data port. This is a more expensive option, obviously, but depending on the nature and number of connections, it may be worth it.
The final solution would be to complain to the FTP client software vendor that passive mode is an integral function of FTP and any client that doesn't support it is not complete. I'm sure Microsoft will immediately respond to that request, right?
Some related links:
FTP PASV mode
The FTP RFC (959)
Eh.
I don't know if I like this template. I'm sure I'll be moving things around a bit and I'll probably end up playing with a few more templates. Bear with me as the blogs goes through the larval stage.
I'll be posting random crap here. I've been looking for a place to dump some of the technical stuff I've been working on, but I'll give you clear warning if it's a technical post and if you're not into that kind of thing, just skip over it. Other than that, I'll blat out some book reviews, movie reviews, music reviews, and whatnot and what have you. Recent stuff includes:
- To Kill a Mockingbird (Finally got around to reading it)
- Proof (Wasn't so impressed)
- Madeleine Peyroux (Her Dylan cover is incredible)
Mo' later.








