Skype

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

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

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

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

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

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

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)

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)

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

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

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 33033 and if unsuccessful Connect to TCP 33033

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?

(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

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

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

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

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

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

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 20000 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

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.

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

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

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

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

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