In recent years, the exponential rise in robocalls and caller ID spoofing has not only become a nuisance for users but also raised significant privacy and security concerns. In response, a framework called STIR/SHAKEN was introduced to counter these deceptive practices and authenticate caller identity.
This article explores what STIR/SHAKEN is and examines its components.
What is STIR/SHAKEN?
STIR (Secure Telephone Identity Revisited) and SHAKEN (Signature-based Handling of Asserted Information Using Tokens) are protocols designed to ensure the authenticity of caller IDs and prevent identity spoofing. These two abbreviations are often used together because STIR provides the technical framework, while SHAKEN defines how to implement and apply this framework.
The following sections detail how STIR/SHAKEN works.
Components of STIR/SHAKEN
STI-AS (STI-Authentication Server)
Provides REST API access for signing requests and uses private keys from the SKS to do so.
STI-VS (STI-Verification Server)
Offers REST API for verification requests and retrieves public keys over the internet using URLs provided in the request.
Authenticator
The REST API provided by STI-AS and STI-VS should be defined in ATIS 1000082 so it can be invoked by an Authenticator. The Authenticator is part of the carrier network or service provider and calls the authentication and signing service to create and verify digital signatures. In an IMS network, the Authenticator could be I-BCF; in non-IMS networks, it could be SBC or an NGN softswitch. It can also be considered part of the SIP application server that provides the STIR/SHAKEN service.
SKS (Secure Key Store)
Holds private keys used by the STI-AS to sign requests. Each private key is securely stored and is only known to the carrier signing the call.
Private keys provided by the SKS are used by STI-AS to sign requests. Remember, each private key must be securely stored.
STI-CR (Certificate Repository)
This HTTPS web server hosts public certificates, accessible to other service providers over the internet. Each provider that holds SHAKEN private keys in an SKS must have a corresponding STI-CR for publishing public certificates.
SP-KMS (Service Provider Key Management Server)
Manages automated certification and key management. It sends token requests from the STI-PA over an HTTP interface, requests an STI certificate from the STI-CA, and generates private-public key pairs for signing and verification. These are stored in the SKS and STI-CR, respectively.
Levels of Signature Authentication
When the STI-AS creates a digital signature, it provides the carrier with assurance that the caller ID has not been spoofed. Authentication levels include Full (A), Partial (B), and Gateway (C).
Full (A)
A full certificate means the carrier signs the call and:
• Is responsible for initiating the call on an IP-based voice network.
• Connects to the customer and can identify the customer.
• Has a verified association with the phone number used for the call.
In other words, the carrier will know that the caller ID has not been spoofed.
Partial (B)
This certificate means the carrier signs the call and:
• Is responsible for initiating the call on its IP-based voice network.
• Connects to the customer and can identify the customer.
• Cannot establish a verified association with the phone number used for the call.
In other words, while the carrier originates the call and connects with the caller, it cannot ensure that the caller ID is not spoofed.
Gateway (C)
This certificate indicates that the carrier signs the call and:
Serves as the entry point for the call into the operator’s VoIP network.
Has no relationship with the caller (e.g., international gateways).
In other words, the carrier cannot guarantee the caller ID and can only specify where the call entered the network. The primary purpose of the Gateway certificate is call tracing,
such as ending a call entering the network on TDM trunks and TDM-IP gateways.
Example of Signature and Verification
The typical deployment architecture for SHAKEN is as follows:
• Calls are signed by the Interconnect SBC upon leaving the originating operator’s network and directed to STI-AS.
• Calls are verified upon entering the carrier network by the Interconnect SBC, which contacts STI-VS.
Here, we provide an example of this architecture.
Signature
The signing process consists of four distinct steps.
Step 1: Incoming Signing Request via SHAKEN API
The Interconnect SBC in the originating carrier receives a call through SIP and sends it to STI-AS to authenticate the caller ID. The image below shows an example of a signed request done via the SHAKEN RESTful API.
Key elements of this request are as follows:
Origin DN (orig): The phone number of the caller.
Destination DN (dest): The phone number of the receiver.
Issued At (iat): The time the request was initiated.
Origin ID (origid): A globally unique identifier indicating the call’s origin. This helps trace the call’s origin within the network.
Authentication Level (attest): Specifies the call verification level (Full, Partial, or Gateway).
Step 2: STI-AS Creates the Signature
Upon receiving the request, STI-AS creates an Identity header, often called a PASSport or digital signature. This header is base64 encoded but can be converted to a human-readable format.
The header (in red) shows it’s a STIR/SHAKEN PASSport, and the x5u element contains the public certificate URL (STI-CR) for the signing service provider.
The payload (in blue) includes information about the original signing request.
The signature (in green) enables the service provider to securely verify the call. It does so by creating a unique hashed token with the service provider’s private key and other call-specific information. This token can only be verified using the service provider’s public key.
Step 3: STI-AS Responds to SHAKEN API Requests
After creating the signature, a response is sent via API to the SBC, containing the header (in red), payload (in blue), and signature (in green).
Step 4: Adding Identity Header to SIP Message
Finally, the Identity header is added to the SIP message, and the SIP call flow continues normally outside the carrier network.
Verification
The verification process consists of three steps.
Step 1: Incoming Verification Request via SHAKEN API
The Interconnect SBC in the provider network receives a call with a signature, extracts it, and sends a verification request via the SHAKEN API.
Step 2: STI-VS Verifies the Request
STI-VS extracts relevant details from the request and retrieves the public certificate from the originating service provider’s STI-CR using the URL in the header. The public certificate may be cached by STI-VS if previously requested from the same provider, reducing delay during verification.
After retrieving the public certificate, STI-VS verifies the digital signature using standard cryptographic techniques. The verification result is then placed in the verstat header and can take the following values:
TN-Validation-Passed: Verification was successful.
TN-Validation-Failed: Verification was unsuccessful.
No-TN-Validation: No validation was performed.
Step 3: STI-VS Responds to SHAKEN API Requests
Finally, the verification result is encapsulated in the response returned to the SBC via the API. The image below shows a successfully verified response.
Final Remarks
STIR/SHAKEN is a framework serving as a standardized technology for authenticating caller identities in IP networks. This set of standards and protocols allows verification of caller identity information for calls transmitted over IP networks.
Designed by regulatory authorities and technical experts to combat the increase in deceptive calls and number misuse, the framework’s goal is to protect the public from fraudsters and ensure that genuine calls are delivered.
