De-obfuscating the RC4 layer of Skype

Sean O'Neil, a security developer (or at least an amateur one), has posted code that is binary-compatible with an obfuscated version of RC4 that is used to protect Skype control traffic (user searches, profiles, contact lists). O’Neil says that the obfuscated version of RC4 is keyless and serves no useful security purpose, but its presence is intended to render Skype incompatible with other messaging clients, effectively making it a proprietary system. Even though Skype was intending to open its APIs to all desktop clients soon enough, O’Neil sees himself as buster of Skype’s 10 year monopoly.

The story is being widely reported in the press (see links below), and it is easy to assume that the general security of Skype has been compromised, especially when O’Neil’s own post carried the title Skype’s Biggest Secret Revealed. But the secret was disentangling the modified version of RC4 from Skype’s operation. User privacy remains protected since full strength versions of AES-256, RSA-1024 and RSA-2048 are used to encrypt session traffic. The code itself is surely obfuscated since the source is over 2800 lines of C, when 50 or so is enough to implement RC4.

The full implications of the discovery are still playing out, and whether losing their biggest secret poses a serious issue for Skype. O’Neil is promising to release more details at the Chaos Communication Conference in Berlin this December.

Related articles by Zemanta

• Skype encryption partially cracked? (voipsa.org)
• Skype's Innermost Security Layers Claimed To Be Reverse-Engineered (techcrunch.com)
• Hackers Crack Skype's Proprietary VOIP Protocol (techie-buzz.com)
• Encrypted and obfuscated? Your P2P protocol can still be IDed (arstechnica.com)
• Reverse engineer extracts Skype crypto secret recipe (go.theregister.com)

Conficker, RSA and RC4

I was reading the excellent paper An Analysis of Conficker's Logic and Rendezvous Points from SRI and was surprised to learn that Conficker botnet updates are distributed at its rendezvous points as encrypted and signed binaries using RC4 and RSA (the “R” in both cases here stands for Ron Rivest). Both the A and B variants of Conficker use these checks to ensure that the updates have been created by the Conficker authors – just like any other software vendor issuing updates and patches. The paper depicts the update process as follows

So each Conficker client carries an RSA public key E for signature verification. A Windows binary file F is encrypted and signed as follows

• Hash F to produce a 512-bit hash M
• Encrypt F with RC4 using M as the key
• Sign M using private key D

A Conficker client authenticates the encrypted binary as follows

• Using the embedded public key E, compute the signature verification to recover M
• Decrypt the encrypted binary using RC4 and M as the key
• Verify that the hash of F is in fact M

For Conficker A, the RSA key is 1024-bits and 2048-bits for Conficker B, both of which are listed in the paper. That’s a large public key for Conficker B but it is dwarfed by the 512-bit symmetric key used in RC4. Yes RC4 can support such huge key sizes, and I will explain in a future post how this is possible.