knowledge-base

Hoe STIR/SHAKEN werkt (en waarom robocalls toch doorkomen)

Een evergreen kennisbankartikel uit de pronk.it-redactie — Hoe STIR/SHAKEN werkt (en waarom robocalls toch doorkomen).

The pronk.it editorial team (AI-assisted, human-reviewed) · · 8 min lezen

TL;DR

Inleiding

Robocalls en ongewenste oproepen blijven een grote bron van overlast voor zowel consumenten als bedrijven. Om het probleem van nummer‑spoofing aan te pakken, hebben regelgevers in de Verenigde Staten en steeds meer landen wereldwijd het STIR/SHAKEN‑raamwerk verplicht gesteld. STIR (Secure Telephone Identity Revisited) definieert de cryptografische mechanismen, terwijl SHAKEN (Signature-based Handling of Asserted information using toKENs) de praktische uitwerking binnen SIP‑netwerken beschrijft.

Het doel van STIR/SHAKEN is niet om alle ongewenste oproepen te blokkeren, maar om het vertrouwen in het bellersnummer te herstellen zodat netwerken en eindgebruikers beleidsmatig kunnen besluiten welke verzoeken ze accepteren, markeren of weigeren. In dit artikel wordt de werking van het raamwerk technisch uitgelegd, worden de stappen in de SIP‑signaling belicht en wordt besproken waarom robocalls ondanks STIR/SHAKEN soms toch door kunnen komen.

Wat is STIR/SHAKEN?

STIR/SHAKEN is een reeks standaarden die een vertrouwensketen creëren tussen de oproepende partij, de verzorgende provider en de ontvangende partij. De kern van het systeem is een ondertekend token, het zogenoemde PASSporT, dat wordt meegestuurd in de SIP‑Identity‑header. Dit token bevat informatie over het bellersnummer, het attestatieniveau en een cryptografische handtekening die kan worden geverifieerd met behulp van publieke sleutels die worden gepubliceerd via een certificaat‑autoriteit (CA) of een openbaar sleutel‑repository.

De werking kan worden samengevat in drie stappen:

  1. Attestatie – de oproepende provider plaatst een PASSporT‑token in de uitgaande SIP‑request, waarbij het attestatieniveau wordt bepaald op basis van de relatie met de bellende partij.
  2. Transport – het token reist mee met het SIP‑verzoek via tussenliggende proxies en eventuele SBC’s zonder wijziging.
  3. Verificatie – de ontvangende provider haalt het token uit de Identity‑header, controleert de handtekening tegen de gepubliceerde sleutel van de attesterende partij en neemt een besluit op basis van het attestatieniveau en lokaal beleid.

Omdat de technologie puur cryptografisch is, vereist hij geen wijziging van de bestaande SIP‑structuur, maar voegt hij alleen een extra header toe. Dit maakt geleidelijke uitrol mogelijk zonder bestaande infrastructuur buiten werking te stellen.

Attestatieniveaus en het PASSporT‑token

STIR definieert drie niveaus van attestatie die aangeven hoe zeker de attesterende partij is over de authenticiteit van het bellersnummer:

Niveau Beschrijving Wanneer gebruikt
A (full) De provider heeft een directe relatie met de klant en kan met zekerheid stellen dat het nummer toegekend is aan die klant. Bij eigen klanten, eigen nummer‑range.
B (partial) De provider kent de klant maar kan niet met zekerheid zeggen dat het nummer aan die klant is toegewezen (bijv. nummer‑porting in uitvoering). Bij resellers of wanneer nummer‑informatie uit een externe database komt.
C (gateway) De provider kan alleen bevestigen dat het nummer afkomstig is van zijn netwerk, maar heeft geen relatie tot de eindgebruiker. Bij internationale oproepen of wanneer het verkeer via een gateway binnenkomt.

Het PASSporT‑token is een JSON‑Web‑Token (JWT) dat wordt base64‑url‑gecodeerd en bestaat uit drie delen: header, payload en signature. Een voorbeeld van een minimal PASSporT voor een full attestatie (A) ziet er als volgt uit:

Header:
{"alg":"ES256","typ":"passport"}

Payload:
{
  "typ": "shaken-pass",
  "iat": 1690843200,
  "exp": 1690846800,
  "dest": {"tn": "+12125551234"},
  "orig": {"tn": "+12125550000", "attest": "A", "origId": "xxxxxxxxxx"},
  "destCallingPartyNumber": "+12125551234",
  "origCallingPartyNumber": "+12125550000",
  "origId": "xxxxxxxxxx"
}

Signature:
[Base64URL-encoded ECDSA‑signature over header.payload]

De header geeft aan welke asymmetrische algoritme wordt gebruikt (doorgaans ES256, een ECDSA‑signature over SHA‑256). De payload bevat onder andere:

De signature wordt gegenereerd met de privésleutel van de attesterende partij. Ontvangende partijen kunnen de publieke sleutel opvragen via een bekend URI (bijv. https://<domain>/shaken/<origId>.json) waarin het certificaat en de bijbehorende publieke sleutel staat.

SIP‑integratie en verificatieproces

In een SIP‑flow wordt de Identity‑header toegevoegd aan het OUTGOING INVITE (of elk ander verzoek dat een bellersnummer transporteert). Een voorbeeld van een SIP‑request met een Identity‑header:

INVITE sip:+12125551234@atlanta.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: <sip:+12125551234@atlanta.com>
From: <sip:+12125550000@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:bob@pc33.atlanta.com>
Identity: <https://atlanta.com/shaken/xxxxxxxxxx.json>;alg=ES256;signature=MEUCIQD...
Content-Length: 0

De Identity‑header bevat drie onderdelen:

Bij ontvangst voert de verifierende partij de volgende stappen uit:

  1. Header ophalen – lees de Identity‑header en extraheer de URL, algoritme en signature.
  2. Certificaat ophalen – download het JSON‑document vanaf de opgegeven URL; dit document bevat het X.509‑certificaat van de attesterende partij (vaak in JWK‑formaat).
  3. Handtekening verifiëren – gebruik de publieke sleutel uit het certificaat om de ECDSA‑signature over de concatenatie van header en payload (in base64‑url) te controleren.
  4. Payload valideren – controleer of de typ gelijk is aan shaken-pass, of de exp nog niet verstreken is, of de orig.tn overeenkomt met het From‑nummer (of met een toegestane afgezette lijst), en of het attestatieniveau voldoet aan lokaal beleid (bijv. alleen A‑attestatie toestaan voor directe oproepen).
  5. Beslissing nemen – op basis van het resultaat kan de provider het verzoek doorlaten, een privacy: id toevoegen, een warning header invoegen of het verzoek afwijzen met een 4xx‑respone (bijv. 403 Forbidden).

Het verificatieproces gebeurt meestal in een SIP‑proxy of SBC voordat het verzoek naar de eindgebruiker wordt doorgestuurd. Omdat de handtekeningcontrole relatief lichtgewicht is (een ECDSA‑verify), kan dit in realtime worden uitgevoerd zonder significante vertraging.

Beperkingen en waarom robocalls toch doorkomen

Hoewel STIR/SHAKEN een krachtig mechanisme biedt voor het verifiëren van het bellersnummer binnen een vertrouwde keten, zijn er verschillende redenen waarom ongewenste oproepen soms toch het netwerk binnen kunnen komen:

  1. Internationale oproepen en ongelijke adoptie
    STIR/SHAKEN is verplicht in veel landen, maar niet wereldwijd. Een oproep die buiten het bereik van een STIR/SHAKEN‑gebied begint (bijv. vanuit een land zonder verplichte implementatie) kan geen geldig PASSporT‑token meekrijgen. De ontvangende partij ziet dan geen Identity‑header of een ongeldige token en kan, afhankelijk van lokaal beleid, het verzoek toch doorlaten.

  2. Legacy‑ en niet‑SIP netwerken
    Oudere TDM‑circuit‑switched netwerken, ISDN‑PRIs of sommige mobiele netwerken transporteren oproepen zonder SIP‑signaling. Deze netwerken hebben geen mogelijkheid om een Identity‑header toe te voegen of te verifiëren. Wanneer zo’n oproep later wordt omgezet naar SIP (bijv. via een media‑gateway), ontbreekt het token tenzij de gateway zelf attestatie uitvoert, wat niet altijd het geval is.

  3. Foutieve of zwakke implementatie
    Sommige providers plaatsen een Identity‑header maar gebruiken een ongeldige of verlopen sleutel, of ze stellen het attestatieniveau te laag (bijv. altijd C) om kosten te besparen. Een verifierende partij die strikt op volledige attestatie A eist, kan deze oproepen blokkeren, maar als het beleid permissief is (bijv. elke geldige token wordt geaccepteerd) kan een ongeldig of matig attestatie‑token nog steeds worden geaccepteerd.

  4. Numero‑spoofing buiten de attestatieketen
    Een kwaadwillende kan een geldig nummer gebruiken dat wel tot zijn eigen bereik behoort (bijv. een geleasd nummer) en toch een ongewenste oproep plegen. Omdat het nummer rechtmatig aan de partij is toegewezen, zal attestatie A mogelijk zijn en de oproep wordt als “geverifieerd” gezien, ondanks de kwaadwillende inhoud. STIR/SHAKEN lost dus niet de inhoud van de oproep op, maar alleen de authenticiteit van het nummer.

  5. Ontbrekende of vertraagde publicatie van sleutels
    Het verificatieproces is afhankelijk van de beschikbaarheid van het publieke certificaat van de attesterende partij. Als de URI ontoegankelijk is (vanwege DNS‑problemen, firewall‑regels of een tijdelijke storing) kan de verifierende partij het token niet valideren. Afhankelijk van lokale fail‑open‑of‑fail‑closed beleid kan het verzoek toch worden doorgelaten.

  6. Replay‑aanvallen en beperkte nonce‑gebruik
    Het PASSporT‑token bevat een iat en exp veld, maar geen unieke nonce per oproep. Een aanvaller die een geldig token interceptieert kan dit binnen de geldigheidsduur opnieuw gebruiken voor een andere oproep met hetzelfde orig.tn en dest.tn. Sommige implementaties beperken de hergebruik van een token door een cached‑check op (origId, iat) uit te voeren, maar dit is niet verplicht in de specificatie.

Deze factoren laten zien dat STIR/SHAKEN een belangrijke stap is richting meer vertrouwde signaling, maar dat het geen volledig plug‑and‑play oplossing is voor alle vormen van ongewenste oproepen. Een effectieve strategie combineert STIR/SHAKEN met aanvullende maatregelen zoals:

Praktische checklist

Verder lezen

Met deze kennis kunnen VoIP‑ingenieurs, PBX‑beheerders en technische besluitvormers een weloverwogen beslissing nemen over de implementatie van STIR/SHAKEN, de bijbehorende beleidsregels en de aanvullende maatregelen die nodig zijn om de impact van robocalls verder te verminderen.