STIR/SHAKEN

STIR/SHAKEN, or SHAKEN/STIR, is a suite of protocols and procedures intended to combat caller ID spoofing on public telephone networks. Caller ID spoofing is used by robocallers to mask their identity or to make it appear the call is from a legitimate source, often a nearby phone number with the same area code and exchange, or from well-known agencies like the Internal Revenue Service or Ontario Provincial Police. This sort of spoofing is common for calls originating from voice-over-IP (VoIP) systems, which can be located anywhere in the world.

STIR, short for Secure Telephone Identity Revisited, has been defined as a series of RFC standards documents by a Working Group of the Internet Engineering Task Force. It works by adding a digital certificate to the Session Initiation Protocol information used to initiate and route calls in VoIP systems. The first public connection on the system, typically the VoIP service provider, examines the caller ID and compares it to a known list of IDs they provide to that customer. The provider then attaches an encrypted certificate to the SIP header with the service provider's identity and a trust value. VoIP software on the receiving end can check the authenticity of the message by decrypting STIR using the provider's public key.

For non-VoIP systems, like cell phones and landlines, call routing information is carried by SS7. In these cases, the SIP header is not directly useful as it cannot be sent to users unless they are on a VoIP connection. This is the purpose of the SHAKEN system, short for Signature-based Handling of Asserted information using toKENs. SHAKEN is a suite of guidelines for public switched telephone networks that indicate how to deal with calls that have incorrect or missing STIR information. This may be in the form of additional information in the CNAM information of caller ID indicating the number has been spoofed, but the details have not been finalized.

As of 2019, STIR/SHAKEN is a major ongoing effort in the United States, which is suffering an "epidemic" of robocalls. The Federal Communications Commission requires use of the protocols by June 30, 2021. The Canadian Radio-television and Telecommunications Commission requires use of the protocols by November 30, 2021.

The name was inspired by Ian Fleming's character James Bond, who famously prefers his martinis "shaken, not stirred". STIR having existed already, the creators of SHAKEN "tortured the English language until [they] came up with an acronym."

Background

Caller ID

Main article: Caller ID

The idea of sending the phone number to the customer for identification purposes dates to 1968, when Ted Paraskevakos introduced the idea of modem-like devices that would send and receive the information over normal voice lines. It sent a small burst of information using the 1200 bit/s Bell 202 modulation in the time between the first and second rings. The concept was developed through the 1970s and had its first public trial with Bell Atlantic in 1984 and a follow-up in 1987.

The system was widespread in the United States and Canada by the mid-1990s, and spread to most other countries by the end of the decade. It soon became an indispensable system allowing customers to screen calls from telemarketers. Marketers often provided alternative numbers in the caller ID so returned calls went to an inbound call center instead of the telemarketing firm where the call originated. Unscrupulous users began using this concept, which became known as "spoofing", to hide the true origins of the call to prevent callbacks. This became so common that the Federal Trade Commission (FTC) was given the mandate to sue companies that provided false caller ID information.

VoIP and SIP

Main article: Session Initiation Protocol

The introduction of voice-over-IP (VoIP) systems allowed users to place calls to other users directly through the internet without ever using the public telephone network. Initially, these systems were proprietary, but over time a series of proposals created the Session Initiation Protocol (SIP), a messaging protocol that contained the information needed to set up a VoIP call between two endpoints. SIP borrowed from existing protocols, including the use of simple headers like "From:" in a format similar to the SMTP email system. SIP requests are sent to proxy servers that provide access information for end-users to the caller, which is then used to provide a direct connection between the two endpoints.

As the cost of an Internet line with enough bandwidth to host a given number of simultaneous calls is much less than leasing that number of telephone lines, there was a strong economic benefit for companies to switch to VoIP as well. From the late 1990s a number of new PBX-like systems emerged that use SIP and VoIP to route calls wherever possible, only exiting to the public switched telephone network (PSTN) system when required to call a non-VoIP user. A company with several of these systems in separate offices could forward the call to the one closest to the number being dialed, thereby reducing or eliminating long distance charges.

As these systems became popular, new telephony providers emerged that offered centralized SIP routing, allowing both companies and end-users to use VoIP systems to call the service and then route back out to the PSTN. Many of these also allowed incoming calls from conventional phone equipment, providing local or toll-free numbers for the inbound calls. This allowed users to place calls to and from anywhere with local access for a greatly reduced cost by avoiding the telephone company's own long-distance service.

Today, a call may travel for most of its "distance" as a SIP-initiated VoIP call, only exiting to the SS7 PSTN network at the final stages, if ever. As this sort of call became common, even the largest service providers, like AT&T, began offering SIP/VoIP to their customers. In this case, the caller ID information is taken from the SIP headers, not the provider, and that information is often editable by the end-user.

ID spoofing

Main article: Caller ID spoofing

The opening of the telephone network to VoIP systems resulted in a dramatic lowering in cost for the support of multiple simultaneous phone calls. This was as much of a boon to robocallers as it was to legitimate users. By purchasing commodity personal computers and running suitable software, a robocaller can make hundreds of simultaneous calls for the cost of a single Internet connection.

In the early days of such robocalling, the caller would often attempt to hide their identity by entering false caller ID information into the VoIP software. This had the added advantage to the robocaller of making it impossible for the called user to call back to complain, or even report the call to their provider or government agency like the Federal Trade Commission. Users quickly learned to stop taking calls from obviously faked IDs.

In response, robocallers began using less obviously incorrect IDs, but these had a lower chance of being picked up – the chance to ignore a call from an unknown user was precisely why many used caller ID in the first place. Robocallers changed their tactics again, first by using phone numbers that were similar to the user's to make it appear local, and later by using well-known numbers, often government agencies, as part of scams. Using such tactics, robocalls become an increasing problem, rising another 18% year-over-year in 2019 with 26 billion calls between January and October, with an estimated 5.7 billion robocalls in the US placed in October 2019 alone. Estimates for 2020 are 46 billion robocalls in the US alone.

STIR

The STIR system aims to add information to the SIP headers that allow the endpoints along the system to positively identify the origin of the data. This does not directly prevent the ability for a robocaller to spoof a caller ID, but it does allow upstream points to decide whether or not to trust that ID.

For instance, a business system using a VoIP-based PBX might connect to the wider telephony network through a SIP service provider. When the SIP packet is received by these providers, they will add additional information to the header, indicating whether they are sure the call originates with a known customer and whether or not the caller ID they provided is one that is known to their system. In this example, the internal phone number may not be known by the provider, but they may agree that all numbers starting with 555-555 do indeed belong to that customer, and that the provided ID, 555-555-1234, is therefore valid. Likewise, a customer might use a separate toll-free number for return calls and thus have a legitimate reason to use a totally different caller ID number, perhaps 800-123-4567.

There are three levels of verification, or "attestation", possible in the STIR protocol. The highest level, "Full Attestation", indicated in the STIR header with an "A", indicates that the provider recognizes the entire phone number as being registered with the originating subscriber. This would be the case for a landline or mobile phone where the customer connects directly to the VoIP network and the phone number can be verified as being a particular customer, or in the case of a company that has registered a particular callback number. "Partial Attestation", or "B", indicates that the call originated with a known customer but the entire number cannot be verified, which would be the case with a call originating from a client PBX where the extension number is not registered with the provider. "Gateway Attestation", "C", indicates the call can only be verified as coming from a known gateway, for instance, a connection to another service provider.

STIR systems produce a JSON Web Token containing, among other things, the originating phone number as provided by the original SIP, the number being called, and the level of attestation being given by the provider. This information is then encrypted with the provider's private key, encoded using Base64, and appended to the original SIP header in a new Identity field. The new information now travels along with the original SIP request until it reaches its destination, another VoIP system or provider that will route the call to an external telephone.

On reception, the STIR information is decoded using the provider's public key. If this fails, the STIR information can be considered invalid. If it properly decodes, it can extract the information and examine the attestation to decide whether to allow the call to continue. In the case of a VoIP endpoint on a smart phone, for instance, the display might show that the call is of an unknown origin ("C") or that it failed verification entirely.

Anyone on the VoIP side of the call can add a STIR header claiming "A" attestation even to known-bad calls. This may start in a robocaller's software, for instance. In this case, upstream users would not have the keys necessary to decode the STIR header and the authentication would fail. The software might also encode a header to pose as a trusted source, but in this case, the known public key for trusted source would fail to decode the header and the authentication would fail.

The STIR system relies on a chain of trust. For this to work, the system requires certification services that are well known so end-user software knows whom to query to retrieve the public key, and are trusted to provide valid information and not provide keys to known-bad players. This network will be based on the existing Certificate Authority system in use today.

The robocaller might find a VoIP provider willing to sign their calls even though they are known-bad, in the same fashion that there are Internet service providers that provide service to known email spam farms. To combat this, the STIR header contains both the original phone number when it enters the provider as well as the caller ID being claimed. If these do not match, the STIR authentication fails. For such a certificate to get through, the provider would also have to be willing to fake the number on reception, for instance, by copying whatever caller ID number the robocaller provided. In this case the STIR will validate correctly, and stopping such calls will have to be done at a higher level, through key revocation or similar.

The STIR system is defined as a series of Request for Comments documents by the IETF:

• RFC 8224 – Authenticated Identity Management in the Session Initiation Protocol (SIP)
• RFC 8225 – PASSporT: Personal Assertion Token
• RFC 8226 – Secure Telephone Identity Credentials: Certificates
• RFC 8588 – Personal Assertion Token (PaSSporT) Extension for Signature-based Handling of Asserted information using toKENs (SHAKEN)

SHAKEN

STIR is based on SIP and is designed to work with calls being routed through a VoIP network. It does not work within the "original" telephony network, which relies on standards such as SS7 to route calls. VoIP calls enter the network at the "edge" through a variety of VoIP-to-telephony gateways, and they can receive STIR information at that point or anywhere earlier during the VoIP section of the call. But once inside the telephony network there is no standard for forwarding that STIR information to the end user.

Additionally, STIR does not define how authentication failures should be handled within the network. In a system where most calls will not have STIR information, at least during the period where the system is being set up, failed STIR checks cannot simply block the call. Some sort of information has to be sent to the user, but the precise nature of that information is not part of STIR itself.

Developed jointly by the SIP Forum and ATIS (the Alliance for Telecommunications Industry Solutions) to efficiently implement the Internet Engineering Task Force’s (IETF) STIR (for Secure Telephony Identity Revisited) standard, SHAKEN (for Signature-based Handling of Asserted information using toKENs) defines a mechanism to verify the calling number and specifies how it will be transported across communications networks.

Together, STIR/SHAKEN offers a practical mechanism to provide verified information about the calling party as well as the origin of the call—what is known as "attestation"—for the first time in the network. Giving service providers the tools needed to sign and verify calling numbers makes it possible for businesses and consumers to know, before answering, that the calls they receive are from legitimate parties.

In the common case of a robocaller calling an end user on a landline or mobile phone, it is the last step of the connection that does not directly handle STIR. For instance, if a call originates in a VoIP system and was tagged with a STIR header that successfully authenticated, the caller ID provided to the user might be appended with "(verified)", whereas one that fails might say "(spoofed)" or "(no verification)".

As of 2019, the exact nature of the messages sent to end users is still being discussed. The Secure Telephone Identity Governance Authority, or STI-GA, is organizing these discussions as well as calling for certificate authorities who will handle the majority of the key protocol. Additionally, the Secure Telephone Identity Policy Administrator, or STI-PA, has the job of actually carrying out policy decisions like key revocation. On May 30, 2019, the GA announced iconectiv had won the role of PA.

Implementation

STIR/SHAKEN was designed to allow expansion to carriers outside the United States.

On December 9, 2019, FCC commissioner Ajit Pai and CRTC chairman Ian Scott conducted "the first official cross-border call" using the protocol. The same day, the CRTC announced that it "expects" all phone providers to adopt STIR/SHAKEN no later than September 30, 2020. This was later extended to June 30, 2021 at the request of Rogers Communications Canada Inc. The implementation date was again pushed back to November 30, 2021, as the CRTC announced that no TSP will be exempted from the requirement.

Enforcement

See also: Mobile phone spam § Criminality and law enforcement

In January 2018, the CRTC issued Compliance and Enforcement and Telecom Decision 2018-32, which states that the CRTC expects Canadian Telecommunications Service Providers to implement STIR/SHAKEN by 31 March 2019, establish a Canadian administrator, and issue progress reports.

In December 2019, the CRTC issued decision 2019-402, which extended the deadline to 30 September 2020. At the same time, the CRTC issued CRTC 2019-403, which approved the establishment of the Canadian Secure Token Governance Authority (CSTGA) as Governance Authority for STIR/SHAKEN.

In September 2020, the CRTC issued decision 2019-402-2, which extended the deadline to 30 June 2021.

In December 2019, the TRACED Act (Telephone Robocall Abuse Criminal Enforcement and Deterrence Act) was signed into U.S. law, which compels the FCC to mandate implementation of the protocols by all U.S. phone companies. The FCC approved the mandate on March 31, 2020, under which large carriers must implement the systems by June 30, 2021, and smaller and rural carriers by June 30, 2022.

In July 2021, the CRTC issued decision 2021-123, further pushing back the implementation deadline to 30 November 2021, while also making it clear that no carrier in Canada would be exempt from the implementation date, in contrast to FCC's decision to grant exemptions to smaller and rural operators.

Testing

Interoperability working:

1. T-Mobile – Sprint

Production

1. AT&T – Comcast
2. Verizon (internal)

See also

• Mobile phone spam
• Telemarketing fraud
• Robocall
• VoIP spam

References

Bibliography

• "Frequently Asked Questions" (PDF). ATIS.
• "Certificate management for STIR/SHAKEN". TransNexus.
• "How SIP Works in VoIP". SIP.US. December 1, 2013.
• "STIR/SHAKEN Information Hub". TransNexus.