Anyone else actually know about these things?
On 2/10/05 7:48 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > david, thanks for your helpful analysis. > > one thing i haven't been able to find is a description of how supernodes are > selected for a particular call. > > (i'd assume they'd attempt to select among those with best latency and > adequate bandwidth to the communicating participants, if that could be > determined -- trickier when you then add in a third participant.) > > do you (or does anyone) know, or willing to express an informed opinion: > > if i have enough bandwidth and compute power to be a supernode myself > (or direct tcp connectivity to my peer) is it true that no other > supernodes are involved in the key exchange or media traffic aspects > of my call? (maybe in the search...) > > if i'm a puny-luser node (opposite of a supernode), is a single > supernode used to accomplish both key exchange and media traffic for a > specific call or all of my calls? > > does the client select the supernode, or is it selected for them? > > is there any attempt at diversity (either by splitting one from the > other or splitting media traffic up among supernodes). > > yes, i understand by having enough bad-seed supernodes a bad guy may > be able to assemble a call's parts despite diversity. but there are >> 1M skype users logged on right now, so i wonder how many bad-seeds i'd > need for p>.5 interception of a specific, targeted communicant. > > > ----- Forwarded message from David Farber <[EMAIL PROTECTED]> ----- > > Delivered-To: [EMAIL PROTECTED] > User-Agent: Microsoft-Entourage/11.1.0.040913 > Date: Sun, 30 Jan 2005 11:40:09 -0500 > Subject: [IP] more on Simson Garfinkel analyses Skype - > Open Society Institute -- interesting set of comments djf > From: David Farber <[EMAIL PROTECTED]> > To: Ip <[email protected]> > Reply-To: [EMAIL PROTECTED] > List-ID: <[email protected]> > List-Software: listbox.com v2.0 > List-Help: <http://v2.listbox.com/doc/[EMAIL PROTECTED]> > List-Subscribe: <mailto:[EMAIL PROTECTED]>, > <http://v2.listbox.com/subscribe/[EMAIL PROTECTED]> > List-Unsubscribe: <mailto:[EMAIL PROTECTED]>, > <http://v2.listbox.com/member/unsubscribe/[EMAIL PROTECTED]> > Errors-To: [EMAIL PROTECTED] > X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on c3.seiden.com > X-Spam-Status: No, hits=1.0 required=4.2 tests=AWL,FVGT_TRIPWIRE_DJ, > FVGT_TRIPWIRE_SL,HTML_MESSAGE,MY_HTML_OBFU autolearn=no version=2.63 > > > ------ Forwarded Message > From: David Pollak <[EMAIL PROTECTED]> > Date: Sun, 30 Jan 2005 07:44:21 -0800 > To: <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Subject: Re: FW: [IP] more on Simson Garfinkel analyses Skype - Open Society > Institute > > Dave, > > I've been following the Simson/Skype thread on IP and I've read the Columbia > analysis of the Skype protocol > (http://www1.cs.columbia.edu/~library/TR-repository/reports/reports-2004/cuc > s-039-04.pdf) I've known Simson for 14 or so years and have a ton of respect > for his technical skills. However, I think there are some significant Skype > vulnerabilities and associated legal ramifications that Simson did not > discuss in his article. > > Security is based on trust of the parties exchanging information that they > are who they claim and that the data exchanged appears to be random to an > untrusted observer. While Skype's use of encryption supports the second part > of the definition, it does not support the first. Because it does not > support the first, it is very easy to use the Skype network to intercept > communications between any user or to pose as any user. This presents a > problem as against both third parties and governmental agencies. > > A critical part of the Skype network is the "super-nodes." According to the > Columbia paper, super-nodes perform 3 functions: > * Designating the login authority > * Media packet forwarding > * Routing user search requests > Super-nodes appear to "volunteer" to perform the function. Or put another > way, they are nodes that are not under the control of Skype, but they > perform all the routing functions necessary to discover a user and exchange > information with the user. Super nodes run on any machine running the Skype > program and the machines under Skype control have no way to determine if the > super nodes are running unmodified Skype code. > > If one were skilled in reverse engineering x86 code and one were willing to > violate Skype's user agreement, one could create a Skype node that > volunteered to be a super-node. It would appear to all other Skype nodes as > a normal super-node. It would perform all the functions of a Skype > super-node. However, it would do a little bit more. Let's call one of these > super-nodes a "bad seed." > > The bad seed could point users to another authentication server. Thus, the > user would exchange username and authentication information with a "bad > relay proxy" rather than the Skype server. That permits the "bad relay > proxy" to deny Skype access to a user that I designate. Okay a denial of > service attack is not great stuff, but for businesses that rely of Skype > (http://news.com.com/No-cost+Skype+strikes+chord+with+businesses/2100-7352_3 > -5553053.html ), having the prospect of a DoS attack could be an issue. > Further, the "bad relay proxy" could collect username/password challenge > (I'm assuming that Skype's not sending the actual password, but performing a > challenge/response method of verifying the password) data and do dictionary > attacks on the passwords. This isn't a hardcore vulnerability you say. > Yep... I agree. > > The bad seed routes some of the media requests if the two peers cannot see > each other directly. Skype claims that because the packets are encrypted, > the super-nodes are just routing agents. This is true unless the bad seed is > part of the key exchange (see the next paragraph.) If the bad seed is part > of the exchange of private AES keys that are used to encrypt the voice data, > then they are able to decrypt the audio or text streams. Yikes. If a bad > seed was a man in the middle of the private key exchange, then the bad seed > could record your conversation with another user. Okay, that's not good. > Given that any Skype node can become a super-node just by raising its hand > and a skilled hacker can re-engineer a Skype node to perform bad acts, then > if you connect to the Skype network, you don't know which nodes are > listening in on your conversation. But wait, you say, the requirement for > the above bit of scariness is doing a man-in-the-middle attack on the > encryption key exchange. You're right. And here's where the Skype network is > totally insecure. > > One function of the super-node in the Skype network is to route and respond > to user search requests. If I want to connect to "other_dude" on the Skype > network, my client sends out search requests to a series of super-nodes. The > super-nodes either respond with the address of "other_dude" or forward the > requests to other super-nodes. If one of the super-nodes is "bad seed", that > node can respond that it is "other_dude." Because there is no cryptographic > trust or any form of trust authority in the Skype network, any super node > that returns the information about "other_dude" is trusted by my node. > > An aside... SSL certificates are signed by a trusted third party. That third > party validates that the certificate is held by the organization that claims > to hold the certificate. Using SSL insures that the party that I'm > communicating with is the party that they claim to be within the bounds that > I trust the signer of the SSL certificate *and* that once the connection is > established that no one can understand the data exchanged with this party. > That initial trust of the signed certification is a critical part of the > security of the overall communication. If I do a session key exchange with > an unknown party, the communication is *not* secure. This is the case with > Skype. > > The Skype network relies on trusting the super-node. A bad seed can perform > a man in the middle attack during the session key exchange by posing as the > party being contacted (or forwarding the information of another compromised > node) to a caller. So, my bad seed is able to route call requests to an > untrusted node and do a man-in-the-middle during the key exchange and snoop > into my call. The only question is how many bad seeds to you need in order > to capture a significant percentage of the routing requests that go over the > Skype network. My guess is that the number is in the hundreds. So, with a > hundred machines located around the world, I could intercept any Skype call > and record it. Pretty scary. > > The PSTN primarily uses pairs of copper wires to transmit voice > communications from my house to the phone company central office. I can gain > physical access to those copper pairs very easily as long as I have physical > proximity to the location of the person I want to snoop on. It's not hard to > do. Yeah, you have to paint a white van with "Verizon" or "SBC" so the > police don't hassle you. But you can do it. > > If the government wants to do it, it's somewhat harder. The government has > to get a warrant to listen to your phone conversations. Once they obtain a > warrant, they present it to the phone company which makes an entry into > their switch to record the call or send a real-time copy of it to the > government. > > SIP is different. SIP supports encryption, but most SIP providers do not > make use of it. The Microsoft SIP client libraries have the option of > communicating with the SIP server via TLS (TLS is like SSL, but uses the > same IP port for both encrypted and unencrypted traffic.) Additionally, the > media portion of a SIP call can be encrypted by setting a flag in the media > descriptor. While most SIP providers do not use this functionality, it's > part of the SIP spec and can be turned on. Note that the machines that could > play man-in-the-middle with an encrypted SIP call are controlled by your SIP > provider (rather than any machine running Skype.) Thus, you can trust the > security of your call as much as you trust your SIP provider. > > With unencrypted SIP calls, if you are able to intercept packets, then you > can tap the call. Anybody on your LAN can listen into your call. This level > of security is no different than anyone in your house can listen in on your > phone calls and anyone in your office can probably do the same. Anyone who > can intercept the packet stream outside your LAN can also listen in on the > conversation. This is more of a challenge. UDP packets (the stuff that the > media stream goes over) may or may not be routed through the same backbone > during all parts of the conversation. There is a certain amount of security > with the packets going over the backbone. The ability to snoop on an > unencrypted SIP call is marginally more difficult that snooping on a PSTN > call. > > For the government, it's more of a challenge. Because the media portion of a > SIP call goes directly between the end points without going through the SIP > providers network. This raises an interesting issues: > http://news.com.com/2100-7352-5296417.html This is interesting for two > reasons. First, SIP "telephone" companies like Vonage will have to provide a > flag to allow them to intercept the media stream and decode it if the > government has a warrant. Second, the government has acknowledged that SIP > callers have the same expectation of privacy that copper-pair PSTN callers > have. This is really important. > > Users of peer-to-peer file sharing programs don't have an expectation of > privacy in their use of P2P programs. That's why so many folks are being > sued > (http://news.com.com/RIAA+files+754+new+file-swapping+suits/2110-1027_3-5494 > 259.html?tag=nl ) Skype touts themselves as a P2P voice communications > system (http://skype.com/products/explained.html ) That means that if you > use Skype, you have the same expectation of privacy as a P2P user. Given > that the government has the resources to build bad seeds and that P2P users > have no expectation of privacy, you can bet that there are government run > Skype nodes looking for Skype communications between Osama911 and > Sleeper_in_Seattle and that the government doesn't have a warrant for these > activities. > > To conclude my long rant, the Skype network is radically insecure because it > relies on untrusted super-nodes to perform trusted functions, most notably > user look-up. It's easy to build a compromised super-node (a bad seed.) With > a limited number of bad seeds, the communications between any users can be > intercepted or denied. It's something that a person with the resources to > rent 100 servers in collocation facilities around the world could do (that's > about $10,000 per month investment.) Given that Skype is a P2P network and > users such networks are not afforded the same expectation of privacy that > users of the PSTN and other telephone networks are afforded, the government > could use such a mechanism to listen to Skype-based calls and have a > reasonable legal argument that they do not need a warrant to do so. > > That's my 2 cents. > > Thanks, > > David > > PS -- I was CTO and VP Engineering for an Internet security company for a > number of years and I'm a member of the Rhode Island bar. > > > > Annette Hurst wrote: >> >> >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of >> David Farber >> Sent: Saturday, January 29, 2005 2:11 AM >> To: Ip >> Subject: [IP] more on Simson Garfinkel analyses Skype - Open Society >> Institute >> >> >> >> ------ Forwarded Message >> From: "Jonathan S. Shapiro" <[EMAIL PROTECTED]> <mailto:[EMAIL PROTECTED]> >> Date: Fri, 28 Jan 2005 22:03:48 -0500 >> To: <[EMAIL PROTECTED]> <mailto:[EMAIL PROTECTED]> >> Subject: Re: [IP] I more on Simson Garfinkel analyses Skype - Open Society >> Institute >> >> I'm going to attempt to chime in on this, because I think Brad is saying >> something that I feel is badly wrong. >> >> >> The most important element of an encryption scheme is that there must be some >> well-founded basis for a well-defined degree of confidence. The encryption >> may >> be well done or poorly done. It may be sufficiently protective or it may not. >> The thing is that the user has a right and a need to know where on the >> spectrum it falls. >> >> The other alternative is ignorance. The first problem with this is that >> *your* bad choices can have the effect of disclosing things that have >> negative >> consequences for someone else! The second problem is that it describes the >> majority of real users. >> >> In the case of Skype, the argument Brad is making is simply absurd. The >> question is not whether something is better than nothing. The question is why >> Skype chose to implement an undocumented and unqualified proprietary >> encryption scheme at considerable expense rather than use one of the many >> existing schemes that are well known, well characterized, and free for the >> taking. >> >> When viewed from a business perspective, the only plausible rationale is >> immediately apparent. Skype's objective isn't to protect conversations. It is >> to render Skype users a captive audience by impeding interoperability. >> >> It is hardly a new precedent. I seem to remember AT&T trying to use allegedly >> proprietary interfaces to impede the attachment of Tom Carter's Hush-a-Phone >> in 1956 or so. Different method, same basic strategy. >> >> >> Jonathan Shapiro >> >> On Fri, 2005-01-28 at 20:53 -0500, David Farber wrote: >> >> >>> >>> ------ Forwarded Message >>> From: Brad Templeton <[EMAIL PROTECTED]> <mailto:[EMAIL PROTECTED]> >>> Organization: http://www.templetons.com/brad >>> Date: Fri, 28 Jan 2005 17:22:29 -0800 >>> To: David Farber <[EMAIL PROTECTED]> <mailto:[EMAIL PROTECTED]> >>> Cc: <[EMAIL PROTECTED]> <mailto:[EMAIL PROTECTED]> , <[EMAIL PROTECTED]> >>> <mailto:[EMAIL PROTECTED]> , >>> <[EMAIL PROTECTED]> <mailto:[EMAIL PROTECTED]> >>> Subject: Re: [IP] Simson Garfinkel analyses Skype - Open Society Institute >>> >>> >>> >>>> >>>> I'm sorry to pick nits, but I have to stand by my statement. No >>>> matter how atrociously bad other systems may be, I don't see any >>>> basis for saying that Skype is any better. It might be better, or >>>> it might be just as bad. We don't know. >>>> >>>> >>> >>> While I fully agree that one can have much more confidence in a >>> security system which can be independently analysed and verified as >>> secure, it is exactly the attitude above, common in the security >>> community, which I believe has stopped us from deploying security. >>> >>> "Some" security, even things like DES (which our own foundation proved >>> can be crackable), poorly chosen keys, algorithms with flaws, >>> protocols that are vulnerable to men in the middle, and proprietary >>> encryption systems -- all of these are often declared to be "no >>> better" than having no encryption at all. >>> >>> And so, people, buying that argument, often give us no encryption at >>> all, because encryption is hard to do well, and if people keep telling >>> you that you have to do it perfectly or you might as well not bother >>> -- then people don't bother. >>> >>> The trut is, most people's threat models are not the same as a security >>> consultants. They accept that if the NSA wants to man-in-the-middle >>> them, the NSA is going to succeed. >>> >>> Skype has resisted basic efforts by skilled reverse engineers to look >>> at its protocols. That doesn't mean they are secure, but it does mean >>> they are secure from basic efforts. If I wanted to listen in your >>> your skype call and had a tap on your ethernet, I would at least have >>> to put a lot of work into it, and possibly could not do it >>> at all. That is a _lot_ more than what is true with in-the-clear SIP, >>> where I could slap a packet sniffer on your net and hear your call >>> fairly trivially, and with certainty that I would succeed. >>> >>> This is, in fact, a huge difference. Encryption is really about how >>> hard you make it for the attacker. Because above a certain level of >>> hardness there are a lot of easier ways into your network and >>> computer. >>> >>> So yes, let's decry that we can't verify Skype's encryption and must >>> take their word that it is resistent to attack. But let's not promote >>> this attitude that it is no better than nothing. >>> >>> ------ End of Forwarded Message >>> >>> >>> ------------------------------------- >>> You are subscribed as [EMAIL PROTECTED] >>> To manage your subscription, go to >>> http://v2.listbox.com/member/?listname=ip >>> >>> Archives at: >>> http://www.interesting-people.org/archives/interesting-people/ >>> >>> >> >> >> >> ------ End of Forwarded Message >> >> >> ------------------------------------- >> You are subscribed as [EMAIL PROTECTED] >> To manage your subscription, go to >> http://v2.listbox.com/member/?listname=ip >> >> Archives at: http://www.interesting-people.org/archives/interesting-people/ >> > > > ------ End of Forwarded Message > > ------------------------------------- > You are subscribed as [EMAIL PROTECTED] > To manage your subscription, go to > http://v2.listbox.com/member/?listname=ip > > Archives at: http://www.interesting-people.org/archives/interesting-people/ > ----- End forwarded message ----- > > --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
