Understanding Stir Shaken: Overview and Guide

STIR/SHAKEN, a communications security framework, was introduced in response to growing concerns over the prevalence and effects of unsolicited calls on telecommunications networks. It has been estimated that between 3 and 5 billion “robocalls” are made each month – and that over 40% of these communications are somehow related to fraud. 

[Image source: magna5global.com]

To assist them in their efforts at gaining access to valuable information or financial assets, criminal actors will often resort to a technique known as spoofing. Here, they use various methods to alter the apparent origin of their outbound phone calls, hoping to fool the recipient into answering what they think is a call that comes from a known location, individual, or institution. 

At the milder end of the scale, such deception can assist the perpetrator in gaining a ready ear for an advertising pitch or information gathering survey. In more severe cases, spoofing can be used by fraudsters and criminals for tricking call recipients into releasing funds, or divulging sensitive data. 

[Image source: ftc.gov]

The Federal Communications Commission (FCC) has been advocating initiatives to curtail this sort of activity since 2014. In response, the telecommunications industry has developed the communications security framework and technology standard known as STIR/SHAKEN. 

In fact, as of June 30, 2021, the FCC has adopted rules requiring telco service providers to deploy a STIR/SHAKEN solution – so it’s definitely something worth knowing about. 

What Does STIR/SHAKEN Mean?

STIR/SHAKEN is a combined acronym. The STIR portion is derived from the first letters of Secure Telephony Identity Revisited and provides a statement of intent for what the technology framework has been created to address. 

SHAKEN is a construct taken from the phrase Secure Handling of Asserted information using toKENs. This points to the digital methodology used in managing communications data, under the STIR/SHAKEN protocol. 

Beyond the lettering, STIR is actually a working group within an internet standards body known as the IETF (the Internet Engineering Task Force). This organization has developed a set of protocols used in creating digital signatures for telephone calls. SHAKEN encompasses the standards governing how STIR should be deployed by telecommunication service providers within their networks. It was formally developed by the Alliance for Telecommunications Industry Solutions (ATIS), and is accredited by the American National Standards Institute (ANSI). 

Basic Principles of STIR/SHAKEN

The STIR Working Group has a charter mandating it to define mechanisms that allow the verification of a calling party’s authorization to use a particular telephone number. 

To achieve this, the STIR/SHAKEN framework makes use of digital certificates, to guarantee the security of the originating number for a phone call. These certificates are based on the techniques of common public key cryptography, under which each service provider must acquire a digital certificate from a certificate authority that is trusted by other telephone service providers. 

[Image source: getvoip.com]

In essence, the cryptographic certificate technology enables the party receiving a call to verify that the calling number is accurate, and has not been spoofed. In a STIR/SHAKEN call, the originating service provider will sign (or attest) to their relationship with the caller, and their right to use the calling number. 

Within the Session Initiation Protocol (SIP) of a digital voice communication, STIR provides the ability to authenticate the caller ID. The SHAKEN protocol defines the end-to-end architecture required to implement caller ID authentication using STIR in the telephone network. 

A Typical STIR/SHAKEN Workflow

When someone initiates a phone call, the calling party issues a SIP INVITE, which goes to the originating service provider. Once received, the provider checks the source of the call and the calling number to determine their attestation level. There are typically three options available: 

1. In Full or “A” Attestation, the service provider knows who the customer is, and can vouch for their right to use a particular phone number.
2. In Partial or “B” Attestation, the service provider knows the customer, but does not know the source of the phone number.
3. In Gateway or “C” Attestation, the service provider cannot authenticate the source of a call (which might for example, be an international gateway) — even though the service provider originates the call onto the network.

The originating service provider will use an authentication service to create an encrypted SIP identity header. This consists of several elements, including:

• The number that the call is coming from
• The receiving number
• The current date and a time stamp of the call
• The attestation level
• A unique origination identifier, which aids in tracing back the call

After this, the SIP Invite and SIP identity header are sent to the terminating provider, who passes the SIP invite to a verification service. If the call is successfully verified, the terminating provider makes a final decision on whether to complete or block the call. In making this decision, they will take the attestation level into account, as well as other factors such as relevant information contained in their own call analytics. 

How It Works in More Detail

Behind the scenes, a typical STIR/SHAKEN implementation consists of several components. They include:

The STI-Authentication Server (STI-AS): This provides an Application Programming Interface known as the REST API, which is responsible for signing requests. To this end, the API has access to private keys in the SKS (Secure Key Store).

The STI-Verification Server (STI-VS): This provides the REST API that plays a role in processing verification requests. This API also retrieves public keys from the public internet using the URL contained in the verification request.

The Authenticator: This is the component in the carrier network that invokes the Authentication and Signing Services to create and verify digital signatures.

The Secure Key Store (SKS): Since every private key used in STIR/SHAKEN verification is a secret known only to the carrier signing the call, it’s important to safeguard these assets. The SKS serves as a safe repository for this purpose. It also provisions the private keys as they are used by the STI-AS in signing requests.

The STI Certificate Repository (STI-CR): This secure web server hosts public certificates, and can be accessed by service providers over the public internet. Each service provider with SHAKEN private keys in a Secure Key Store should have a corresponding STI-CR where its public certificates are published.

The Key Management Server (SP-KMS): This provides automated certificate and key management, and serves a number of functions. The SP-KMS requests and receives a token from the STI-PA over an HTTP interface, in addition to requesting an STI certificate from the STI-CA. It also generates a private and public key pair for signing and verification, storing them respectively in the SKS and the STI-CR.

Current and Future Applications of STIR/SHAKEN

As STIR / SHAKEN becomes more widespread, real-time analytics systems will gain greater ability to differentiate between spoofed and genuine calls, and greater power to filter out the bad communications that can sour the telephony experience for network subscribers. 

STIR/SHAKEN also has the potential to provide a standardized methodology for tracing back the origin of calls. This has been difficult to achieve to date, given the number of disparate networks and connections that are typically involved. However, STIR/SHAKEN includes a standardized tracing function that represents the originating point of a call in each network. This opens up the possibility of streamlining the trace back process. 

In future, adoption of STIR/SHAKEN may also make it possible to create some form of standardized display, which confirms to call recipients that the caller ID of the party initiating an incoming call has been fully verified. This might for example be a Caller Name and Call Purpose display. 

Stir/Shaken as of November 2024

Here are some of the latest updates on STIR/SHAKEN as of November 2024:

1. FCC Regulatory Updates:
   • The FCC is refining STIR/SHAKEN regulations to enhance the framework’s integrity, particularly when service providers rely on third parties for implementation. This aims to curb improperly authenticated calls and bolster accountability in the caller ID authentication process.
   • Expanded obligations now require all providers, including intermediate and non-gateway providers, to participate in the robocall mitigation database, detailing practices to block illegal robocalls and describing “know-your-upstream provider” procedures. These measures enhance traceability and enforcement.
2. Participation and Effectiveness:
   • Participation in STIR/SHAKEN continues to grow. In October 2024, there was a 2.3% increase in the number of providers authorized under the framework, and the percentage of signed calls remained steady at just under 50% at termination.
   • While the percentage of calls with full A-level attestation slightly decreased, B- and C-level attestations saw marginal increases, reflecting a shift in how calls are signed.
3. Robocall Trends:
   • Despite increased participation, robocalls signed with A-level attestation by prolific robocall signers remain high, accounting for 58.3% of such calls in October 2024.
   • The FCC has introduced stricter enforcement tools, including per-call penalties and expedited removal from the robocall mitigation database for non-compliance.

These updates underscore ongoing efforts to improve call authentication, reduce robocalls, and ensure compliance across the telecommunications industry. For further details, you can explore resources like the FCC’s open meeting summaries and reports from industry leaders such as TransNexus.

To get started in using STIR/SHAKEN to authenticate calls on your network right now, you can access our free tool here at IDT.