I J SRD - I nternational J ournal for Scientific Research & Development| Vol.

1, I ssue 4, 2013 | I SSN (online): 2321-0613

All rights reserved by www.ijsrd.com
Abstract— The invention of Voice over Internet Protocol
(VoIP) in communication technology created significant
attractive services for its users, it also brings new security
threats. Criminals exploit these security threats to perform
illegal activities such as VoIP malicious attacks, this will
require digital forensic investigators to detect and provide
digital evidence. Finding digital evidence in VoIP malicious
attacks is the most difficult task, due to its associated
features with converged network. In this paper, a Model of
investigating VoIP malicious attacks is proposed for
forensic analysis. VoIP spoofing is being a common and
most important threat to the VoIP users. It is technically
possible for an attacker to masquerade as another VoIP
caller (VoIP spoofing). A design of a SIP which will try to
capture all of the data on a VoIP network and process it for
forensic analysis with also detection of the spoofing or the
fake caller address.
Keywords: VoIP, Spoofing, Digital Evidence, Digital
Forensics, SIP
Securing VoIP is not an easy task, as it needs efforts in
several stages. One of the essential issues in VoIP security is
protecting the signaling messages being exchanged between
VoIP infrastructures. Signaling does not transfer voice
packets, but is designed for establishing, controlling,
modifying and terminating communications. The protection
of signaling includes integrity and confidentiality of
signaling messages as well as availability and confidentiality
of signaling services [1]. Another core issue in VoIP security
is protecting multimedia communications between
endpoints, which is a separate topic from signaling security.
It consist confidentiality, integrity and availability of
multimedia communications. In this thesis, the scope of our
research ONLY focuses on the security issues of SIP, a
signaling protocol. Security issues deal with the problems
encountered during the authentication phase rather than at
the communication phase. It focuses on the pre-requisites of
the communication so that the attacks can be avoided.
Traditionally, in the normal telephone network, it was much
harder to spoof Caller ID as at every end, a unique phone
number is assigned by the phone company. Today, with the
move to SIP trunks and VoIP technology, spoofing caller ID
is fairly trivial. It has been said that the nature of VoIP calls
make it difficult to trace the identity or location of the
callers. The most outstanding phenomena is Dialing
telephone numbers directly by the arbitrary number
modification software, for fraudulent activities which is
termed as CALLER ID SPOOFING. Existing protocol will
not provide the mechanism for spoofing detection and
prevention. The main challenge in VoIP is to accurately
identify that from where actually the call has been initialized
and identify the legitimate caller.

This research focuses on the tendency of the evildoers to
use existing communication technology while committing
the crime basically the SPOOFING in VoIP. The analysis
will be focused on the security of internet phone and design
a prevention method of internet phone call attack and the
attention points of setting up a internet phone to prevent it
from such phone frauds. A design of SIP which will prevent
VoIP spoofing using Public Key Infrastructure concepts and
use it as forensic analysis, all this will help in the detection
and prevention of the spoofing or identify the fake caller.
A. What is VoIP?
VoIP stands for-Voice over Internet Protocol (VoIP) or
transmission of voice over internet. In more simple terms,
one can say that VoIP is the transmission of voice over the
digital network. VoIP is an innovative technology which
enables its users to make calls through the existing packet-
switched networks (e.g., the Internet) instead of traditional
PSTN networks. The concept of VoIP is based on the factor
that packets running over an IP network can deliver different
kinds of multimedia contents including text, pictures, audio
and video.
B. VoIP Spoofing Attack
An attacker may insert fake (spoofed) messages into a
certain VoIP session to interrupt the service, or insert them
to steal the session. Attackers and spammers equently spoof
identities in order to become untraceable. It is possible for
an attacker to masquerade as another VoIP caller (VoIP
1) Why people are doing spoofing?
Attackers can use call spoofing for many cyber-crimes.
These may be the main reasons.
1) Making abusive or threatening calls.
2) Making calls from bank numbers to ask users
personal banking details.
3) Marketing company using this to fake a number to
show that it comes from local area. And then trick
users to sale their services.
C. Digital Evidence
Digital evidence or Electronic evidence is any probative
information stored or transmitted in digital form that a party
to a court case may use at trial. Before accepting digital
evidence a court will determine if the evidence is relevant,
whether it is authentic, if it is hearsay and whether a copy is
acceptable or the original is required.

Analysis of VoIP Forensics with Digital Evidence Procedure

Ovel Database-Centric Framework For Incremental Information
Riddhi Patel
Aditya K. Sinha
PG Student
Principal Technical Officer
Department of Computer Engineering, GTU, India
CDAC-ACTS, Pune, India

S.P.B.Patel Engineering College, Mehsana, Gujarat

Analysis of VoIP Forensics with Digital Evidence Procedure
(IJSRD/Vol. 1/Issue 4/2013/0020)

All rights reserved by www.ijsrd.com
1) Integrating Digital Evidence with VoIP call
1) In VoIP we can find address of spoofed call and
present it as evidence in court.
2) So, basically when a VoIP call is made to some one’s
phone and when one find sit as a spoofed(different)
address on the screen then here will try to prevent the
system from spoofed call after crime, if crime has been
done using VoIP, so we can get back to the attacker
using digital evidence. Here, the digital certificate
from CA for that particular user which has been shown
as caller ID can be presented as evidence.
A. Introducing SIP
SIP, developed by IETF, is a text-encoded protocol based on
elements from the HTTP and SMTP protocols. The primary
function of SIP is to establish or terminate a session between
two or more endpoints, but it also contains other important
function such as notification for presence and short
messaging services. Similar to email users, SIP users are
rep-resented by means of Uniform Resource Identifier
(URI), a universal name with a pair of domain name and a
user name registered for this domain. Most current SIP
applications in the real world employ a client/server
transaction model similar to HTTP. A SIP client generates
SIP request messages and a SIP server responds by
generating response messages. SIP RFC is RFC 3261.
That being said, SIP is flexible and open enough to
allow developers to build their own “hooks” into SIP. This
flexibility has given SIP an advantage over other
“telecommunications protocols,” and is why many
enterprises are eager to develop, implement, and use SIP.
SIP supports basically five services for managing
1) User Location: determination of the end system to
be used for communication
2) User Availability: determination of the willingness
of the called party to engage in communications.
3) User Capabilities: determination of the media and its
parameters to be used.
4) Call Setup: ringing and establishing call parameters
at both called and calling party.
5) Call handling: the transfer and termination of calls.
C. Components of SIP

1) User Agent Client: Actual client who is requesting
for call to establish. Eg: Soft phone, IP phone
2) User Agent Server: It is a server which is
responsible to initiate the call to the destination and
provides VoIP services.
3) Registration Server: In order to establish call, user
(UAC) has to get registered to the SIP server. So
registration server will performs the authorization
of user.
4) Proxy Server: It works as a forwarder, in which UA
will locate one proxy server, proxy will forward it
to another and so on up to the destination server. It
also provides routing, authentication, authorization,
address resolution, and loop detection.
D. Security mechanism in SIP RFC

Here, we have listed some of the security mechanisms with
a detailed explanation given below:
1) SIP Digest
This digest authentication algorithm (RFC-2617) is
currently the most frequently deployed security mechanism
with SIP. Derived from HTTP Digest it allows
authentication of a SIP subscriber (user agent, proxy-server
or registrar server). It is based on the transmission of a
shared secret, which consists of a checksum over a nonce
and parameters (user name, password, nonce, SIP method,
Request URI). SIP Digest does not exchange passwords.
The shared secret is hashed using MD5 or SHA- 1. SHA-1
is the IETF recommendation.
SIPS (SIP over SSL/TLS) protect sensitive data such as
SIP URI, IP addresses from sniffing or message
manipulation. The URI scheme slightly differs from the
conventional SIP URI: sips:this_is_me@sip.com. SIPS
encrypts a connection between a SIP subscriber and a SIPS
URI and the network instances (user agent, proxy server,
DNS server, location server) in between via SSL/TLS.
However, because of SSL/TLS SIPS has to be transmitted
via TCP, instead of UDP. The default TCP port for SIP
over TLS is 5061. User authentication is accomplished by
SIP Digest, which hashes the SIP message (digital
As RTP and RTCP do not offer any protection against
sniffing and manipulation of VoIP data, SRTP (Secure
Real-Time Transport Protocol; RFC-3711) has been
developed. It constitutes an alternative to IPsec based VPN
communications, particularly for real-time transport. SRTP
encrypts data symmetrically with AES2 (Advanced
Encryption Standard), i.e. SRTP is the secured variant of
RTP and SRTCP of RTCP respectively. They complicate
attacks such as sniffing, replay and DoS. For transportation
RTP/RTCP packets are encapsulated in SRTP/SRTCP
packets. Security features of SRTP comprise:
1) Encryption of the media stream (against sniffing)
2) Authentication of the sender (against identity
3) Validation of the integrity (against
4) Replay3 protection (against unauthorized access to
S/MIME (Security/Multipurpose Internet Mail Extension;
RFC-2311) has been originally designed to encrypt and
authenticate message bodies (MIME) in email
communications. However, MIME is not restricted to email
messaging. It can be applied for secured end-to-end
transport of message bodies within IP and thus it is suitable
for SIP. In addition to SDP parameters detailed subscriber
information data (e.g. presence information) can be secured
as well. In contrast to SIP, where encryption is only applied
on a “hop-by-hop” basis and thus information contained in
the message bodies are unencrypted within the traversed
SIP network, S/MIME offers “end-to-end” encryption.
Analysis of VoIP Forensics with Digital Evidence Procedure
(IJSRD/Vol. 1/Issue 4/2013/0020)

All rights reserved by www.ijsrd.com

Table (3): Overview of VoIP Security Protocol
We have two major weaknesses in HTTP digest
authentication in SIP. The first missing security issue is the
lack of securing all headers and parameters in SIP which
would possibly need protection. The second security
weakness, relating to digest authentication, is the
requirement of pre-existing user configuration on servers,
which does not scale well [9].Though, for authenticating in
cellular mobile communication, it provides simple
authentication. This solution enables a mutual authentication
between any devices and the network. This security policy
requires a shared secret key and a shared cryptographic
algorithm that exist in SIP. So, pre-share keys are one of the
main problems for security distributed keys and cause
algorithm load for encode and decode security information
packet. S/MIME in SIP is used on carrying signed or
encrypted replication of headers and authenticating users.
This mechanism lacks the public key distribution problem,
which means that the public keys used in authentication are
difficult to distribute and maintain. The public key
infrastructure is also susceptible to man-in-the middle attack
[3]. It uses several hash computations and server certificates
to ensure security. This causes overhead and reduction in
1) One of the crucial security issues faced by current SIP
Protocol in how to authenticate end user identities. In
SIP , the identity of an end user is defined by its SIP
Uniform Identifier(URI), Which typically has a
canonical address-of record(AoR), From field, for ex:
sip:alice@ . There are several places within a
SIP request where an end user can express his identity.
For example, the user populated From header field in the
SIP INVITE message. Hence an end user can spoof his
identity by inserting a false address in the From field and
there is no mechanism for verifying that field.
2) Source IP cannot be determine because VoIP assign IP
address dynamically. Since request and response each of
the header contains the field name as “Via:” which store
the path of each proxy so that receiver can communicate
to the same path but the problem is that what about the
path from UAC to proxy, proxy will not store that
address, only SIP address of the caller (UAC) will be in
the header but not any other information. So that makes
it difficult to reach to the caller. In the proposed SIP
stack they have the proxy which has the authentication
certificate. but they do not have the client which has its
own certificate which uniquely identifies the user and its
public key and private key. Another problem is the path
between caller (UAC) to proxy is still unsecure so that
the authentication is also unsecure because man in the
middle attack can be possible between UAC and proxy.
If the user is authorized then it won’t create any problem
but if the user is attacker and he wants to attack by doing
spoofed call then we can never determine that who has
done attack and from where it has been initiated because
VoIP uses dynamic IP address.
3) In the existing mechanism, SIP can provide client-to-
client protection only at the time of media exchange
using RTP and not at the time of authentication. So to
lessen the impact of the vulnerabilities from all the above
mentioned issues. There is a need for a stronger
authentication mechanism.
A. Proposed Authentication Mechanism
The proposed mechanism has the following features, as
shown below:
1) Proposes a transitive authentication mechanism
1) A new SIP header
2) An authentication service running on proxies
and UAC both
3) Only relevant for SIP requests, not responses
B. Steps in header verification
1) Acquire certificate for domain either stored or
2) Validate certificate, determine signer's authority over
3) Verify signature
4) Validate Date, Contact, Call-ID
We will start explaining the concept starting from the
problem mentioned below:
Suppose if Alice sends an INVITE message along with her
signature to Bob, then Bob would require Alice’s public key
to verify her signature. Hence in this case, Bob is faced with
two problems:
1) How and from where would Bob retrieve Alice’s
public key?
2) And how can Alice be sure that the key is actually
Bob’s public key and not the attacker’s public key?
Public Key Infrastructure (PKI) helps solve the above
problem. The purpose of PKI is to help Bob retrieve Alice’s
public key, and to assure Alice that the key really belongs to
Alice and not of somebody else. PKI distributes public keys
using public key certificates.
However, with VoIP communications the audio signal is
converted in several encrypted digital 'packets' which are
sent separately via different routes across the internet, only
re-collating when they reach the other user's computer. This
means that there is no exchange through which all the
information passes and so traditional methods of
interception are ineffective. Instead, the problem of
interception becomes one for computer forensic analysts.
Analysis of VoIP Forensics with Digital Evidence Procedure
(IJSRD/Vol. 1/Issue 4/2013/0020)

All rights reserved by www.ijsrd.com

Fig (1): Proposed Approach
A. Analysis of Modified SIP Protocol
The end user certificate and a server certificate has been
created by running the “riddhi_certificate_create” script in
the contrib/scripts shown as below.

Fig (2)
In the development, standardization and implementation of
LTE Networks based on Orthogonal Freq. Division Multiple
Access (OFDMA), simulations are necessary to test as well
as optimize algorithms and procedures before real time
establishment. This can be done by both Physical Layer
(Link-Level) and Network (System-Level) context. This
paper proposes Network Simulator 3 (NS-3) which is
capable of evaluating the performance of the Downlink
Shared Channel of LTE networks and comparing it with
available MATLAB based LTE System Level Simulator
KEY WORDS--3GPP, LTE, Downlink, NS-3, Simulator,
The Long Term Evolution (LTE) standard specified by the
3rd Generation Partnership Project (3GPP) is a new mobile
communication technology, which is evolution of the
Universal Mobile Telecommunications System (UMTS) and
High-Speed Packet Access (HSPA) systems. LTE intends to
deliver high speed data and multimedia services to next
generation. LTE is also backward compatible with the
CDMA family of technologies and thereby enables even
CDMA operators to move to this technology. The main
reasons for these changes in the Radio Access Network
(RAN) system design are the need to provide higher spectral
efficiency, lower delay, and more multi-user flexibility than
the currently deployed networks. LTE supports scalable
carrier bandwidths, from 1.4 MHz to 20 MHz and supports
both frequency division duplexing (FDD) and time-division
duplexing (TDD). The IP-based network architecture called
the Evolved Packet Core (EPC) is designed to replace the
GPRS Core Network. The LTE device has been conceived
as a container of several entities: the IP classifier, the RRC
entity, the MAC entity and the PHY layer. The core of the
LTE module is composed by both MAC and PHY layers of
an LTE device.
The Evolved Packet Core comprises the Mobility
Management Entity (MME), the Serving Gateway (SGW),
and the Packet Data Network Gateway (PGW). The MME is
responsible for user mobility, intra-LTE handover, and
tracking and paging procedures of User Equipment (UEs)
upon connection establishment. The main purpose of the
SGW is, instead, to route and forward user data packets
among LTE nodes, and to manage handover among LTE
and other 3GPP technologies. The PGW interconnects LTE
network with the rest of the world, providing connectivity
among UEs and external packet data networks. The LTE
access network can host only two kinds of node: the UE
(that is the end-user) and the eNB. Note that eNB nodes are
directly connected to each other (this speeds up signaling
procedures) and to the MME gateway. The eNB is the only
device in charge of performing both radio resource
management and control procedures on the radio interface.
Figure 1 shows Service Architecture Evolution in LTE
network [7].
After certificate generation, now we will try to
establish a call between two of the clients using the
certificates and then analyze the call for the resultant
scenario. For that we have to recompile our modified SIP
code and run SIP phone again.
Once a call has been established will capture the
VoIP Packets using WIRESHARK and analyze the
REGISTER packet. it will show that user is able to add his

Fig (3): modified SIP with URL
Analysis of VoIP Forensics with Digital Evidence Procedure
(IJSRD/Vol. 1/Issue 4/2013/0020)

All rights reserved by www.ijsrd.com
A. Modified SIP REGISTER Packet
The following figure shows the packet captured during a
normal VoIP call scenario.
1) Client (UAC A) to server normal

Fig. (4) SIP INVITE from Client (UAC A) to Server
After modifying the code, when client will establish a call,
at that time after capturing the packet (client to server) and
analyzing it, it shows an extra field showing the hash value.
2) Modified SIP INVITE packet Client (UAC A) to Server

Fig. (5) Modified SIP INVITE from Client to Server
The below figure shows the comparative analysis of the
hash generated manually for the header packet to the hash
generated by client in SIP packet and both the values show
same result. This again shows the normal call establishment
between Servers to client (UAC B). It has been added to
show a comparative analysis of the packets virtue to the
header fields modified and the proposed result
When client will establish a call, at that time after capturing
the packet (server to client) and analyzing it, it shows URL

Fig. (5) SIP INVITE from Server to Client (end user)
field which is added by server and also shows the hash
already generated by client.
3) Modified SIP INVITE Packet from Server to Client

Fig. (6) Modified SIP INVITE from Server to Client
At this point, the generated hash is encrypted by client and
able to send along with the original header to the receiver
side and at receiver side, the encrypted hash is decrypted
and compared with the hash value contained in the original
[1] R.Zhang, X. Wang, X. Yang, and X. Jiang. “Billing
attacks on SIP-based VoIP systems”. In WOOT ’07:
Proceedings of the first USENIX workshop on Oensive
Technologies, pages 1–8, Berkeley, CA, USA, 2007.
USENIX Association.
[2] Global NGN IP VoIP - Analyses Statistics and forecasts.
ductid=1513239&g=1 2007.
[3] D. Richard Kuhn, Thomas J. Walsh, Steffen Fries
“Security Consideration for Voice Over IP Systems”
National Institute of Standards & Technology.
[4] Paul Stalvig “Session Initiated Protocol – A Five Fun-
ction Protocol”
[5] Rakesh Arora “Voice Over IP Protocols and Standards”
[6] http://www.ietf.org/rfc/rfc3261.txt
[7] Jill Slay12, Matthew Simon1, David Irwin “Voice Over
IP And Forensics: A Review of Recent Australian
Work”, University of South Australia, Mawson Lakes,
[8] Prof. Dr. Even Eren, Dr. Kai-Oliver Detken “Voice-
over-IP Security Mechanisms – State-of-the-art, risks
assessment, concepts and recommendations”, 2007.
[9] A. Nemi, J. Arkko, V. Torvinen, '' Hypertext Transfer
Protocol(HTTP) Digest Authentication Using
Authentication and Key Agrement(AKA)”, IETF RFC
3310, 2002.

Sign up to vote on this title
UsefulNot useful