I’ve been doing a lot of work with VOIP in my Enterprise lately, so when Skype started turning up on laptops in significant numbers, I guess I became a logical Go-To Guy to look into it. This is a summary of what I’ve pulled together for presentation to senior management. What they do with it, however, is their business. As I’m always quick to point out, I don’t Manage the Risks; I just Assess and Analyze them.

I think that most of the security concerns at this time are more that the Skype organization has been completely unwilling to allow third-party review of their security measures and have even gone so far as to have the application disable itself if certain debuggers (i.e. SoftICE) are even installed on the same machine. The lack of good answers back from the Skype team to Garfinkel (a credible, disinterested party) is also not consistent with the actions of an organization which feels they have nothing to worry about in their crypto implementation.

This behavior is completely inconsistent with the ethos of cryptography in particular and “honest” software vendors in general. When you factor in their association with Kazaa (same company, same network architecture and, from what I’ve read, maybe even the same dev team), the product starts to look worse and worse.

From an end-user perspective, I know a significant number of people who use the application and they all say that it from a functional perspective, it works well–good voice quality and reliability.

Thus, as I currently see it, while we have no known threats immediately identifiable, there are a lot of unknowns and some less-than-encouraging behavior. On the other hand, Skype is seeing a skyrocketing adoption rate with no ill effects documented thus far, so it may be that we’re falsely assuming that paranoia necessarily implies ill intent. To me, this is the worst sort of, “knowing we know nothing.”

Skype was pretty easy to get a handle on. I was already pretty familiar with it from reading “An Analysis of the Skype Peer-to-Peer Internet Telephony Protocol” by Salman A. Baset and Henning Schulzrinne when it came out and have following some interesting discussions on it in the past month or so. Throw in the fact that I’m far from the first person to take a look at it and this became more of a documentation project than an actual research effort.

This paper by Dennis Bergström, “An analysis of Skype VoIP application for use in a corporate environment” was a big help. It explicitly discusses Skype’s suitability as a corporate tool, focusing primarily on its controllability (there’s essentially none) within a corporate environment:

The conclusion must be that the Skype application is currently not suitable or secure enough to be deployed in a corporate environment.

I fundamentally agree with his assessment at this time.

Simson Garfinkel also conducted an evaluation of Skype which focused less on the network architecture and more on the application itself and while he was not able to prove it insecure, he had some significant concerns as to the quality of the crypto implementation.

The key issues which have not been addressed to the security or crypto communities’ satisfaction are:
1) The quality of the AES implementation. To paraphrase someone smarter than myself (since I’m more of a Risk guy than a Cypherpunk), “Implementing encryption is easy. Implementing it well is a whole different matter.”

From Garfinkel (p.5):

“Skype claims that its system uses the RSA encryption algorithm for key exchange and 256-bit AES as its bulk encryption algorithm. However, Skype does not publish its key exchange algorithm or its over-the-wire protocol and, despite repeated requests, refused to explain the underlying design of its certificates, is authentication system, or its encryption implementation. Therefore it is impossible to validate the company’s claims regarding encryption. It is entirely possible that the data is both encrypted and not secure.”

(emphasis mine)

2) Following along with #1, there has been some concern expressed that the SuperNodes might be able to implement a Man-in-the-Middle attack during the call setup Key Exchange. I don’t have the exact reference for this handy, but I read some reasonable thoughts on this area which would be consistent with both Garfinkel’s and Baset & Schulzrinne’s work.

3) The Skype client contacts a SuperNode to obtain the address of the Login Server. As a result, it is theoretically possible for a malicious SuperNode to direct the client to a malicious login proxy to either steal user credentials or create a Denial-of-Service situation for clients of the SuperNode (this ties back again to #1)

3) The skype codec is proprietary, though Baset & Schulzrinne do identify the likely vendor.

It will be interesting to see what comes of this. Skype has already made its way onto company laptops and has proven itself very good at skirting network access controls. While we’re currently able to block it by denying requests to the login servers at the proxy or router, that’s fundamentally a reactive approach. Skype could begin shifting its login server IP Addresses and we’d never be able to catch back up.