D-kriptik Blog

Once again, we have fallen behind on reading the multitude of blog feeds we are subscribed to, but I just noticed the Skype blog posted that a general security analysis has been performed on the workings of the Skype system. I downloaded the report, which is essentially a summary of the results of the analysis. While details of the proprietary protocols are not given, it does provide some information about the mechanisms being employed and clearly states that the author of the report, Tom Berson of Anagram Laboratories, feels that Skype has done a good job of designing security elements into its system. The conclusions are summarized in the following statements at the end of the report.

The designers of Skype did not hesitate to employ cryptography widely and well in order to establish a foundation of trust, authenticity, and confidentiality for their peer-to-peer services. The implementers of Skype implemented the cryptographic functions correctly and efficiently. As a result, the confidentiality of a Skype session is far greater than that offered by a wired or wireless telephone call or by email and email attachments.

Beyond errors in the cryptosystem, I have also looked for back doors, Trojans, overreaching “debugging” facilities, etc. I did not find any hints of malware in the portions of the Skype code I reviewed.

I remember a post we wrote back in September of this year, in which I stated the following.

On a side note, the article glazes over the security of VoIP, as it does anything technical being outside the focus, but Werbach does give the following example.

“Skype, for example, encrypts every call end to end, providing more privacy than any traditional phone company.”

It may, it may not. I tend to think it is no worse.

The main drawback of Skype is that it uses proprietary protocols. For example, the cryptographic protocol has not been publicly disclosed.

Now, I do feel Skype provides confidentiality beyond a traditional phone company. I still believe the protocols should be publicized fully for proper evaluation, but I think Skype has done a good job having a respectable and known third party evaluate the security assessment of its system. That is a big step, and I was particular encouraged by the following statement from the blog post.

As Skype and its software and services evolve, so does the need for security and similar reviews. This won’t remain the last one, but we’re happy to get our security review process off the ground with this report.

On a side note, some things I noted while skimming the paper. Berson’s conclusions pretty much summed these up.

1. The code correctly implements AES using a block size of 128 bits and a key size of 256 bits. Standard AES-256 test vectors and keys were compared to the Skype AES. Skype AES matches the results produced by other implementations. Skype put significant effort into making Skype AES run quickly. It is optimized for Integer Counter Mode.

   Optimized AES implementations can be susceptible to information leaks, like these. Berson later points out

   It is well known that implementations of cryptographic operations may sometimes leak information about the plaintext or the key through their consumption of shared resources, such as storage, CPU time or power.

   and

   I consider this a minor problem, because a malicious program running on the same platform as a Skype client could do much greater damage directly.

2. B. A CRC is computed on the contents of the encrypted buffer. The mod 2 sum of the CRC with the low order 2 bytes of the packet_index is stored in the last 2 bytes of the buffer.

   No keyed message authentication code (MAC) for integrity, just a squishy CRC. Berson later points out

   CRC-type checksums are commonly used in communication protocols to reliably and efficiently detect bit errors. However, because they are linear, they may be unsuitable for the purpose of detecting intentional modification of data.

3. Why use AES with a 256 bit key when RSA with a ?? (client-client), 1536 (client-server), or 2048 (client-server) bit modulus is being used for key exchange? It could be planning for future changes that will strengthen the key exchange mechanism.
4. There is no discussion on the coding practices utilized by the Skype team. For example, is code reviewed for common errors, such as buffer overflows? Berson finds
   

   I found a potential error associated with the decoding of integers. The error does not imperil the confidentiality of Skype communications, but might lead to unpredictable behavior in the presence of malicious inputs. I communicated this information to Skype engineering.

5. The details on the protocols being used, especially for key exchange, are vague. While more information is given, it still requires leaps of interpretation by the reader to figure out what may be going on.
6. Bravo to Skype for this initial security review.

Update: Whoops, forgot – via Share Skype

This entry was posted on Sunday, October 23rd, 2005 at 2:51 pm and is filed under Crypto, Skype, VoIP. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.