Most of us who work on STIR/SHAKEN today are very focused on getting the basic functionality off the ground. In North America, regulators are urging service providers to implement and deploy STIR/SHAKEN quickly, as the scourge of illegal robocalling continues to infuriate consumers.
But once STIR/SHAKEN as a foundational technology becomes ubiquitous, you can bet it will be leveraged to do more than just defeat robocallers. It is already being incorporated into the analytics used in fraud prevention, and the assurance that STIR/SHAKEN provides will have applicability to a variety of other problems in this space.
So let’s gaze into the crystal ball a bit and look at how incorporating “connected identity” into the STIR/SHAKEN infrastructure could help address a particular type of fraud in the telephone network, enable new calling features, and help restore trust in the calling experience.
Why your call may not reach the desired destination.
The connected identity problem is the inverse of the traditional STIR/SHAKEN problem: instead of trying to figure out if the number calling you has been spoofed, you are trying to figure out if you actually reached the number you were trying to call. There are a number of potential reasons that a call you place might not end up at the destination you expect: ordinary call forwarding is the most common. But there are also some ways that attackers can force calls to divert from their intended destinations.
There have been high-profile cases of hijacking telephone numbers in the mobile space, and Internet call routing sometimes relies on forwarding tables that attackers can attempt to compromise to redirect calls to a chosen destination.
Another area where these worries arise is in certain phishing attacks, where a text message, a web page, or some similar document contains a telephone number that supposedly belongs to some service. Say you get a text message that seems to be coming from your bank, and in it there is a callback number you can click-to-call on your mobile phone to contact customer support. How can you be sure if that number really connects to your bank?
Bi-directional STIR/SHAKEN may help solve the issue.
Connected identity addresses this problem by specifying how STIR/SHAKEN might work in the reverse direction: that is, how the familiar STIR/SHAKEN “PASSporT” object carried in SIP calls could be used to attest the identity of the answering party, not just the calling party.
Thus, if STIR/SHAKEN were used in both directions, both parties would have an assurance that they are connected to who they intended. Or alternatively, if a call doesn’t end up where the caller expected for some legitimate reason, the caller will get an assurance of who they connected to. This might not be something that callers will demand for casual dialing, but when contacting financial institutions, healthcare providers, or government agencies, it could be a very reassuring indication.
Getting this all to work at a protocol levels requires a few new capabilities, but mostly it is a matter of leveraging the same certificates and infrastructure, like authentication and verification services, that will already be deployed for baseline STIR/SHAKEN.
Getting the right user interface.
One of the bigger challenges is getting the user interface right: the ideal user experience of blocking a robocall is that a user never hears the phone ring, or at worst gets a visible indication that a ringing call is probably spam. But how would it work when the user is the one placing the call, and something fishy is going on?
There are a few potential answers to that, but it ultimately depends on the sophistication of the device placing the call. Perhaps the right thing to do when a user places a call from a traditional telephone, and a connected identity check reveals there is a problem, would be to simply not allow the call to connect.
Perhaps an audio message could be played to the user explaining that a security violation had been detected. This would likely best be coupled with some way for the user to signal in advance that a call reaching its intended destination was critical: not something you would do for everyday calls, but for the cases where this is a potential risk of fraud.
Connected identity can include rich call data.
More sophisticated devices, such as smart phones, have richer display capabilities that could show the caller what destination their call has reached—or more interestingly, what destination the call will reach when placed. Smart phones often prompt users in click-to-call scenarios, such as selecting a telephone number from a web page or a text message, to make sure that the user really wants to place the call and didn’t just accidentally touch the wrong part of the screen.
Any device that pauses to let users verify that a number should be called could use those spare milliseconds to perform a media-less probe call, something that would test the route and determine what entity resides on the terminating side. If it reaches a STIR/SHAKEN-compliant destination, it could receive a PASSporT in the backwards direction that conveys more than just an assurance of the reached number, but even richer call data, like brand information, so you can see your bank’s logo before you press the button authorizing the phone to continue a call.
All this may sound like science fiction—and it is, a bit. But connected identity could become a building block in the STIR/SHAKEN infrastructure that will make our trust in the telephone network stronger than ever.
0 Comments