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
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.
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.
Our STIR/SHAKEN products:
- Most affordable commercial solutions
- Work with your existing network
- Include support with deployment
STIR/SHAKEN information hub
Whitepapers, videos, and more
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.
There are currently three different options to convey verification results through the verstat parameter:
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
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.
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
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 (*).
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.
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).
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.
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.
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.
If verification fails, then further analytics need not be performed. The screen should display a warning.
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.
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
July 26, 2021
July 15, 2021
July 14, 2021
July 2, 2021
July 1, 2021
July 1, 2021
June 29, 2021
June 23, 2021
June 16, 2021
June 15, 2021
June 11, 2021
June 9, 2021
June 7, 2021
June 2, 2021
June 1, 2021
May 26, 2021
May 25, 2021
May 13, 2021
May 11, 2021
May 3, 2021
April 30, 2021
April 26, 2021
April 7, 2021
March 31, 2021
March 29, 2021
March 26, 2021
March 3, 2021
February 23, 2021
February 23, 2021
February 17, 2021
February 8, 2021
February 4, 2021
February 1, 2021
January 27, 2021
January 18, 2021
January 15, 2021
January 4, 2021