Implementing STIR/SHAKEN

Robocalls and caller ID spoofing have eroded trust in the phone network for years. If you've ever ignored a call from an unknown number, you've felt the problem firsthand. STIR/SHAKEN is the industry's answer — a framework that lets carriers cryptographically sign caller ID information so the receiving side can verify a call really originated from who it claims to.

I recently worked through implementing STIR/SHAKEN support, and I wanted to share a few notes on what the work actually involves.

What STIR/SHAKEN does, briefly. When a call is placed, the originating provider attests to the caller's identity and signs a token — a PASSporT — that travels with the call inside a SIP Identity header. The terminating provider pulls that token, fetches the originating provider's certificate, and verifies the signature. If everything checks out, the called party can be shown that the caller ID is trustworthy. The signing uses standard public-key cryptography, and the certificates chain back to an approved authority, so a spoofer can't simply forge a valid token.

Signing the call (the originating side). Here you build the PASSporT from the call's identity information, sign it with your private key, and attach the resulting Identity header to the outbound INVITE. You also include a reference to the certificate that can be used to verify the signature, along with an attestation level indicating how confident the provider is in the caller's right to use that number.

Verifying the call (the terminating side). This is where most of the interesting work lives. You parse the incoming Identity header, retrieve and validate the signing certificate, confirm it chains to a trusted root, and then verify the signature over the token. Beyond the cryptography, there are plenty of real-world details to get right: handling expired tokens, mismatched caller ID, retrieving certificates over HTTP without letting a slow or unreachable server stall your call processing, and producing a sensible verification result when something doesn't line up.

Handling forwarded calls (diversion). Calls get forwarded, and that breaks the simple model: once a call is retargeted, the original caller ID no longer matches the number it's being delivered to, so a naive verifier would reject a perfectly legitimate call. The answer is the diversion ("div") PASSporT — each redirection adds a signed token recording where the call was sent next, building a verifiable chain from the original destination through every forward. Getting the chain checks right is genuinely tricky: each link has to be validated and tied to the one before it, the tokens have to line up in the correct order, and the whole chain has to reconcile with what actually arrived. It's worth the effort, though — most implementations don't support diversion yet, so handling it correctly is a real differentiator and means forwarded calls keep their verified status instead of silently failing.

Done well, STIR/SHAKEN support is mostly invisible — calls flow as they always did, but now they carry a verifiable claim about who's really calling. And that, slowly, is how we start trusting the phone again.