QQ:41806229 点击这里在线咨询代写
网  址:http://www.assignment.cc/
代写essay,End to End VoIP Security
发表日期:2013-09-16 08:45:32 | 来源:assignment.cc | 当前的位置:首页 > 代写essay > 正文


User communications applications are in high demand in the Internet user community. Two classes of such applications are of great importance and attract interest by many Internet users: collaboration systems and VoIP communication systems. In the first category reside systems like ICQ , MSN Messenger and Yahoo! Messenger while in the latter, systems like Skype and VoipBuster are dominating among the public VoIP clients. In the architecture plane, collaboration systems form a distributed network where the participants communicate with each other and exchange information. The data are either routed from the source through a central server to the recipient or the two clients communicate directly. The participants in such networks are both content providers and content requestors . On the other hand, the data communication path in the VoIP systems is direct between the peers, without any involvement of the service network in the data exchange path with some exceptions like Skype’s “supernode” communications. Data are carried over public Internet infrastructures like Ethernets, WiFi hotspots or wireless ad hoc networks. Security in these networks is a critical issue addressed in several different perspectives in the past.

In this assignment I focus on cryptographic security implementation in VoIP. Security is implemented dynamically in cooperation by the two (or more) peers with no prior arrangements and requirements, like out of band exchanged keys, shared secrets etc. Ease of use (simplicity), user friendliness (no special knowledge from the user side) and effectiveness (ensuring confidentiality and integrity of the applications) combined with minimal requirements on end user devices are the goals achieved by our approach. We leverage security of user communications, meeting all the above requirements, by enhancing the applications architecture with VoIPSec security elements.

Over the past few years, Voice over IP (VoIP) has become an attractive alternative to more traditional forms of telephony. Naturally, with its in-creasing popularity in daily communications, re-searchers are continually exploring ways to improve both the efficiency and security of this new communication technology. Unfortunately, while it is well understood that VoIP packets must be encrypted to ensure confidentiality, it has been shown that simply encrypting packets may not be sufficient from a privacy standpoint. For instance, we recently showed that when VoIP packets are first compressed with variable bit rate (VBR) encoding schemes to save bandwidth, and then encrypted with a length preserving stream cipher to ensure confidentiality, it is possible to determine the language spoken in the encrypted conversation.

As surprising as these findings may be, one might argue that learning the language of the speaker (e.g., Arabic) only affects privacy in a marginal way. If both endpoints of a VoIP call are known (for example, Mexico City and Madrid), then one might correctly conclude that the language of the conversation is Spanish, without performing any analysis of the traffic. In this work we show that the information leaked from the combination of using VBR and length preserving encryption is indeed far worse than previously thought.


This assignment is about security, more specifically, about protecting one of your most precious assets, your privacy. We guard nothing more closely than our words. One of the most important decisions we make every day is what we will say and what we won’t. But even then it’s not only what we say, but also what someone else hears, and who that person is.

Voice over IP- the transmission of voice over traditional packet-switched IP networks—is one of the hottest trends in telecommunications. Although most computers can provide VoIP and many offer VoIP applications, the term “voice over IP” is typically associated with equipment that lets users dial telephone numbers and communicate with parties on the other end who have a VoIP system or a traditional analog telephone. (The sidebar, “Current voice-over-IP products,” de-scribes some of the products on the market today.)

As with any new technology, VoIP introduces both opportunities and problems. It offers lower cost and greater flexibility for an enterprise but presents significant security challenges. Security administrators might assume that because digitized voice travels in packets, they can simply plug VoIP components into their already se-cured networks and get a stable and secure voice net-work. Unfortunately, many of the tools used to safeguard today’s computer networks—firewalls, network address translation (NAT), and encryption—don’t work “as is” in a VoIP network. Although most VoIP components have counterparts in data networks, VoIP’s performance demands mean you must supplement ordinary network software and hardware with special VoIP components.

Integrating a VoIP system into an already congested or overburdened network can be disastrous for a company’s technology infra-structure. Anyone at- tempting to construct a VoIP network should therefore first study the procedure in great detail. To this end, we’ve outlined some of the challenges of introducing appropriate security measures for VoIP in an enterprise.

End-to-End Security

IN this assignment I am going to describe the end-to-end security and its “design principle” that one should not place mechanisms in the network if they can be placed in end nodes; thus, networks should provide general services rather than services that are designed to support specific applications. The design and implementation of the Internet followed this design principle well. The Internet was designed to be an application-agnostic datagram de-livery service. The Internet of today isn’t as pure an implementation of the end-to-end design principle as it once was, but it’s enough of one that the collateral effects of the network not knowing what’s running over it are becoming major problems, at least in the minds of some observers. Before I get to those perceived problems, I’d like to talk about what the end-to-end design principle has meant to the Internet, technical evolution, and society. The Internet doesn’t care what you do—its job is just to “deliver the bits, stupid” (in the words of David Isenberg in his 1997 paper, “Rise of the Stupid Network”2). The “bits” could be part of an email message, a data file, a photograph, or a video, or they could be part of a denial-of-service attack, a malicious worm, a break-in attempt, or an illegally shared song. The Net doesn’t care, and that is both its power and its threat.

The Internet (and by this, I mean the Arpanet, the NSFNet, and the networks of their successor commercial ISPs) wasn’t designed to run the World Wide Web. The Internet wasn’t designed to run Google Earth. It was designed to support them even though they did not exist at the time the foundations of the Net were designed. It was designed to support them by being designed to transport data without caring what it was that data represented.

At the very first, the design of TCP/IP wasn’t so flexible. The initial design had TCP and IP within a single protocol, one that would only deliver data reliably to a destination. But it was realized that not all applications were best served by a protocol that could only deliver reliable data streams. In particular, timely delivery of information is more important than reliable delivery when

trying to support interactive voice over a network if adding reliability would, as it does, increase delay. TCP was split from IP so that the application running in an end node could determine for itself the level of reliability it needed. This split created the flexibility that is currently being used to deliver Skype’s interactive voice service over the same network that CNN uses to deliver up-to-the-minute news headlines and the US Patent and Trademark office uses to deliver copies of US patents.

Thus the Internet design, based as it was on the end-to-end principle, became a generative facility. Unlike the traditional phone system, in which most new applications must be installed in the phone switches deep in the phone net-work, anyone could create new applications and run them over the Internet without getting permission from the organizations that run the parts of the Net. This ability was exploited with “irrational exuberance”4 during the late 1990s Internet boom. But, in spite of the hundreds of billions of dollars lost by investors when the boom busted, the number of Internet users and Web sites, the amount of Internet traffic, and the value of Internet commerce have continued to rise, and the rate of new ideas for Internet-based services hasn’t no- ticeably diminished.

Security and privacy in an end-to-end world

The end to end arguments paper used “se-cure transmission of data” as one reason that an end-to-end design was required. The paper points out that network-level or per-link encryption doesn’t actually provide assurance that a file that arrives at a destination is the same as the file that was sent or that the data went unobserved along the path from the source to the destination. The only way to ensure end-to-end data integrity and confidentiality is to use end-to-end encryption.

Thus, security and privacy are the responsibilities of the end nodes. If you want to ensure that a file will be transferred without any corruption, your data-transfer application had better include an integrity check, and if you didn’t want to allow anyone along the way to see the data itself, your application had better encrypt it before transmitting it.

There are more aspects to security on a network than just data encryption. For example, to ensure that communication over the net-work is reliable, the network itself needs to be secure against attempts—purposeful or accidental—to disrupt its operation or redirect traffic away from its intended path. But the original Internet design didn’t include protections against such attacks. Even if the network is working perfectly, you need to actually be talking to the server or person you think you are. But the Internet doesn’t pro-vide a way, at the network level, to assure the identities of its users or nodes. You also need to be sure that the message your computer re receives isn’t designed to exploit weaknesses in its software (such as worms or viruses) or in the ways that you use the Net. Protection against such things is the end system’s responsibility.

Note that there is little that can be done “in the Net” or in your end system to protect your privacy from threats such as the government demanding the records of your use of Net-based services such as Google, which collect information about your network usage.

Many of today’s observers assume that the lack of built-in protections against attacks and the lack of a se-cure way to identify users or nodes was a result of an environment of trust that prevailed when the original Internet design and protocols were developed. If you trusted the people on the Net, there was no need for special defensive functions. But a few people who were “at the scene” have told me that such protections were actively discouraged by the primary sponsor of the early Internet—that is to say, the US military wasn’t all that interested in having good nonmilitary security, maybe because it might make its job harder in the future. Whatever the reason, the Internet wasn’t designed to provide a secure environment that included protection against the malicious actions of those who would disrupt it or attack nodes or services provided over it.

End-to-end security is not dead yet, but it is seriously threatened, at least at the network layer. NATs and firewalls interfere with some types of end-to-end encryption technology. ISPs could soon be required by regulations to, by default, filter the Web sites and perhaps the protocols that their customers can access. Other ISPs want to be able to limit the protocols that their customers can access so that the ISP can give service providers an “incentive” to pay for the customer’s use of their lines—they don’t see a way to pay for the net-work without this ability. The FBI has asked that it be able to review all new Internet services for tapability before they’re deployed, and the FCC has hinted that it will support the request

If this were to happen, applications such as Skype that use end-to-end encryption could be outlawed as inconsistent with law enforcement needs.

Today, it’s still easy to use end-to-end encryption as long as it’s HTTPS, but that might be short-lived. It could soon reach the point that the use of end-to-end encryption, without which end-to-end security can’t exist, will be seen as “an antisocial act” (as a US justice department official once told me). If that comes to be the case, end-toend security will be truly dead, and we will all have to trust functions in the network that we have no way of knowing are on our side.

What is VoIP end to end security?

Achieving end-to-end security in a voice-over-IP (VoIP) session is a challenging task. VoIP session establishment involves a jumble of different protocols, all of which must inter-operate correctly and securely. Our objective in this paper is to present a structured analysis of protocol inter-operation in the VoIP stack, and to demonstrate how even a subtle mismatch between the assumptions made by a protocol at one layer about the protocol at another layer can lead to catastrophic security breaches, including complete removal of transport-layer encryption.

The VoIP protocol stack is shown in figure 1. For the purposes of our analysis, we will divide it into four layers: signaling, session description, key exchange and secure media (data) transport. This division is quite natural, since each layer is typically implemented by a separate protocol. Signaling is an application-layer (from the viewpoint of the underlying communication network) control mechanism used for creating, modifying and terminating VoIP sessions with one or more participants. Signaling protocols include Session Initiation Protocol (SIP) [27], H.323 and MGCP. Session description protocols such as SDP [20] are used for initiating multimedia and other sessions, and often include key exchange as a sub-protocol.

Key exchange protocols are intended to provide a cryptographically secure way of establishing secret session keys between two or more participants in an untrusted environment. This is the fundamental building block in se-cure session establishment. Security of the media transport layer—the layer in which the actual voice datagrams are transmitted—depends on the secrecy of session keys and authentication of session participants. Since the established key is typically used in a symmetric encryption scheme, key secrecy requires that nobody other than the legitimate session participants be able to distinguish it from a random bit-string. Authentication requires that, after the key exchange protocol successfully completes, the participants’ respective views of sent and received messages must match (e.g., see the notion of “matching conversations” in [8]). Key ex-change protocols for VoIP sessions include SDP’s Security DEscriptions for Media Streams (SDES) , Multimedia Internet KEYing (MIKEY) and ZRTP [31]. We will analyze all three in this paper.

Secure media transport aims to provide confidentiality, message authentication and integrity, and replay protection to the media (data) stream. In the case of VoIP, this stream typically carries voice datagrams. Confidentiality means that the data under encryption is indistinguishable from random for anyone who does not have the key. Message authentication implies that if Alice receives a datagram apparently sent by Bob, then it was indeed sent by Bob. Data integrity implies that any modification of the data in transit

We show how to cause the transport-layer SRTP protocol to repeat the keystream used for datagram encryption. This enables the attacker to obtain the xor of plaintext datagrams or even to completely decrypt them. The SRTP keystream is generated by using AES in a stream cipher-like mode. The AES key is generated by applying a pseudo-random function (PRF) to the session key. SRTP, however, does not add any session-specific randomness to the PRF seed. Instead, SRTP assumes that the key exchange protocol, executed as part of RTP session establishment, will en-sure that session keys never repeat. Unfortunately, S/MIME-protected SDES, which is one of the key ex-change protocols that may be executed prior to SRTP, does not provide any replay protection. As we show, a network-based attacker can replay an old SDES key establishment message, which will cause SRTP to re-peat the keystream that it used before, with devastating consequences. This attack is confirmed by our analysis of the libsrtp implementation.

• We show an attack on the ZRTP key exchange protocol that allows the attacker to convince ZRTP session participants that they have lost their shared secret. ZID values, which are used by ZRTP participants to retrieve previously established shared secrets, are not authenticated as part of ZRTP. Therefore, an attacker can initiate a session with some party under the guise of another party B, with whom previously established a shared secret. As part of session establishment, is supposed to verify that knows their shared secret. If the attacker deliberately chooses values that cause verification to fail, will decide—following ZRTP specification—that has “forgotten” the shared secret.

The ZRTP specification explicitly says that the protocol may proceed even if the set of shared secrets is empty, in which case the attacker ends up sharing a key with who thinks she shares this key with B. Even if the participants stop the protocol after losing their shared secrets, but are using VoIP devices without displays, they cannot confirm the computed key by voice and must stop communicating. In this case, the attack becomes a simple and effective denial of service. Our analysis of ZRTP is supported by the AVISPA formal analysis tool .

• We show several minor weaknesses and potential vulnerabilities to denial of service in other protocols. We also observe that the key derived as the result of MIKEY key exchange cannot be used in a standard cryptographic proof of key exchange security (e.g., ). Key secrecy requires that the key be in-distinguishable from a random bitstring. In MIKEY, however, the joint Diffie-Hellman value derived as the result of the protocol is used directly as the key. Membership in many Diffie-Hellman groups is easily checkable, thus this value can be distinguished from a random bitstring. Moreover, even hashing the Diffie-Hellman value does not allow the formal proof of security to go through in this case, since the hash function does not take any random inputs apart from the Diffie-Hellman value and cannot be viewed as a randomness extractor in the proof. (This observation does not immediately lead to any attacks.)

While we demonstrate several real, exploitable vulnerabilities in VoIP security protocols, our main contribution is to highlight the importance of analyzing protocols in con-text rather than in isolation. Specifications of VoIP protocols tend to be a mixture of informal prose and pseudocode, with some assumptions—especially those about the protocols operating at the other layers of the VoIP stack—are left implicit and vague. Therefore, our study has important lessons for the design and analysis of security protocols in general.

The rest of the paper is organized as follows. In section 2, we describe the protocols, focusing on SIP (signaling), SDES, ZRTP and MIKEY (key exchange), and SRTP (transport). In section 3, we describe the attacks and vulnerabilities that we discovered. Related work is in section 4, conclusions are in section 5.

VoIP security different from normal data network security

To understand why security for VoIP differs from data network security, we need to look at the unique constraints of transmitting voice over a packet network, as well as the characteristics shared by VoIP and data networks.

Packet networks depend on many configurable parameters: IP and MAC (physical) addresses of voice terminals and addresses of routers and firewalls. VoIP networks add specialized software, such as call managers, to place and route calls. Many network parameters are established dynamically each time a network component is restarted or when a VoIP telephone is restarted or added to the net-work. Because so many nodes in a VoIP network have dynamically configurable parameters, intruders have as wide an array of potentially vulnerable points to attack as they have with data networks. But VoIP systems have much stricter performance constraints than data networks, with significant implications for security.

Threats for VoIP

VoIP security threats contain Eavesdropping, Denial of Service, Session Hijacking, VoIP Spam, etc. For preventing these threats, there are several VoIP standard protocols. And we discuss this in Section 3.


VoIP service using internet technology is faced with an eavesdropping threat, in which is gathering call setting information and audio/voice communication contents illegally. Eavesdropping can be categorized largely by eavesdropping in a LAN(Local Area Network) environment, one in a WAN( Wide Area Network) environment, one through a PC(Personal Computer) hacking, etc.

Denial of Service

Denial of Service is an attack, which makes it difficult for legitimate users to take telecommunication service regularly. Also it is one of threats, which are not easy to solve the most. Since VoIP service is based on internet technology, it also is exposed to Denial of Service. Denial of Service in VoIP service can be largely divided into system resource exhaustion, circuit

This work was supported by the IT R&D program of MIC/IITA resourceexhaustion,VoIP communication interruption/blocking, etc.

Session Hijacking

Session Hijacking is an attack, which is gathering the communication session control between users through spoofing legitimate users, and is interfering in their communication, as a kind of man-in-the-middle attack. Session Hijacking in VoIP communication can be categorized largely by INVITE session hijacking, SIP Registration hijacking, etc.

VoIP Spam

VoIP Spam is an attack, which is interrupting, and violating user privacy through sending voice advertisement messages, and also makes VMS(Voice Mailing System) powerless. It can be categorized by Call Spam, IM(Instant Messaging) Spam, Presence Spam, etc.

Security trade-offs

Trade-offs between convenience and security are routine in software, and VoIP is no exception. Most, if not all, VoIP components use integrated Web servers for configuration. Web interfaces can be attractive, easy to use, and inexpensive to produce because of the wide availability of good development tools. Unfortunately, most Web development tools focus on features and ease of use, with less attention paid to the security of the applications they help produce. Some VoIP device Web applications have weak or no access control, script vulnerabilities, and inadequate parameter validation, resulting in privacy and DoS vulnerabilities. Some VoIP phone Web servers use only HTTP basic authentication, meaning servers send authentication information without encryption, letting anyone with network access obtain valid user IDs and passwords. As VoIP gains popularity, we’ll inevitably see more administrative Web applications with exploitable errors.

The encryption process can be unfavorable to QoS

Unfortunately, several factors, including packet size expansion, ciphering latency, and a lack of QoS urgency in the cryptographic engine can cause an excessive amount of latency in VoIP packet delivery, leading to degraded voice quality.

The encryption process can be detrimental to QoS, making cryptodevices severe bottlenecks in a VoIP net-work. Encryption latency is introduced at two points. First, encryption and decryption take a nontrivial amount of time. VoIP’s multitude of small packets exacerbates the encryption slowdown because most of the time consumed comes as overhead for each packet. One way to avoid this slowdown is to apply algorithms to the computationally simple encryption voice data before packetization. Although this improves throughput, the proprietary encryption algorithms used (fast Fourier-based encryption, chaos-bit encryption, and so on) aren’t considered as secure as the Advanced Encryption Standard,16 which is included in many IPsec implementations. AES’s combination of speed and security should handle the demanding needs of VoIP at both ends. following general guidelines, recognizing that practical considerations might require adjusting them:

• Put voice and data on logically separate networks. You should use different subnets with separate RFC 1918 address blocks for voice and data traffic and separate DHCP servers to ease the incorporation of intrusion-detection and VoIP firewall protection.

• At the voice gateway, which interfaces with the PSTN, disallow H.323, SIP, or Media Gateway Control Protocol (MGCP) connections from the data network. As with any other critical network management component, use strong authentication and access control on the voice gateway system.

• Choose a mechanism to allow VoIP traffic through firewalls. Various protocol dependent and independent solutions exist, including ALGs for VoIP protocols and session border controllers. Stateful packet filters can track a connection’s state, denying packets that aren’t part of a properly originated call.

  • Use IPsec or Secure Socket Shell (SSH) for all remote management and auditing access. If practical, avoid using remote management at all and do IP PBX access from a physically secure system.
  • Use IPsec tunneling when available instead of IPsec transport because tunneling masks the source and destination IP addresses, securing communications against rudimentary traffic analysis (that is, determining who’s making the calls).
  • If performance is a problem, use encryption at the router or other gateway to allow IPsec tunneling. Be-cause some VoIP end points aren’t computationally powerful enough to perform encryption, placing this

Recent studies indicate that the greatest contributor to the encryption bottleneck occurs at the cryptoengine scheduler, which often delays VoIP packets as it processes larger data packets.17This problem stems from the fact that cryptoschedulers are usually first-in first-out (FIFO) queues, inadequate for supporting QoS requirements. If VoIP packets arrive at the encryption point when the queue already contains data packets, there’s no way they can usurp the less time-urgent traffic. Some hardware manufacturers have proposed (and at least one has implemented) solutions for this, including QoS reordering of traffic just before it reaches the cryptoengine.18 But this solution assumes that the cryptoengine’s output is fast enough to avoid saturating the queue. Ideally, you’d want the cryptoengine to dynamically sort incoming traffic and force data traffic to wait for it to finish processing the VoIP packets, even if these packets arrive later. However, this solution adds considerable overhead to a process most implementers like to keep as light as possible. Another option is to use hardware-implemented AES encryption, which can improve throughput significantly. Past the cryptoengine stage, the system can perform

further QoS scheduling on the encrypted packets, provided they were encrypted using ToS preservation, which copies the original ToS bits into the new IPsec header. Virtual private network (VPN) tunneling of VoIP has also become popular recently, but the congestion and bottlenecks associated with encryption suggest that it might not always be scalable. Although researchers are making great strides in this area, the hardware and soft-ware necessary to ensure call quality for encrypted voice traffic might not be economically or architecturally vi-able for all enterprises considering the move to VoIP.

Thus far, we’ve painted a fairly bleak picture of VoIP security. We have no easy “one size fits all” solution to the issues we’ve discussed in this article. Decisions to use VPNs instead of ALG-like solutions or SIP instead of H.323 must depend on the specific nature of both the current network and the VoIP network to be. The technical problems are solvable, however, and establishing a secure VoIP implementation is well worth the difficulty.

To implement VoIP securely today, start with the following general guidelines, recognizing that practical considerations might require adjusting them:

• Put voice and data on logically separate networks. You should use different subnets with separate RFC 1918 address blocks for voice and data traffic and separate DHCP servers to ease the incorporation of intrusion-detection and VoIP firewall protection.

• At the voice gateway, which interfaces with the PSTN, disallow H.323, SIP, or Media Gateway Control Protocol (MGCP) connections from the data network. As with any other critical network management component, use strong authentication and access control on the voice gateway system.

• Choose a mechanism to allow VoIP traffic through firewalls. Various protocol dependent and independent solutions exist, including ALGs for VoIP protocols and session border controllers. Stateful packet filters can track a connection’s state, denying packets that aren’t part of a properly originated call.

  • Use IPsec or Secure Socket Shell (SSH) for all remote management and auditing access. If practical, avoid using remote management at all and do IP PBX access from a physically secure system.
  • Use IPsec tunneling when available instead of IPsec transport because tunneling masks the source and destination IP addresses, securing communications against rudimentary traffic analysis (that is, determining who’s making the calls).

If performance is a problem, use encryption at the router or other gateway to allow IPsec tunneling. Be-cause some VoIP end points aren’t computationally powerful enough to perform burden at a central point ensures the encryption of all VoIP traffic emanating from the enterprise network. Newer IP phones provide AES encryption at reason-able cost.

  • Look for IP phones that can load digitally (cryptographically) signed images to guarantee the integrity of the software loaded onto the IP phone.
  • Avoid softphone systems (see the sidebar) when security or privacy is a concern. In addition to violating the separation of voice and data, PC-based VoIP applications are vulnerable to the worms and viruses that are all too common on PCs.
  • Consider methods to harden VoIP platforms based on common operating systems such as Windows or Linux. Try, for example, disabling unnecessary services or using host-based intrusion detection methods.
  • Be especially diligent about maintaining patches and current versions of VoIP software.
  • Evaluate costs for additional power backup systems that might be required to ensure continued operation during power outages.
  • Give special consideration to E-91 1 emergency services communications, because E-911 automatic location service is not always available with VoIP.

VoIP can be done securely, but the path isn’t smooth. It will likely be several years before standards issues are settled and VoIP systems become mainstream. Until then, organizations must proceed cautiously and not assume that VoIP components are just more peripherals for the local network. Above all, it’s important to keep in mind VoIP’s unique requirements, acquiring the right hardware and software to meet the challenges of VoIP security.

Methods for VoIP end to end security

Voice over IP (VoIP) security where security design patterns may prove exceedingly useful. Internet telephony or VoIP has grown in importance and has now passed the tipping point – in 2005 U.S. companies bought more VoIP phones than ordered new POTS lines. However, with the powerful convergence of software-based VoIP to enable new functionality to store, copy, combine with other data, and distribute over the Internet also comes security problems that need to be solved in standard ways in order to ensure interoperability. This is further complicated by the fact that various vendors competing for market share currently drive VoIP security.

Given the importance of VoIP security, we are only aware of only two other efforts for VoIP security design patterns, a chapter within and an unpublished M.S. thesis supervised by Eduardo Fernandez of Florida Atlantic University.

Figure 1. VoIP Infrastructure Vulnerabilities

NIST released a report on VoIP security in January 2005 . This report elaborates on various aspects of securing VoIP and the impact of such measures on call performance. The report argues that VoIP performance and security are not seamlessly compatible; in certain areas they are orthogonal. We briefly review this report and group VoIP infrastructure threats into three categories as depicted in Figure 1:

(1) Protocol

(2) Implementation and

(3) Management

Quality of Service (QoS) Issues

A VoIP call is susceptible to latency, jitter, and packet loss. ITU-T recommendation G.114 has established 150 ms as the upper limit on one-way latency for domestic calls. If Goode's latency budget is considered, very little time (< 29 ms) is left for encryption/decryption of voice traffic. QoS-unaware network elements such as routers, firewalls, and Network Address Translators (NAT) all contribute to jitter (no uniform packet delays). Use of IPsec both contributes to jitter and reduces the effective bandwidth. VoIP is sensitive to packet loss with tolerable loss rates of 1-3%; however, forward error correction schemes can reduce loss rates.

Signaling and Media Protocol Security

SIP (Session Initiation Protocol) (RFC 3261) and H.323 are the two competing protocols for VoIP signaling. H.323 is an ITU-T umbrella of protocols that supports secure RTP (SRTP) (RFC 3711) for securing media traffic, and Multimedia Internet Keying (MIKEY) (RFC 3830) for key exchange. SIP supports TLS and S/MIME for signaling message confidentiality and SRTP for media confidentiality.

Firewalls and NATs

RTP is assigned a dynamic port number that presents a problem for firewall port management. A firewall has to be made aware of the ports on which the media will flow. Thus a stateful and application-aware firewall is necessary. However, if a client is behind a

NAT, call establishment signaling messages transmit the IP address and RTP port number that is not globally reachable. NAT traversal protocols like STUN (RFC 3489), TURN (RFC 2026), and ICE (14) are necessary to establish a globally routable address for media traffic. For protocols that send call setup messages via UDP, the intermediate signaling entity must send to the same address and port from which the request arrived.

Encryption and IPsec

IPsec is preferred for VoIP tunneling across the Internet, however, it is not without substantial overhead. When IPsec is used in tunnel mode, the VoIP payload to packet size ratio for a payload of 40 bytes and RTP/UDP headers drops to ~30%. The NIST solution to avoid queuing bottlenecks at routers due to encryption is to perform encryption/decryption solely at endpoints. SRTP and MIKEY are specified for encrypting media traffic and establishing session keys respectively.

Categorizing VoIP Threats

The threats faced by a VoIP are similar to other applications including: unwanted communication (spam), privacy violations (unlawful intercept), impersonation (masquerading), theft-of-service, and denial-of-service. Table 1 groups these threats into protocol, implementation, and management categories.





end-to-end protection as well as hop-by-

hop (Proxies might be malicious)




most VoIP devices are managed remotely

Identity Assertion

Users concerned about whether they are

talking to the real entity as opposed to a

'phished' entity

Reputation Management


Buffer Overflow, Insecure Bootstrapping.


Access Control

protection against unauthorized access to


VoIP servers and gateways

Power Failures

Table 1. Categorizing VoIP Threats

Secure VoIP call

The Secure VoIP call pattern hides the meaning of messages by performing encryption of calls in a VoIP environment.


Two or more subscribers are participating in a voice call over a VoIP channel. In public IP networks such as the Internet, it is easy to capture the packets meant for another user.


When making or receiving a call, the transported voice packets between the VoIP network nodes are exposed to interception. How to prevent attackers from listening to a voice call conversation when voice packets are intercepted on public IP networks?

The solution will be affected by the following forces:

  • Packets sent in a public network are easy to intercept and read or change. We need a way to hide their contents.
  • The protection method must be transparent to the users and easy to apply.
  • The protection method should not significantly affect the quality of the call.


To achieve confidentiality we use encryption and decryption of VoIP calls.


In cases where performance is an important issue, symmetric algorithms are preferred. Such algorithms require the same cryptographic key (a shared secret key) on both sides of the channel.

If the IPSec standard is used, it is necessary for participants in a call (i.e. Caller and Callee) to agree previously on a data encryption algorithm (e.g. DES, 3DES, AES) and on a shared secret key. The Internet Key Exchange (IKE) protocol is used for setting up the IPSEC connections between terminal devices. The caller encrypts the voice call with the secret key and sends it to the remote user. The callee decrypts the voice call and recovers the original voice packets.

Additionally, the Secure Real Time Protocol (SRTP) can be used for encrypting media traffic and the Multimedia Internet KEYing (MIKEY) for exchanging keying materials in VoIP.

If public key cryptography is used, the callee must obtain the caller's public key before establishing a connection. The caller encrypts the voice call with the callee’s public key and sends it to her. The callee decrypts the voice call and recovers the original voice packets.

The class diagram of Figure 4 shows a Secure-channel communication in VoIP (adapted from the Cryptographic Metapattern in).This model uses the Strategy pattern to indicate choice of encryption algorithems. Both the Caller and Callee roles use the same set of algorithms although they are shown only in the caller side.


The advantages of this pattern include:

  • Symmetric encryption approaches provide good confidentiality.
  • Encryption is performed transparently to the user’s activities.
  • The need to provide separate VLANs for VoIP security could possibly be removed.
  • It may no longer be necessary to use IPSec tunneling that was previously required in the MAN/WAN.

Figure 4 Class Diagram for a VoIP Secure Channel

Possible disadvantages include:

  • The quality of the call can be affected if encryption is not performed very carefully [Wal05].
  • It is hard to scale because of the need for shared keys.
  • 介绍
    用户通信的应用是在互联网的用户群体有很高的需求。两个类等应用是非常重要的,吸引许多网民协作系统和VoIP通信系统的兴趣。在第一类而后者驻留系统,如ICQ , MSN Messenger和雅虎通, Skype和VoipBuster系统,如在公众中的VoIP客户端主导。协作系统体系结构中的平面上,形成一个分布式的网络参与者通信相互交换信息。的数据,是从源通过中央服务器路由到收件人或两个客户端直接沟通。在这样的网络中的参与者都是内容提供商和内容请求者。另一方面,在VoIP系统中的数据通信路径是直接的对等体之间,有一些例外,如Skype的“超级节点”通信数据交换路径的服务网络,在没有任何参与。数据通过公共互联网基础设施,如以太网, WiFi热点或无线ad hoc网络。在这些网络的安全性是一个关键问题,在过去的几个不同的角度解决。
    在这个作业中,我将重点在VoIP加密的安全实施。安全实施动态合作,由两个(或更多)的同龄人没有事先的安排和要求,喜欢的乐队交换密钥,共享秘密等易于使用(简单) ,用户友好(从用户端没有特殊的知识)和有效性(确保机密性和完整性的应用与最终用户设备上的最低要求)结合实现的目标是通过我们的方法。我们充分利用用户通信的安全性,满足上述所有要求,通过加强应用架构与VoIPSec安全要素。
    在过去的几年中, IP语音(VoIP)的已成为一种有吸引力的替代传统形式的电话。当然,在日常通信,在增加普及重新搜索者不断探索如何改善这种新的通信技术的效率和安全性。不幸的是,这是很好理解的同时, VoIP数据包必须​​被加密,以确保机密性,它已经表明,简单的加密数据包,从隐私的观点来看可能是不够的。例如,我们最近发现, VoIP分组时,第一压缩的可变比特率(VBR )编码方案,以节省带宽,然后加密的保留流密码的长度,以确保机密性,有可能确定在加密的语言谈话。
    这些研究结果可能是令人惊讶,因为,人们可能会认为,学习扬声器的语言(如阿拉伯语) ,只影响边际隐私。如果VoIP呼叫的两个端点是已知的(例如,墨西哥城和马德里) ,则可能正确地得出这样的结论的谈话的语言是西班牙语,不进行任何分析的交通。在这项工作中,我们将展示,使用VBR和长度保持加密相结合的信息泄露确实是差远了,比以前认为的。
    比传统的分组交换的IP网络语音通过IP传输语音是电信最热门的趋势之一。虽然大部分的电脑可以提供VoIP和许多提供VoIP应用中,术语“ IP语音”通常与设备,让用户拨打电话号码,谁拥有VoIP系统或传统的模拟电话的另一端与各方沟通。 (侧边栏, “电流通过IP语音产品, ”去描述一些目前市场上的产品。 )
    与任何新技术, VoIP的引入既是机遇和问题。这对于一个企业提供了较低的成本和更大的灵活性,但呈现明显的安全挑战。安全管理员可能会假设,因为数字化的语音包时,他们可以简单地插入到他们已经固化网络的VoIP组件,并得到一个稳定和安全的语音网络工作。不幸的是,许多用来保护当今的计算机网络防火墙,网络地址转换( NAT ) ,不要加密工作的工具“,是”在VoIP网络。尽管大多数VoIP组件有同行在数据网络中, VoIP的性能需求意味着你必须补充普通的网络软件和硬件与特殊的VoIP组件。
    为公司的技术基础架构, VoIP系统集成到一个已经拥挤或网络负担过重,可能是灾难性的。因此,任何人都在试图构建一个VoIP网络应该首先研究非常详细的程序。为此,我们列出了一些引入适当的保安措施,在企业的VoIP的挑战。
    在此任务,我要描述的端至端的安全性和它的“设计原则” ,一个不应该放置在网络机制,如果他们可以被放置在端节点,因此,网络应提供一般服务,而不是服务被设计为支持特定的应用程序。遵循这样的设计原则以及设计和实施互联网。互联网被设计成一个与应用无关的数据包去号衣服务。今天的互联网是不是纯的实施结束 - 到 - 结束设计原则因为它曾经是,但它是足够的,不知道什么是运行在它的网络抵押品的影响正在成为主要的问题,至少在一些观察家的心目中。我得到那些被认为问题之前,我想谈论到互联网,技术演进,社会意味着什么样的终端到终端的设计原则。互联网并不关心你做什么,它的工作就是“提供的位,愚蠢的” (大卫·伊森伯格在他1997年的论文中的话, “崛起的愚蠢网络”2 ) 。 “位” ,可能是一封电子邮件,一个数据文件,照片,或视频,或者他们可能是一部分的拒绝服务攻击,恶意的蠕虫病毒,一个突破尝试,或非法共享歌曲。 Net不关心,那就是其权力和威胁。
    互联网(通过这一点,我的意思是ARPANET , NSFNET的其继任商业的ISP和网络)是不是设计来运行的万维网。互联网是不是设计来运行谷歌地球。它被设计为支持他们,即使他们不存在的时候设计的基础净。它被设计为支持他们不关心这是什么,代表的数据传输数据。
    上面的第一, TCP / IP协议的设计不那么灵活。最初的设计在一个单一的协议,只会提供可靠的数据到目的地TCP和IP 。但人们认识到,并不是所有的应用程序的最佳途径是一种协议,只能提供可靠的数据流。尤其是较可靠的交付时,及时传递信息,更重要的
    因此,基于互联网设计,因为它是在终端到终端的原则,成为生成设施。不同于传统的电话系统,其中大多数新的应用程序必须安装在手机开关深手机网工作,任何人都可以创建新的应用程序,并在互联网上运行他们没有得到许可的组织运行的部分净。这种能力被利用“非理性繁荣” ,在20世纪90年代末互联网繁荣。不过,尽管数十亿美元的损失由投资者的热潮时,破获数百,互联网用户数和网站,互联网流量的金额,以及互联网电子商务的价值持续上升,新的速度基于互联网的服务的想法不是没有ticeably减少。
    终端到终端的安全性是不是死了,但它是严重威胁,至少在网络层。 NAT和防火墙的干扰某些类型的终端到终端加密技术。互联网服务供应商可能很快就会法规要求,默认情况下,过滤网站,也许他们的客户才能访问的协议。其他互联网服务供应商希望能够限制的协议,他们的客户可以访问ISP可以为服务提供商提供一个“激励” ,以支付他们的台词,为客户的使用,他们看不到的方式来支付净没有这种能力。联邦调查局(FBI)已要求能够成带性审查所有新的互联网服务,他们正在部署之前, FCC已经暗示将支持请求
    今天,它仍然很容易使用终端到终端的,只要它的HTTPS加密,但可能是短命的。它可能很快就会达到这一点,使用的终端到终端加密终端到终端的安全性,没有它不能存在,将被视为“反社会行为” (作为美国司法部官员曾告诉我) 。如果来的情况下,端到端的安全性将是真的死了,我们所有人都信任在网络功能方面,我们有没有办法知道就在我们身边。
    - over-IP的语音电话(VoIP)会话中实现终端到终端的安全性,是一项具有挑战性的任务。 VoIP会话的建立,涉及到不同的协议,所有这些都必须互操作正确并牢固地混杂。在本文中,我们的目标是在VoIP协议栈,协议互操作提出了结构化分析和演示甚至在另一个一层一层的协议由协议作出的假设之间的一种微妙的不匹配可能会导致灾难性的安全违规行为,包括传输层加密的彻底清除。
    图1中所示的VoIP协议栈。对于我们分析的目的,我们把它分为四个层面:信令,会话描述,密钥交换和安全介质(数据)传输。这种划分是很自然的,因为每一层的典型实现是一个单独的协议。信号是一个应用层从底层通信网络的观点来看,用于创建,修改和终止与一个或多个参与者的VoIP会话的控制机制。信令协议包括会话发起协议( SIP ) [27] , H.323和MGCP 。会话描述协议SDP等[20]用于启动多媒体和其他会议,并经常作为一个子协议包括密钥交换。
    密钥交换协议的目的是提供一个安全加密的方式,在不受信任的环境中的两个或两个以上的参与者之间建立秘密的会话密钥。这是SE -治愈会话建立的基石。安全媒体传输层的层,其中实际的语音数据报被发送的会话密钥的保密性和认证的会话参与者。由于在对称加密方案通常用于建立密钥,密钥的保密要求,没有人以外的合法会话参与者可以区分从一个随机的位串。认证要求,密钥交换协议后,成功完成后,参加者必须符合各自的意见,发送和接收的消息(例如,见的概念匹配谈话“ [8 ] ) 。关键前变化协议的VoIP会话包括SDP的安全描述媒体流( SDES ) ,多媒体互联网键控(MIKEY )和ZRTP [31]。本文,我们将分析所有三个。
    我们将展示如何导致SRTP协议传输层重复用于报文加密密钥流。这使攻击者获得明文数据包的异或什至完全解密他们。的的SRTP密钥流生成通过使用AES流中的密模式。 AES密钥生成的会话密钥通过施加一个伪随机函数( PRF ) 。然而, SRTP ,不添加任何特定会话随机性的PRF种子。相反, SRTP假定密钥交换协议,执行为RTP会话建立的一部分,将确保会话密钥永不重复。不幸的是,S / MIME保护的SDES ,这是其中一个键的前变化可能被执行之前的SRTP协议,不提供任何重放保护。正如我们所展示的,基于网络的攻击者可以重放老SDES密钥建立的消息,这将导致SRTP的密钥流重新泥炭,它使用之前,灾难性的后果。这种攻击被证实由我们分析的libsrtp实施。
    •我们ZRTP的密钥交换协议,允许攻击者以欺骗ZRTP会话参与者,他们已经失去了他们的共享秘密攻击。 ZRTP的参与者所使用的检索先前建立的共享秘密, ZID值,不需要进行验证ZRTP的一部分。因此,攻击者可以发起会话,一些甲方乙方的幌子下,另一人,与先前建立一个共享的秘密。作为建立会话的一部分,A应该是验证B知道他们共享的秘密。如果攻击者刻意选择值,导致验证失败,将决定以下ZRTP规范B已经“遗忘”的共享秘密。
    该的ZRTP规范明确说,即使设定的共享秘密是空的,该协议可能会继续在这种情况下,攻击者最终共享的一个关键阿谁认为她分享这一关键B.即使参与者停止协议后,失去其共享的秘密,但正在使用VoIP设备不显示,他们不能确认通过语音计算的关键,并且必须停止沟通。在这种情况下,拒绝服务攻击成为一个简单而有效的。 ZRTP的支持,我们的分析的AVISPA正式的分析工具。
    我们几个小的弱点和其他协议中潜在的漏洞拒绝服务。我们还观察到MIKEY密钥交换的结果派生的密钥不能被用于在一个标准的加密密钥交换的安全性证明(例如,) 。关键保密要求的关键是从一个随机的位串区别。然而,在MIKEY ,用于联合的Diffie-Hellman导出的值作为该协议的结果直接作为密钥。 Diffie-Hellman组在许多成员是很容易辨认的,因此这个值可以区分一个随机的位串。此外,即使散列的Diffie-Hellman值不会允许的正式证明的安全性,以去,通过在这种情况下,除了因为散列函数不采取任何随机输入的Diffie-Hellman值,并可以不被浏览了随机性提取在证明。 (这种观察并不立即导致的任何攻击。 )
    虽然我们展示了一些真实的,可利用的漏洞在VoIP安全性协议,我们的主要贡献是突出的重要性,分析协议的文本,而不是孤立。 VoIP协议的规格往往是非正式的散文和伪的混合物,用一些假设,尤其是那些有关协议运行在其他层的VoIP协议栈留隐和模糊。因此,我们的研究具有重要的安全协议的设计和分析的经验教训。
    剩下的纸张安排如下:在第2节中,我们描述了协议,专注于SIP (信令) , SDES ,ZRTP和Mikey (密钥交换)和SRTP (运输) 。在第3节中,我们描述了我们发现的攻击和漏洞。相关工作是在第4节,结论是在第5 。
    分组网络依赖于许多配置参数: IP和MAC (物理)地址的语音终端和地址的路由器和防火墙。 VoIP网络添加专门的软件,如呼叫管理,地方和呼叫路由。许多网络参数动态地建立网络组件,每次重新启动时或重新启动或添加一个VoIP电话网络工作。因为这么多的在VoIP网络中的节点动态配置参数,入侵者有尽可能广泛的一系列潜在的薄弱环节进行攻击,因为他们有与数据网络。但是, VoIP系统有更严格的性能比数据网络的约束,安全性的显着影响。
    VoIP安全威胁包含窃听,拒绝服务攻击,会话劫持, VoIP的垃圾等,为防止这些威胁,有几个VoIP标准协议。我们讨论这个问题在第3节。
    使用VoIP服务的互联网技术正面临着被窃听的威胁,这是非法收集通话设置信息和音频/语音通信内容。可以分为主要通过窃听窃听在一个LAN (局域网)环境下,在WAN (广域网)的环境中,通过一台PC(个人计算机)的黑客攻击,等
    这项工作是支持的IT研发项目, MIC / IITA resourceexhaustion的, VoIP通信中断/拦截等。
    会话劫持攻击,这是收集通过欺骗合法用户,用户之间的通信会话控制,并干扰他们的沟通,作为一种的man-in - the-middle攻击。 VoIP通信会话劫持,基本上可以分为SIP INVITE会话劫持,注册劫持等
    VoIP垃圾邮件的攻击,中断,侵犯用户隐私,发送语音广告讯息,也使得VMS (语音邮件系统)无能为力。它可以分为呼叫垃圾邮件, IM (即时通讯)垃圾,存在垃圾等
    便利性和安全性之间的权衡是常规软件和VoIP也不例外。大多数情况下,即使不是全部, VoIP组件使用集成的Web服务器进行配置。网络接口可以是有吸引力的,易于使用的,因为好的开发工具的广泛应用,生产成本低廉。不幸的是,大多数的Web开发工具,专注于功能性和易用性,用更少的重视,帮助他们的应用程序产生的安全性。一些VoIP设备的Web应用程序有弱或没有访问控制,脚本漏洞,参数验证不足,导致在隐私和DoS漏洞。一些VoIP电话Web服务器只使用HTTP基本身份验证,这意味着服务器发送认证信息没有加密,让任何人都能够通过网络访问取得有效的用户ID和密码。随着VoIP的普及,我们将不可避免地看到更多的行政Web应用程序利用的错误。
    在加密过程可能是有害的QoS ,使得在VoIP网工作cryptodevices严重的瓶颈。加密延迟被引入在两个点上。首先,加密和解密的一个非平凡的时间量。 VoIP的大量的小数据包的加密放缓加剧,因为大多数所消耗的时间作为每个数据包的开销。一种方法来避免这种放缓是算法计算简单的加密语音数据打包前。虽然这可以提高吞吐量,专有的加密算法(基于快速傅立叶加密,混沌位加密,等等)都没有考虑安全的高级加密标准,16个,其中包括许多IPsec实现。 AES的组合应该处理的速度和安全性的苛刻需求的VoIP两端。按照一般准则,承认实际的考虑可能需要调整:
    •将语音和数据在逻辑上独立的网络。你应该使用不同的子网单独的RFC 1918地址块的语音和数据流量和单独的DHCP服务器,以缓解纳入入侵检测和VoIP防火墙保护。
    •语音网关, PSTN ,禁止H.323 , SIP或媒体网关控制协议(MGCP)从数据网络的连接接口。与任何其他关键的网络管理组件,使用强大的身份验证和访问控制的语音网关系统。
    使用IPsec或安全接壳( SSH )所有远程管理和审计访问。如果可行,应避免使用远程管理和做IP PBX接入,从物理安全系统。
    使用IPsec隧道代替IPsec传输时,因为隧道口罩的源和目的IP地址,确保对基本的通信流量分析(也就是确定谁呼叫) 。
    最近的研究表明,贡献最大的加密瓶颈发生上面的cryptoengine调度,往往VoIP分组延迟,因为它处理更大的数据: packets.17此问题源于一个事实,即通常第一cryptoschedulers的入先出( FIFO )队列,不足以支持QoS要求。如果VoIP数据包到达队列中已经包含了数据包加密点时,有没有出路,他们可以篡夺紧急交通的时间就越少。一些硬件制造商已提出(以及至少一个已实现)解决方案,包括QoS的流量重新排序刚刚才达到cryptoengine.18但此解决方案假定在cryptoengine的输出速度足够快,以避免饱和队列。理想情况下,你会希望cryptoengine传入流量和力数据流量等待它完成处理的VoIP数据包,即使这些数据包到达后进行动态排序。但是,这个方案增加了相当大的开销的过程中,大多数实施者想保持尽可能轻。另一种选择是使用硬件实现的AES加密,它可以显着地提高吞吐量。过去cryptoengine阶段,该系统可以执行
    进一步的QoS调度加密的数据包,只要他们使用TOS保存,这会将原始的ToS位到新的IPsec头加密。虚拟专用网(VPN)隧道的VoIP也成为最近流行的,但与加密有关的拥塞和瓶颈表明,它可能并不总是可扩展性。尽管研究人员正在大踏步前进在这方面,有必要的硬件和软件,以确保加密语音通信的通话质量可能不是经济或建筑VI-能对所有企业考虑向VoIP 。
    到目前为止,我们已经描绘了一幅相当暗淡的画面VoIP安全。我们有没有简单的“一刀切”的解决办法的问题,我们在这篇文章中讨论。必须依赖于当前的网络和VoIP网络的特殊性质决定,而不是使用VPN或SIP ALG-类似的解决方案,而不是H.323 。的技术问题都是可以解决的,但是,建立一个安全的VoIP实现的难度是非常值得的。
    •将语音和数据在逻辑上独立的网络。你应该使用不同的子网单独的RFC 1918地址块的语音和数据流量和单独的DHCP服务器,以缓解纳入入侵检测和VoIP防火墙保护。
    •语音网关, PSTN ,禁止H.323 , SIP或媒体网关控制协议(MGCP)从数据网络的连接接口。与任何其他关键的网络管理组件,使用强大的身份验证和访问控制的语音网关系统。
    使用IPsec或安全接壳( SSH )所有远程管理和审计访问。如果可行,应避免使用远程管理和做IP PBX接入,从物理安全系统。
    使用IPsec隧道代替IPsec传输时,因为隧道口罩的源和目的IP地址,确保对基本的通信流量分析(也就是确定谁呼叫) 。
    安全或隐私是一个问题时,避免使用软电话系统(见边栏) 。除了违反语音和数据的分离,基于PC的VoIP应用程序容易受到蠕虫和病毒都是太常见的PC上。