SIP Security MechanismsThrough a secure Software

Engineering approach

Prajwalan Karanjitpkaranji@cc.hut.fi

Agenda

• Introduction• Security Issues during phases of SDLC

– Requirements Engineering– System Design– Implementation– Testing

• Open Issues

Introduction• SIP Session Management Protocol, Signalling/Call Control

Protocol• Many Applications:

– VoIP, Distributed Classroom, Virtual Meeting, Shared Whiteboard, Publish/Subscribe based applications etc...

• Vulnerable to several attacks– Attacks on confidentiality/secrecy (sniffing, traffic analysis)– Attacks on integrity (message tampering, hijack REGISTER)– Attacks on authenticity (spoofing)– Attacks on availability (message fabrication, replay, false proxy )

• Countermeasures– TLS/SSL, S/MIME, Digest Authentication, IPSec, and many others ...

Introduction

• But, is just considering countermeasures enough ?– No, Not at all– A systematic and disciplined approach of development

– Security aspects need to considered in all phases of Software Development Life Cycle (SDLC)

• SQUARE (Security Quality Requirements Engineering)• UMLSec

– Safety critical systems require Spiral Model R. Anderson. Security Engineering: A Guide to Building Dependable Distributed Systems. Wiley, 2001.

– What about other models ? • Waterfall, Agile Development Methods, eXtreme Programming

Software Engineering

Boehm Spiral Model

Requirements Engineering

System Design

Implementation (Coding)

System Testing and Customer Review

Requirements Engineering

• What could an end user expect ?– Call should be established with right callee– Media will remain confidential throughout the path– Third party should not be able to see who is calling whom– Caller is charged correctly– It is possible to make calls when caller wants

• Security goals– Maintain confidentiality (Encryption)– Integrity protection ( MAC )– DoS protection ( Deal with replay, ... )– Entities involved are authenticated ( Both caller and callee )

Requirements Engineering

• Attacks and their impact Risk

Threat Impact

Sniffing the signal messages Loss of privacy

Sniffing the media Loss of privacy

Message tampering (Impersonating, Hijack REGISTER )

DoS, Loss of Integrity, Incorrect Billing, Unauthorized Access

Replay DoS, Incorrect Billing

Spam REGISTER and INVITE DoS

Fabricated Messages DoS, Incorrect Billing, Unauthorized Access

Tearing down session (e.g. BYE attack, CANCEL attack)

DoS, Incorrect Billing

Requirements Engineering

• Prioritize the Requirements

Requirement Priority Level

Connection to correct callee High

Proper billing High

Connection availability High

Signal Proctection High

Caller and callee identity protection High / Medium ???

Call Quality Medium

Media Protection Medium

System Design

• Several security mechanisms Which one to go for ?• Its important to analyze the tradeoffs associated with each

countermeasure– Lets analyze now

xyz.com

sip:bob@abc.comsip:alice@xyz.com

abc.com

Trudy

Digest Authentication

• Authenticating Client

– No Encryption No confidentiality– No guarantee of successful client authenticity Use Identity

Header(RFC 4474)

Digest Authentication UA and Proxy Authentication

* Source of Picture: Sawda, S., Urien, P.: SIP Security Attacks and Solutions: A state-of-the-art review. IEEE Network, (2006)

Identity Header

• First Step : Digest Authentication• Second Step :

FromToCall IDDateCseqContact

SHA - 1 RSA

Signature

Base 64

Identity

Private Key of Proxy

INVITE sip:bob@abc.com SIP 2.0From: ...To: ...Call-ID : ...Cseq: ...Contact: ...Date: ...Identity: ”IUSY89KJ%)(HASD=”Identity-Info: <https://somesite.com/xyz.cer>;alg=rsa-sha1Content-Type:....

TLS/DTLS• Provides confidentiality as well as integrity• Integrated key management• Hop by Hop Intermediate proxies must be trusted• If all the links do not use TLS/DTLS then security may be

compromised– ”sips:” URI is used to indicate that TLS must be used.

• TLS TCP, DTLS UDP• If signalling is also done over UDP Only DTLS may be sufficient• Using DTLS (without RTP) for media may result into high network

overhead• PKI Problem

S/MIME

• Encrypt the MIME body with public key of receiver• Provides both confidentiality and integrity• Entity authentication • Public key of receiver Obtained through X.509 certificate

(signed by trusted CA )• Additional overhead due to PKI• All the headers cannot be encrypted Request URI, Via,

Record-Route, To, From, Cseq, Call ID– OR, encrypt all the headers along with body and their hash over

header and body + attach unencrypted header

• End to End

IPSec

• Network layer security, so protects both TCP and UDP• Confidentiality, Integrity, Entity Authentication• Integrated Key Management• Transparent to application• But it is also based on PKI

• Deployment challenges– SAD, Administrative Rights, Support by all OS

• Hop by Hop• It seems like application will have to depend on the platform

Chang, C., Lu, Y.F., Pang, A.C., Kuo, T.W..: Design and Implementation of SIP Security.LNCS, vol. 3391, pp. 669--678. Springer, Heidelberg (2005)

Secure RTP

• Basically RTP based media protection• Confidentiality AES in key stream mode• Integrity HMAC-SHA-1• Replay based DoS Sequence Numbers• Low network overhead• Key Management Issue

– Have to depend on additional SIP signal + TLS or S/MIME– ZRTP key agreement protocol which performs Diffie-Hellman key

exchange for SRTP, No need of PKI, SAS (Short Authentication String)

• What if media is not RTP ?

So Which one to go with ?• Digest + Identity ...• S/MIME PKI problem• IPSec Deployment issues + PKI problem• TLS Trusted Proxies and all intermediate proxis must support it• SRTP Key Distribution issues and supports only RTP• DTLS TLS problems + network overhead if RTP is not used.

Requirement Solution

Connection to correct callee TLS/DTLS, S/MIME, IPSec

Proper billing Digest, TLS/DTLS, S/MIME, IPSec

Connection availability ???

Signal Proctection TLS/DTLS, S/MIME, IPSec

Caller and callee identity protection Digest, TLS/DTLS, S/MIME, IPSec

Call Quality ???

Media Protection DTLS, SRTP, IPSec

Implementation

• Configuration of different servers such as DNS, Proxies etc...• Developing custom proxies, UAs

– JAIN SIP + JAIN SDP from Sun Microsystems and NIST– SIP Servlet– SIP API for J2ME from Sun Microsystems and Nokia– As per recent documentation, none provides API support for above

security mechanisms Different API needed– Open SSL Strictly C based with Unix libraries

• Java and .NET based API• Visual C++ (Win 32 and MFC)

– Write Responsible codes

SIP Security Testing

• Should at least focus on security requirements identified in Requirements Engineering phase

• Should be performed by sending malformed SIP requests,• Sending a lot of authenticated and unauthenticated requests• Check of TLS or S/MIME or DTLS or SRTP support• Check if deprecated technologies are used• RTP or media tampering• Buffer overflow and SQL Injection ???

SIP Security Testing

• Tools:– SIPp: A free Open Source test tool / traffic generator for the SIP protocol.

– PROTOS SIP Fuzzer: - Tool that sends a set of malformed SIP messages.

– SiVuS: A SIP Vulnerability Scanner that scans for SIP targets and attacks them

– SIPNess: A basic tool to construct, send or receive SIP messages

– SIPBomber: A sip-protocol [RFC3261] testing tool

– SFTF: A SIP Forum test framework to evaluate and report the security and robustness of a SIP user agent

Open Issues

• Denial of Service Attacks– Against UA, Proxies– Flooding Set threshold for each user in the proxy

• How to know that proxy is authorized for a particular domain – Attribute Certificate– Existing X.509 fields ??

• Will the method described in this paper really result into a secure SIP based product ?

Summary

• SIP is highly vulnerable to several attacks• Security Mechanims are there, but each of them have their

own tradeoffs– Mainly implementation issues and practical problems

• Security should be considered through all the phases of SDLC– From Requirements Engineering to Testing