1. Skype

2. Overview P2P architecture Closed and proprietary design
Encryption of data
Obfuscation of protocol
Knowledge of protocol is due to analysis, not to standards or code
Different client platforms, e.g. mobile devices

3. Features Voice Video Conferencing Chat File transfer Client to client
Skypein and Skypeout connection with Telephone networks
Video
Conferencing
Chat
Usual features: e.g. status, profiles etc.
File transfer

4. History
Developed by the same Estonians that developed Kazaaa: Ahti Heinla, Priit Kasesalu and Jaan Tallinn
First version
2005 – Purchased by eBay

5. Network Architecture Skype Login server Super node Host node
Only centralized node
Authenticates users
Super node
Assists in calls
Location of peers
NAT traversal
Must not be behind firewall or NAT
Host node
Skypein servers
Skypeout servers

6. Registration Register a username with Skype web server
No real identity check
Install Skype client
Client software contains hard-coded, obfuscated list of login servers
Obfuscation?
Various tricks to hide what is actually there
Example: list of super nodes is encrypted and decryption only occurs when the software is running

7. Host Cache Each client has a host cache
Stores a list of super nodes and login servers
Similar in function to Chord finger table or Gnutella neighborhood
List of super nodes is updated during regular Skype operation
Upon login, client will attempt to contact one of the hosts in the host cache
In Windows XP, appears in C:\Documents and Settings\user\Application Data\Skype\shared.xml

8. Ports Each client listens on several ports
At installation a random port P is chosen
The client listens on P in UDP
The client listens on P in TCP
TCP 80 (HTTP)
TCP 443 (HTTPS)

9. Buddy List List of users which client “knows”
Can open a session with buddy
Aware of buddy presence
In Windows XP appears in C:\Documents and Settings\user\Application Data\Skype\Skype name\config.xml
Buddy list is also stored on a central Skype server
Skype stores 4 bytes per contact (this is some function of both the contact and the current user, i.e. two users with the same buddy have a different 4-byte identifier)

10. Login Functions Login proceeds by connecting to:
Connect to Skype network
Authenticate Skype client
Determine if client is behind NAT and discover real address and port
Update software version (if necessary)
Advertise presence
Login proceeds by connecting to:
Host in host cache (if exists)
One of hard-coded servers
Repeat many times

11. It just works Skype users are a cross section of society
Many are not knowledgeable about technology
Skype login may be hindered by
NAT
Firewall rules: blocking UDP, blocking certain IP addresses etc.
The Skype login process needs to work in the background and overcome obstacles

12. Connect to Skype Network
Choose a host from Host Cache (one of at most 200 possible choices)
Attempt to establish contact on host’s UDP port
If unsuccessful try next host in cache
If unsuccessful for 20 hosts
Assume that there is a firewall blocking Skype
Repeat the above with TCP ports
If unsuccessful, attempt to establish contact with 7 bootstrap nodes
Connect to UDP and if unsuccessful
Connect to TCP 33033

13. Skype Authentication Function: network authenticates Skype client
If client passes authentication, it can connect to other clients
If client doesn’t pass authentication, it can’t connect
The authenticator is a central node – one of the Skype login servers
The nodes that require data on the authentication are other nodes
How can the other nodes know of the authentication result?

14. (Failed) Attempts
Login server contacts all nodes and notifies them of authentication result
Login server gives Skype client a “cookie”, a unique random quantity that identifies it as legitimate
Skype client routes all its connections through login server
Login server generates a key for symmetric authentication and sends it to Skype client who uses it for every authentication

15. Overview of Skype Authentication
The last idea is not bad except we need a public key instead of a symmetric key
How does a node know that a public key is authorized by the login server?
A signature by the login server!
Two stages
The client authenticates to the login server using a <username, password> pair
The login server returns a signed public key

16. Authentication Process
Skype has a list of trusted RSA public keys
Client and login server have a shared key
Hashed password
Client generates a random session key
RSA with 1024 bit modulus
Client encrypts the shared secret with:
Symmetric encryption (AES 256 bits)
The key is a hash of the session key
Client uses one of the trusted RSA keys to encrypt a concatenation of
Session key
Random string

17. Authentication process (cont.)
Client sends to login server
Encrypted session key
Encrypted shared key
Login server decrypts both keys
Login server verifies that shared key is correct
If shared key is correct

18. Authentication (client – login server)
Quoted from “Skype uncovered Security study of Skype” by
Desclaux Fabrice1

19. Global Index
Many Skype operations are based on a Skype client finding data
What is my buddy’s IP address (to place a call)
What is the status of a contact
Find a user based on profile information
Relevant data must be published to network, e.g.
Client status
How does this work?
Skype needs the same functionality that Chord has
It is called Global Index (by Joltid corporation), but details are not public

20. Global Index (What is known?)
Super nodes have hierarchy
9-10 super nodes to a slot
8 slots per block
In 2006 there were 2050 slots (so about super nodes)
Each super node knows almost any other super node
Data is replicated (unlike Chord)
Finding an object requires limited multicast (request data from 4 super nodes, then 8 super nodes, then 16 etc.)
Skype claims that any user that has been logged on in the last 72 hours can be found

21. Global Index (cont.)
Failed search for users goes through central login servers
Possibly, these servers store all users who have logged on in the past 72 hours.

22. Skype Super Node Map (2006)
Quotes from “An Analysis of the Skype Peer-to-Peer Internet Telephony Protocol” bySalman Baset and Henning Schulzrinne

23. Voice call The call can be placed between two buddies Two stages
Signaling
Media
Several cases
Both peers have public addresses
One behind NAT
Both behind NAT

24. Two Public IP addresses
Signaling
Direct TCP connection between initiator and responder
Includes negotiation on CODEC, agreement on encryption key etc.
Includes extended services e.g. conferences
Media
Direct UDP connection between them

25. Addresses behind NAT One address behind NAT Two addresses behind NAT
Signaling through super node
Media directly between the peers
Two addresses behind NAT
Both signaling and media are relayed through one or more super nodes

26. Encryption RC-4 to obfuscate packet headers
AES 256-bit key to encrypt data (media, IM etc.)
RC-4 key is computed based on publicly available data such as the IP address (but what happens with NAT?)
AES key is transferred using the client’s RSA session key