Securing Voice Communication

SECURING VOICE COMMUNICATION

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

by Luca Pradovera

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

About meLuca Pradovera Voice Application Developer Mojo Lingo LLC, Atlanta, GA


CAN WE TRUST VOIP?NO.


Alice, Bob and Bubba

All cleartext!


Signaling: SIP(SESSION INITIATION PROTOCOL)


SIP is similar to HTTP

Request methods: INVITE, ACK, BYE

Headers: To, From


INVITE sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP 10.203.175.1:63851;rport;branch=z9hG4bKPjOZmllyLuQ52Gda.vzcmWrVVtmFKSyRuz

Max-Forwards: 70

From: "Luca Pradovera" <sip:[email protected]>;tag=DRTwWU5q2EfrbebG7IMvd3RdDbsKFPOX

To: <sip:[email protected]>

Contact: <sip:[email protected]: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:[email protected]", 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

a=rtpmap:0 PCMU/8000

a=rtpmap:8 PCMA/8000

a=rtpmap:96 telephone-event/8000

a=fmtp:96 0-15

a=sendrecv

SDP Payload


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 vulnerableForging Contact: to hijack a session

Denial of servicevia BYE

Easy man-in the middle attacks

Denial of servicevia REGISTER

Identity theft

DoS via Expires: 0


How do we solve this?SIPS(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

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

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


Media: RTP(REAL-TIME TRANSPORT PROTOCOL)


RTP BasicsUDP protocol

Ports 1024 to 65535


Let me hear you say…Packet sniffing 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 injectionBy predicting timestamp, sequence and SSRC, we can

play whatever frame we want.

“Did you just say something?


Audio replacementUsing 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 flooding (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 symmetric keys and ciphers that need to be negotiated somehow

Uses AES in counter mode (AES-CTR) with 128 or 256 bit keys

Generates a cypher stream that is XORed real-time with plaintext media

Headers are signed, payload is encrypted


Still need those keys…(NEGOTIATION)


MIKEY and SDES

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

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

MIKEY was never actually adopted because it requires additional SIP capabilities


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 does1. 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/

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

https://jitsi.org/

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

http://goo.gl/33EtU7

http://goo.gl/sFSsSi

http://goo.gl/U4QOJj


Thank you!• http://

mojolingo.com

• @lucaprado on Twitter

• polysics on Github and IRC

http://mojolingo.com

Technology

Securing Voice Communication