Path: utzoo!attcan!uunet!mailrus!accuvax.nwu.edu!nucsrl!telecom-request From: boomer@athena.princeton.edu (Don Alvarez) Newsgroups: comp.dcom.telecom Subject: Re: BAD Digital Cellular Standard Under Development Message-ID: <8394@accuvax.nwu.edu> Date: 29 May 90 15:42:19 GMT Sender: news@accuvax.nwu.edu Reply-To: Don Alvarez Organization: Princeton University Lines: 84 Approved: Telecom@eecs.nwu.edu X-Submissions-To: telecom@eecs.nwu.edu X-Administrivia-To: telecom-request@eecs.nwu.edu X-Telecom-Digest: Volume 10, Issue 395, Message 2 of 9 In article <8372@accuvax.nwu.edu> gnu@toad.com (John Gilmore) writes: >So far nobody is claiming that the privacy of IS 54's digital cellular >system is really great, just that it's slightly better than analog >cellular. What burns me is that they could have made it *really >great* with relatively trivial spec and software changes (encryption) >but didn't bother. (Yes, the changes are "relatively" trivial if you >examine the protocol they are running here.) I have no idea what protocol they are running, but I do know that creating a system that allows for secure and trusted communications between large numbers of remote devices is never trivial. Providing *encrypted* communications is trivial (rec.funny readers use rot-13 "encryption" all the time, for example) , but providing *secure* and *trusted* communications is. Secure communications mean that only the sender and the intended recipient can read (or in this case listen to) the communication. Trusted communications add caveats that one can detect interuption of service, replay or delay of messages, etc. The important point for a cellular phone link is that encrypted does not mean secure. If you and I wanted to exchange encrypted mail over the internet, we'd have to first agree on and somehow exchange our encryption key without anyone else discovering it for it to be secure. The same is true for cellular phones, only there the key exchange has to be automatic and transparent to the user. How do your phone and my phone agree upon and exchange an encryption key without allowing eavesdroppers to pick up the key? We can't just use public key encryption techniques, because of the following senario: A wants to call B. A says "I need B's public key". C hears the request, and quickly replies "B's public key is foo". C then says "I need B's public key," and waits for B to reply "My public key is bar." A now tries to talk to B. A encrypts the communication using foo, and sends it out. C decrypts it (since C knows how to decrypt foo), copies it, and reencrypts it using bar (which only B knows how to decrypt). B recieves it, decrypts it, and says "I just got a message from A which was encrypted in a way that no one else can decrypt, so it is secure." Likewise, C can catch B request for A's public key and listen to the return half of the call. Somehow, your phone and my phone need to already share a unique key with each other inorder to exchange the key they will use in their communications. That is a chicken and egg problem. The solution, clearly is to have a secure "directory server", which shares a different unique key with every phone in the system. This is a reasonably tractable solution (the number of keys grows only with N, each phone needs only a single key, and distribution of that key can be done when the phone is manufactured), and forms the basis of MIT's Kerberos system for secure and trusted logins to Unix boxes. (<- Actually, Kerberos uses secret key encryption rather than public key encryption, because the security of the method is unaffected and a careful accounting of messages reveals that more packets need to be exchanged to start up a conversation using public key than is needed to start up one using secret key). The problem is that the directory server is now a tremendous single point of failure. Anyone who cracks any directory server anywhere instantly renders the entire security algorythm null and void. Worse, *every phone* would have to be sent back to the manufacturer to get a new secret key burned in (otherwise there would be no way to trust that the new key was not intercepted if it was reprogrammed remotely). That would be prohibitively expensive, so it would never happen. But we all know that somewhere out there is a nasty who would manage to crack into one of these servers (you've got to admit they'd be real attractive nuisances). Now you have a system that everyone believes is secure, but actually provides little or no more real security than current cellular phones. In short, providing secure and trusted communications over a "hostile" network is not trivial, and in my opinion providing a false sense of security about ones communications is worse than providing no security. don alvarez Princeton Univ. Physics Dept. (609) 924-3039