Home → Magazine Archive → November 2011 (Vol. 54, No. 11) → Security Risks in Next-Generation Emergency Services → Full Text

Security Risks in Next-Generation Emergency Services

By Hannes Tschofenig

Communications of the ACM, Vol. 54 No. 11, Pages 23-25

[article image]

Save PDF

In mid-June 2011, the National Emergency Number Association (NENA) approved the end-state architectural vision for Next Generation 9-1-1.6 The "i3" architecture, as technical experts call it, presents a detailed architecture for key elements of the next-generation 9-1-1 systems, describing how networks and devices will eventually work together to enable voice, text, image, and data exchange between citizens and first responders.

It took NENA members years to complete the work on the i3 architecture and related specifications. Although NENA is the leading emergency services organization in North America, it did not develop the specifications alone. The i3 architecture borrows heavily from the standards developed by the Internet Engineering Task Force (IETF) on SIP, location, and emergency calling. It is not only the reuse of specifications that is significant but the mind-set acquired by NENA from the IETF: IETF's emergency services architecture follows the Internet application deployment model where applications may be provided by companies that are different than those providing Internet access. This assumption may not necessarily be surprising for Internet and smartphone application designers, but it is a significant change for anyone coming from the circuit-switched telephony world, which formed the current emergency services system for placing 9-1-1 and 1-1-2 emergency calls.

The regulatory community has also noticed the steady shift to Internet Protocols for all forms of communication. In early 2011, the Federal Communication Commission (FCC) issued a Notice of Inquiry (NOI) on the Framework for Next-Generation 911 Deployment5 to solicit feedback on all forms of multimedia emergency calling.a

The characteristics associated with a deployed architectural model impact security. The fundamental security problem of emergency services is that these are services associated with a high cost, such as dispatching first responders like ambulances, law enforcement, fire department services, and the service must be available to all users, not just highly vetted ones. Consequently, there is much potential for misuse of the system, which unfortunately does occur. Yet the fact that the services must be universally available means there is little way to prevent such misuse.

Since the emergency services solutions are built on top of the existing communication architectures and protocols, they inherit the associated characteristics, including the security problems of Voice over IP, instant messaging (IM), and other forms of communication technologies. Yet despite these problems, from the point of view of economics it is unlikely to assume a separate end-to-end communication infrastructure will ever be deployed solely for use by emergency services.

Back to Top

False Emergency Calls

Among all the security challenges today's systems suffer most from so-called "false emergency calls," a form of denial-of-service attack. As the European Emergency Number Association (EENA), the European counterpart of NENA, has noted, "False emergency calls divert emergency services away from people who may be in life-threatening situations and who need urgent help. This can mean the difference between life and death for someone in trouble." EENA has attempted to define terminology and describe best current practices for dealing with false emergency calls,3 which in certain European countries can be as high as 70% of all emergency calls. Reducing the number of bogus calls often represents a significant challenge, since emergency services authorities in most countries are required to answer every call (whenever possible). If there is no ability to associate the caller with a real-world person in case of misuse, then the ability to prosecute is limited. Due to requirements for supporting the so-called SIM-less emergency calls in many countries (emergency calls that are placed without a SIM card); calls from phones with pre-paid cards, or from public telephones make accountability difficult.

The fact that the services must be universally available means there is little way to prevent misuse.

While hoax call attacks typically lead to various negative results, they typically do not cause life-threatening situations. But a small percentage of these calls pose a significant risk. Most significantly, "swatting"faking an emergency that draws a response from law enforcement (usually a SWAT team)has the potential for causing life-threatening problems.4

The attack is fairly simple: the location system of today's telephony system performs a lookup using the telephone number as used by the caller. The obtained location information is then provided to the emergency number authorities for dispatch of first responders, in this case a SWAT team. Unfortunately, the caller's phone number can be modified.

A very similar attack can be used in IP-based emergency services systems.13 In its simplest form, the adversary crafts location information and attaches it to an outgoing emergency call.

While there are various counter-measures, none are easy to deploy. When location information is obtained from the Internet access provider (as it is common for both fixed as well as cellular telecommunication emergency services systems), various identifiers must be linked to each other in order to obtain the physical location of the emergency caller. The proposed intermediate VoIP emergency services architecture developed by a U.K. standardization organization illustrates this mapping process in the example of a DSL network in Appendix E of an EENA operations document.7 A weak link in the mapping process can be exploited. Similarly, when location measurements must be obtained, as those are often provided with the support of the end devices themselves (for example, from a GPS module). Naturally, an adversary in control of the end device is able to return fake measurement results and can thereby impact the obtained location.

An approach that focuses on the prosecution of those who misuse the service is difficult to accomplish in an IP-based emergency services solution as well. The challenges are primarily on the technical side but are a side effect of the deployment reality: strong identity proofing is not widely deployed by many VoIP/IM services nor is it deployed in the Internet in general. In-person identity proofing is expensive and by itself is not sufficient to provide a high level of assurances throughout the entire service life cycle (for example, as described in NIST SP 800-63).8

The Internet is global, and many application service providers operate their services everywhere. So, despite a perfect mapping between the digital identifier and a real-world person the solution to the problem will be dependent on the regulatory environment and the ability of law enforcement agencies in different countries to cooperate. For example, how easy will it be to hold a person located in country X using [email protected] responsible for making a hoax call to an emergency service in country Y? This problem was identified long ago and has surfaced again in the ongoing debate about the accountable Internet (for example, see Clark and Landau2).

The list of security threats in VoIP and IM systems is naturally quite long. Of course, research and standardization has also been ongoing, and various countermeasures have been developed and are waiting to be deployed. Some specific protocols also had to be developed to support emergency services, such as the Location-to-Service Translation (LoST) protocol that is used for routing emergency calls to the appropriate Public Safety Answering Points (PSAPs). These components introduce additional attack vectors.12

Back to Top


The work on the next-generation emergency services infrastructure is progressing with NENA and EENA leading the work in North America and Europe, respectively. With the baseline technical standards coming from the IETF, security threats have been investigated and documented, and technical countermeasures have also been developed. While many of these problems are being observed in today's emergency services system, it is likely the transition to an all-IP-based emergency services infrastructure will invite far more attacks. There are various barriers for dealing with these problems, namely:

  • As long as attacks are still low (and the amount of IP-based emergency services is still low due to either the lack of regulation or unclear regulatory situation worldwide) there is no incentive to resolve the problem;
  • Many Internet players seem to lack economic incentives to deploy infrastructure for a high level of assurancesan area that aims to be addressed by NSTIC but with uncertain success outcome at this point in time; and
  • A lack of harmonization at the legal level. The Internet architectural model is not well enough understood by the regulatory community. The temptation to follow well-established patterns and to talk to their existing clientele is often too big; unfortunately that work style is not a match for today's ecosystem.

The last item is a particular area where further work is needed to bridge the gap between the policy and the technical community. Organizations developing technical standards are typically not ideally positioned to convey messages to policymakers on how responsibilities for the deployment have to be shared among the different stakeholders in the ecosystem and what nontechnical considerations need to be addressed. Due to their broader mandate, which includes training, certification, lobbying, and operational guidance, emergency services communities such as NENA and EENA are in an ideal position to close this gap.

In a nutshell, research and standardization have gone a long way toward providing the necessary building blocks. Now it is time for deployments to catch up.

Back to Top


1. Barnes, R., Cooper, A., and Tschofenig, H. Technical considerations for next-generation 911Comments in the matter of framework for next generation 911 deployment, PS Docket No. 10255; http://fjallfoss.fcc.gov/ecfs/document/view?id=7021034355.

2. Clark, D., and Landau, S. Untangling attribution. In Proceedings of a Workshop on Deterring Cyber Attacks: Informing Strategies and Developing Options for U.S. Policy, 2010.

3. EENA. False emergency calls EENA operations document; http://www.eena.org/ressource/static/files/2011_03_15_3.1.2.fc_v1.0.pdf.

4. FBI. Don't make the callThe new phenomenon of 'swatting,' Feb. 2008; http://www.fbi.gov/news/stories/2008/february/swatting020408.

5. Federal Communications Commission. Framework for next generation 911 deployment, PS Docket No. 10255, December 21, 2010; http://www.fcc.gov/daily_Releases/Daily_Business/2010/db1221/FCC-10-200A1.pdf.

6. NENA. NENA executive board approves end-state vision for next generation 9-1-1; http://www.nena.org/stories/technical/executive-board-approves-i3-standard.

7. NICC. VOIPLocation for Emergency Calls (Architecture), NICC ND 1638 Issue 1.1.2, March 2010; http://www.niccstandards.org.uk/files/current/ND1638%20V1.1.2.pdf.

8. NIST. DRAFT Electronic Authentication Guideline; Special Publication 800-63, June 2011; http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-63-Rev.%201.

9. NIST. National Strategy for Trust Identities in Cyberspace (NSTIC); http://www.nist.gov/nstic/.

10. Rosen, B. and Polk, J. Best current practice for communications services in support of emergency calling; draft-ietf-ecrit-phonebcp-17 (work in progress), March 2011.

11. Rosen, B. et al. Framework for emergency calling using Internet multimedia; draft-ietf-ecrit-framework-12 (work in progress).

12. Taylor, T. et al. Security threats and requirements for emergency call marking and mapping. RFC 5069, January 2008.

13. Tschofenig, H., Schulzrinne, H., and Aboba, B. Trustworthy location information, draft-ietf-ecrit-trustworthy-location-02 (work in progress), May 2011.

Back to Top


Hannes Tschofenig ([email protected]) is employed by Nokia Siemens Networks in Finland and spends most of his time in the Internet Engineering task Force (IETF) with the design of Internet protocols. He is a member of the Internet Architecture Board and co-chairs the IETF Web Authorization Protocol (oauth) working group. For many years he was co-chair of the IETF Emergency Context Resolution with Internet Technologies (ecrit) working group.

Back to Top


a. In their NOI response Barnes et al.1 provided a high-level description of the IETF emergency services architecture and illustrated the main characteristics. A more technically minded reader may want to consult the original IETF specifications (see Rosen et al.11 and Rosen and Polk10).

Back to Top


UF1Figure. An emergency communications technician responds to calls at the Emergency Communications Center in Arlington, VA.

Back to top

Copyright held by author.

The Digital Library is published by the Association for Computing Machinery. Copyright © 2011 ACM, Inc.