When I was about 4 years old, at the peak of my artistic abilities, I was inspired by my inner Banksy to take a marker and create a large mural on the wall of my parent’s living room. I don’t recall the exact details of the picture, and like many masterworks it was destroyed by powerful overseers who did not appreciate its beauty, but I believe it was somewhat abstract in nature.
Upon completion of my masterpiece, it occurred to my young mind, that my parents may not perhaps be overjoyed to discover my creation, and so I sought to put them off the scent by signing the drawing “Jenny” (my sister).
Sadly, there was a flaw in my plan. My sister was (and is) 2 years younger than me, and was not yet able to write her name. I was quickly identified as the culprit, and the ensuing judgement was swift and well-deserved. Thus ended my career as an art forger.
My childhood attempt at fraud may not have caused much interest in the wider world, but caller ID spoofing is a big problem in today’s telephone network. Ever since the advent of voice-over-IP (VoIP) it has been possible for bad-actors to put a false caller ID on a phone call, and today caller ID spoofing is commonly used for robocalls, for toll-free traffic pumping, and for various phone fraud scams.
In this article we’ll look at the problem and a possible solution, using the analogy of ancient wax seals. Obviously.
Caller ID today: no signatures
In today’s PSTN, if you can get a call into the network with a spoofed caller ID, then you’re home free – there’s no way for anyone to validate the calling number after that point.
This is very similar to today’s postal service. I can buy a Valentine’s card at a store, carefully print “Jennifer Aniston” at the bottom, drop it in a mailbox in Hollywood, and when my friend opens the card, he’ll have no way of knowing it’s not genuine.
Actually let me rephrase that: unless he’s an idiot he’ll likely suspect it’s not genuine, but a genuine card would look identical to the fake card – so he can’t know for sure.
The biggest challenge for my Valentine’s card fraud plan is that I’d have to travel to Hollywood to use a local mailbox to get the right postmark. And in the same way the biggest challenge for a caller ID spoofer is to find a way into the phone network – but since there are so many entry points (from wholesale VoIP providers to business PBXs) it’s not that hard to find a place where the caller ID is not validated on entry to the phone network.
STIR and SHAKEN
Due to the rise in complaints about caller ID spoofing, the FCC has demanded that service providers get their act together and find a solution to this issue. As a result, we have two new SIP standards – STIR (a technology standard for using secure identities) and SHAKEN (which describes how to use STIR to authenticate caller ID).
To understand how these work, let’s look at how the ancient world tried to solve this same problem – using wax seals – and we’ll find that although the technology may have changed, the general ideas are much the same.
Sealed with a… seal
Starting in ancient Mesopotamia, and even today in some parts of the world, people could authenticate their identity by pouring wax on a letter, then stamping it with their official seal.
The idea was that the recipient would be able to validate the sender by looking at the seal, and provided the recipient knew what the original seal looked like this method provided at least a modicum of security.
Of course, any modern security expert can see the potential for flaws in this system – and in fact the Los Alamos National Laboratory (of Manhattan Project fame) published a paper in 2001 identifying 4 methods for spoofing these seals that would have been available in ancient times, and concluded that “ancient stamp and cylinder seals may have been highly vulnerable to spoofing”. However, history does not record any significant incidents of seal-spoofing, so although the potential was there, it was not apparently a big problem.
Caller ID spoofing, however, IS a big problem. So let’s see how STIR/SHAKEN uses and improves on these methods.
Let’s start with the originator of the call / the sender of the letter.
- The originating service provider receives a SIP INVITE from a caller (perhaps a registered SIP line, or through a PBX SIP trunk) – and validates that this subscriber owns the caller ID.
- The originating service provider uses a third-party authentication service (think Verisign for SSL certificates) to create a SIP identity header, attesting to the world that the caller ID on a SIP INVITE is valid.
- This is equivalent to the sender of the ancient letter putting their seal on the letter.
- So far so good – this is largely equivalent to the wax seal, except that the “caller ID seal” was made by a trusted third-party, not by the individual person making the call.
This SIP identity header is then routed through the PSTN to the destination number, and remains in place and unchanged, provided the intermediate providers route the call over SIP at all stages.
Finally, the call arrives at the terminating service provider, who is responsible for validating the seal.
- The terminating service provider receives a SIP INVITE destined for a number it owns, and looks at the SIP identity header.
- The SIP identity header is sent to a third-party validation service that verifies the certificate used by the originating service provider, and inspects the contents of the header (which include the caller ID, destination number, time of the call, and so on).
- If all is well, then the seal is considered to be valid, and the terminating service provider can provide this information to the end user.
- In our ancient world analogy, this is equivalent to the recipient of the letter taking the sealed letter to the person who made the seal, asking them to check that the seal on the letter matches the original mold, verifying that it not only matches the mold but also that the wax used to make the seal was sold on the same day as the letter was sent and that red wax is only used for letters to this particular recipient. Somehow I doubt that happened often.
If all is well, the call is delivered to the called subscriber, along with some kind of indication that the caller ID has been validated.
(Note that I’ve skipped a lot of the technical detail, including the idea that different claims can be made about the caller ID – ranging from “this is my caller ID and I stand by it”, to “I received this off an international trunk so who knows where it came from before that”. You can read more technical detail on the TransNexus website.)
Does STIR/SHAKEN actually work?
There are two ways to answer this…
- If we look at the theory, I could answer “yes, it’s a solution based on well-established principles (c.f. ancient wax seals and SSL certificates) that provides genuine caller ID security”.
- In practice however, I could answer “no, there are a ton of practical issues to overcome before it becomes significantly useful to anyone”.
I’ve hopefully already explained how and why it works in theory, so let’s finish by looking at some of the problems that need to be overcome before this framework becomes genuinely useful.
It requires an entirely SIP call path
You may have noticed that these new SIP headers can only be carried on SIP messages, which means if this call ever passes over a TDM leg of the network they are lost. Given that the RBOCs generally require local ILECs and CLECs to connect to them over TDM trunking, only a small percentage of calls are going to use SIP trunks all the way from the originating to the terminating service provider.
Both the originating and destination service provider need to enable STIR/SHAKEN
If you deploy STIR/SHAKEN in your network that doesn’t do any good unless the service provider on the other end of the call (inbound or outbound) also uses the technology. This is a classic network-effect problem. The technology will initially have almost zero value, and will only become valuable once most service providers use it. There’s therefore little benefit in being an early adopter of STIR/SHAKEN, and obviously people will therefore enable the technology slowly.
Note that the Canadian regulators have mandated that all telcos enable STIR/SHAKEN by March 2019, and while that seems an unrealistic time frame it does at least show how government can help solve the adoption problem through regulation.
What exactly should be communicated to the called party?
The framework doesn’t actually specify how the called party should be notified about the results of the caller ID verification, and this is actually a pretty complex question.
- Initially, most calls will not have this new identity header, and so most calls will be unverified. Should subscribers be told that? Probably not as it will just confuse them.
- If a call has an identity header but it is invalid, then that’s a big warning sign – so perhaps the service provider should just block the call? Or set the caller ID to “Likely Fraud”?
- If there’s a valid identity header how exactly do we communicate that to the subscriber? Do we modify the caller ID? Do we somehow display a check-mark next to the caller ID to mark it as valid? The possibilities here are going to depend hugely on the access-side technology. We have more options on a SIP phone with a color display than a pure POTS landline.
- What if a specific calling number sometimes has a verifiable caller ID and sometimes doesn’t? Does that indicate that the verified calls are valid and the unverified calls are spoofed? Perhaps. If so, how would you communicate that to the called party? Or does it indicate that (due to least-cost routing, or cell phone location) some of these calls were transported entirely over SIP, and others used a mix of SIP and TDM in the PSTN carrier network. So maybe you shouldn’t communicate anything to the user?
Fundamentally, the current situation is very problematic. Initially at least, most calls will be unverified, and only occasionally will a subscriber receive a call that is marked as verified. It’s great that you’ll be able to trust that rare call for sure, but how is a recipient supposed to react to the 99% of calls that are not verified as trustworthy?
Don’t be SHAKEN by this STIR
“It is not the critic who counts; not the man who points out how the strong man stumbles, or where the doer of deeds could have done them better. The credit belongs to the man who is actually in the arena” – Theodore Roosevelt, 1910
As I’ve demonstrated, it’s easy to poke holes in STIR/SHAKEN. However, the truth is, I can’t think of a better alternative.
So while this new set of standards is not a silver bullet for caller ID spoofing, and while it may take many years to become useful, we have to start somewhere.
If the telecoms industry moves forward with this technology, then over time we’ll eventually reach a point where it is widely available. Perhaps this may even be a catalyst to force the RBOCs to offer SIP interconnect rather than SS7 – and eventually, perhaps in 5 or 10 years, most caller IDs will be validated in a way that’s commonplace and simple for people to understand – just as most people understand that a website is secure if there’s a padlock icon in their browser.
It may take a long time for this new technology to bear fruit, but if we do nothing subscribers may just give up on their phones as a result of incessant robocalls and fraud.
If you have a Metaswitch, then they just announced their QCall product that implements STIR/SHAKEN, so talk to your account manager if you’re interested in that.