[VOIPSEC] Skype security evaluation (Fwd: Voipsec Digest, Vol 12, Issue 24
Mark Baugher
mbaugher at cisco.com
Thu Jan 5 08:21:09 CST 2006
I'd like to hear your comments on the Skype security evaluation that
Henry cites below. My comments are inline. I should say that I don't
know a whole lot about Skype yet - its protocols are not published;
they're proprietary. I once worked on a proprietary protocol (NetBIOS)
and feel that the security of such systems is potentially at risk with
each new release since there is no guarantee of public review prior to
release. Public review is a well-established requirement for
cryptographic protocols as well as algorithms. That's not to say that
Skype is insecure. I'm just saying that I can't tell. Personally I
might be willing to rely on experts of the caliber of the author, but
what about the next or a future release? Maybe there will be a
different set of reviewers or no external security review at all.
I have more comments below.
Begin forwarded message:
> From: "Henry Sinnreich" <henry at pulver.com>
> Date: January 2, 2006 8:21:37 AM PST
> To: "'Mark Baugher'" <mbaugher at cisco.com>
> Cc: <Voipsec at voipsa.org>
> Subject: RE: [VOIPSEC] Voipsec Digest, Vol 12, Issue 24
> Reply-To: <henry at pulver.com>
>
> Hi Mark and Happy New Year!
>
> You may have seen the security evaluation for Skype:
> http://www.skype.com/security/files/2005
> -031%20security%20evaluation.pdf
What I read is a paper from a well-regarded cryptographer stating that
he has looked at the algorithms, protocols and code and judges Skype to
be secure. I think this is the crux of the paper. There is no mention
of the vulnerabilities or potential vulnerabilities. Why not? I think
it's inadvisable to publish specific attacks, but there is no mention
even of the intermediate systems that are at the heart of the Skype
peer-to-peer system. Is it not a security issue that the forwarding
nodes are outside of Skype control process but nonetheless route Skype
calls?
(see http://www.interesting-people.org/archives/interesting-people/
200501/msg00235.html). Who controls the intermediate nodes and what
can they see in the messages that they forward? Can they see who is
calling whom? I bet that they don't see much, but it would be helpful
if the paper said what. At minimum the IP addresses are exposed.
So personally I cannot match the security mechanisms with what they
need to secure. There is detail on the cryptographic algorithms in the
paper, which are standard, but practically nothing on the security
protocols beyond saying they're good. It would help if the paper
compared the level of protection to published security protocols such
as TLS or IPsec/IKE (such as: Does Skype feature perfect forward
secrecy of session keys?). It also would be helpful if the author said
what was exposed rather than what was not.
>
> It would be very interesting for someone who disagrees to take up this
> evaluation, item by item and provide arguments to the contrary.
As far as overall security goals, I read this on page 1: "Skype makes
wide use of cryptography to authenticate user and server identities,
and to protect the content transmitted across the P2P network from
disclosure by parties other than the peers... The goals of providing
verified user identity and content confidentiality across the P2P cloud
are achieved."
Content is confidential, but what is content? Does it include the
signaling as well as the user data? How much privacy is afforded to
the call signaling? Again, I expect that the IP addresses are exposed
and not much more, but this is not stated in the paper.
Regarding the algorithms and protocols, the paper states on page 1 that
"Skype uses only standard cryptographic primitives to meet its ends,
which is a sound engineering approach." Page 2 states "Skype uses a
proprietary session-establishment protocol. The cryptographic purposes
of this protocol are to protect against replay, to verify peer
identity, and to allow the communicating peers to agree on a secret
session key. The communicating peers then use their session key to
achieve confidential communication during the lifetime of the session.
I analyzed this protocol, and found that it achieves its cryptographic
aims. Further, I explored the strength of the protocol against a range
of well-known attacks, including replay attack and man-in-the-middle
scenarios is computationally infeasible."
The advantages of using public cryptography applies to protocols as
well as algorithms. Yet the protocols are secret. They may be very
good, but many expert eyes are better than one or a few.
Regarding security policy on page 2, "Messages transmitted through a
Skype session are encrypted from Skype-end to Skype-end. No
intermediary node, if any exist, has access to the meaning of these
messages." I wonder if it is true that Skype tamper resists its code.
If so, is that to protect against what in intermediary or at end
nodes? If true, the author should state that the security of Skype
does not rest on the obfuscation of its code.
Section 2.1 does not mention how key rollover is handled or anything
about key lifetimes of asymmetric keys. Regarding symmetric session
keys, section 2.2 and 2.3 describe the Skype session key between caller
A and caller B, Sab, which is a shared key used in AES integer counter
mode (ICM). There is no mention in the paper of the vulnerability in
AES ICM when it is used incorrectly and two sides share a keystream;
the necessary condition for this to happen is when two senders to share
a key. Section 3 describes a cryptographic mechanism that would allow
Sab to be shared among A and B for use in AES ICM: Each side
contributes a nonce called "salt." This seems analogous to the SSRC in
SRTP, which also uses AES ICM as its default. The use of the packet
index, block number and salts in forming the counter (Section 3.2.1) is
a lot like default SRTP with a few exceptions (such as Skype does not
use salt in McGrew-Fluhrer definition). Based on the paper, I doubt
that there is a key-sharing problem in Skype. Still, there are
boundary cases that should be mentioned such as forking. Does Skype
support forking? Based on the description in the paper, it seems that
Skype does not support endpoint forking or that this is correctly
handled in the key agreement protocol (Sab is pairwise-unique to
endpoints A and B; I expect that there will be a different pairwise
secret for A and D if forking to D occurs based on my reading of the
paper).
Section 4 concludes the paper with an endorsement of the security of
the current version of Skype and notes that Skype is an "early" example
of what abundant cryptography might yield. An even earlier example is
SSL - this year is the tenth anniversary of the release of SSL 1.0.
That too was developed by experts. SSL-based systems have become
ubiquitous. Still, SSL systems have weaknesses that were critiqued as
early as 1998 and that are today exploited by phishing attacks. It's
overall success, however, is undoubtedly due to the open nature of the
technology. It is a published protocol unlike Skype. Like Skype, SSL
was a closed development effort by a single company. The lead
architect of SSL once told me that they would never have gotten out the
door with a complete protocol in twice the development time (and cost)
had they done SSL through a standards body. I would add that it would
not have gained such rapid adoption and support had they not at least
published the specifications for SSL.
One final observation with respect to a Skype security evaluation:
Users and enterprises are generally concerned with the security of all
calls and not just that subset of calls that are within the Skype
network. Unless it happens that Skype is adopted by every person on
the planet, some thought needs to be given to how Skype will interface
to other secure telephony networks.
That's my two cents.
Mark
> I have not
> not seen any arguments to the contrary, but just people who either like
> Skype and some who don't.
>
> There is a test report though from a credible lab:
>
> http://www.networkworld.com/reviews/2005/121205-skype-test.html
>
> In this light, Skype is probably more useful in the enterprise than the
> hypothetical risks it may represent. Are Windows and its applications
> less
> risky?
>
> Actuallly, Skype can significantly increase productivity IMHO and
> should be
> encouraged by IT untill a similar well designed application based on
> SIP
> will emerge. Instead of griping about Skype, I would like IETF-minded
> folks
> to work on a better-than-Skype P2P SIP product.
>
> Thanks, Henry
>
>
>
> -----Original Message-----
> From: Mark Baugher [mailto:mbaugher at cisco.com]
> Sent: Monday, January 02, 2006 9:33 AM
> To: henry at pulver.com
> Cc: Voipsec at voipsa.org
> Subject: Re: [VOIPSEC] Voipsec Digest, Vol 12, Issue 24
>
> hi Henry,
>
> On Dec 28, 2005, at 7:05 AM, Henry Sinnreich wrote:
>
>>> You can't sell expensive phones or nobody will be your customer
>>
>>
>>
>> Check out the Skype phones, (or the Nimcat/Avaya or Peerio PBX
>> phones).
>>
>> There is no central call routing and the phones are both secure and
>> affordable.
>
> I have not found a public description of Skype security and for that
> reason would not claim that they are secure. In fact, what I have
> read about Skype security leads me to conclude that there is too much
> that is hidden from the user for Skype to be considered secure.
>
> Mark
>>
>>
>>
>> Both the business models and the platforms (no VoIP infrastructure)
>> are
>> different though from the "carrier" model, and this changes the
>> security
>> model and cost in a fundamental way.
>>
>>
>>
>> Let the flames come! :-)
>>
>>
>>
>> Thanks, Henry
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: Voipsec-bounces at voipsa.org [mailto:Voipsec-
>> bounces at voipsa.org] On
>> Behalf Of Voipsec-request at voipsa.org
>> Sent: Wednesday, December 28, 2005 6:00 AM
>> To: Voipsec at voipsa.org
>> Subject: Voipsec Digest, Vol 12, Issue 24
>>
>>
>>
>> Send Voipsec mailing list submissions to
>>
>> Voipsec at voipsa.org
>>
>>
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>
>> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
>>
>> or, via email, send a message with subject or body 'help' to
>>
>> Voipsec-request at voipsa.org
>>
>>
>>
>> You can reach the person managing the list at
>>
>> Voipsec-owner at voipsa.org
>>
>>
>>
>> When replying, please edit your Subject line so it is more specific
>>
>> than "Re: Contents of Voipsec digest..."
>>
>>
>>
>>
>>
>> Today's Topics:
>>
>>
>>
>> 1. VoIP vulnerabilities summarization (david.castro)
>>
>>
>>
>>
>>
>> ----------------------------------------------------------------------
>>
>>
>>
>> Message: 1
>>
>> Date: Tue, 27 Dec 2005 16:12:14 +0100
>>
>> From: "david.castro" <david.castro at adianta.net>
>>
>> Subject: [VOIPSEC] VoIP vulnerabilities summarization
>>
>> To: Voipsec at voipsa.org
>>
>> Message-ID: <43B159CE.8030706 at adianta.net>
>>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>>
>>
>> Hello, I'm David.
>>
>> I've just read your interesting "chat", and I learned a lot, but I'd
>>
>> like make a question about SIP.
>>
>> Let's imagine you are making an IP phone-operator. You have a central
>>
>> access point (server SIP and gateway to PSTN), or several access
>> points
>>
>> across internet. You can sell to your customers a IP-phone, so they
>>
>> don't have a computer run to chat on the phone. You can't sell
>>
>> expensives phones or nobody will be your customer, so the phones
>> hasn't
>>
>> TLS, IPSEC or proxy SIP, because they are connecting direct to
>> access point.
>>
>> How do you protect this scenario?
>>
>> I'm using login/password in register request, but in other request I
>>
>> can't by the phones. What would you do?
>>
>> Thanks
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ------------------------------
>>
>>
>>
>> _______________________________________________
>>
>> Voipsec mailing list
>>
>> Voipsec at voipsa.org
>>
>> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
>>
>>
>>
>>
>>
>> End of Voipsec Digest, Vol 12, Issue 24
>>
>> ***************************************
>>
>>
>>
>>
>>
>> _______________________________________________
>> Voipsec mailing list
>> Voipsec at voipsa.org
>> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
More information about the Voipsec
mailing list