![]() ![]() It implements the SIP side of things and does not care about certificate storage or signing and is effectively stateless. The res_pjsip_stir_shaken module acts as the boundary between SIP and the core of STIR/SHAKEN. In the dialplan the STIR/SHAKEN identities can then be iterated or examine and based on that the user can choose what to do. The certificate authority information is also configured here. This is configured in the "general" section. This module will support reload so if things change on disk or in configuration, it can be reloaded by using a reload command.Īs STIR/SHAKEN requires retrieving and using a public key it is advantageous to keep a cache of public keys to minimize call handling time. If we truly feel we need realtime in some way we could use sorcery but it doesn't seem reasonable to allow what most people would consider realtime (looking up at use time). Due to the amount of state required it is implemented using ACO. It is architected as such: ConfigurationĬonfiguration is done using a stir_nf configuration file. It's generic in the sense that protocol specific users need to be written to actually use the information. The res_stir_shaken module is responsible for certificate management, signing, verification, and information exposure. If you're actually planning to work on this here's some handy links! Receiving a call without the information has to become abnormal or non-existent so that you don't have to let calls through regardless. To be effective, though, everyone has to buy into this system and use it. It's then up to local policy as to what to do with the information. Once this is done the receiver can then examine the call to see if the data matches (your call said you are X, your payload said you are X). The receiver can then look at this payload and signature and use your public key (after retrieving it from the URL provided with the payload) to verify that it is you who made the payload - thus giving trust that you have permission. When you go to use a phone number for callerid you construct a payload that conveys what you're doing (I am X calling Y on this date at this time) and sign it using your private key. As the name says the private one only you have while the public one is handed out and made available. This certificate is comprised of a private and public key. It is based around a phone number (or a block of numbers) having a certificate that conveys that you have permission to use it. ![]() The design is broken down into two modules:īefore we dive into things how about a bit of a TLDR on STIR/SHAKEN? From a purely technical perspective STIR/SHAKEN is actually fairly simple. It is also flexible in that we could add different ways to manage certificates since that may be an unknown at this point. Welcome to a page about making callerid non-fictional in an effort to stop robocallers! Will it actually work out in the end? Who knows, but hey have a design for implementing such a thing in Asterisk! This design was done in such a way as to allow drop-in to all currently supported versions of Asterisk that use PJSIP. It's one thing to say "oh you use private key to sign some stuff" but who issues such things? Who actually does the work of signing and verifying? Are the certificates short lived ephemeral ones? Do you have to use a proprietary API to some upstream to manage things? There's still lots to flesh out there by the industry and governments. The problematic area is really the foundational aspects and policy side of things. STIR/Shaken from a technical perspective has improved quite a lot, so much so that some companies have been able to do interop and it does work.
0 Comments
Leave a Reply. |