Voice communication remains a critical channel for businesses and government agencies, yet trust is eroding due to the widespread use of spoofed numbers. According to the CFCA Global Fraud Loss Survey 2025, global losses from telecommunications fraud have reached approximately $41.82 billion. The primary attack vector remains Caller ID spoofing, as traditional signaling protocols lack built-in mechanisms to verify the origin of a call.
To cryptographically confirm the legitimacy of a number, the STIR/SHAKEN standards were developed. However, their implementation at the transit network level represents a complex modernization of the voice core, requiring the integration of anti-fraud systems with flexible operator platforms.
Anatomy of spoofing: why SIP networks are vulnerable to Caller ID manipulation by default
In the basic SIP (Session Initiation Protocol) architecture, the initiator's identity is transmitted in SIP INVITE headers, such as From or P-Asserted-Identity. The problem is that a transit node or a malicious initiator can insert any value there, and the recipient's network trusts this metadata by default.
This architectural feature leads to several types of fraud:
- Vishing (Voice Phishing): Attackers mimic bank or payment system call center numbers, manipulating user trust to obtain confidential data.
- Impersonation of official institutions: Unauthorized modification of the caller's identifier to simulate calls from government agencies, tax authorities, or the police.
- Bypassing inter-operator billing: Spoofing numbers at the SIP trunk level between carriers to disguise expensive international traffic as cheaper local traffic.
Furthermore, a significant portion of calls in mobile networks passes through legacy signaling protocols. According to the ENISA Threat Landscape 2025, the exploitation of SS7 and Diameter protocol vulnerabilities creates ongoing security risks, generating thousands of incidents. While IP-level authentication standards cannot directly close SS7 vulnerabilities, they form a necessary barrier at the interface with modern IP networks.
STIR/SHAKEN standards: cryptographic protection of voice traffic via SIP Identity
The technological core of this protection is based on two related groups of standards:
- STIR (Secure Telephone Identity Revisited): Defined in the IETF RFC 8224 specification. It describes the cryptographic signing of call origin information using the Identity header. This header carries an encrypted JWT token signed with the originating provider's private key.
- SHAKEN (Signature-based Handling of Asserted information using toKENS): Regulates certificate governance processes and the rules for implementing STIR at the telecom infrastructure level in accordance with regulatory requirements (e.g., FCC).
During a call, the operator's authentication server verifies the client's right to use the number, generates an Identity header, and sends the SIP INVITE into transit. The recipient's operator retrieves the corresponding public key and decrypts the signature, verifying the call's origin.
Attestation levels (A, B, C): how operators classify call trust
The SHAKEN standard requires the signing operator to assign one of three Attestation Levels, reflecting the degree of trust in the number:
| Attestation Level | Trust Criterion Description |
|---|---|
| Level A (Full Attestation) | The operator has fully identified the client and confirms their right to use the specific Caller ID number. |
| Level B (Partial Attestation) | The operator has identified the client making the call but cannot confirm their right to use this specific Caller ID (e.g., a corporate PBX). |
| Level C (Gateway Attestation) | The operator only records that the call entered its network from another network (e.g., international transit), without verifying the client or the number. |
Based on these levels, the terminating operator can configure flexible policies: from displaying a "Verified" tag for Class A calls to automatically blocking or labeling "Spam" for suspicious Level C calls.
Architectural implementation challenges: certificates, transit, and legacy network interoperability
Transitioning to cryptographic verification requires overcoming several engineering challenges. The primary one is the loss of metadata during transit. If the call route includes TDM (Time-Division Multiplexing) segments, the Identity header is lost, as older signaling formats do not support the transmission of large text blocks.
Another issue concerns equipment performance. Validating every SIP request in real-time places a significant load on Session Border Controllers (SBCs). This compels operators to optimize computing resources and deploy a comprehensive Public Key Infrastructure (PKI) for the continuous exchange of certificate revocation lists.
Comprehensive voice core protection: integrating authentication with operator platforms
Implementing STIR/SHAKEN is critical, but it does not eliminate all fraud. The technology ensures trust in the number but does not guarantee the integrity of the subscriber themselves (e.g., if a legitimate Level A call center begins aggressive spamming). Therefore, cryptographic verification must work in tandem with intelligent routing and anti-fraud analytics.
For telecom operators, voice core modernization is often realized through solutions from the Intecracy Group ecosystem—an alliance of independent companies linked by partner agreements and share exchanges. Specifically, the DooxSwitch platform for telecom operators provides flexible LCR routing, real-time billing, and SIP traffic control. DooxSwitch allows for the integration of call authentication mechanisms into the call processing route, acting as a bridge between signaling and authentication/verification servers (AS/VS) without the need to fully replace legacy BSS/OSS systems.
Simultaneously, for organizing administrative portals, monitoring security policies, and managing internal processes, the UnityBase platform is utilized, offering features such as RBAC/RLS, audit trails, and rapid API generation. The high performance of the UnityBase server core allows for the deployment of secure enterprise solutions for managing certificate registries and incident logging, ensuring reliable integration at the operator backend level.
Only an architectural approach that combines standardized cryptography, modern VoIP switches, and robust enterprise platforms can systematically counter fraud and restore trust in voice communications.
FAQ
How exactly does STIR/SHAKEN use the SIP Identity header to verify a number?
According to IETF RFC 8224, when a call is initiated, the originating network creates an Identity header in the SIP INVITE message. This header contains a JWT token cryptographically signed with a private key. The recipient's operator retrieves the sender's public key from a trusted repository and decrypts the token to confirm the legitimacy of the Caller ID.
Does STIR/SHAKEN protect against vulnerabilities in SS7 and Diameter signaling protocols?
No, STIR/SHAKEN standards operate exclusively at the SIP/IP signaling level. They do not resolve the architectural issues of legacy SS7 and Diameter protocols, the exploitation of which continues to cause security incidents according to ENISA. However, STIR/SHAKEN forms a line of defense at the point where traffic enters modern IP networks.
What are the technical requirements for operator equipment to support Caller ID authentication?
Operator SBCs (Session Border Controllers) or Softswitches (e.g., DooxSwitch class) must correctly process SIP Identity metadata according to RFC 8224, be capable of interacting with authentication/verification servers (AS/VS) via API, and avoid creating critical latency during real-time cryptographic verification.