[Français]
Sponsor List
|
End-to-end encryption
(and Person-in-the-middle attacks)
Encryption in MUTE
First of all, what is end-to-end encryption, at least in relation to MUTE?MUTE nodes use encryption, but only to secure the direct connections to their neighbors. This might be described as "link encryption." For a given MUTE route, each leg of the route is encrypted separately. When a node receives a message from one of its neighbors, it essentially decrypts the message, reads it, and then re-encrypts it to route it onward through another neighbor. Notice the phrase "reads it" in the above description: each MUTE node that routes a message has full access to the unencrypted contents of the message. Thus, it would be possible for these intermediary nodes to "spy" on the contents of messages that pass through them. Worse yet, it would even be possible for intermediaries to modify the contents of messages before passing them on.
For a network that might provide privacy along with anonymity, this seeming lack of security sounds like a major problem. How might we fix the problem? In an anonymous network like MUTE, for reasons that I will discuss below, it is impossible to fix this problem in any real way.
Over the course of MUTE's development, various people have suggested (and even demanded) that I add "end-to-end" encryption to MUTE. The basic idea is that a sender would encrypt the contents of a message with the receiver's key before routing it through the MUTE network. Since only the receiver could decrypt the message contents, this kind of encryption would thwart any attempts by intermediary nodes to read or modify the message in-route. This idea sounds wonderful at first, but there is a major technical issue lurking that turns out to be a fatal flaw. This flaw prevents end-to-end encryption from adding any extra security at all. Every time someone suggests end-to-end encryption, I point out this flaw, and the suggester says, "Oh, yeah, I guess end-to-end will not work." Of course, a few months later, someone else suggests end-to-end encryption, and I have to explain the fatal flaw all over again. So, I am going to do this one more time...
Why I will never add end-to-end encryption to MUTE
End-to-end encryption actually would work if senders had a secure way to obtain receiver keys. Of course, in the MUTE network, the sender and receiver are anonymous. How is the sender going to obtain a key from an anonymous receiver before commencing communications with that receiver? To preserve their anonymity, the sender and receiver cannot connect to each other directly. Thus, the receiver's key must somehow be transfered through the MUTE network itself.If the communication channel that the key travels through is not encrypted end-to-end, intermediary nodes can modify that key. In fact, if Eve operates an intermediary node, she can completely replace the receiver's key with her own key. In this case, the sender would encrypt a message to the receiver using Eve's key, and if that message was routed through Eve's node, she could read the message and then re-encrypt it with the true receiver's key before routing it onward. With this trick, Even can bypass the end-to-end encryption without either the sender or the receiver detecting the breach: a classic "person-in-the-middle" attack (historically called a "man-in-the-middle" attack).
We can think about this issue as a "chicken-and-egg" problem. To build a secure end-to-end channel, we need to exchange end-point keys in a secure way. To exchange end-point keys securely, we need a secure end-to-end channel.
What about trusted third parties?
At this point, you might be wondering how encryption works on the rest of the Internet. For example, millions of credit card transactions are passing from web browsers to web servers each day through SSL connections, and these connections are built on top of Internet routes through untrusted routers. Am I claiming that SSL and secure HTTP are a sham? No. But these connections use a key exchange mechanism that is not practical in the MUTE network: a trusted third party. When you make a secure connection to Amazon.com, you do not blindly obtain Amazon's key directly from Amazon's web server, since your transaction would then be subject to a person-in-the-middle attack. Instead, you rely on a third party, called a "certificate authority," to verify that Amazon's key is really from Amazon. The assumption is that if you obtain Amazon's key through a different channel than the channel through which you obtained the authority's key (authority keys are shipped with your web browser), a single person-in-the-middle attack will be thwarted.So why not use trusted third parties in MUTE? The core problem is that it is difficult or impossible to be trusted (in any secure sense) when you are anonymous. As soon as you connect directly to the certificate authority, your anonymity is compromised. We might try routing messages to the authority through MUTE, but then we are back to our original problem: we cannot communicate securely with the authority unless we have a secure end-to-end channel. Of course, we might forgo the secure end-to-end channel and just route unencrypted messages to the authority. In this case, we would be assuming that our sender-receiver route is different from our sender-authority route so that a single person-in-the-middle could not interfere with both routes. But what about coordinated person-in-the-middle attacks, where several nodes work in concert on different routes? Such an attack could both fake the receiver key and fake the certificate.
Even if we can connect securely to the certificate authority in some way, we have no way of talking about the receiver. In other words, how are we going to describe the receiver to the authority to obtain a certificate? Using the receiver's virtual MUTE address? But where did we obtain that virtual address from? The address was probably sent along with search results through a route from the receiver to the sender. In other words, the person-in-the-middle might already have interfered with our communications, replacing the receiver's address with his or her own address, before we even contact the certificate authority. In that case, we would be asking the authority about the wrong address and then routing all future messages through the person-in-the-middle. So, because of the anonymity in the MUTE network, even a trusted third party would not enable secure end-to-end communications.
What about ______ ?
There are many possible variations in terms of schemes for enabling end-to-end encryption, but the fatal flaw affects all of them. To establish a secure channel, you must exchange keys (or other information) somehow. As long as you are passing this channel-setup information through the MUTE network, intermediary nodes can interfere and defeat the security of the resulting end-to-end encryption.Of course, proponents of end-to-end encryption in MUTE are insistent, and new schemes pop up from time to time that supposedly solve the person-in-the-middle problem. Here is an example email that was sent just five days ago (in reference to the ANTs project):
|
From: "Roberto Rossi" <labforweb@hotmail.com> To: mute-net-discuss@lists.sourceforge.net Subject: Re: [MUTE] ANts tackles Man-in-the-middle threat :) Date: Thu, 14 Oct 2004 19:46:17 +0200 ANts is now definitely secured against MIM attacks! A new node identification system is going to be implemented in a short: it will make computationally impossible a MIM attack. A prototype is already working I only have to sync all the versions! Details: The idea is to use a particular DS (Digital Signature) public key as node ID on the ants net. The key (node ID) will be changed each time you run ANts and it will be generated in couple with a private one. You'll use your private one to sign your messages so that everyone on the ants net will be able to verify if a message from the node identified by a particular ID (i.e. public key) is spoofed or valid. The method is computationally secure cause it implies no DH exchange or communication stuffs. You simply publish your ID (i.e. public Key) on the net through your queries and you'll be the ONLY one able to use that ID to spread messages on the net. Spoofed message will be automatically rejected by other nodes, cause the spoofer will not be able to create a fake signature (unless he can perform a 1024 bit factorization... :P ) and the nodes will fail in verifying the signature. Obiously this will work within the current secured environment creating a far more strong security. We are definitely DONE! This can be applied also on MUTE so coder take notes :P I think it's a great idea. |
|
Jason Rohrer Potsdam, NY October 2004 |