How STIR/SHAKEN Works: Technical Deep Dive

Most articles about STIR/SHAKEN explain what it does (“verifies caller ID”) without explaining how it does it. For operators who want to understand why A-level attestation matters at the technical level, why resellers cannot replicate direct carrier attestation, and what actually happens to the SIP INVITE when a call is signed — this is that article.

SIPNEX holds its own STIR/SHAKEN Service Provider certificate (SP-KI) and signs every originating call directly. We implemented the full STIR/SHAKEN stack on our own infrastructure. What follows is the technical reality from the carrier that does the signing.

The framework: STIR and SHAKEN

STIR and SHAKEN are separate but complementary standards that together form the caller ID verification framework mandated by the FCC.

STIR — Secure Telephony Identity Revisited — is a set of IETF standards (primarily RFC 8224, RFC 8225, and RFC 8226) that define how to cryptographically sign and verify the identity of a telephone call’s originator. STIR specifies the data format (PASSporT — Personal Assertion Token), the signing mechanism (JSON Web Signature), and the verification process.

SHAKEN — Signature-based Handling of Asserted information using toKENs — is the implementation framework developed by ATIS (Alliance for Telecommunications Industry Solutions) and the SIP Forum that defines how to deploy STIR on production SIP networks. SHAKEN specifies the certificate management infrastructure (STI-CA, STI-PA, STI-GA), the carrier-to-carrier trust model, and the operational procedures for signing and verifying calls.

Together, STIR provides the cryptographic mechanism and SHAKEN provides the operational infrastructure. When people say “STIR/SHAKEN,” they mean the complete framework.

The certificate chain

STIR/SHAKEN uses a public key infrastructure (PKI) with three levels:

STI-GA (Governance Authority) — the policy body that establishes rules for the framework. In the US, this role is filled by the Secure Telephone Identity Governance Authority, operating under direction from the FCC.

STI-PA (Policy Administrator) — manages the trust framework operationally. The STI-PA maintains the list of approved Certificate Authorities, enforces governance policies, and manages the token repository. In the US, iconectiv serves as the STI-PA.

STI-CA (Certificate Authority) — issues certificates to service providers. The STI-CA verifies that the applicant is a legitimate voice service provider (holds an FCC license or has a filing in the Robocall Mitigation Database) and issues an SP-KI (Service Provider Key Identifier) certificate. This certificate contains the carrier’s public key and is signed by the STI-CA’s root certificate.

SP-KI (Service Provider Key Identifier) — the certificate held by individual carriers (like SIPNEX) that allows them to sign outbound calls. The SP-KI contains the carrier’s public key. The carrier holds the corresponding private key securely and uses it to sign calls. When a terminating carrier receives a signed call, it retrieves the originating carrier’s public key from the certificate to verify the signature.

This chain — STI-GA → STI-PA → STI-CA → SP-KI — establishes a hierarchical trust model. A terminating carrier trusts a signature because it can trace the signing certificate back to a recognized Certificate Authority that is approved by the Policy Administrator under the Governance Authority’s rules.

What happens when a call is signed

Here is the exact technical sequence when SIPNEX signs an outbound call:

Step 1: Call origination. Your PBX sends a SIP INVITE to SIPNEX’s SIP proxy. The INVITE contains the called number in the Request-URI and your outbound caller ID in the From header.

Step 2: Authentication and number verification. SIPNEX’s authentication service verifies your trunk (IP authentication or digest authentication). Our STIR/SHAKEN signing service checks the calling number (From header) against your account’s authorized DID list. If the number is a DID we provisioned to your account or verified through porting, the verification succeeds.

Step 3: Attestation assignment. Based on the verification result:

• Number verified as authorized for your account → A-level (Full Attestation)
• Customer relationship verified but number not in authorized list → B-level (Partial Attestation)
• Call from gateway/upstream source with no direct customer verification → C-level (Gateway Attestation)

Step 4: PASSporT creation. Our signing service constructs a PASSporT (Personal Assertion Token) — a JSON object containing:

• orig — the originating telephone number (your CID) in E.164 format
• dest — the destination telephone number in E.164 format
• iat — the issued-at timestamp (Unix epoch seconds)
• attest — the attestation level (“A”, “B”, or “C”)
• origid — a unique identifier for this call

Step 5: JWT signing. The PASSporT is signed using SIPNEX’s SP-KI private key, producing a JSON Web Signature (JWS). The resulting JWT (JSON Web Token) contains three parts: header (algorithm and certificate URL), payload (the PASSporT), and signature (the cryptographic signature). The header includes an x5u URL pointing to SIPNEX’s public certificate, which the terminating carrier will use for verification.

Step 6: SIP Identity header insertion. The signed JWT is placed in a SIP Identity header and added to the outbound SIP INVITE. The modified INVITE — now containing the Identity header — is forwarded to the next hop in the call path (the terminating carrier or an intermediate transit carrier).

Step 7: Call proceeds. The call routes through the telephone network normally. The Identity header travels with the SIP INVITE through each hop. The cryptographic signature is tamper-evident — any modification to the PASSporT content invalidates the signature.

What happens when a call is verified

At the terminating carrier (the carrier serving the person being called):

Step 1: Identity header extraction. The terminating carrier receives the SIP INVITE and extracts the Identity header containing the JWT.

Step 2: Certificate retrieval. The terminating carrier reads the x5u URL from the JWT header and retrieves the originating carrier’s SP-KI public certificate. The certificate is typically cached for performance.

Step 3: Certificate validation. The terminating carrier verifies that the certificate was issued by a trusted STI-CA, is not expired, and has not been revoked. This traces the certificate back through the trust chain.

Step 4: Signature verification. Using the public key from the certificate, the terminating carrier verifies the JWT signature. If the signature is valid, the PASSporT has not been tampered with and was genuinely signed by the claimed originating carrier.

Step 5: PASSporT validation. The terminating carrier checks the PASSporT contents: is the iat timestamp recent (within the allowed freshness window)? Does the orig number match the From header? Does the dest match the called number?

Step 6: Attestation application. If all verification passes, the terminating carrier applies the attestation level to its call treatment decision. A-level calls may receive a “Verified” badge on the handset. B and C level calls receive neutral or cautious treatment. Failed verification (invalid signature, expired certificate, tampered PASSporT) results in the call being treated as unsigned.

Why this architecture makes reseller A-level attestation unreliable

The technical architecture explains the reseller limitation that impacts answer rates.

The signing carrier’s SP-KI private key is what produces the JWT signature. The signing carrier is making a cryptographic assertion: “I, SIPNEX (identified by this certificate), attest at A-level that this caller is authorized to use this number.”

For this assertion to be meaningful, the signing carrier must have independent knowledge that the caller is authorized for the number. On SIPNEX, this knowledge comes from our DID provisioning database — we assigned the number to the customer, or we verified it through porting. The chain of evidence is direct: carrier assigns number → carrier verifies customer authority → carrier signs at A-level.

When a reseller is involved, the chain breaks. The reseller assigns the number. The upstream carrier signs the call. The upstream carrier did not assign the number — it received an assertion from the reseller that the number belongs to the end customer. The upstream carrier must trust the reseller’s data without independent verification. Most upstream carriers are unwilling to sign at A-level based solely on a reseller’s assertion because the liability for false attestation falls on the signing carrier’s certificate.

This is not a policy limitation — it is a structural consequence of the PKI trust model. The signature is only as trustworthy as the signing entity’s ability to verify the claim. A direct carrier verifies directly. A carrier signing on behalf of a reseller’s customer cannot verify directly.

Frequently asked questions

What is a PASSporT in STIR/SHAKEN?

PASSporT (Personal Assertion Token) is the JSON data structure defined by RFC 8225 that carries the caller identity assertion in STIR/SHAKEN. It contains the originating phone number, the destination phone number, the attestation level (A, B, or C), a timestamp, and a unique call identifier. The PASSporT is cryptographically signed by the originating carrier’s private key and placed in a SIP Identity header attached to the outbound SIP INVITE. The terminating carrier verifies the signature using the originating carrier’s public certificate.

What is an SP-KI certificate?

SP-KI (Service Provider Key Identifier) is the digital certificate issued to voice service providers (carriers) that allows them to sign outbound calls under the STIR/SHAKEN framework. The certificate contains the carrier’s public key and is issued by an approved STI-CA (Certificate Authority) after verifying the carrier’s legitimate status (FCC license, RMD registration). The carrier holds the corresponding private key and uses it to sign PASSporT tokens. SIPNEX holds its own SP-KI certificate — we do not rely on an upstream carrier’s certificate, which is why we can provide direct A-level attestation for our customers’ calls.

Can STIR/SHAKEN be spoofed or bypassed?

The cryptographic signature itself cannot be forged without the signing carrier’s private key, which is securely stored. However, there are limitations: calls that transit through non-SIP segments of the network (TDM/SS7 hops) may lose the Identity header, arriving at the terminating carrier unsigned. Carriers with poor security practices could theoretically have their private keys compromised. And the attestation level is only as trustworthy as the signing carrier’s verification practices — a carrier that signs at A-level without actually verifying number authority is technically compliant but undermining the framework’s trust model. The FCC’s enforcement mechanisms (RMD requirements, traceback cooperation, certification audits) are designed to address these edge cases over time.

Does STIR/SHAKEN add latency to call setup?

The signing process adds minimal latency — typically 10 to 50 milliseconds for the cryptographic signing operation. Certificate retrieval by the terminating carrier adds another 50 to 200 milliseconds on the first lookup, but certificates are cached aggressively, so subsequent calls from the same originating carrier incur no additional lookup delay. The total impact on post-dial delay is generally imperceptible — well under the normal PDD variation that occurs due to routing and network conditions. On SIPNEX, our signing infrastructure is designed for high-throughput, low-latency operation specifically because our customers run predictive dialers where every millisecond of PDD matters.

---

SIPNEX holds its own SP-KI certificate and signs every originating call directly — no intermediate carriers, no inherited attestation, no trust chain gaps. Get A-level attestation from the signing carrier or see our rates.