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 Voice over IP networks without proper licensing from Skype.
Numerous attempts to study and/or reverse engineer the protocol have been
undertaken to reveal the protocol, investigate security or to allow
unofficial clients. On June 20, 2014, Microsoft announced
the deprecation of the old Skype protocol. Within several months from
this date, in order to continue using Skype services, Skype users had to
update to Skype applications released in 2014, and users were not able to log in
to older Skype versions. There's no word on whether SmartTV and hardware phones
with built-in Skype functionality will continue to work without interruptions.
The new Skype protocol - Microsoft Notification Protocol 24 - promised
better offline messaging and better messages synchronization across Skype
devices. The deprecation became effective in the second week of August,
2014. Peer-to-peer architecture
Skype was the first peer-to-peer IP telephony network. The network contains
three types of entities: supernodes, ordinary nodes, and the login server.
Each client maintains a host cache with the IP address and port numbers of
reachable supernodes. The Skype user directory is decentralized and
distributed among the supernodes in the network.
Previously any client with good bandwidth, no restrictions due to
firewall or NAT, and adequate processing power could become a supernode. This
placed an extra burden on those who connected to the Internet without NAT,
as Skype used their computers and Internet connections as third parties
for UDP hole punching or to completely relay other users' calls. In 2012,
Microsoft altered the design of the network, and brought all supernodes
under their control as hosted servers in data centres. Microsoft at the time
defended the move, saying they "believe this approach has immediate performance,
scalability and availability benefits for the hundreds of millions of users
that make up the Skype community." At the time there was some concern
regarding the privacy implications of the change, which appear to have been
proven true with the revelation of the PRISM surveillance program in June 2013.
Skype does not support the use of the IPv6 protocol, which would greatly
reduce the complexity associated with the aforementioned IPv4 communication
structure. Supernodes relay communications on
behalf of two other clients, both of which are behind firewalls or
"one-to-many" Network address translation. Without relaying by the
Supernodes, two clients with firewall or NAT difficulties would be unable to make
or receive calls from one another. Skype tries to get the two ends to negotiate
the connection details directly, but sometimes the sum of problems at both
ends can prevent direct conversation being established.
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 reception of TCP
sessions Supernodes are grouped into slots, and
slots are grouped into blocks. Protocol
Signaling is encrypted using RC4; however, the method only obfuscates the
traffic as the key can be recovered from the packet. Voice data is encrypted with
AES. The Skype client's application
programming interface 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. The Skype code is closed source, and the
protocol is not standardized. Parts of the client use Internet Direct, an open
source socket communication library. On July 8, 2012, a researcher from
Benin, Ouanilo Medegan, released articles and proof of concept code,
results of his reverse engineering the Skype client.
= 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. Preliminaries
Abbreviations that are used: SN: Skype network
SC: Skype client HC: host cache
Skype client The main functions of a Skype client
are: login
user search start and end calls
media transfer presence messages
video conference = Login =
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 otherwise the login will fail. Here hc
means host cache i.e. the information that a skype client stores about the
list of supernodes(sc) 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
7. if not connected then 8. attempt TCP connection with HC
on port 443 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
public 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 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. UDP
UDP packets: IP
UDP Skype SoF
Skype Crypted Data01 The Start of Frame consists of:
frame ID number payload type
obfuscated payload Ack/NAck packet
payload forwarding packet payload resending packet
other 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. The XOR of these two 32-bit values is
transformed to an 80-byte RC4 key using an unknown key engine.
A notable misuse of RC4 in Skype can be found on TCP streams. The first 14 bytes
are XOR-ed with the RC4 stream. Then, the cipher is reinitialized to encrypt
the rest of the TCP stream. TCP
TCP packets: TCP
Skype Init TCP packet The Skype Init TCP packet contains
the seed 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 |
|------------------ 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 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 European Union law allows reverse-engineering a computer program
without getting a permission from an author for inter-operability purposes.
In the United States, the Digital Millennium Copyright Act provides
protections for reverse engineering software for the purposes of
interoperability with other software. There are also legal precedents in the
United States when the reverse-engineering is aimed at
interoperability of file formats and protocols.
In addition, some countries specifically permit a program to be copied for the
purposes of reverse engineering. Notes
References External links
Website containing articles and tools related to Skype protocol and behaviour
analysis Repository of articles on Skype analysis