Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!athena.mit.edu!dla From: dla@athena.mit.edu (Don Alvarez) Newsgroups: comp.protocols.tcp-ip Subject: Re: RSA Encryption on the Internet Summary: it's the key distribution that counts Keywords: RSA, Encryption, Public Key Message-ID: <10061@bloom-beacon.MIT.EDU> Date: 23 Mar 89 23:43:25 GMT References: <8903222040.AA03642@braden.isi.edu> Sender: daemon@bloom-beacon.MIT.EDU Reply-To: boomer@space.mit.edu (Don Alvarez) Organization: Massachusetts Institute of Technology Lines: 78 The most important part of any public-key system is the key distribution method. I can "break" any public key encryption scheme, no matter how robust the algorithm, if you aren't sufficiently careful about distributing the public keys. Consider the case of secure communications between your workstation and a file server which is located on another machine. Suppose that you have never used this file server before (not a critical assumption, but it makes the argument simpler). You call up some kind of directory service to get the public key for that file server. Lets assume that it is a perfect world, and that you are rightly confident that only one machine on the net knows the private counterpart to that key, and also rightly confident that the algorithm is unbreakable. You now enter into a communication with the file server using the public key that the directory service has told you belongs to the file server to get your private data. No other machine can read what you and the file server say to each other, so you are "safe", right? Wrong. All you know is that only one machine can read what you say. You don't as yet have any way to know that you are really talking to *your* file server. You don't even know that you are talking to a file server at all. Suppose I got on the net and started masquerading as the directory service. You say "what's the public key of FOOBAR fileserver?" My fraudulent directory server intercepts the request and gives you a different public key. The private counterpart to the public key you just received is known to a confederate of mine. You send your request to (what you believe to be) the file server encrypted in that public key, along with any info needed to authenticate yourself to the file server. The confederate then calls the "real" directory server, gets the "real" public key of the "real" file server, and passes the request on to it. The file server then calls the "directory service" to find *your* public key, so that it can encrypt any files it needs to send to you. That request gets intercepted too, and now the file server sends your data out encrypted in a key which no one but my confederate can read. The confederate decrypts whatever the real fileserver sends back, copies it, and then sends it on to you reencrypted this time in your true private key. Your communications have just been completely penetrated, and I never broke a single code. The info posted to this group has implied that keys need to be registered with some central body. Presumably what happens is that the central body encrypts your name into the public half of your key in some way when it is created. Then whenever someone gives you a public key, you can run the key through a black box and out will pop the name of the party registered as owning the private component of the key. I would argue that if that is what is done, it is probably not as effective a solution as I would have liked (a large organization will probably end up with zillions of keys whose owners have names like FOOBAR_INC:this_machine and FOOBAR_INC:that_machine. If you don't know what machine your service resides on (suppose many machines can offer the service, or something similar), I could misappropriate any valid FOOBAR_INC key any publish it as the key for the other server I want to penetrate). As I say, I don't know if that is how it works or not. If it is, I'd argue that it is very much not the final solution, but it is at least a decent starting point. One thing I will say is that I am VERY heartened to discover that the committee which picked this scheme is chaired by Stephen Kent. I've never met him, but anybody interested in topics like this should DEFINITELY check out the article he and Victor Voydock wrote in Computing Surveys, Vol. 15, No. 2, June 1983 (Computing Surveys may be filed under Assoc. of Computing Machinery in your library). The article is about forty pages long, readable by the layman, and in my opinion is probably the best thing ever written on the subject of network security. It's a survey article, and the title is "Security Mechanisms in High-Level Network Protocols". So, in short, I'd say that the most important technical question to be asked is how do you know that you can trust the public key you are given. I don't know the answer, but the presence of Mr. Kent's name on the committee makes me think that there will probably be some good way to do so. - Don Alvarez + ----------------------------------------------------------- + | Don Alvarez MIT Center For Space Research | | boomer@SPACE.MIT.EDU 77 Massachusetts Ave 37-618 | | (617) 253-7457 Cambridge, MA 02139 | + ----------------------------------------------------------- +