How SHAKEN Cryptographic Signing Works, Technically

The Certificate Hierarchy

SHAKEN uses a Public Key Infrastructure (PKI) to establish a chain of trust. At the top sits the STI-PA — the Secure Telephone Identity Policy Administrator. In the US, this role is performed by iconectiv under an FCC designation. The STI-PA is responsible for issuing credentials to carriers that have verified their identity and right to sign calls.

Below the STI-PA are STI-CAs — the Secure Telephone Identity Certificate Authorities. These are the organizations that issue signing certificates to individual voice service providers. Every carrier that wants to sign calls must obtain a certificate from an accredited STI-CA, and that certificate must chain back to the STI-PA's root trust anchor.

A carrier that has not completed this certificate enrollment process cannot issue valid STIR/SHAKEN signatures. Any signatures they produce will fail validation at the terminating carrier.

The PASSporT: What Gets Signed

The signing artifact in SHAKEN is called a PASSporT — Personal Assertion Token. It is a JSON Web Token (JWT) structured according to RFC 8225, with specific claims defined by the ATIS-1000074 standard.

The PASSporT carries:

• iat (issued at): a Unix timestamp of when the token was generated
• orig: the originating telephone number (the caller ID being presented)
• dest: the destination telephone number
• attest: the attestation level — "A," "B," or "C"
• origid: a unique identifier for the originating call (used for traceability)

The signing carrier generates this JWT, signs it with their STI-CA-issued private key, and appends the result to the outbound SIP INVITE in the Identity header. The token is encoded as a compact JWT — header.payload.signature — all base64url-encoded.

A real Identity header looks like:

`` Identity: eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwicHBpIjoiMS4wIiwi...;info=<https://cert.example.com/cert.pem>;alg=ES256;ppt=shaken ``

The info parameter points to the certificate used for signing, so the terminating carrier can retrieve it and validate the signature.

The Validation Flow at the Terminating Carrier

When the call arrives at the terminating carrier, their STIR/SHAKEN verification function runs before the call is delivered to the handset. The verification steps are:

1. Extract the Identity header from the SIP INVITE
2. Fetch the signing certificate from the URL in the info parameter
3. Validate the certificate chain back to the STI-PA root
4. Verify the JWT signature using the certificate's public key
5. Check that the iat timestamp is within a freshness window (typically 60 seconds; stale tokens are rejected)
6. Read the attest claim to determine attestation level
7. Feed the attestation level and originating number into the analytics scoring model

If any step fails — certificate fetch failure, signature mismatch, expired timestamp, invalid certificate chain — the call is treated as unvalidated, similar to C-level or unsigned traffic. This is why network latency issues during certificate retrieval can affect signing validation even on properly signed calls.

Why Timestamps Matter: The Freshness Window

The 60-second freshness window on the iat claim is a real operational concern. If there is clock drift between the originating carrier's signing system and the terminating carrier's validation system, or if the call transits multiple intermediate hops with significant delay, the token may arrive outside the freshness window and be treated as invalid.

This issue is rare in direct SIP peering arrangements. It is more common when calls transit through multiple intermediary carriers, particularly when those intermediaries re-generate SIP headers (which can strip or corrupt the Identity header) or add delay through complex routing.

If you are seeing unexpectedly high B-level or C-level validation results on calls you believe should be A-level, timestamp freshness failure is worth investigating through SIP trace analysis.

ES256 Signing and Why It Matters

SHAKEN requires ES256 — ECDSA using the P-256 curve with SHA-256. This is an elliptic curve signature algorithm, chosen for its short signature length (important for SIP header size constraints) and strong security at equivalent key lengths compared to RSA.

The practical implication: every SIP INVITE with STIR/SHAKEN signing carries a small cryptographic payload. At high call volumes, this adds trivial per-call processing overhead on both originating and terminating sides. This is not a real-world performance concern for any call volume a call center would run — it is relevant if you are evaluating provider infrastructure scalability.

Where the Identity Header Gets Stripped

The STIR/SHAKEN Identity header travels through SIP signaling. It is not carried in the RTP media stream. This means it is present in the SIP INVITE but is not regenerated during call transfer or re-INVITE.

The header can be stripped by:

• Intermediate SBCs (Session Border Controllers) configured to sanitize SIP headers
• Protocol translation points where SIP is converted to H.323, MGCP, or TDM
• SIP normalization rules that remove non-standard headers for compatibility reasons
• Carriers that intercept and re-originate calls rather than passing them through

If your outbound calls transit a carrier that performs SIP normalization or re-origination, the Identity header may be stripped before reaching the terminating carrier. This is a common cause of C-level or unsigned delivery despite A-level signing at the origin. UnlimCall's direct network routing avoids intermediate re-origination for US and Canadian traffic, preserving the Identity header end-to-end.