ABOUT

In response to Federal government goal to define “Interoperable Secure Voice for the Federal Government,” this project uses existing commercial voice systems from leading service providers and enterprise equipment manufacturers to create a testbed for a full function secured and interoperable inter-agency voice service. This project will define, implement, test and document a secure voice network that can support landline-to-landline, landline-to-mobile and mobile-to-mobile secure communications.

Living in an era of continuous cyber-attacks, we have come a long way in securing much of our infrastructure.  The banking industry has secured all financial transactions, utilities are hardening their infrastructure, and health care has set requirements for securing health care records.  One area that has been lacking in this transition is that of voice (and soon to be video) communications.

In 2020, the Department of Homeland Security released a solicitation to fill this gap.  A contract was awarded to Texas A&M University, Columbia University and Texas A&M University at Commerce.  The team of principle investigators have vast experience in voice standards development, voice system implementation, and cyber security.  The result of this project is a recommendation that will be released in early 2023 that defines a secure voice reference architecture and a roadmap that explains how to implement the architecture.

The project began with two fundamental requirements in mind.  First, the architecture needs to be implemented on existing voice systems at agencies.  Second, the architecture must include sub elements with the capability to allow agencies to select elements of the architecture without taking on the entire architecture.

PROBLEM STATEMENT

Today, most critical network communications are secured. This includes remote access to the enterprise, web services, and financial transactions, to name a few. This prevents the unauthorized use of private accounts, the hijacking of servers, the installation of malware and other malicious acts. But one critical network communications type, possibly the oldest form of electronic communications, the telephone, is still not secure.

For approximately the first 100 years of telephony, the service was provided using large, expensive switching systems using circuit switched services. In the mid-1990s, a revolutionary change began to occur as voice moved over from circuit switched to packet based. It did not take long for the voice traffic to move to the Internet Protocol as Voice over the Internet Protocol (VoIP).

VoIP used a few early protocols such the ITU H.323 and MGCP but it did not become a global success until the publishing of the Internet Engineering Task Force (IETF) Session Initiation Protocol (SIP), in 1999. The first version of the SIP protocol only made a brief introduction to securing voice traffic using Pretty Good Privacy (PGP). By the next release of SIP in 2002, the preferred security implementation had transitioned to Transport Layer Security (TLS) for the signaling and the Secure Real Time Protocol (SRTP) for the media. Security was an inherent part of the VoIP Protocol from the beginning and the capability of securing voice traffic has been embedded in every commercial system for at least the last decade. Despite this ability, few agency or enterprise voice systems have taken advantage of secure voice to this date.

Bypassing the voice service provider and directly routing calls between agencies is possible, given nearly ubiquitous IP connectivity. But maintaining routing tables for a growing number of interconnected agencies can become labor intensive and prone to human error without a reliable database of telephone numbers and routing information. Service providers have these systems, but most agencies do not.

Finally, attacks against the voice telephone network continue to grow. Denial of service attacks, caller ID spoofing and other cyber-attacks are becoming more common. These attacks are often not reported, or well documented. There is currently no requirement to report voice cyber-attacks.

FINDING A SOLUTION

In 2019 the Department of Homeland Security funded a project for Texas A&M University, Columbia University and Texas A&M Commerce to develop, test and document a secure architecture that could be implemented by all federal agencies.

The high-level approach is show in Figure 1 below and enables the following capabilities for direct agency-to-agency VoIP calls:

• • Trusted Directory of Secure Endpoints: a scalable and secure method of maintaining a routing directory for calls between agencies.

• • • Secure signaling:  the call setup and is protected by encryption

  
  

  • • Secure transport:  the voice audio is protected by encryption

  
  

  • • Caller ID integrity:  the receiving party can be assured that the calling number is legitimate

  
  

  • Caller Name integrity:  the receiving party can be assured that the name of call is correct

Figure 1:  Secure Voice – High Level Objective

LAB TESTBED

To complete this project, the researchers implemented a testbed that emulated three larger agencies, some remote offices, a central IP support organization, a wireless network, and some service providers.

The team selected VoIP systems most commonly in use today.  The systems were the Avaya Aura (Agency 1), Cisco Universal Call Manager (Agency 2), and the BroadSoft (now Cisco) BroadWorks platform (Agency 3).  Avaya Aura and Cisco UCM are the most widely used platforms in government agencies. BroadWorks is the most widely used platform for cloud service providers.

The agencies were connected to wireless networks at the Texas A&M University (TAMU) Internet2 Technology Evaluation Center (ITEC) and the Verizon Wireless lab for testing wireless voice calls over LTE. And a connection to Neustar was used to add caller identity services.

Figure 2 below shows a high-level view of the testbed.

Figure 2:  Lab Testbed for Secure Voice Architecture

Architecture

In developing the architecture, the researchers were guided by three requirements. The first was that the solution had to be 100% standards driven. The second requirement was that it could only use features implemented in VoIP systems widely utilized today. The final requirement was that the architecture be made up of sub-elements that could be implemented individually without an agency being required to provide the entire architecture. Each of the sub-elements would have to provide an increased level of protection against cyber threats if only that sub-element were implemented.

There were six sub-elements that together made up the architecture. Each of these elements were implemented, tested, and documented using the above testbed.

Implement Secure Signaling and Transport Within Agencies  

Unsecured VoIP systems utilize the Session Initiation Protocol (SIP) to control the call (i.e., signaling) and the Real Time Protocol (RTP) to convey the voice audio (i.e., media). The SIP standard also supports the use of Transport Layer Security (TLS) for encrypted signaling and Secure Real Time Protocol (SRTP) for encrypted media. Both options are available in all three of the systems implemented in the testbed. SIP-TLS and SRTP are selected and configured using the management interfaces for the respective VoIP system configuration.  TLS relies on X.509 digital certificates, covered below.

Implement a Certificate Authority for X.509 Certificates  

TLS relies on X.509 certificates to authenticate the other end of a connection in the same way that a web browser relies on certificates for accessing a secure web site with HTTPS. Several options are available for generating X.509 certificates, including commercial services that charge by the certificate, federated services that charge a flat fee for a group of organizations, and private certificate authorities created by agencies.  These models were reviewed and two examples of setting up a private certificate authority were explored.

Implement ENUM Call Routing Between Agencies  

The Internet Engineering Task Force (IETF) described an alternate call routing process in a series of standards called E.164 Number to URI Mapping (ENUM). This process maps telephone numbers into DNS NAPTR records, with the DNS returning the URI of the SIP call manager that owns the destination number. This allows calls to be routed in a scalable way. Each provider maintains its own DNS records that other providers can query for routing information.

Calls today between agencies are primarily sent to the Public Switched Telephone Network or PSTN. This made routing simple for the agency: any calls destined for outside of the agency are sent to the service provider. The service provider either uses the well-established legacy Signaling System 7 or SS7 to route the calls over legacy networks, or a service-provider implementation of ENUM.

To route calls directly to other agencies, each agency will need a scalable way to manage the routing information. This section describes the implementation and testing of ENUM for direct agency-to-agency call routing. It describes some of the challenges involved and some ways to overcome those challenges.

Implement a Secure ENUM Infrastructure  

Most computer-related activity is dependent on the Domain Name System (DNS) to convert hostnames, such as host.example.com, to IP addresses. If ENUM is implemented, call routing would also be dependent on DNS. That makes the integrity of the DNS responses that much more critical. To ensure that the DNS responses can be trusted, several security mechanisms were deployed, including Domain Name System Security Extensions (DNSSEC), Transaction Signatures (TSIG), secure replication, DNS over TLS, and DNS over HTTPS.

DNSSEC uses a set of keys to establish a chain of trust between DNS servers. TSIG and secure replication are used between primary and secondary servers within an organization. And DNS over TLS and DNS over HTTPS are used to encrypt the query/response communications between DNS clients and servers.

Implement Secure Caller Identities  

A large percentage of today’s VoIP cyber-attacks involve manipulation of the caller’s telephone number, (Caller ID) or caller name (CNAM), allowing attackers to pretend that they are someone that they are not. These attacks vary from nuisance robocalls to life endangering “swatting” calls.  A combination of services which are Secure Telephone Identity Revisited (STIR) and Signature-based Handling of Asserted information using toKENs (SHAKEN) are mandated by the FCC for implementation by US telephone service providers.  These help to reduce the risk for calls coming from US service providers. Unfortunately, international calls are beyond the control of the FCC. And direct enterprise-to-enterprise calls are outside the scope of the current FCC mandate. This section of the project describes how agencies could utilize STIR/SHAKEN, CNAM and Rich Call Data (RCD) to further secure their VoIP traffic from cyber-attacks.  It also describes how one agency, the U.S. Marine Corps Recruiting Section used Rich Call Data and STIR/SHAKEN to increase the effectiveness of their call center software.

Implement Secure Wireless Calls  

IP Media Subsystem (IMS) is how VoIP (SIP) calls are made over a wireless network. IMS is a Global 3GPP standard that is required for wireless service providers to assure call persistence as a mobile user moves between networks within the service provider, and to support billing information and authentication as these same mobile users roam between service provider’s networks. This section, which is still under development, will describe how calls from service provider and private LTE networks will be able to provide secure voice communications to the rest of the architecture.

Implement Secure Trunks to Voice Service Provider

Finally, calls that cannot be secured end-to-end will always have a default route to a public voice service provider. Today these calls are usually connected without the benefit of encryption. This section describes how to establish a secure voice trunk service from the secure architecture described in this document and the service provider use of TLS and SRTP. Although this call may be transcoded at the far end of the call from TLS to SIP and from SRTP to RTP before it is connected to the unsecured party, it will be secured further than it would be otherwise. This feature was tested and documented with the service provider that provides the commercial SIP trunks to the testbed.