[IP] more on Simson Garfinkel analyses Skype - Open Society Institute -- interesting set of comments djf

David Farber dave at farber.net
Sun Jan 30 08:40:09 PST 2005

------ Forwarded Message
From: David Pollak <dpp at athena.com>
Date: Sun, 30 Jan 2005 07:44:21 -0800
To: <dave at farber.net>
Cc: <slg at ex.com>
Subject: Re: FW: [IP] more on Simson Garfinkel analyses Skype - Open Society


I've been following the Simson/Skype thread on IP and I've read the Columbia
analysis of the Skype protocol
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
-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

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

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

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
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

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.



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: owner-ip at v2.listbox.com [mailto:owner-ip at v2.listbox.com] 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
> ------ Forwarded Message
> From: "Jonathan S. Shapiro" <shap at eros-os.org> <mailto:shap at eros-os.org>
> Date: Fri, 28 Jan 2005 22:03:48 -0500
> To: <dave at farber.net> <mailto:dave at farber.net>
> 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
> well-founded basis for a well-defined degree of confidence. The encryption
> be well done or poorly done. It may be sufficiently protective or it may
> 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
> 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
> 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
> 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
> proprietary interfaces to impede the attachment of Tom Carter's
> 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 <btm at templetons.com> <mailto:btm at templetons.com>
>> Organization: http://www.templetons.com/brad
>> Date: Fri, 28 Jan 2005 17:22:29 -0800
>> To: David Farber <dave at farber.net> <mailto:dave at farber.net>
>> Cc: <daw at cs.berkeley.edu> <mailto:daw at cs.berkeley.edu> ,
<adam at shostack.com>
>> <mailto:adam at shostack.com> ,
>> <simsong at csail.mit.edu> <mailto:simsong at csail.mit.edu>
>> 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 shap at cs.jhu.edu
>> 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 annette at lostlake.org
> 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 eugen at leitl.org
To manage your subscription, go to

Archives at: http://www.interesting-people.org/archives/interesting-people/
----- End forwarded message -----
Eugen* Leitl <a href="http://leitl.org">leitl</a>
ICBM: 48.07078, 11.61144            http://www.leitl.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE
http://moleculardevices.org         http://nanomachines.net

[demime 1.01d removed an attachment of type application/pgp-signature]

More information about the cypherpunks-legacy mailing list