As defined by IETF and ATIS, the STIR/SHAKEN architecture is detailed in the diagram below.
This diagram looks complex, and it is. It requires a service provider to implement a minimum of 5 new functions into their network, and often a total of 8 (CRc, CVT and CPS functions are not shown in the above minimum model). Achieving compliance with STIR/SHAKEN as mandated by the FCC is a non-trivial undertaking.
Let’s examine the operation of this architecture through the lens of a single call, traveling across the network and hoping to accomplish this feat inside of the STIR/SHAKEN trust network. A number of things must be in place before the call in question can take advantage of STIR/SHAKEN, and we turn our attention to those things first.
Three preconditions must be in place before the call above can transit the network inside the STIR/SHAKEN wall of trust:
- The originating service provider must be approved by the STI-PA (STI Policy Administrator) as a SHAKEN entity.
- The originating service provider must generate a public/private key pair, place the private key in its SKS (Secure Key Store) and place an STI-CA signed certificate containing the paired public key into its STI-CR (STI Certificate Repository).
- The originating service provider must be registered with an STI-CA (STI Certification Authority).
The process of being approved as a SHAKEN entity by the STI-PA is largely manual and involves detailed vetting of the requesting service provider by the STI-PA. This is a one-time event, and once completed (and assuming that the service provider successfully clears the vetting process), the service provider is admitted to the STIR/SHAKEN trust network and provided with a Service Provider Code Token (SPC Token), which represents its’ SHAKEN status and credentials.
Getting registered with an STI-CA is a more direct process, involving only a series of protocol exchanges between the service provider’s SP-KMS (Service Provider Key Management System) and the STI-CA, whereby the SP-KMS presents its’ service provider’s STI-PA credentials and opens an account with the STI-CA. With this account open, the SP-KMS is now authorized to send Certificate Signing Requests (CSRs) to the STI-CA, allowing it to create the fully signed public key certificates needed to authenticate signed calls.
The last of the three pre-conditions is the creation of a public/private key pair, and their storage in the appropriate locations in the STIR/SHAKEN architecture. These keys are used to sign and authenticate calls, and so are of enormous importance. It is critical that no hacker is ever able to reverse engineer them and begin to generate fraudulently signed traffic using the result. With this in mind, NetNumber recommends generating new public/private key pairs on a daily basis. The degree of brute force computing that would be needed to break into a public/private key pair is enormous, but even if this could be accomplished, it would be of very limited benefit if the above recommendation is followed, as the key pair would typically be replaced in no more than 24 hours. As a result, there will be little incentive for fraudsters to turn their ample resources towards breaking into key pairs
Once the SP-KMS creates a new public/private key pair, it places the private key (which the service provider will sign calls with) into its’ SKS. It then engages in a CSR transaction with the STI-CA which results in an STI-CA signed certificate containing the private key’s paired public key. This certificate is placed into the service provider’s STI-CR and this completes the tasks associated with key generation. The service provider is now ready to sign calls.
STIR/SHAKEN Origination Processing
Returning to the call that wishes to traverse the network inside the STIR/SHAKEN wall of trust, the calling party now places that call from their SIP end device and the associated SIP Invite enters the network core, where a session control element (which may be an SBC, a CSCF, a gateway, etc.) recognizes that a new call in need of signature has arrived. It sends a request containing the particulars of that call (the calling number, the called number, the time of the call, the attestation level and the OrigID) to the STIR/SHAKEN STI-AS (Authentication Service) via any one of a number of methods (HTTP interface, SIP Redirect, etc.).
Upon receipt of the request, the STI-AS retrieves its’ private key from its’ SKS and generates a JSON structure called a PASSporT (Persona Assertion Token) which contains all of the call particulars described above and critically, a call signature generated by algorithmically processing all of those particulars using the private key. The principles of this cryptographic processing ensure that the paired public key (available in the service provider’s STI-CR) can be used by the terminating service provider to verify the validity of the received signature. The resulting PASSporT is then Base64 encoded, turning it into single cohesive text “blob” that is easily passed as a SIP header, and that header (called an Identity Header) is then returned by the STI-AS to the requesting session control element in the network.
The call, now attested and signed, is routed onwards to its destination, where the terminating service provider will reverse this process and verify that the call’s signature (and hence its’ Caller ID) is valid.
More on that will follow in the next blog episode on STIR/SHAKEN.
Contact firstname.lastname@example.org for further details.