STIR/SHAKEN verification service

The STIR/SHAKEN framework enables telephone service providers to authenticate and verify caller identities to mitigate caller ID spoofing, a common tactic used in unwanted robocalls. This paper explains how the verification service uses the SIP Identity header and signature provided in a signed call.

This whitepaper covers the following topics to explain the STIR/SHAKEN authentication service:

  1. Verification service
  2. Verification results
  3. Using verification results

1. Verification service

Service providers who terminate calls on the IP network are responsible for verifying calls through a verification service. These terminating service providers verify calls by checking the format and contents of the Identity header and verifying the originating service provider’s signature.

How the verification process works

The terminating service provider uses the Identity header and digital signature provided by the originating service provider in the authentication process. (For more detailed information about this process, see our whitepaper on the STIR/SHAKEN authentication service.) When the terminating service provider receives a signed call with an in-band Identity token, it is sent to the verification service in a verification request. Alternatively, the service provider may receive tokens out-of-band from a Call Placement Service.

Terminating provider receives signed call, sends Invite for verification

SHAKEN Call flow

Review Identity header format and contents

The verification service checks the format and contents of the Identity header and PASSporT token to ensure every required parameter is present and contains a value.

It checks that the date and time indicated in the iat parameter is not earlier than 60 seconds before the time of verification.

To ensure the token contains accurate information, the verification service compares the telephone numbers in the dest and orig parameters with the telephone numbers in the To and From (or P-Asserted-Identity) headers.

Validate the certificate

Before verifying the originating provider’s signature, the terminating provider acquires the originating provider’s certificate and assesses its validity.

The verification service makes a request for the certificate to the originating provider’s certificate repository and receives a copy of the current certificate.

Then the verification service ensures the certificate is currently valid:

  • The expiration date and time have not passed.
  • The issuing certificate authority is currently valid according to a list of approved certificate authorities compiled by the SHAKEN policy administrator.
  • The certificate authority signature on the originating provider’s certificate is verified with the certificate authority’s public key.

The time between sending a certificate request and then receiving the certificate can depends on the distance between the verification service and the certificate repository. To speed up certificate acquisition, the verification service can implement certificate caching.

Verify the signature

Once the originating provider’s certificate has been verified, the verification service extracts the public key from the certificate to verify the signature.

Signatures are evaluated to determine if the call information within the SIP Invite was altered in transit.

The verification service takes the PASSporT token header and payload within the Identity header and computes the hash value.

Then it inputs the public key and digital signature into the signature verification algorithm to obtain the original hash value computed by the originating service provider.

Verify the signature

The verification service compares the computed hash value with the original hash value. If they match, the signature is considered valid.

verify the signature

If the hash values are different, the signature is considered invalid and verification fails. This mechanism allows caller ID spoofing and replay scams to be detected and stopped in real time.

Compare hash values

 

2. Verification results

If an error occurs during verification, the verification service signals this to the originating service provider through an error code:

  • 403: Stale Date. Verification service receives an Identity header that is older than 60 seconds after the time indicated in the iat parameter.
  • 428: No ID Header. Unsigned call is received when it is expected to be signed. This error code is reserved until SHAKEN is widely adopted.
  • 436: Bad Identity Info. Verification service is unable to access the certificate repository listed in info URI due to a request timeout or 4XX (client) or 5XX (server) error.
  • 437: Unsupported Credential. Verification service does not trust certificate or certificate authority.
  • 438: Invalid Identity Header. Signature verification fails, attest value not valid, orig and dest do not match From or P-Asserted-Identity header and To header.

Verification results are transmitted to the called party’s user equipment in the SIP verstat parameter.1 The verstatparameter is a tel URI parameter within the P-Asserted-Identity header or the From header.

P-Asserted-Identity: tel:+15617500080;verstat=TN-Validation-Passed

There are currently three different options to convey verification results through the verstat parameter:

  1. TN-Validation-Passed
  2. TN-Validation-Failed
  3. No-TN-Validation

If the called party’s user equipment does not support the verstat parameter, then the user equipment can discard the parameter.

3. Using verification results

Call analytics

STIR/SHAKEN verification results are valuable when combined with a call analytics service where STIR/SHAKEN provides a source of reliable call data. An analytics service can determine the level of risk associated with an incoming call by evaluating SHAKEN verification results alongside other data:

  • Reported phone number lists (FCC, FTC lists)
  • Social media
  • Caller reputation data

The analytics service can be implemented as part of the terminating network, by a third-party that partners with the terminating service provider or as an application in the user equipment.

Verification policies

Terminating providers will probably want to leverage STIR/SHAKEN verification results in policy actions. The STIR/SHAKEN framework doesn’t specify policy actions. These are left for carriers to develop as a value-added service for their customers.

When planning their STIR/SHAKEN deployment, carriers should give careful consideration to the verification policies they wish to offer and how they will develop these capabilities.

User equipment displays

The results of verification must be communicated to the called party. The creators of the STIR/SHAKEN frameworks have published recommended guidelines on verification displays for user equipment based on usability studies.2

Text-based displays

Some user equipment may be limited to communicating verification results through text. Recommended text-based displays are based on conventional CNAM displays that are limited to 15 alphanumeric characters.

Option 1: A designated special character is added to the official CNAM to indicate whether a call has been verified. In this example, the special character is represented as an asterisk (*).

John Doe*

Option 2: A conventional CNAM query is performed and results are delivered to an analytics server. If a call is unlikely to be fraudulent, the CNAM is displayed. However, if a call is likely to be fraudulent, the CNAM is overwritten with text to indicate fraud.

FRAUDULENT CALL

Visual displays

Usability studies focused on how displaying different icons and descriptions influenced call pickup and blocking rates. Display options can differ depending on whether a call analytics service is used.

Without call analytics:

Without call analytics, the end user equipment only displays whether an incoming call has passed or failed verification.

If verification is successful, then the screen should display a normal call profile without any indication of successful verification such as a padlock or green checkmark. The display may show the calling number, caller name, logo of the calling party, and location (city, state).

Successful verification results without analytics

If verification fails, then the display can show the calling number along with a warning and a brief description for the reason. It is recommended to use the phrase “Fake Number” along with a stop sign icon. The terminating service provider may block these calls if requested by the end user.

Failed verification results without analytics

With call analytics:

With call analytics, the end user equipment can display whether a call is likely to be spam or fraudulent in addition to verification results.

If verification was successful, the display should show the normal call profile. Analytics results can also be provided to give the end user more information to trust the call.

Successful verification results with analytics

If verification was successful but analytics indicates that the call is likely to be spam, then the display should show a warning and reason with the calling number. Analytics results can be added to further explain why the call is likely spam.

Successful verification results with suspicious analytics

If verification fails, then further analytics need not be performed. The screen should display a warning.

Failed verification results with analytics

Conclusion

SHAKEN enables service providers to authenticate and verify caller identities to mitigate call spoofing. Originating service providers are responsible for authenticating calls by creating the signed Identity header. Terminating service providers are then responsible for verifying the call by validating first the originating provider’s certificate and then the signature. Verification results are communicated to the end user through the verstat parameter and an enhanced display. Call analytics can provide additional information to determine if a call should be trusted.


Notes

1. Martin Dolly, “Mitigation Techniques for Unwanted Robocalls: Updates on ATIS and Other Key Industry Initiatives,” October 2016, https://www.atis.org/01_news_events/webinar-pptslides/robocallslides_final.pdf

2. ATIS, “ATIS Technical Report on a Framework for Display of Verified Caller ID,” May 2018, https://access.atis.org/apps/group_public/download.php/40779/ATIS-1000081.pdf


More on TransNexus.com

July 28, 2021

Who should sign SHAKEN calls?

July 26, 2021

Spam robocalls and SHAKEN attestation

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