6 voice-over-ip security

ITA, 27.10.2013, 6-VoIP_Security.pptx 1

Information Security 2 (InfSi2)

Prof. Dr. Andreas Steffen

Institute for Internet Technologies and Applications (ITA)

6 Voice-over-IPSecurity


Audio/video connection

directly via RTP

Call setup via SIP

Hop 2

Hop 1

Hop 3

Proxy Proxy

Security ?

sip:[email protected] sip:[email protected]

atlanta.com biloxi.com

VoIP Communications Channels

Authentication

Confidentiality / Data Integrity


Session Initiation Protocol (RFC 3261)

sip:[email protected] atlanta.com biloxi.com sip:[email protected]

ProxyProxy

200 OK F14

INVITE F2INVITE F4100 Trying F3

100 Trying F5180 Ringing F6

180 Ringing F7180 Ringing F8 200 OK F9

200 OK F10200 OK F11

Media Session

BYE F13

ACK F12

INVITE F1

User Agent UA


Without security measures anyone with network accesscan eavesdrop on a VoIP session!

Voice-over-IP Demo Session



6.1 Eavesdropping onMultimedia Sessions


Download: www.wireshark.org (Windows or Linux)

Network-Sniffing with Wireshark


Selecting a VoIP Call


Playing the RTP Media Stream


Download: www.oxid.it/cain.html (Windows)

Tapping VoIP Sessions with Cain



6.2 Securingthe Media Streams


Virtual LAN for Hardware IP Phones

VLAN A

VLAN B

A2A1 A3 A4 A5

B1 B2 B3 B4 B5

VLANSwitch

VLANSwitch

??


Secure RTP Packet Format (RFC 3711)

RTP payload

RTP header extension (optional)

V CC

0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7

P X M PT sequence number

timestamp

synchronization source (SSRC) identifier

contributing source (CSRC) identifiers...

RTP pad countRTP padding

authentication tag (recommended)32..80 bits

SRTP master key identifier (MKI, optional)

encr

ypte

d

auth

entica

ted


Secure RTCP Packet Format (RFC 3711)

sender info...

V RC

0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7

P X M PT=RR length

SSRC of packet sender

SRTCP master key identifier (MKI, optional)

encr

ypte

d

auth

entica

ted

report block 1...

report block 2...

...

SRTCP indexE

authentication tag32..80 bits


• Encryption uses AES in Counter Mode (AES-CTR) with 128 bit key

Default Encryption and Authentication Algorithms

• Authentication uses HMAC-SHA-1 with truncated 80 bit MAC

HMACSHA-1

auth_key160 bits auth tag

RTP/RTCP payload

80/32 bits

RTP/RTCP payload +

encr_keykeystream generator

AES-CTR128 bits

encrypted payload

128 bits IV = f(salt_key, SSRC, packet index)IV 112 bits

XOR


• Key Derivation uses AES in Counter Mode (AES-CTR)

Session Key Derivation

IV = f(master_salt, label, packet index)

encr_key

master_key

key derivationAES-CTR

128 bits192 bits256 bits

128 bits IV 112 bits

salt_key

auth_key

encr_key

auth_key

salt_key

0x00

0x01

0x02

0x03

0x04

0x05

SRTCPsessionkeys

SRTPsessionkeys

128 bits

160 bits

112 bits

128 bits

160 bits

112 bits

label

divkey derivation rate


SRTP for KphoneSilvan Geser &Christian HöhnHSR Project 2005

Problem:

How to distribute the

SRTP Master Key?

Media Stream Encryption with Secure RTP


Secure RTP

Needs a secret master key that must be distributed in a secure way.

The key exchange can be effected via the Session Description Protocol (SDP) payload that is transmitted during the SIP connection setup.

The SDP payload can be protected on a „hop-to-hop“ basis via TLS(i.e. SIPS). This approach allows „lawful inspection“ but on the down side requires full trust into the proxy-servers (SDP Security Descriptions, RFC 4568).

As an alternative the Multimedia Internet KEYing Protocol (MIKEY,RFC 3830) can be used which guarantees a true peer-to-peer keyexchange. MIKEY payloads are also transported via SDP.

IPsec

IPsec tunnels protecting media streams are set up via the Internet Key Exchange protocol (IKE). If there is already a site-to-site VPN or a remote access scheme in place then the VoIP calls can be transportedvia IPsec as well.

Drawback: Large IPsec overhead of 60-80 Bytes per RTP audio packet!

Securing the Media Streams


SDP Security Descriptions (RFC 4568)

v=0

o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5

s=SDP Seminar

i=A Seminar on the session description protocol

u=http://www.example.com/seminars/sdp.pdf

[email protected] (Jane Doe)

c=IN IP4 161.44.17.12/127

t=2873397496 2873404696

m=video 51372 RTP/SAVP 31

a=crypto:1 AES_CM_128_HMAC_SHA1_80

inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32

m=audio 49170 RTP/SAVP 0

a=crypto:1 AES_CM_128_HMAC_SHA1_32

inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32

m=application 32416 udp wb

a=orient:portrait


• RSA Public Key Encryption Method

MIKEY Key Exchange Methods

• Diffie-Hellman Key Exchange Method

HDR [IDi Certi] [IDr]

Env_Key Pub_Keyr

IDi TGK MAC Env_Key Sigi

KEMAC PKE

HDR [IDr] V

TGK = g(xi xr)

HDR [IDi Certi] [IDr] DHi Sigi DHi = gxi

HDR [IDr Certr] IDi DHi SigrDHr DHr = gxr


MIKEY payload embedded into SDP attachment

v=0

o=alice 2891092738 2891092738 IN IP4 w-land.example.com

s=Cool stuff

[email protected]

t=0 0

c=IN IP4 w-land.example.com

a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyONQ6gAAA...v9zV

m=audio 49000 RTP/SAVP 98

a=rtpmap:98 AMR/8000

m=video 52230 RTP/SAVP 31

a=rtpmap:31 H261/90000



6.3 Securingthe SIP Call Setup


Short advertising messages automatically spread in large numbers by SPIT-bots could become a big nuisance in the not too distant future.

Can content-based filtering methods known to work against SPAM successfully be applied to SPIT or will it become mandatory for callers to authenticate themselves in a cryptographically strong way?

As long as no ubiquitous VoIP authentication is in place on a global scale, the access to the ENUM Domain Name Service must be tightly controlled in order to prevent the systematic collection of SIP URIs.

My phone number +41 55 222 42 68 as an ENUM entry:

8.6.2.4.2.2.2.5.5.1.4.e164.arpa => sip:[email protected]

SPIT – SPam over Internet Telephony


Redirection or disruption of VoIP calls

If the SIP session management is not protected by special security measures an attacker can redirect VoIP calls to an arbitrary network destination (MITM attack) or can forcefully terminate them (DoS attack).

Dozens of VoIP signalling abuse scenarios have already been documented in the literature.

The call setup can be effectively secured by setting up a TLS session on a hop-to-hop basis (sips:[email protected])

Main problem: Lack of strong peer and gateway authentication

Man-in-the-Middle, Denial-of-Service or SPIT attacks can only be thwarted by a strong authentication of all communication parties

(both clients and gateways). The introduction of a Public Key Infrastructure (PKI) will become indispensable at least at the

domain level.

Abuse of VoIP Signalling


Securing the Session Management

Auth

entica

tion

Data

Inte

grity

Confidentialit

y

HTTP 1.0 Basic Authentication PSK - - Deprecated by SIPv2Insecure transmission of password

HTTP 1.1 Digest Authentication PSK - - Challenge/response exchange based on MD5 hash of [strong] password

Pretty Good Privacy (PGP) PKI Deprecated by SIPv2

Secure MIME (S/MIME) PKI For encryption the public key of the recipient user agent must be known

SIPS URI (TLS) PKI SIP application and proxies must tightly integrate TLS

IP Security (IPsec) PKI Integration with SIP application not required but proxies must be trusted

Authentication methods:

PSK Pre-Shared Keys

PKI Public Key Infrastructure


Audio/video connection

directly via RTP

Hop 2

Hop 1

Hop 3

Proxy Proxy

sip:[email protected]

atlanta.com biloxi.com

Dream or Nightmare?Strong PKI-based Security

Smartcards

sip:[email protected]


Lookup forAuthentication

Lookup forEncryption

sip:[email protected] sip:[email protected]

Pragmatical Approach: DomainKeys via DNS

SIP INVITE Messagewith MIKEY Record

HSR Diploma Thesis 2005 by Silvan Geser and Christian Höhn

alice._domainkey.atlanta.com

k=rsa; p=C4oBU … ExUn/7

bob._domainkey.biloxi.com

k=rsa; p=XuyDL … 4+wQK

DNS Server

biloxi.com

DNS Server

atlanta.com


openssl genrsa –out myPrivateKey.pem 1024

openssl rsa –in myPrivateKey –pubout –out myPublicKey

cat myPublicKey

-----BEGIN PUBLIC KEY-----

MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC1l4Y1oPxnYgrjKThuZVd1uJh2

xMiP+wzPd0czDGpkw5w8Ex0ZGHnws1GfMIqSpcUZgR5SxEbJGkbD+lyeEbHhPs0T

j37f3zar9LY3LTUCiTw7CfZHXAjC31VcSaeWrxEI+rjjnPjUWjEAHycWOYqxs+dr

fKt6gJJCz4UJZC3O9wIDAQAB

-----END PUBLIC KEY-----

Public Key Cache folder stores DomainKeys in the OpenSSLformat shown above:

alice._domainkey.atlanta.com

bob._domainkey.biloxi.com

andreas.steffen._domainkey.hsr.ch

DomainKeys Generation

k=rsa; p=MIGfMA0…wIDAQAB


SRTP - Confidentiality of VoIP Calls

The Secure RTP protocol (SRTP) offers efficient encryption andauthentication of multi-media packets. The main problem is thesecure distribution of the SRTP session keys.

MIKEY – Secure Peer-to-Peer Key Exchange

The MIKEY protocol allows the secure key exchange between two ormore peers. Two public key methods are defined: RSA public keyencryption (PKE) or Diffie-Hellman (DH). Both methods require thetrusted distribution of the peers‘ public keys. The main problem is thelack of a global Public Key Infrastructure (PKI).

DomainKeys – Global Public Key Distribution

The DNS-based DomainKeys scheme postulated by Yahoo et al. fortrusted email can be used for the public key operations required bythe MIKEY exchange. DNS requests are not very secure but currentlyDNSSEC is being deployed on a global scale.

DomainKeys fetching was realized by HSR students for the Kphoneand minisip clients as well as for the Soxy SIP security proxy server.

Summary


The original Skype used proprietary, undisclosed protocols. The client was a tamper-proof black box (Anti-debugger traps, partial code encryption, junkcode).

The original Skype used strong 256 bitAES call encryption and a 1024 bit RSA authentication key for each user.

Microsoft acquired Skype in October2011 and started to integrate it into itskey software and services.

Skype does not publish TransparencyReports detailing which user dataMicrosoft collects and makes availableto third parties!

Microsoft replaced peer-to-peersupernodes by 10’000 centralized Linux servers.

What about Skype?

6 voice-over-ip security

Documents