Communications of the ACM

Privacy and security

Security Risks in Next-Generation Emergency Services

By Hannes Tschofenig
Communications of the ACM, November 2011, Vol. 54 No. 11, Pages 23-25
10.1145/2018396.2018405
Comments

In mid-June 2011, the National Emergency Number Association (NENA) approved the end-state architectural vision for Next Generation 9-1-1.⁶ 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 Deployment⁵ 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,³ 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.⁴

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.¹³ 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.⁷ 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).⁸

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 Landau²).

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.¹²

Back to Top

Conclusion

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 assurances—an 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

Back to Top

Back to Top

Back to Top

Back to top

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