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:

Verification service
Verification results
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

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.

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

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.

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.¹ 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:

TN-Validation-Passed
TN-Validation-Failed
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.²

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/higherlogic/ws/public/download/40779/ATIS-1000081.pdf