Caller ID spoofing is the act of maliciously faking the caller ID on a phone call. This is usually to increase the chances of the person being called answering the call and to take advantage of them in some way, perhaps to defraud them. For example, a bad actor may spoof the caller ID to be a number in the local area code of the person being called. This is distinct from changing the caller ID for legitimate reasons, for example if a call center is making a call on behalf of a business and is presenting the caller ID of the business.
At a high level, STIR provides the ability within SIP to authenticate caller ID, and SHAKEN defines the end-to-end architecture to implement caller ID authentication using STIR in the telephone network. You can see a list of relevant standards and specifications here.
See here for a high-level summary of how STIR / SHAKEN works and a description of the STIR / SHAKEN Governance Model.
STIR / SHAKEN architecture
If you look under the hood of a STIR / SHAKEN implementation, you will find the following components.
STI-AS (STI-Authentication Server)
Provides the REST API for signing requests and has access to private keys in the SKS for doing so.
STI-VS (STI-Verification Server)
Provides the REST API for verification requests and retrieves public keys from over the public internet using the URL in the verification request.
Authenticator
The REST API exposed by the STI-AS and STI-VS is defined in ATIS 1000082 and is called into by an Authenticator. The Authenticator is the component in the carrier network that invokes the Authentication and Signing Services to create and verify the digital signatures. In an IMS network this could be an I-BCF, or in a non-IMS network this could be an SBC or an NGN Softswitch. It could also be part of a SIP application server providing STIR / SHAKEN services. The SHAKEN architecture is flexible in terms of where the STI-AS and STI-VS is anchored into the network.
SKS (Secure Key Store)
Private keys are provisioned on the SKS for use by the STI-AS in signing requests. Each private key must be kept very safe, as it is a secret known only to the carrier signing the call.
STI-CR (Certificate Repository)
This is an HTTPS web server hosting the public certificates and accessible to other service providers over the public internet. Every service provider with SHAKEN private keys in an SKS should have a corresponding STI-CR where its public certificates are published.
SP-KMS (Key Management Server)
The SP-KMS provides automated certificate and key management. The SP-KMS
- requests and receives a token from the STI-PA over an HTTP interface
- requests an STI certificate from the STI-CA
- generates a private and public key pair for signing and verification and stores them in the SKS and STI-CR respectively.
For more information on the STI-GA, STI-PA and STI-CA, see here.
Attestation Levels
When the STI-AS creates the digital signature, the carrier is attesting to a certain level of confidence that the caller ID has not been spoofed. This level of confidence is represented by the level of attestation, which is one of Full (A), Partial (B) and Gateway (C).
Full (A)
Full attestation means that the carrier signing the call
- is responsible for the origination of the call onto the IP based voice network
- has a direct authenticated relationship with the customer making the call and can identify the customer
- has established a verified association with the telephone number used for the call.
In other words, the carrier knows the caller ID has not been spoofed.
A straightforward example is a call originating from a residential voice subscriber hosted on an in-network softswitch or IMS Application Server.
Partial (B)
Partial attestation means the carrier signing the call
- is responsible for the origination of the call onto its IP-based voice network
- has a direct authenticated relationship with the customer making the call and can identify the customer
- has NOT established a verified association with the telephone number used for the call.
In other words, although the carrier originated the call and has a relationship with the customer making the call, the carrier cannot be certain the caller ID has not been spoofed.
An example of a call that should be partially attested is from an enterprise customer PBX subscriber (DID) where DIDs are not screened for originating calls because enterprise uses DIDs from multiple carriers. PBX DID screening is a process where a carrier determines whether the caller is permitted to use the DID they are calling from. If a PBX is configured with DIDs assigned from multiple carriers, then it is common practice not to screen the DIDs, because it is not easily possible for a carrier to determine whether a DID has been legitimately assigned by another carrier.
Gateway (C)
Gateway attestation means the carrier signing the call
- is the entry point of the call into the carrier VOIP network
- has NO relationship with the initiator of the call, e.g. international gateways.
In other words, the carrier cannot vouch for the caller ID at all and can only say for certain where the call entered their network. The primary purpose of Gateway attestation is for traceback.
An example of this is a terminating call entering the network on TDM trunks on a TDM-IP gateway.
Example Signing and Verification
Example signing and verification
A common deployment architecture for SHAKEN is that
- calls are signed as they leave the originating carrier’s network by the Interconnect SBC calling into an STI-AS
- calls are verified as they enter the terminating carrier’s network also by the Interconnect SBC calling into an STI-VS.
The following example assumes this architecture.
Signing
Signing consists of four distinct steps.
Step 1. Incoming Signing Request over the SHAKEN API.
The Interconnect SBC in the originating carrier receives a call over SIP and calls into the STI-AS to authenticate the caller ID. Here is an example of a signing request going over the SHAKEN RESTful API.
The important components of this request are as follows.
- Originating DN (orig). This is the telephone number of the person making the call.
- Destination DN (dest). This is the telephone number of the person being called.
- Initiated at time (iat). The time this request is initiated.
- Origination ID (origid). This is a globally unique identifier that represents the originating point of the call, for example the telephone switch where the call started, or a trunk group. This information is used to help traceback the origin of a call on the trusted network.
- Attestation level (attest). This is the attestation level of the call (Full, Partial, or Gateway), see here for more information on what this means.
Step 2. The STI-AS creates the signature
Once the signing request is received, the STI-AS creates an Identity header, often referred to as the PASSport or digital signature. This header is base64 encoded and can be decoded into human readable format consisting of the following three parts.
The Header conveys that this is a STIR / SHAKEN PASSporT, with the x5u element containing the URL of the public certificate (STI-CR) for the service provider signing the call.
The Payload contains the pertinent signing information from the original signing request.
The Signature is used to allow the service provider at the terminating end to securely verify the call. It does this using standard cryptographic techniques which at a high level involve creating a unique hashed token using the service provider’s private key and other information specific to this call. The token can only be verified using the service provider’s public key.
Step 3. The STI-AS responds to the request over the SHAKEN API
Once the signature has been created, the response is sent over the API to the SBC with the Header, Payload and Signature from Step 2.
Step 4: add Identity to the SIP message
Finally, the Identity header from the signing response is added to the SIP message by the SBC as follows and the SIP call flow continues as normal out of the carrier’s network.
Verification
Verification consists of three steps.
Step 1: Incoming verification request over the SHAKEN API
The Interconnect SBC in the terminating service provider’s network receives the call with a signature in it and so the SBC extracts the signature from the SIP message and sends a verification request over the SHAKEN API.
Step 2: The STI-VS verifies the request
The STI-VS extracts the relevant details from the verification request and extracts the public certificate from the originating service provider’s STI-CR using the URL from the info header. The public certificate may be cached by the STI-VS if the STI-VS has already made a request for that certificate when processing a previous verification request from the same originating service provider. The purpose of caching is to reduce latency time during the verification process.
Once the public certificate is retrieved, the STI-VS verifies the digital signature using standard cryptographic techniques. The result of the verification is then placed into the verstat header in the response and can take the following values.
TN-Validation-Passed: successful verification
TN-Validation-Failed: unsuccessful verification, e.g. the certificate could not be trusted or retrieved
No-TN-Validation: no validation occurred, for example there was no signature to be validated.
Step 3: The STI-VS responds to the request over the SHAKEN API
Finally, the result of the verification is encapsulated in the response returned over the API back to the SBC. In this example, the verification was successful.
What to do with the result of the verification?
The results of the verification are used in the following ways.
The first is to feed into the CVT (Call Validation Treatment), also known as Real-Time Analytics – see here for more background. As STIR / SHAKEN becomes more widely deployed in the telephone network, then Real-Time Analytics will be more empowered to tell the difference between spoofed calls and non-spoofed calls and will be better able to filter out the bad calls from the good, ultimately providing a better experience for subscribers.
The second is to provide a standardized method of tracing back the origin of calls. The telephone network is highly distributed and end-to-end calls may traverse many different networks. This makes the problem of tracing back the origin of a call difficult. There is an organizational challenge to get each of the organizations that run the networks to work together and also a technical challenge of piecing together data gathered from multiple networks into a coherent whole. The origid , standardized as part of STIR / SHAKEN, represents the originating point of a call in each network and opens up the possibility of streamlining the traceback process.
The third is potentially to provide some form of display to the end user that the caller ID has been verified. There is much debate in the industry about how useful this is and what form it should take. A study by Transaction Network Services concluded that delivery of reliable Caller Name and call purpose has the highest positive impact on caller pickup rates.