|This article may need to be rewritten entirely to comply with Wikipedia's quality standards, as the article is too technical in its nature (see Talk Page). You can help. The discussion page may contain suggestions. (August 2009)|
|Part of a series on|
Microsoft Skype Division
Features of Skype
The Skype protocol is a proprietary Internet telephony network based on peer-to-peer architecture, used by Skype. The protocol's specifications have not been made publicly available by Skype and official applications using the protocol are closed-source.
The Skype network is not interoperable with most other VoIP networks without proper licensing from Skype. Digium, the main sponsor of Asterisk PBX released a driver licensed by Skype dubbed 'Skype for Asterisk' to interface as a client to the Skype network, however this still remains closed source. Numerous attempts to study and/or reverse engineer the protocol have been undertaken to reveal the protocol, investigate security or to allow unofficial clients.
 Peer-to-peer architecture
Skype was the first peer-to-peer IP telephony network, requiring minimal centralized infrastructure. The Skype user directory is decentralized and distributed among the clients, or nodes, in the network.
Any client with good bandwidth, no restriction due to firewall or NAT, and adequate processing power can become a supernode. This puts an extra burden on those who connect to the Internet without NAT, as Skype may use their computers and Internet connections as third party for UDP hole punching (to directly connect two clients both behind NAT) or to completely relay other users' calls. Skype does not choose to supply server power with associated bandwidth required to provide the relay service for every client who needs it, instead it uses the resource of Skype clients. 
Supernodes relay communications on behalf of two other clients, both of which are behind firewalls or "one to many" Network address translation. The reason that relaying is required is that without relaying clients with firewall or NAT difficulties, the two clients would be unable to make or receive calls from other. Skype tries to get the two ends to negotiate the connection details directly, but what can happen is that the sum of problems at both ends can mean that two cannot establish direct conversation.
The problems with firewalls and NAT can be
- The external port numbers or IP address are not derivable, because NAT rewrites them,
- The firewall and NAT in use prevents the session being received
- UDP is not usable due to NAT issues , such as timeout
- firewalls block many ports
- TCP through many to one NAT is always "outward only" by default - Adding Port Forwarding settings to the NAT router can allow receiving TCP sessions
Supernodes are grouped into slots (9-10 supernodes), and slots are grouped into blocks (8 slots).
The Skype client's application programming interface (API) opens the network to software developers. The Skype API allows other programs to use the Skype network to get "white pages" information and manage calls.
 Protocol detection
Many networking and security companies claim to detect and control Skype's protocol for enterprise and carrier applications. While the specific detection methods used by these companies are often proprietary, Pearson's chi-squared test and stochastic characterization with Naive Bayes classifiers are two approaches that were published in 2007.
Abbreviations that are used:
- SN: Skype network
- SC: Skype client
- HC: host cache
 Skype client
The main functions of a Skype client are:
- user search
- start and end calls
- media transfer
- presence messages
- video conference
A Skype client authenticates the user with the login server, advertises its presence to other peers, determines the type of NAT and firewall it is behind and discovers nodes that have public IP addresses.
To connect to the Skype network, the host cache must contain a valid entry. A TCP connection must be established (i.e. to a supernode) otherwise the login will fail.
1. start 2. send UDP packet(s) to HC 3. if no response within 5 seconds then 4. attempt TCP connection with HC 5. if not connected then 6. attempt TCP connection with HC on port 80 (HTTP) 7. if not connected then 8. attempt TCP connection with HC on port 443 (HTTPS) 9. if not connected then 10. attempts++ 11. if attempts==5 then 12. fail 13. else 14. wait 6 seconds 15. goto step 2 16. Success
After a Skype client is connected it must authenticate the username and password with the Skype login server. There are many different Skype login servers using different ports. An obfuscated list of servers is hardcoded in the Skype executable.
Skype servers are:
Skype-SW connects randomly to 1-8.
On each login session, Skype generates a session key from 192 random bits. The session key is encrypted with the hard-coded login server's 1536-bit RSA key to form an encrypted session key. Skype also generates a 1024-bit private/public RSA key pair. An MD5 hash of a concatenation of the user name, constant string ("\nSkyper\n") and password is used as a shared secret with the login server. The plain session key is hashed into a 256-bit AES key that is used to encrypt the session's public RSA key and the shared secret. The encrypted session key and the AES encrypted value are sent to the login server.
On the login server side, the plain session key is obtained by decrypting the encrypted session key using the login server's private RSA key. The plain session key is then used to decrypt the session's public RSA key and the shared secret. If the shared secret match, the login server will sign the user's public RSA key with its private key. The signed data is dispatched to the super nodes.
Upon searching for a buddy, a super node will return the buddy's public key signed by Skype. The SC will authenticate the buddy and agree on a session key by using the mentioned RSA key.
IP UDP Skype SoF Skype Crypted Data01
The Start of Frame (SoF) consists of:
- frame ID number (2 bytes)
- payload type (1 byte)
- obfuscated payload
- Ack/NAck packet
- payload forwarding packet
- payload resending packet
 Obfuscation Layer
The RC4 encryption algorithm is used to obfuscate the payload of datagrams.
- The CRC32 of public source and destination IP, Skype's packet ID are taken
- Skype obfuscation layer's initialization vector (IV).
The XOR of these two 32-bit values is transformed to a 80-byte RC4 key using an unknown key engine.
A notable misuse of RC4 in Skype can be found on TCP streams (UDP is unaffected). The first 14 bytes (10 of which are known) are xored with the RC4 stream. Then, the cipher is reinitialized to encrypt the rest of the TCP stream.
TCP Skype Init TCP packet
The Skype Init TCP packet contains
- the seed (4 bytes)
- init_str string 00 01 00 00 01 00 00 00 01/03
 Low-level datagrams
Almost all traffic is ciphered. Each command has its parameters appended in an object list. The object list can be compressed.
/ Object List ... -| Enc -> Cmd -> Encod ^ \ Compressed List ... -| Frag | | |------------------<---------------| Ack
Forward -> Forwarded..Message
 Object Lists
An object can be a number, string, an IP:port, or even another object list. Each object has an ID. This ID identifies which command parameter the object is.
Object: Number IP:Port List of numbers String RSA key
Object List List Size (n) Object 1 . . Object n
 Packet compression
Packets can be compressed. The algorithm is a variation of arithmetic compression that uses reals instead of bits.
 Legal issues
Reverse engineering of the Skype protocol by inspecting/disassembling binaries is prohibited by the terms and conditions of Skype's license agreement. However there are legal precedents when the reverse-engineering is aimed at interoperability of file formats and protocols. In the United States, the Digital Millennium Copyright Act grants a safe harbor to reverse engineer software for the purposes of interoperability with other software. In addition, many countries specifically permit a program to be copied for the purposes of reverse engineering.
- ^ Skype for Asterisk – Production Released!, By pengler, August 31st, 2009, Digium - The Asterisk Company
- ^ Page 11 in Salman A. Baset; Henning Schulzrinne (2004). "An analysis of the Skype peer-to-peer Internet telephony protocol". arXiv:cs/0412017v1 [cs.NI].
- ^ Skype "3.3 Utilization of Your Computer", End User License Agreement, August 2010
- ^ Introduction Skype analysis Enforcing anti-Skype policies, Skype uncovered Security study of Skype, Desclaux Fabrice, 7/11/2005, EADS CCR/STI/C
- ^ http://support.skype.com/en_US/faq/FA153/Which-protocols-does-Skype-use[dead link]
- ^ Dario Bonfiglio et al. “Revealing Skype Traffic: When Randomness Plays with You,” ACM SIGCOMM Computer Communication Review, Volume 37:4 (SIGCOMM 2007), p. 37-48
- ^ Fabrice Desclaux, Kostya Kortchinsky (2006-06-17). "Vanilla Skype part 2". RECON2006. http://www.recon.cx/en/f/vskype-part2.pdf.
- ^ Sega vs Accolade, 1992
- ^ Sony vs Connectix, 2000
- ^ Pamela Samuelson and Suzanne Scotchmer, "The Law and Economics of Reverse Engineering", 111 Yale Law Journal 1575-1663 (May 2002) 
- ^ 17 U.S.C. Sec. 1201(f).
- ^ WIPO Copyright and Performances and Phonograms Treaties Implementation Act
- ^ In the French "intellectual property" law set, there is an exception that allows any software user to reverse engineer it. See code de la propriété intellectuelle (French). This law is the national implementation of a piece of EU legislation: Council Directive 91/250/EEC, since then repealed by Directive 2009/24/EC of the European Parliament and of the Council of 23 April 2009 on the legal protection of computer programs which also has a very similar provision allowing reverse engineering/decompilation for the purposes of development and testing of independent but inter-operating programs).
- Salman A. Baset; Henning Schulzrinne (2004). "An analysis of the Skype peer-to-peer Internet telephony protocol". arXiv:cs/0412017v1 [cs.NI].
- P. Biondi and F. Desclaux (March 3, 2006). "Silver Needle in the Skype". http://www.blackhat.com/presentations/bh-europe-06/bh-eu-06-biondi/bh-eu-06-biondi-up.pdf.
- F. Desclaux and K. Kortchinsky (June 6, 2006). "Vanilla Skype - part 1". http://www.recon.cx/en/f/vskype-part1.pdf.
- F. Desclaux and K. Kortchinsky (June 17, 2006). "Vanilla Skype - part 2". http://www.recon.cx/en/f/vskype-part2.pdf.
- L. De Cicco, S. Mascolo, V. Palmisano (May 2007). "An Experimental Investigation of the Congestion Control Used by Skype VoIP.". WWIC 07. Springer. http://c3lab.poliba.it/images/d/d2/Skype_wwic07.pdf.
- L. De Cicco, S. Mascolo, V. Palmisano (December 9–11, 2008). "A Mathematical Model of the Skype VoIP Congestion Control Algorithm.". Proc. of IEEE Conference on Decision and Control 2008. http://c3lab.poliba.it/images/2/22/Skype_voip_model.pdf.
- Dario Bonfiglio, Marco Melia, Michela Meo, Dario Rossi, Paolo Tofanelli (August 27–31, 2007). "Revealing Skype Traffic: When Randomness Plays With You". ACM SIGCOMM Computer Communication Review. https://www.dpacket.org/articles/revealing-skype-traffic-when-randomness-plays-you.
- Repository of articles on Skype analysis
- Reversed skype protocol, this torrent contain sources in c++