Understanding STIR/SHAKEN

Criminals and unscrupulous robocallers often alter 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 and SHAKEN work

STIR and SHAKEN use 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, and the SHAKEN certificate governance model, will be described in future TransNexus blogs and newsletters.

The following call flow diagram illustrates how SHAKEN works:

How STIR and SHAKEN work in a network

A SIP INVITE is received by the originating telephone service provider.
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 — 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 — 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 — 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.

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
Date and time
Attestation
Unique originating identifier

The SIP INVITE with the SIP identity header is sent to the terminating telephone service provider.
The SIP INVITE with identity header is passed to the verification service.
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 base-64 decoded and the details are compared to the SIP INVITE message.
The certificate is verified to determine if the originating telephone service provider is authorized to originate calls for the calling number.
The public key of the certificate is used to verify the SIP identity header signature.

The verification service returns the results to the terminating service provider’s softswitch or SBC.
The call is completed to the called party.

SIP Identity Header example

The following is an example SIP INVITE message with a SIP Identity Header which is highlighted in yellow, green and blue:

SIP invite example

Signed-identity-digest

The SIP Identity Header has three sections. The contents of each section are described below.

PASSporT header:

Base64 encoded value of {"alg":"ES256","ppt":"shaken","typ":"passport","x5u":"http://ca-authority.com/transnexus.crt"}

alg — Encryption algorithm used. May be either ES256 (recommended) or RS256
ppt — Shaken. This value identifies that the shaken extensions are used.
typ — Passport. This value indicates Personal Assertion Token format.
x5u — Identifies the URL of the X.509 certificate repository.

PASSporT payload:

Base64 encoded value of {"attest":"A","dest":{"tn":["14045266060"]},"iat":1501620763,"orig":{"tn":"14049313777"},"origid":"40597e13-ff75-4516-b998-170f6dfbae94"}

attest — Attestation indicator (A=Full, B=Partial or C=Gateway)
dest — Called number or called Uniform Resource Identifier
iat — Date and time in Unix time format, which represents the number of seconds that have passed since the beginning of 00:00:00 UTC 1 January 1970
orig — Calling number or calling Uniform Resource Identifier
origid — Origination Identifier

PASSporT signature

ident-info: This is the URL for the public certificate repository.

Ident-info-params

ident-info-alg: This value may be ES256 or RS256. ES256 is recommended and indicates that support for signing JSON Web Tokens (JWTs) with the Elliptic Curve Digital Signature Algorithm (ECDSA) using the P-256 curve and the SHA-256 hash algorithm is required.

ident-type: PASSporT extension identifier indicates the token includes the Attest and Origid elements.

Find out more

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.

More on TransNexus.com

November 16, 2018

New bill to mandate SHAKEN introduced in the U.S. Senate

November 15, 2018

U.S. SHAKEN governance authority issues RFP for policy administrator selection

November 6, 2018

FCC chairman asks telecom carriers to implement SHAKEN without delay

October 10, 2018

State attorneys general call for aggressive implementation of STIR/SHAKEN

September 21, 2018

TransNexus in the news about STIR-SHAKEN

Notes

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:

draft-ietf-stir-rfc4474bis. Defines how SIP Identity tokens are used to authenticate and verify the calling number in SIP signaling.
draft-ietf-stir-passport. Defines a method for creating and validating a token that cryptographically verifies a calling number.
draft-ietf-stir-certificates. Describes the use of certificates in establishing authority over telephone numbers.

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).