STIR/SHAKEN
[email protected], 15.05.2021
Contrary to the name, STIR/SHAKEN is not a reference to our favorite British spy series but a new program mandated by the FCC and being implemented by the communications and network carriers nationwide. Like 10DLC for text messaging, STIR/SHAKEN is designed to stop unwanted robocalling, spam calls, and fraud that is often associated with it. In this overview, we’ll explain STIR/SHAKEN and provide background on its major components.
Why We Need It?
If you live in the United States and own a phone, you probably have noticed a higher volume of robocalls in recent years. In fact, nearly five billion robocalls are made every month, and research suggests that more than 40% of those calls may be fraudulent.
Calls about your auto warranty expiring soon, a pending IRS audit, or issues with your social security number are all examples of these types of unwanted calls. The list is endless, and most times these calls are malicious. In 2020 alone, it is estimated that consumers lost nearly $20B to robocall-enabled scams.
Funny Name, What Does STIR/SHAKEN Mean?
STIR/SHAKEN is the title given to the major initiative to improve call validity in the United States. ‘STIR’ is an acronym that stands for ‘Secure Telephone Identity Revisited’. ‘SHAKEN’ stands for ‘Signature-based Handling of Asserted Information Using toKENs standards’.
How It Works
STIR/SHAKEN is a technology framework designed to cut down on fraud and improve calling standards. Its set of protocols and procedures intends to combat issues like Caller ID spoofing on public telephone networks, which is used by robocallers to mask their identity or to make it appear the call is coming from a legitimate source (often a nearby phone number with the same area code and exchange, or from well-known agencies). This sort of spoofing is common for calls originating from ‘Voice over IP’ (VoIP) systems, which can originate anywhere in the world.
Using digitally-verified certificates, STIR/SHAKEN authenticates the transfer of each phone call passing through a complicated series of networks, which allows phone companies to verify that a consumer’s incoming calls are actually coming from the number listed on their Caller ID. Essentially this means that the legitimacy of calls will be checked by both the originating carrier and the carrier of the consumer.
It’s VoIP’s Fault
STIR/SHAKEN has become a necessity because of the high volume of spoofing and robocalls, most of which are coming from VoIP systems. Before understanding STIR/SHAKEN, one must understand why VoIP was a necessary innovation in the first place.
The VoIP system’s introduction allowed users to place calls to other users directly through the Internet, while never having to use the physical public telephone network (which was almost impossible to spoof). At first these systems were proprietary, but over time a series of proposals created the Session Initiation Protocol (SIP), a messaging protocol that contains the information needed to set up a VoIP call between two endpoints online. SIP took elements from existing protocols (for example, using a format similar to the email (SMTP) system). The SIP requests are then sent to proxy servers, which then provide access information to the caller for end-users. These are then used to provide a direct connection between the two..
Because costs for an Internet connection, even one with enough bandwidth to host a large number of simultaneous calls, is much less than leasing that number of physical telephone lines, VoIP created a strong economic benefit for companies as well. Since the late 1990s there have been many new PBX-like systems that use SIP and VoIP to route their calls (whenever possible). A company that has several of these systems spread out over different offices could then easily forward the call to the office closest to the number being dialed, thereby eliminating (or at least reducing) long-distance charges.
New telephony providers took notice of these systems and their rise in popularity. The providers offered centralized SIP routing, which allowed both the companies and the end-users a way to use VoIP systems for calling and routing back out to the ‘Plain Old Telephone Service’ (POTS). Many of these providers also allowed incoming calls from standard phone equipment, which provided local or toll-free numbers for inbound calls, allowing users to place calls to and from anywhere. This local access reduced expenses by avoiding the provider’s own long-distance fees. This benefited robocallers as much as legitimate users, however.
The Rise of Robocalls
By buying the right computers and software, a robocaller can make hundreds of calls at the same time for the cost of a single Internet connection. In the early days, robocallers like this could attempt to hide their identity easily by entering fake Caller ID information into the VoIP software, like a PBX. This also made it impossible to call the number back and make a complaint, or even to report the call to their provider or a government agency. Users quickly stopped taking calls from obviously-faked IDs.
In response to the users catching on, robocallers had to begin using fake IDs that were less obvious. These had a lower chance of being picked up by users, however. The ability to ignore calls from unknown users was the exact reason why many used Caller ID in the first place. Robocallers adapted once again. First, they tried using phone numbers that were similar to users so it appeared local. Later, they used well-known numbers, like government agencies, for their scams. Because of these tactics, instances of robocalls increased to billions a year.
A robocall may be a SIP-initiated call from a VoIP system for most of its trip, and only exit to the POTS network at its final stages (if ever). This sort of call has become so popular that even major service providers, like AT&T, started offering SIP and VoIP to their customers. However, in these cases the Caller ID info is taken from the SIP header, not taken from the provider, and because of that the information is often editable by the end-user. This is where STIR/SHAKEN comes into play.
STIR: A Solution for VoIP
STIR works by adding a digital certificate to the SIP information used to initiate and route calls in VoIP systems. The first point of connection in the call, 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 provides an encrypted certificate to the SIP header, along with the service provider's identity and a trust value.
VoIP software on the receiving end can then check the authenticity of the call by decrypting STIR using the provider's public key. STIR exists within the IETF, an Internet standards body, developing protocols to create a digital signature for phone calls. This signature includes info about the calling party, and also gives verification of the signature by the terminating provider. STIR works to add information to the SIP headers that allow the system to confirm the origin of the data. This does not directly stop a robocaller from spoofing Caller ID, but it does create opportunities upstream to verify and potentially block the call.
For example, a company that is using a VoIP-based PBX might be connected to a larger telephony network through a SIP service provider. When the SIP packet reaches that SIP provider, they can then add more information about the origin and validity of the caller, as well as if the Caller ID is known to their system. The internal phone number may not be necessarily known by the provider, but they know that all phone numbers starting with XXX-XXX belong to the customer, which then proves the incoming call is valid. Similarly, a customer might have a separate toll-free number for return calls, therefore having a legitimate reason to use a different Caller ID number.
There are three levels of verification possible in this STIR protocol:
- The highest level is called ‘Full Attestation’, or level ‘A’. This is when the provider verifies the entire phone number as being registered with the originating subscriber. For example, this could be a landline or mobile phone number of a customer connected directly to the VoIP network, verified as being that particular customer’s number. Another example would be a company that has registered a specific callback number.
- The next-highest level is ‘Partial Attestation’, or ‘B’. This level indicates that the call did originate from a known customer, but the entire number cannot be verified. For example, a call originates from a client PBX but the extension number is not registered with the provider.
- The lowest level is ‘Gateway Attestation’, or ‘C’, which means the call can only be verified as coming from a known gateway, for example, a connection to another service provider.
STIR systems can create a web token which contains the originating phone number (as provided by the original SIP), the number being called, and the level of proof being given by the provider. The data in the token is then encrypted using the provider’s private key, encoded using Base64, and then attached to the original SIP header. This new info then travels, along with the original SIP request, until it reaches its destination (another VoIP system or provider that routes the call to an external telephone).
Once it reaches its destination, the STIR information is then decoded using the provider’s key. If it is decoded properly, it can then take the data, examine its validity, and then decide whether the call can continue or not. If it fails, the STIR info will be considered invalid. If this happens, and if for example the VoIP endpoint is a smartphone, the Caller ID might display that the call is of an unknown origin (level C or Gateway Attestation), or that it failed verification entirely.
One issue that might arise is that it is possible for the VoIP side of the call to add a STIR heading of ‘A’, or ‘Full Attestation’, to calls that are known to be bad. For example, a robocaller’s software could accomplish this. If this happens, users further down the chain would not have the ability to decode the STIR header, therefore leading the authentication to fail. They may also encode their header to look like a trusted source. If that were to happen, the known public key for the real trusted source would be unable to decode the header, and again the authentication would fail.
STIR relies on a system of trust. For this system to work, it requires validation services that are well known, which then allows end user software to know how to retrieve the public key. They need to provide valid information, and not provide keys to bad actors. This system will be based on the already-existing system of Certificate Authority.
Another potential problem: robocallers still might find a VoIP provider willing to verify their calls, the same way there are Internet service providers that allow known email spam farms. Because of this, the STIR header contains both the original phone number as well as the Caller ID being claimed. If they do not match, the STIR authentication will fail. For the robocall to get through, the provider would also have to be willing to fake the number on the Caller ID. In this case, the STIR will validate it and the calls would have to be stopped at a higher level, either through revoking their key or something similar.
SHAKEN: A Solution for Everything Else
For non-VoIP systems, like cell phones and landlines, call routing information is carried by SS7. In these cases, the SIP header is not useful as it cannot be sent to users unless they are on a VoIP connection. The SHAKEN system was created to solve this issue. SHAKEN is a host of guidelines for public-switched telephone networks. They determine how to deal with calls that have incorrect or missing STIR information.
STIR is used by service providers by the standards of SHAKEN in their respective networks. STIR is based on SIP, and is meant to work with the calls being routed through a VoIP network. It does not have the ability to work within the original telephony network. The original network relies on standards (such as SS7) to route its calls. VoIP calls enter the network through a variety of VoIP-to-telephony entryways. They can receive STIR info at the point of entry, or anywhere earlier during the VoIP section of the call. Once inside the telephony network, however, there is no standard for forwarding STIR information to the end user.
STIR also does not decide how authentication failures should be handled by the network. In this period where the system is still being established, most calls will not have STIR info yet. Failed STIR checks cannot simply block the call, as this would be very inconvenient for users. Instead, some type of info needs to be sent to the user, but the details of that information is not part of STIR itself.
STIR/SHAKEN Call Flow
For example,a robocaller dials an end user on a landline or on their mobile phone. It is the last step of this connection that is not directly handled with STIR. Instead, if a call begins in a VoIP system and was also tagged with a successfully authenticated STIR header, the user’s Caller ID may say something ending with “(verified)” versus one that is unauthenticated which may say something like “(spoofed)” or “(no verification)”.
This is where SHAKEN comes in. To address these issues, the Alliance for Telecommunications Industry Solutions (ATIS) started the process of creating the associated system of SHAKEN. SHAKEN includes systems to pass STIR information through the SS7 network, information on how to send STIR information to POTS endpoints, a general standard for how data can be added to SIP for calls that begin in the SS7 network, and crucially a set of guidelines on how to handle STIR failures.
Implementation and Enforcement
Next steps for STIR/SHAKEN
FCC rules require providers to implement STIR/SHAKEN in the IP portions of their networks by June 30, 2021. In September 2020, the FCC went further, implementing the Pallone-Thune Telephone Robocall Abuse Criminal Enforcement and Deterrence Act (TRACED Act) in Congress. They have also created more rules to ensure that providers are taking steps to protect consumers from robocalls, even if they are unable to implement STIR/SHAKEN right away.
As the June deadline arrives, the FCC will start requiring that all providers certify their STIR/SHAKEN implementation in a newly-created public database, or prove that they have started a robocall mitigation program of some kind, to ensure they are not the source of robocalls. All service providers will also be required to submit the contact info of the employee(s) at their company responsible for robocall mitigation. They will also need to include descriptions of steps they are taking to avoid illegal traffic. Finally, they will also be required to either upgrade their networks to IP, or actively work to develop a way of authenticating Caller IDs that is usable on non-IP networks, if they are using older forms of network technology.
