D-kriptik Blog

I got in from running around town in the cold, miserable weather outside and was pointed to the following post on Skype Journal.

The Skype Forum is buzzing with commentary on Tom Berson’s security white paper. Most of it from sidewalk superintendents.

I thought I would find an industry specialist to talk with.

Please meet Michael Gough.

The whole post should be reviewed to see what Michael Gough has to say, and it gives a little background on him. I have three comments on Michael Gough’s statements.

1. “Nothing custom; nothing home grown. The fact that Skype followed industry best practices helped to ease my concerns and those in my field as to how Skype actually implemented their encryption scheme.”

   From the details provided, we know Skype has not created home brew cryptographic algorithms (the implementations are custom), and the report did ease some of our concerns. However, the report is a summary of conclusions and, as such, is quite vague. For example, we do not know much about the protocols being utilized, especially for session key negotiation, and these do appear to be home grown. And, the CRC usage is an example to me of not using industry best practices (of course, VoIP is not my industry).

2. “Skype uses 256-bit AES to encrypt every session between users. More important, this encryption changes each time you contact someone via IM, file transfer, or a voice call. So if some malicious person managed to capture all the data and managed to figure out your AES key, it would be worthless for the next call you make with Skype. Cracking the AES key would take someone roughly 20 years, so it’s not very probable.”

   The fact is, we do not know enough to make such statements. The key life cycle for Skype has not been provided to us. For example, without knowing how these AES session keys are generated and exchanged, claiming the strength of the session confidentiality is equivalent to that of cracking AES encryption with a 256 bit key is not possible and there is no guarantee of perfect forward secrecy.

   Let’s take the example of a very simple, RSA-based key exchange between two clients to demonstrate the example given in the preceding paragraph. (This is not a step-by-step example of a key exchange, and we are not going into the various types of attacks, just a couple relevant to what we want to demonstrate – please don’t beat me up on this piece. ) Let’s say each client has a static, 1024 bit RSA key pair. Both clients generate a 128 bit random values from a reasonable pseudo random number generator seeded with a solid amount of gathered, whitened system entropy, encrypt these key components using RSA with the other client’s public key, exchange these encrypted key components with each other, decrypt the encrypted key component using their respective private keys, and then simply concatenate these two values to form a 256 bit AES key. This key exchange is weaker than the 256 bit AES key being exchanged (e.g., an ideally generated RSA key pair with a 1024 bit modulus being used for RSA encryption is not close to equivalent in strength to (half of) a 256 bit AES key being used for AES encryption), and it lacks perfect forward secrecy (e.g., if the RSA private keys are compromised, then all AES session keys negotiated between these two clients (or one half of the session keys negiotated between one of these clients and another client) under these RSA key pairs are compromised, regardless of whether new session keys are generated during each key exchange, assuming the adversary can eavesdrop on the key exchange as they can the established session).

   When I skimmed the report previously, I did not see any claims in the report as to the confidentiality of the session being as strong as the underlying AES primitive with a 256 bit key nor to perfect forward secrecy.

3. “Tom found some code issues, didn’t he? Well are they fixed yet? Where is the proof? How will Skype continue to test their security with third parties like Anagram Labs?” Security is an on going process and one security evaluation will not be enough to convince the biggest of security skeptics.”

   Very true, reading the post on the Skype blog, there is no statement as to whether they actually made changes with respect to the issues discussed in the report. I also wonder if they are reading the comments on the report and other questions raised by security people.

This is not to put the Skype security assessment nor Michael Gough’s positive comments in a negative light. As stated in a previous post,

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.

My set of thoughts as I skimmed the report can be found in a previous post.

(Ok, time for some hot coffee!)

via Skype Journal

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