Securing Voice Communication

SECURING VOICE
COMMUNICATION
(The NSA does not need to hear about this.)

by Luca Pradovera

About me
Luca Pradovera
Voice Application Developer
Mojo Lingo LLC, Atlanta, GA

Securing telephony - AdhearsionConf 2013 - December 4 and 5, Atlanta, GA

CAN WE
TRUST
VOIP?

NO.


Alice, Bob and Bubba

All
cleartext!

Signaling: SIP
(SESSION INITIATION PROTOCOL)


Request methods: INVITE,
ACK,
BYE
SIP is similar

to HTTP
Headers: To, From

INVITE sip:123@10.203.175.11 SIP/2.0
Via: SIP/2.0/UDP
10.203.175.1:63851;rport;branch=z9hG4bKPjOZmllyLuQ52Gda.vzcmWrVVtmFKSyRuz
Max-Forwards: 70
From: "Luca Pradovera" <sip:usera@10.203.175.11>;tag=DRTwWU5q2EfrbebG7IMvd3RdDbsKFPOX
To: <sip:123@10.203.175.11>
Contact: <sip:23941570@10.203.175.1:63851>
Call-ID: PvpN2LErALSXW16MbkJPBcZNf7fzeSc4
CSeq: 15461 INVITE
Allow: SUBSCRIBE, NOTIFY, PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, MESSAGE, REFER
Supported: 100rel, replaces, norefersub, gruu
User-Agent: Blink Pro 3.4.0 (MacOSX)
Authorization: Digest username="usera", realm="asterisk", nonce="080a602e", uri="sip:
123@10.203.175.11", response="40732f23b39bc681484874c89c424bf4", algorithm=MD5

SIP Headers

Content-Type: application/sdp
Content-Length: 396

!
v=0
o=- 3595073567 3595073567 IN IP4 10.203.175.1
s=Blink Pro 3.4.0 (MacOSX)
c=IN IP4 10.203.175.1
t=0 0
m=audio 50000 RTP/AVP 108 99 98 9 0 8 96
a=rtcp:50001
a=rtpmap:108 opus/48000
a=fmtp:108 useinbandfec=1
a=rtpmap:9 G722/8000

SDP
Payload

a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-15
a=sendrecv


Attacking SIP
(TRY THIS AT SOMEONE ELSE’S HOME.)


SIP digest auth is weak.
MD5-1 = MD5 (Username:Realm:Password) 
MD5-2 = MD5 (Method:URI) 
Response MD5 Value = MD5 (MD5-1:Nonce:MD5-2)

The only
unknown
term is
the password

=

An offline attack
is possible!


SIP is vulnerable
Forging Contact: to hijack a session
Easy man-in the
middle attacks
DoS via Expires: 0
Denial of service
via REGISTER

Denial of service
via BYE
Identity theft


SIPS
How do we solve this?
(SIP Secure)

Very similar to HTTPS - Requires client support

Software support
•

Asterisk: https://wiki.asterisk.org/wiki/display/AST/Secure
+Calling+Tutorial

•

FreeSWITCH: http://wiki.freeswitch.org/wiki/SIP_TLS

•

Many softphones and hardware phones


Media: RTP
(REAL-TIME TRANSPORT PROTOCOL)


RTP Basics
UDP protocol

Ports 1024 to 65535


Let me hear you say…
Packet snifﬁng enables easy eavesdropping

A switched network requires an ARP cache poisoning
attack but not much more

CREEPY DEMO TIME!

What if I want to be REALLY bad?
The timestamp usually starts with 0 and increments by the
length of the codec content (e.g. 160ms); the sequence starts
with 0 and increments by 1, and the SSRC is usually a static
value for the session and a function of time.

=
They are PREDICTABLE!

How can we have fun?


Audio injection
By predicting timestamp, sequence and SSRC, we can
play whatever frame we want.

“Did you just say
something?

Audio replacement
Using higher sequences and timestamp, we
make the original audio packets obsolete.

Just replace “buy” with “sell” and
watch Bitcoin crash!

What if I am just
grumpy?
DoS via packet ﬂooding
(keep repeating a packet)
DoS by RTCP Bye
(session teardown)


By the way, the NSA
knows about this.
(AND IN CASE THEY WERE MISSING ANYTHING, IT IS IN
MY DROPBOX ANYWAY)


SRTP

(Secure RTP)
Uses AES in counter mode (AESCTR) with 128 or 256 bit keys

Generates a cypher stream that
is XORed real-time with plaintext
media
Headers are signed, payload is
encrypted
Uses symmetric keys and
ciphers that need to be
negotiated somehow

Still need those keys…
(NEGOTIATION)


MIKEY and SDES
MIKEY was never actually adopted
because it requires additional SIP
capabilities

SDES (SDP Security Descriptions)
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32

requires full TLS protection and still exposes keying to
SIP servers.

Keying in the media
path: DTLS-SRTP
•

DTLS exchange over the media port

•

Uses secrets from the DTLS handshake as keying
information

•

Requires PKI (Public Key Infrastructure)

•

Used by WebRTC


ZRTP

(Z is cooler than S.)


What it does
1. Discovery phase, to find out if the peers
support ZRTP
2. Key agreement phase, to exchange the
keying data
3. Secure phase, confirming the
cryptographic exchange worked and
switching to SRTP


How it works
•

Exchange happens in
media path

•

Diffie-Hellman key
exchange

•

SAS (Short Authentication
String) produced so it can
be compared by humans


Hellman, the mayonnaise guy?


Why is the SAS important?
•

The Short Authentication String is computed with a
hash of the keys negotiated during DH exchange

•

It is usually a 4 digit number

•

It guarantees the absence of a man-in-the-middle

•

It is retained and reused for subsequent
communications


Benefits
•

Does not require any signaling security

•

It is, in fact, signaling and server agnostic (SIP, H.
323, Jingle, WebRTC)

•

Protected against man-in-the-middle attacks

•

Best-effort encryption with feedback (the user agent
knows if the line is secure or not)

•

It has a Z in the acronym.


Software support
•

FreeSWITCH: https://wiki.freeswitch.org/wiki/ZRTP

•

Jitsi: https://jitsi.org/

•

ZFone: http://zfoneproject.com/


Final caveats
•

You are never truly
secure

•

Ensure you never
drop out of the IP
network

•

Endpoints are easy
targets


Bibliography
•

Hacking VoIP: Protocols, Attacks and
Countermeasures (http://goo.gl/33EtU7)

•

SIP: Understanding the Session Initiation
Protocol (http://goo.gl/sFSsSi)

•

Applied Cryptography: Protocols, Algorithms, and
Source Code in C (http://goo.gl/U4QOJj)

•

Countless RFCs and extensions


Thank you!
•

http://
mojolingo.com

•

@lucaprado on
Twitter

•

polysics on
Github and IRC


Securing Voice Communication

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Securing Voice Communication

Ähnlich wie Securing Voice Communication (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Securing Voice Communication