Transcript Skype peer

INF570
Skype
dario.rossi
INF570
v09/2012
Dario Rossi
http://www.enst.fr/~drossi
Agenda
• What is Skype,
• What services it offers
• Overview on how we think it works
• Skype security phases
• Obfuscation, encryption & co (not on the exam)
• Details on
• Skype service traffic
• congestion control (bandwidth, loss, etc.)
• usage in real networks (call duration, etc.)
• Skype signaling traffic
• Normal period (volume, type and spatial properties)
• Breakdown event (overlay message storm)
• References
Why studying Skype ?
• Skype is very popular
– Succesful VoIP service over the unreliable Internet
– More than 100M users, 5% of all VoIP traffic (in 2007)
– Easy to use, many free services
• voice / video / chat / data transfer over IP
• Understanding Skype is a challenging task
–
–
–
–
Closed design, proprietary solutions
Almost everything is encrypted or obfuscated
Uses a P2P architecture
Lot of different flavors
Skype for Dummies
• Architecture
– P2P design
Skype for Dummies
• Architecture
– P2P design
• Service traffic
–
–
–
–
Voice calls
Video calls
Chat
Data transmission
Skype for Dummies
• Architecture
– P2P design
• Service traffic
–
–
–
–
–
Voice calls
Video calls
Chat
Data transmission
nodes may act as
relay when peers are
behind NAT
Skype for Dummies
• Architecture
– P2P design
• Service traffic
–
–
–
–
–
Voice calls
Video calls
Chat
Data transmission
Skypeout/Skypein
Skype for Dummies
• Architecture
– P2P design
• Service traffic
–
–
–
–
–
Voice calls
Video calls
Chat
Data transmission
Skypeout/Skypein
• Signaling traffic
– Login & auth.
– Look for buddies
– ….
Security phases
User registration
• Register username at Skype server
User login
• Get the one-time public key for the user certified by
Skype login server
User to User authentication
• Each user ensures the other is certified by Skype
User to User communication
• Get a one-time symmetric key for privacy enforcement
User registration
0. User selects a unique
username (over the Skype
domain) and a password
1. User sends username and
SHA-1 hash of password to
the Skype login server,
encrypted with the public
key of the Skype Server
2. Skype server extracts
username, hash of password
using its private key
→ Public Key of Skype Server
known to client during Skype
installation (hard-coded)
1. Ks+ ( usr, H(pwd) )
2. Ks- (Ks+ ( usr, H(pwd) ))
= usr, H(pwd)
• usr : unique over Skype’s domain
• Ks+ : public key for Skype Server
(hard-coded in Skype application)
• H(): SHA-1 hash
• H(pwd): stored securely in the client
User login
1. Skype client generates 1024-bits
public-private key pair (KA+, KA-)
•
One-time key pair for the user
for this login session
2. Client generates 256-bits
AES symmetric key (K)
3. Sends to Skype login server:
3. Ks+ (K), K (KA+, usr, H(pwd) )
• Encrypted KA username and SHA1 pwd hash using K
• Encrypted K using Skype
login
server public key Ks+
4. Ks-(Ks+ (K)) → K
• Extracts K using its private key Ks• Decrypts KA+, username, H(pwd)
using K.
5. Verify usr, H(pwd)
+,
4. Skype login server:
5. If username and password hash
match, user is authenticated.
6. Skype
Server signs username and
+
KA pair to give certificate (CA).
7. CA sent to user
K(K(KA+, usr, H(pwd)))
→ KA+, usr, H(pwd)
6. Ks-(usr, KA+) → CA
7. CA
User-to-user authentication
Users exchange certificates. Alice gets
Bob one-time public key KB+ from the
certificate CB using server public key KS+
• Ks-(usr, KB+) → CB
• KS+ (CB ) = KS+ ( Ks-(usr, KB+)) → usr, KB+
Each use 8 bytes challenge-response
method to authenticate each other
1. Alice sends challenge R1 to Bob
2. Bob sends KB- (R1) to Alice
3. Alice obtains challenge by applying
the one-time public key of the
certificate KB+(KB- (R1))
CA
CB
1. R1 (8 bytes)
2. KB- (R1)
3. KB+(KB- (R1)) == R1
User-to-user communication
1. After mutual authentication, Alice and
Bob establish a 256-bits common
session key Ks (AES) for encryption
2. Each side contributes 128-bits for the
256-bits long Ks
3. Each side sends its contribution to the
other side, encrypted with the latter’s
public key
4. Two 128-bits contributions combined
in some way (+) to generate the 256bits secret session key Ks
5. All traffic (voice, video and text) is
encrypted with symmetric key Ks
KB+(K1)
KA+(K2)
• KA-(KA+(K2)) → K2
• KB-(KB+(K1)) → K1
• K1 + K2 → Ks
• K1 + K2 → Ks
(now comes the funky part)
• Next slides courtesy of:
• Not in the exam, just for fun
(now comes the funky part)
• Partial reverse
engineering work
– Very long & detailed
– ~1hr video of the talk
available online
• In this context
– Useful to show what a
“proprietary” protocol is
– I.e., what to do when
there are no docs
– Mostly focus on
skype protection
+ some obfuscation
Is Skype malicious software?
Is Skype malicious software?
Is Skype malicious software?
Is Skype malicious software?
Binary packing: encryption
Binary packing: overwriting
Code integrity checks
Code integrity checks
Anti-debugging techinques
Code obfuscation
Note: KaZaa security was broken ultimately. So they were more
cautious with Skype
Code obfuscation
Note: KaZaa security was broken ultimately. So they were more
Network obfuscation
Network obfuscation
Network obfuscation
Network obfuscation
Packet compression
Packet compression
(some 50 slides later)
Well hidden traffic
• Encryption
• Skype adopts AES (Rijndel) cipher to encrypt information
• 256-bit long keys, or 1.1X1077 different keys
• 1536 or 2048 bit RSA is used to negotiate the
AES symmetric key
• Public keys are authenticated by the login server
• Obfuscation
• Encrypted payload is also obfuscated using
Arithmetic compression
• Headers that are not encrypted are obfuscated
using the RC4 Algorithm
State-of-the-Art
Encryption +
Obfuscation
Mechanisms
Available Skype Codecs
• E2E calls use preferentially
• SVOPC – starting ~2008
• iSAC – bit rate : 10-32 kbps (adaptive, variable) (30 ms frames)
• iLBC – bit rate : 13.3 kbps (30 ms frames) 15.2 kbps (20 m frames)
• E2O calls use preferentially
• G729 – bit rate : 11.5 kbps (20 ms frames) 30.2 kbps
• Other codecs are available
• iPCM-wb, G711A, G711U, PCM-A, PCM-U, …
• Skype framing alters the original codec framing
• Redundancy may be added to mitigate packet loss
• Frame size may be changed to reduce overhead impact
Skype Source Model
Skype
Message
TCP/UDP
IP
Types of Skype messages
• Depending on transport protocol:
• Use TCP when forced to, with ciphered payload
• Login, lookup and data: everything is encrypted
• Use UDP whenever possible, payload is encrypted
• But some header MUST be exposed
• Otherwise, in case of a packet loss, receiver could not
properly align and decrypt the rest of the flow (as in SSL/TLS)
TX data
RX data
Unreliable
AES
AES
Skype service traffic
Agenda
• Investigate Skype service traffic
• Methodology
• Service traffic (voice & video)
•
•
•
•
Service multiplexing
Skype reactions to transport layer
Skype congestion control
Skype loss recovery
• Users’ behavior
• Call volume and duration
• Further details on the papers
Preliminary Definition
•Useful information
–At installation, Skype chooses
a port at random
–The port is never changed
(unless forced by the user)
–All traffic multiplexed over the
same socket (UDP preferably)
Skype peer
– A Skype peer can be identified
by its L3/L4 endpoint
– Consider only peers that were
ever observed making a call
(IP addr, UDP port)
Skype flow
–UDP is connectionless (no
SYN/SYNACK sequence to detect
start of flow, nor FIN at the end)
– Sequence of packets originated
from a Skype peer (and destined to
another skype peer)
–Flow starts when the first packet is
observed
–Flow ends when no packet
is observed for a given inactivity
timeout (200s)
–Skype sends packets every
~120sec to keep NAT entries open
Methodolody
•Service traffic
•Small scale active testbed
•Measure Skype response to
controlled perturbation
•Control bandwidth, packet loss,
transport protocol, etc.
•User behavior
•Passive measurement technique
on real network (LAN and ISP)
•Own classification framework (see refs)
•Inspect and quantify unperturbed
Skype traffic of real users
7000 hosts
1700 peers
300.103
external
peers
Service Traffic: Normal Condition
• Unperturbed conditions
– Two peers, same LAN
– 100Mbps, <1ms delay
– Use different codecs
• Metrics
– Inter packet gap [ms]
Switched LAN
• (time between two
consecutive Skype
messages)
– Message size [Bytes]
– Bitrate [Kbps]
Service Traffic: Normal Condition
250
Smooth
Transient
200
Bitrate
[kbps]
ISAC
iLBC
iPCM-WB
PCM
G729
Normal
Behavior
150
Aggressive
Startup
100
50
0
0
10
20
30
Time [s]
40
50
60
Service Traffic: Normal Condition
Message
Payload
[Bytes]
300
200
100
ISAC
100
G729
50
300
200
100
iLBC
900
600
300
iPCM-WB
600
400
200
PCM
0
10
20
30
Time [s]
40
50
60
Service Traffic: Normal Condition
70
ISAC
iLBC
iPCM-WB
PCM
E2O G729
60
50
IPG
[ms]
40
30
20
10
0
0
10
20
30
Time [s]
40
50
60
Recall…
On unknown network
conditions (e.g., at the
beginning of a call),
Skype aggressively send
voice blocks twice to
counter potential losses
Service Traffic: Video Source
– Typical of voice call
– Back-to-back video
messages
800
0
80
[ms]
– Typical of voice calls
– Larger video messages
IPG
60
40
20
0
L
900
[Bytes]
– Voice and video
multiplexed over the
same UDP socket
400
200
• Message size
• Multiplexing
B
600
[kbps]
• Variable bitrate
• Inter packet gap
600
300
0
0
10
20
30
Time [s]
40
50
60
Service Traffic: TCP vs UDP
• Transport scenario
– Two peers, same LAN
– Blocking UDP with
a firewall
• Metrics
– Inter packet gap [ms]
Switched LAN
• (time between two
consecutive Skype
messages)
– Message size [Bytes]
– Bitrate [Kbps]
Under TCP
• No initial transient
• IPG unmodified
Kbps
Service Traffic: TCP vs UDP
– TCP PSH,URG flags
• Cautious with
bandwidth
– In case of loss, TCP
goes slow-start
(cwnd=1 segment)
– Call would be
likely stopped,
avoid slow-start!
Bytes
– TCP recover losses
ms
• Old blocks not
multiplexed
B - UDP
B - TCP
80
60
40
20
0
90
IPG - UDP
IPG - TCP
60
30
0
250
200
150
100
50
0
0
L - UDP
L -TCP
10
20
30
40
Time [s]
50
60
Service Traffic: Network impact
• Network impact
– Two peers, same LAN
– Artificially controlled
• bottleneck capacity
• packet losses
• Metrics
– Inter packet gap [ms]
Switched LAN
• (time between two
consecutive Skype
messages)
– Message size [Bytes]
– Bitrate [Kbps]
[ms]
Service Traffic: Congestion control
100
80
60
40
20
0
100
80
60
40
20
0
300
250
200
150
100
50
0
Average Throughput
Bandwidth limit
Framing
Skype Message Size
0
30
60
90
120 150 180 210 240 270 300
Time [s]
Skype
performs
congestion
control
adapting
coding
rate and
framing
Service Traffic: Loss recovery
Loss %
60
10
50
Inter-Pkt
Gap [ms]
8
40
6
30
4
20
Skype performs
loss recovery…
10
2
0
0
0
500
Payload
[Bytes]
100
200
300
400
500
10
Loss profile
400
8
300
6
200
4
...by multiplexing old
and new voice blocks
100
2
0
0
0
100
200
Time [s]
300
400
500
Service Traffic: User behavior
• Network scenario
– >1000 peers campus LAN
– Unperturbed environment
• Sniffing traffic at
the edge router
• Metrics
7000 hosts
1700 peers
300.103
external
peers
– Volume of calls
– Duration of calls
– Geolocalization, location of
Skype PSTN gateways, etc.
(see refs.)
User Behavior: Volume
•Asymmetry in the number
of calls per protocol type:
•Explanation:
- one direction UDP,
- the other TCP
Skype call duration & arrival process
• Free calls are longer, Poisson arrivals
Call duration
Experimental
quantiles
Paying
$kypeout
Free
voice
Negative exponential
quantiles
Call duration [min]
Free
video55
Skype signaling traffic
Agenda
Methodology
• Passive observation
on real networks Typical week
Signaling
•
•
•
•
Volume
Traffic pattern
Geolocalization
Message storm
Skype breakdown (Aug’07)
Flooding storm!
1700 internal peers
100 internal peers
Skype
300,000 external peers classifier 40,000,000 external peers
2,500,000 flows
33,000,000 packets
Internet
Internal peers
External peers
How much signaling traffic ?
Typically, limited amount
of signaling bandwidth
1
Yet, rather active
signaling exchanges
1
0.9
Cumulative
Distribution
Function
(CDF)
0.8
0.7
0.6
0.75
0.5
0.5
0.25
0.4
0.3
1
10
100
1000
Average per-peer
signaling bitrate [bps]
10000
0
0
25
50
75
Number of peers
contacted in 300 sec.
100
Skype spatial pattern
Each dot is
a packet
1500
1000
Each line
is a flow
500
Peer ID
0
-500
ID++ on
new peer
-1000
-1500
Time evolution [hr]
Skype spatial pattern
1500
1000
Outgoing
traffic
500
Peer ID
0
-500
-1000
-1500
Incoming
traffic
Time evolution [hr]
Skype spatial pattern
1500
1000
Skype network
probing
500
Peer ID
0
-500
Calls, buddy
updates, etc.
-1000
-1500
Time evolution [hr]
Skype spatial pattern
1500
1000
80% flows
5% bytes
500
Peer ID
0
-500
20% flows
95% bytes
-1000
-1500
Time evolution [hr]
Skype spatial pattern
•Probes
–Single packet toward unknown
peers; reply possibly follows
–No further traffic is exchanged
between the same peers pair
–Most of the flows (80%) are probes
•Dialogs
–More than a single packet sent toward the same
peer; buddy status & overlay mainenance
–Persistent activity, carries most of the signaling
bytes (95%)
Skype peers location
Paris
Turin
64
Skype peers location
Probability distribution function (pdf)
Probes
Others
• RTT distance
– Between first pair of
(request, reply) packets
• Two threads shape
the Skype overlay
– Probes favor discovery
of nearby hosts
– Buddy signaling and calls
driven by social network
Round Trip Time RTT [ms]
65
Flooding storm
•August 2007 (& 2010): massive Skype outage!
!?
Flooding storm
150
0
Flows
40k
0
Before
During
After
Incoming (-) and Outgoing (+) Traffic
LAN
Peers
40k
40k
Pkts
0
40k
4M
Bytes
0
4M
Thu 9th
Sun 12th
Thu 16th Sun 18th
August 2007
Thu 23th
Sun 25th
Flooding storm
• Probing traffic increase considerably
–
–
–
–
Before
During
After
4x more flows
3x more packets
10x more external peers
2x less bytes
• In the LAN,
August 2007
– Skype predominant portion of UDP traffic (70% bytes, 94% flows)
• 10 most active LAN peers
– receive almost all Skype traffic (94% bytes, 97% flows)
• The single most active peer
– 50% bytes 75% flows
– contacts 25% of all external pees seen
– namely 11 millions, a 30x increase
Everybody looking for
super-peers; significant
volumes of traffic handled
by some peer
Summarizing this course on
•Skype protocol and format
•Proprietary, complex, well hidden
•Not broken so far
•Service traffic
•Active testbed
•Application layer multiplexing
•Transport layer UDP/TCP usage
•Skype congestion and loss control
•Aggressive with losses
•Conservative with bottlenecks
•User behavior
•Call duration per service
•Call arrival still Poisson
•Free services preferred
•Signaling traffic
•Passive measurement
•Two different threads shapes
the Skype overlay
•Probes : selection driven by
proximity in the IP- network
(the close the better)
•Dialogs: Social network driven
(friends are everywhere)
•Signaling rate and spatial spread
•Large number of contacted
peers
•Typically, very limited bitrate
•Huge broadcast storm in case
of bugs/problems
References
• Mandatory readings
•
•
S. A., Baset, H. Schulzrinne, An Analysis of the Skype Peer-to-Peer Internet Telephony
Protocol. IEEE Infocom'06, Barcelona, Spain, Apr.2006.
D. Bonfiglio, M. Mellia, M. Meo and D.Rossi, Detailed Analysis of Skype Traffic. IEEE
Transactions on Multimedia, 11(1):117-127, January 2009. (preliminary version
appeared at IEEE Infocom08 ok as well)
• Optional readings
– P. Biondi, F. Desclaux, Silver Needle in the Skype. Black HatEurope'06, Amsterdam, the
Netherlands, Mar. 2006.
– S. Guha, N. Daswani and R. Jain, An Experimental Study of the Skype Peer-to-Peer VoIP
System, USENIX IPTPS, Santa Barbara, CA, Feb. 2006
– K. Ta Chen, C. Y. Huang, P. Huang, C. L. Lei Quantifying Skype User Satisfaction, ACM
Sigcomm'06, Pisa, Italy, Sep. 2006.
– D. Bonfiglio, M. Mellia, M. Meo, D. Rossi and P. Tofanelli, Revealing Skype Traffic: When
Randomness Plays with You . ACM SIGCOMM, Kyoto, Japan, August 2007.
– D. Rossi, M. Mellia and M. Meo, Understanding Skype Signaling . Elsevier Computer
Networks, 53(2):130-140, February 2009.
– D. Rossi, M. Mellia and M. Meo, Evidences Behind Skype Outage. In IEEE International
Conference on Communications (ICC'09), Dresde, Germany, June 2009
?? || //