Understanding STIR/SHAKEN

Criminals and unscrupulous robocallers often alter or spoof the calling number of their outbound telephone calls in order to deceive the called party. This deception can be as simple as changing the calling number so it appears that a neighbor is calling.

This deception increases the chance that the called party will answer a robocall. In other cases, the deception may be more malicious, such as a fraudster impersonating an IRS agent in order to steal a tax refund. This practice of altering the calling number of a telephone call is known as spoofing.

The Federal Communications Commission (FCC) has been encouraging the telecommunications industry to develop a solution to stop robocalls and spoofed calling numbers since 2014. The industry’s response has been to develop a new technology standard called STIR [1] (Secure Telephony Identity Revisited) and SHAKEN [2] (Secure Handling of Asserted information using toKENs) which defines how telephone service providers should implement the STIR technology to ensure calling numbers are not spoofed.

How STIR/SHAKEN works

STIR/SHAKEN uses digital certificates, based on common public key cryptography techniques, to ensure the calling number of a telephone call is secure. In simple terms, each telephone service provider obtains their digital certificate from a certificate authority who is trusted by other telephone service providers. The certificate technology enables the called party to verify that the calling number is accurate and has not been spoofed. The details of how SHAKEN uses public key infrastructure is explained in our whitepaper on Certificate Management for STIR/SHAKEN.

The following call flow diagram illustrates how STIR/SHAKEN works:

How STIR/SHAKEN works in a network

How STIR and SHAKEN work in a network
  1. A SIP INVITE is received by the originating telephone service provider.
  2. The originating telephone service provider checks the call source and calling number to determine how to attest for the validity of the calling number.
    • Full Attestation (A) — The service provider has authenticated the calling party and they are authorized to use the calling number. An example of this case is a subscriber registered with the originating telephone service provider’s softswitch.
    • Partial Attestation (B) — The service provider has authenticated the call origination, but cannot verify the call source is authorized to use the calling number. An example of this use case is a telephone number behind an enterprise PBX.
    • Gateway Attestation (C) — The service provider has authenticated from where it received the call, but cannot authenticate the call source. An example of this case would be a call received from an international gateway.
  3. The originating telephone service provider uses the authentication service to create a SIP Identity header. The authentication service could be a third-party service hosted in the cloud a software application integrated with the telephone service provider’s softswitch or Session Border Controller (SBC). The SIP Identity header contains the following data:
    • Calling number
    • Called number(s)
    • Current timestamp
    • Attestation level
    • Origination identifier
  4. The SIP INVITE with the SIP Identity header is sent to the terminating telephone service provider. In addition, the Identity token may be sent across the internet, around non-SIP call segments, using Out-of-Band SHAKEN.
  5. The SIP INVITE with Identity header is passed to the verification service.
  6. The verification service obtains the digital certificate of the originating telephone service provider from the public certificate repository and begins a multi-step verification process. If all verification steps are successful, then the calling number has not been spoofed.
    • The SIP Identity header is base64 URL decoded and the details are compared to the SIP INVITE message.
    • The public key of the certificate is used to verify the SIP Identity header signature.
    • The certificate chain of trust is verified.
  7. The verification service returns the results to the terminating service provider’s softswitch or SBC.
  8. The call is completed to the called party.

SIP Identity header example

The following is an example SIP INVITE message with an Identity header:

SIP invite example

INVITE sip:18001234567@example.com:5060 SIP/2.0
Via: SIP/2.0/UDP example.com:5060
From: "Alice" <sip:14045266060@5.6.7.8:5060>;tag=123456789
To: "Bob" <sip:18001234567@1.2.3.4:5060>
Call-ID: 1-12345@5.6.7.8
CSeq: 1 INVITE
Max-Forwards: 70
Identity: eyJhbGciOiAiRVMyNTYiLCJwcHQiOiAic2hha2VuIiwidHlwIjogInBhc3Nwb3J0IiwieDV1IjogImh0dHBzOi8vY2VydGlmaWNhdGVzLmNsZWFyaXAuY29tL2IxNWQ3Y2M5LTBmMjYtNDZjMi04M2VhLWEzZTYzYTgyZWMzYS83Y2M0ZGI2OTVkMTNlZGFkYTRkMWY5ODYxYjliODBmZS5jcnQifQ.eyJhdHRlc3QiOiAiQSIsImRlc3QiOiB7InRuIjogWyIxNDA0NTI2NjA2MCJdfSwiaWF0IjogMTU0ODg1OTk4Miwib3JpZyI6IHsidG4iOiAiMTgwMDEyMzQ1NjcifSwib3JpZ2lkIjogIjNhNDdjYTIzLWQ3YWItNDQ2Yi04MjFkLTMzZDVkZWVkYmVkNCJ9.S_vqkgCk88ee9rtk89P6a6ru0ncDfSrdb1GyK_mJj-10hsLW-dMF7eCjDYARLR7EZSZwiu0fd4H_QD_9Z5U2bg;info=<https://certificates.clearip.com/b15d7cc9-0f26-46c2-83ea-a3e63a82ec3a/7cc4db695d13edada4d1f9861b9b80fe.crt>alg=ES256;ppt=shaken

The SIP Identity header contains a JSON web token (JWT) and three parameters. The JWT has three sections: header + payload + signature. The header and payload are base64 URL encoded JSON. The contents of each section are described below.

The SIP Identity header is comprised of a web token and parameters, as follows:

  • JSON web token
    • Header
    • Payload
    • Signature
  • Parameters
    • Info
    • Alg
    • PPT

JSON web token

Encoded Header

Identity: eyJhbGciOiAiRVMyNTYiLCJwcHQiOiAic2hha2VuIiwidHlwIjogInBhc3Nwb3J0IiwieDV1IjogImh0dHBzOi8vY2VydGlmaWNhdGVzLmNsZWFyaXAuY29tL2IxNWQ3Y2M5LTBmMjYtNDZjMi04M2VhLWEzZTYzYTgyZWMzYS83Y2M0ZGI2OTVkMTNlZGFkYTRkMWY5ODYxYjliODBmZS5jcnQifQ.eyJhdHRlc3QiOiAiQSIsImRlc3QiOiB7InRuIjogWyIxNDA0NTI2NjA2MCJdfSwiaWF0IjogMTU0ODg1OTk4Miwib3JpZyI6IHsidG4iOiAiMTgwMDEyMzQ1NjcifSwib3JpZ2lkIjogIjNhNDdjYTIzLWQ3YWItNDQ2Yi04MjFkLTMzZDVkZWVkYmVkNCJ9.S_vqkgCk88ee9rtk89P6a6ru0ncDfSrdb1GyK_mJj-10hsLW-dMF7eCjDYARLR7EZSZwiu0fd4H_QD_9Z5U2bg;info=<https://certificates.clearip.com/b15d7cc9-0f26-46c2-83ea-a3e63a82ec3a/7cc4db695d13edada4d1f9861b9b80fe.crt>alg=ES256;ppt=shaken

Decoded Header

{
  "alg": "ES256",
  "ppt": "shaken",
  "typ": "passport",
  "x5u": "https://certificates.clearip.com/b15d7cc9-0f26-46c2-83ea-a3e63a82ec3a/7cc4db695d13edada4d1f9861b9b80fe.crt"
}

  • alg — This value indicates the encryption algorithm. Must be ES256.
  • ppt — This value indicates the extension used. Must be shaken.
  • typ — This value indicates the token type. Must be passport.
  • x5u — This value indicates the location of the certificate used to sign the token.

Encoded Payload

Identity: eyJhbGciOiAiRVMyNTYiLCJwcHQiOiAic2hha2VuIiwidHlwIjogInBhc3Nwb3J0IiwieDV1IjogImh0dHBzOi8vY2VydGlmaWNhdGVzLmNsZWFyaXAuY29tL2IxNWQ3Y2M5LTBmMjYtNDZjMi04M2VhLWEzZTYzYTgyZWMzYS83Y2M0ZGI2OTVkMTNlZGFkYTRkMWY5ODYxYjliODBmZS5jcnQifQ.eyJhdHRlc3QiOiAiQSIsImRlc3QiOiB7InRuIjogWyIxNDA0NTI2NjA2MCJdfSwiaWF0IjogMTU0ODg1OTk4Miwib3JpZyI6IHsidG4iOiAiMTgwMDEyMzQ1NjcifSwib3JpZ2lkIjogIjNhNDdjYTIzLWQ3YWItNDQ2Yi04MjFkLTMzZDVkZWVkYmVkNCJ9.S_vqkgCk88ee9rtk89P6a6ru0ncDfSrdb1GyK_mJj-10hsLW-dMF7eCjDYARLR7EZSZwiu0fd4H_QD_9Z5U2bg;info=<https://certificates.clearip.com/b15d7cc9-0f26-46c2-83ea-a3e63a82ec3a/7cc4db695d13edada4d1f9861b9b80fe.crt>alg=ES256;ppt=shaken

Decoded Payload

{
  "attest": "A",
  "dest": {
    "tn": [
      "14045266060"
    ]
  },
  "iat": 1548859982,
  "orig": {
    "tn": "18001234567"
  },
  "origid": "3a47ca23-d7ab-446b-821d-33d5deedbed4"
}

  • attest — This value indicates the attestation level. Must be either A, B, or C.
  • dest — This value indicates the called number(s) or called Uniform Resource Identifier(s).
  • iat — This value indicates the timestamp when the token was created. The timestamp is the number of seconds that have passed since the beginning of 00:00:00 UTC 1 January 1970.
  • orig — This value indicates the calling number or calling Uniform Resource Identifier.
  • origid — This value indicates the origination identifier.

Signature

S_vqkgCk88ee9rtk89P6a6ru0ncDfSrdb1GyK_mJj-10hsLW-dMF7eCjDYARLR7EZSZwiu0fd4H_QD_9Z5U2bg

Parameters

info

info=<https://certificates.clearip.com/b15d7cc9-0f26-46c2-83ea-a3e63a82ec3a/7cc4db695d13edada4d1f9861b9b80fe.crt>;

This value indicates the location of the certificate used to sign the token. It must be the same as the x5u value in the JWT.

alg

alg=ES256;

This value indicates the encryption algorithm. Must be ES256.

ppt

ppt=shaken

This value indicates the extension used. Must be shaken.

TransNexus STIR/SHAKEN solutions

We offer production-ready STIR/SHAKEN solutions in our ClearIP and NexOSS software products. These solutions are unique in their capabilities to combine complete STIR/SHAKEN services with flexible policy controls and a comprehensive portfolio of other services, including fraud prevention, least cost routing and much more.

Contact us today to explore how we can help you implement SHAKEN quickly and easily.

Request information

* required

This information will only be used to respond to your inquiry. TransNexus will not share your data with any third parties. We will retain your information for as long as needed to retain a record of your inquiry. For more information about how we use personal data, please see our privacy statement.


Notes

  1. STIR, or Secure Telephony Identity Revisited, is a Working Group of the Internet Engineering Task Force (www.ietf.org). The IETF’s stated mission is to make the Internet work better by producing high quality, relevant technical documents that influence the way people design, use, and manage the Internet. The charter for the STIR Working Group (WG) is to define mechanisms that allow verification of the calling party's authorization to use a particular telephone number. The IETF standards developed by the STIR WG are:
    • RFC 8224. Defines how SIP Identity tokens are used to authenticate and verify the calling number in SIP signaling.
    • RFC 8225. Defines a method for creating and validating a token that cryptographically verifies a calling number.
    • RFC 8226. Describes the use of certificates in establishing authority over telephone numbers.
  2. SHAKEN provides telephone services providers with a framework and guidance on how to use techniques defined by the STIR WG for validation of legitimate calls and the mitigation of illegitimate spoofing of telephone identities on the VoIP Telephone Network. SHAKEN is formally known as the ATIS Standard on Signature-based Handling of Asserted Information Using Tokens. ATIS (www.atis.org), or the Alliance for Telecommunications Industry Solutions, is accredited by the American National Standards Institute (ANSI).

More on TransNexus.com

July 15, 2021

SHAKEN for TDM standards approved

July 14, 2021

SHAKEN attestation statistics for early July 2021

July 2, 2021

June 2021 STIR/SHAKEN statistics

July 1, 2021

Webinar—Out-of-Band SHAKEN deployment—everything you need to know

July 1, 2021

Robocall Mitigation Database filing statistics

June 29, 2021

Robocaller tried to hack SHAKEN

June 23, 2021

FCC issues public notice on SHAKEN and robocall mitigation June 30 deadline

June 16, 2021

TransNexus at ITEXPO 2021

June 15, 2021

May 2021 STIR/SHAKEN statistics

June 11, 2021

Webinar recording — Preparing for SHAKEN in Canada

June 9, 2021

Robocall Mitigation Database filing statistics

June 7, 2021

U.S. — Canada cross-border SHAKEN

June 2, 2021

Webinar — TDM to SIP network transformation best practices

June 1, 2021

Webinar — Robocall mitigation filing essentials

May 26, 2021

Webinar — Preparing for SHAKEN in Canada

May 25, 2021

Press release — New Out-of-Band SHAKEN whitepaper available

May 13, 2021

FCC — Service providers must now diligently pursue SHAKEN certificates

May 11, 2021

STI Governance Authority changes effective date of new SPC token access policy

May 3, 2021

Out-of-Band SHAKEN goes to letter ballot

April 30, 2021

Webinar recording — Robocall mitigation filing essentials

April 26, 2021

Robocall mitigation certification filing begins

April 7, 2021

Canadian regulator postpones STIR/SHAKEN deadline

March 31, 2021

FCC STIR/SHAKEN deadline extension petitions denied or withdrawn

March 29, 2021

Robocall mitigation compliance strategy

March 26, 2021

Webinar recording — Prepare for the FCC robocall deadline

March 3, 2021

Why you might use a Centralized SHAKEN Server, and how

February 23, 2021

Webinar — What is STIR/SHAKEN, and how to comply

February 23, 2021

TransNexus works with DigiCert to provide SHAKEN certificates

February 17, 2021

ClearIP Out-of-Band SHAKEN enhancements

February 8, 2021

FCC to telcos—You cannot be dumb pipes for robocalls

February 4, 2021

U.S. SHAKEN Governance Authority issues year-end report for 2020

February 1, 2021

Webinar — TRACED Act compliance — everything you need to know

January 27, 2021

Service provider STI fee changes for 2021

January 18, 2021

Webinar recording — Complying with the TRACED Act made simple

January 15, 2021

FCC proposes rules on SHAKEN certificate revocation for noncompliance

January 4, 2021

FCC issues further restrictions on robocalls