STIR/SHAKEN with Paul Grubbs and Josh Brown

Josh Brown and Paul Grubbs join us to describe how those damned spam calls work, and how STIR/SHAKEN is supposed to try to stop them, but have other privacy and security implications as well. 

Transcript: https://securitycryptographywhatever.com/2024/04/30/stir-shaken/

Links: 
- https://iacr.org/submit/files/slides/2024/rwc/rwc2024/98/slides.pdf
- https://www.youtube.com/watch?v=3trxXF0-fRU
- Paul Grubbs: https://web.eecs.umich.edu/~paulgrub/

"Security Cryptography Whatever" is hosted by Deirdre Connolly (@durumcrustulum), Thomas Ptacek (@tqbf), and David Adrian (@davidcadrian)

Chapters

• 0:12 Combatting Robocall Scams With Stir-Shaken
• 6:10 Telephone Network Protocols and Security
• 20:48 Phone Call Authentication and Deniability
• 31:38 Protocol Issues in Telephone Networks
• 38:26 Telecom Privacy Risks in Metadata Sharing
• 48:41 Challenges and Solutions in PKI
• 53:01 Certificate Transparency and Security Improvements

Transcript

David: 0:12

Hello. Welcome to security cryptography. Whatever. I'm David, and I'm out of order.

Deirdre: 0:18

I'm Deirdre.

Thomas: 0:20

I'm Thomas. I think I'm Thomas.

David: 0:23

And today we have Paul Grubbs and Josh Brown here to talk about stir shaken and robocall scams. And so with that off, I say, let's talk about phones. What's the problem with phones?

Josh: 0:37

Well, where to begin? Right. Yeah. So our topic is about robocalls and scams. You've probably received a call or two, you know, maybe from supposedly Microsoft technical support or the IR's or, I don't know, somebody else who's trying, seeking some information. And many people experience this on a daily basis, and it gets really annoying. It just interrupts your day. And so there's been a large recent effort by the United States government to try to combat that. And one of the ways that they have tried to combat it is by passing legislation that requires this new protocol. And that's kind of that protocol called stir shaken is what we looked at, too.

David: 1:25

So the base problem is you get a phone call that looks like it's from the state police of Michigan, which is a thing that has happened to me, or it looks like it's from the IR's, and then they try and get you to do something, or they say that they're revoking your PhD, which, again, is a thing that has happened to me, and they attempt to do some sort of scam. So we're talking about spoofed phone calls being used for scams.

Josh: 1:50

Yep. One of the things that frequently happens to me is they'll use your area code. It kind of looks like it's somebody you may actually know, which you're more likely to answer. So that's another type of spoofing thing that I've seen.

Thomas: 2:06

So the idea here is there's been, I don't know, ten, whatever years of these spoofed call scams. And they're annoying. Um, the, like, the basic underlying phone network is spoofable. And then there's a law passed and a bunch of protocols designed to try to defeat spoofing. And you guys looked at it, which is ominous, because we wouldn't talk about this unless you had found something. So I guess my first question is, why did you look at this?

Josh: 2:35

Good question. So I had seen Star shaken, which is. Which is this protocol a few years back, because I was, you know, I kept on getting spam calls, and I was like, you know, could we figure this out? And when I looked into what was going on at the time. I saw that stir shaken was being discussed. It hadn't been mandated yet, but it was being discussed. And so once I got to school, I spoke with Professor Grubbs, and we, we decided that this would be a really good research project and to look into the various different privacy concerns and security concerns we found with this protocol and the ecosystem.

Deirdre: 3:19

I have a question. Who designed this? Where did stir shaking come from?

Josh: 3:23

Sure. So stir shaking, it's kind of a bit of a weird story. So there is two main organizations that worked on the specs for this. One is the IETF. While the IETF designs some general standards, how it's actually going to be deployed, and I guess the spec for actually deploying it in the telephone ecosystem specifically. So some of these are broader protocols just for communication, but specifically for the telephone ecosystem, that is an organization called ADIS.

Deirdre: 4:00

Hate is.

Paul: 4:00

Okay, well, I was just gonna say related to who designed this. I mean, I think it's really interesting. Like, I spoke to someone who's involved in this ecosystem, and he sort of apropos of nothing made what I think is a very telling statement about the sort of cultural divide between the IETF and the telephony standards people. And so what he said is something along the lines of, yeah, the ITF, they sort of design all this stuff on paper. And then we over here at Aidas have to figure out how it's going to work in the real world. So there's sort of like, this person almost considers the IETF to be like a theory organization, and then the Aidas is like the practical people that actually deploy things. So I think, like, even going down to the fact that the name of this protocol suite is stir slash shaken, stir is actually what the IETF working group is called. And then shaken is the version of the stir, uh, specifications that ADAs has taken and used in the telephony ecosystem. So right. Right away, we sort of have, like a split brain. Like, no single organization is sort of thinking about all these things, which I think maybe is the source of some of the, like, kind of awkwardness in the. In the design and implementation.

David: 5:15

Okay, so before we get more into stir shaken, let's back up and just say, how does spoofing work? Like, without stir shaken, how do I spoof calls? If I want to call Thomas as from Paul's phone number, what would I do?

Josh: 5:29

Sure. So there is a protocol called SIP, which is the protocol used for setting up calls. And there's a specific field. It's just a text based protocol and so you could just spoof this field, and this field indicates where the call is coming from. And so that caller id field that you see when you're answering the phone call or when it's ringing, that is just a text field that is basically transmitted through the telephone network. And so it's very easily spoofable. There's no type of authentication or anything going on to ensure the accuracy of that caller id.

David: 6:10

So what network is this message being sent on? You have a text based protocol as a from field that you can just set because it's text. If you're deciding that you don't want to comply with the protocol, but presumably you have to somehow connect to something and send that message somewhere, what are you using to send that message? And what network is this?

Josh: 6:29

I guess we call that network the publicly switched telephone network. It's composed of a lot of different carriers and there's two main set of protocols that are used for this communication. One is the legacy TDM based protocols, and then there's the newer set of Internet based protocols that we call VoIP or voice over IP. Many calls, when traversing the network go over both legacy TDM nodes and VoIP based nodes. That's the network that is being used. And again, this is referred to as the PSTN or publicly switched telephone network.

Deirdre: 7:11

That's interesting. How do you decide which one to pick? Is it just literally you provide both to the end device going through all these networks that you would like to connect to and it picks one.

Josh: 7:21

So it's kind of like a routing like protocol. So you're trying to figure out the providers are going to choose what is the most optimal path or most efficient path in terms of cost and in terms of many other factors. And that may mean, especially if you're in a very rural area, that may require going over some of this legacy telephone network, but other calls may stay entirely on, on the Internet through VoIP based protocols.

Thomas: 7:55

I have like a. I have like this conception of spoofing calls as being a thing that you use VoIP providers for, and I have them. I had this idea that like a VoIP provider is like, I don't know, like some tiny company running asterisks on a couple of boxes in their closet that somehow has a connection to a phone company. And I don't know what that connection is. And I also don't know if that mental model is right, but I do have this picture now of, okay, so we're spoofing calls. There is a phone network like a phone system. And that phone system is bifurcated into like the modern phone system, which is all sip, which like, literally you can run asterisks to run sip, right. And then ss seven and the packets, whatever the PSTN, the public, whatever, blah, blah, blah, TVM phone number. Right? So I guess like one big question I have just as like a, you know, a vulnerability person who can like think about talking to, um, you know, VoIP systems or systems on the Internet as real targets. Um, but not ss seven is like when I'm making a call on at and t. Am I like, am I probably like doing a VoIp thing? Like, do you guys have a sense of what the topology of this network is, how much of it is ss seven and how much of it is sip? And also, um, if you have that sense, how the hell did you get it? Like, it's. Is this information? How public is this information? How easy is it to look up?

Josh: 9:10

Yeah, two really, really good questions. I do want to note that depending on the context in which people are talking about this network, some people reserve the phrase PSTN to only refer to this legacy network, but at least how I introduced it and how we discussed it in the presentation, we're talking about more broadly about the entire PSTN, which includes both the legacy and the newer VoIP network. Now, to answer your question and kind of how we acquire that knowledge, that was a really, really big challenge for this research project. So with something like the Internet, it's really visible. You can set up Wireshark or something like that to just intercept traffic and take a look at what's going on with the telephone network. It's not really that visible. And also the protocols are very, very old. There's a lot of different ones, many of which aren't compatible learning about this network. And also there's a large divide on how things are specified in various different documentation online and how it's actually deployed in the ecosystem. This was a really big challenge. One of the ways that we navigated that was one reading the documentation, but also speaking with industry professionals, people who work in the industry, people who operate telecoms and have specialized knowledge in this ecosystem to kind of understand how things are deployed and how things work.

Deirdre: 10:40

Yeah.

Thomas: 10:41

Do they have like a discourse that you can join?

Deirdre: 10:44

Discord?

Josh: 10:46

You could probably get their email after the podcast. I'm happy to provide that.

Paul: 10:53

I doubt telephony uses discord. That seems like a little bit advanced, but I'll just add to what Josh said that my sense and I don't know if there are measurements of this, but my sense is that increasingly calls are routed completely over Sip, but many calls probably do have a legacy telephone pop in their routing. And so I think legacy telephone protocols like SS seven are not as common. But my sense is that they, like, in terms of like, the path that calls actually take to be routed, a large fraction of calls are routed through legacy telephone networks. So, like, if there's like, you know, five hops in the routing, then one of those hops for many calls might be an SS seven hop.

Josh: 11:41

And one of the things that was stressed to us by people in the industry is that it's essential that anybody can call anybody. And so if there's even a very small amount, and there is, I agree with Paul, there's probably a decreasing amount of calls, they're actually going over this legacy telephone network. But even if there's a very small portion of those calls, people still need to be able to access those phone numbers or call those people that are only accessible on the legacy telephone network. So it has been stressed to us that when considering solutions, we need to consider the legacy telephone network.

Deirdre: 12:17

Okay, so how does stir slash shaken work to mitigate these spoofing attacks? How does it work?

Josh: 12:25

Sure. So the stir shaken system, the basic idea here is that you're going to have an originating telephone provider and they are going to sign call metadata, which includes the caller and callee. And by signing it, they're testing to the identity of the caller. And when the destination provider receives this signature, they can then verify that signature. What this allows them to do is if they detect a fraudulent call or the end user, the recipient of the call reports that call to the destination provider. The destination provider can then report the originating provider to some type of governance authority and the government can punish those providers that are providing attestation to fraudulent callers.

Deirdre: 13:19

My first question is, what prevents stripping off the signature on that metadata? If the number one priority is make call, go make call, connect, how do I prevent the signing from the origin provider from being stripped off so that the destination provider doesn't even know that there's something missing that should have been verified?

Josh: 13:41

So as it exists today, that is a common problem. Not as much as is in the malicious sense, but just, oops. Yeah, kind of like that, you know, some type of incompatibility with, you know, especially when going over the legacy telephone network, this, this tends to be an issue. And sometimes stir shaken signatures, what we call passports, are stripped. So that is an issue. Eventually. The idea, from my understanding, is to move to. And right now, by the way, if a call is received that doesn't have, um, that doesn't use stir shaken, it's not going to be immediately dropped. But the eventual idea with this system is that every call will use surshaken. And if your call does not have attestation, then maybe it will be put through, but it will likely be indicated as very likely spam. And most users maybe even have a default or something like that to decline those types of calls. There's going to be a situation where if you want your call to get through, eventually, it's going to have to have this type of attestation.

Thomas: 14:51

So that's why when I get a phone call and it says like probably spam or whatever, that's either a broken stir shaken signature or it's a lack of a stir shaken signature.

Josh: 15:00

Most likely those are a few of the stronger factors, but many providers also have proprietary lists and different things. So there are a combination of factors that can lead to the call being displayed as likely spam on your phone. But certainly stir shaken is one of the large factors in that decision.

Thomas: 15:24

Okay. And this is like an extension on top of sip is what I'm hearing. Like this is like a header or whatever?

Josh: 15:29

Yes, this is a header within Sip. Yeah.

Paul: 15:31

And it's, I mean, it's worth like emphasizing to Deirdre's point that just because sip and SS seven are not interoperable protocols, when a call with a stir shaken passport enters the SS seven part of the network, its passport cannot be retained. Right. There is no place in the SS seven protocol to put the passport, which maybe jumping ahead a little bit, leads to the necessity of a system called out of bandster shaken, which we'll probably discuss later in the podcast.

David: 16:00

So just to clarify something you said earlier, so this isn't an identity system for callers. We have a PKI, but it's not like every phone number has its own signature. Basically telecom saying, I swear I sent this call over my network. And so it's a way to tattletail like an attestation that something happened. It's more of like a public bulletin board than it is an identity system.

Josh: 16:26

It's an identity system. Yeah. The PKI exists for providers, not for individual callers. Now in theory that could change in the future, but the intent for surshaking, at least right now, is for it to be a provider system.

Deirdre: 16:41

And that makes sense because the way that phone numbers live in a place by their owner, their provider. And so that's why? When you're making a call, especially the old days, if you're roaming and you're on european networks, but your american phone number lives back home, part of the reason that it takes so long to make that old style connection is you have to go back across the Atlantic to sort of like do a little handshake with your home base, and then you can, like, make the call connect from Europe, but via your actual phone number and all this extra crap. So it makes sense that you're not going to deploy keys and stuff to every single phone in the world because they don't know how to do that. But you can, you have to trust your, like, home based provider of where your phone number lives to route your calls, period. So having them basically be like, no, I am me. You know, my root key or whatever it is, all the interoperable stir shaken providers know each other's root keys and signing keys, sorry, verifying keys. And then you can just be like, you're on t mobile or you're on at and T and the at and t key signed this. And I trust at and T to not give me spoofed calls or something like that.

Josh: 18:01

Yeah.

Paul: 18:02

It can be surprisingly complicated to figure out the public key for a provider. There are these interesting, especially in VoIP, because of the way that larger providers delegate control of phone numbers to smaller providers. It's not always clear who is actually the cognizant provider for a given phone number or because of the way that the stir, shake and PKI works. It's also not always clear you can't necessarily map provider name to a public key.

Deirdre: 18:36

That sucks.

Josh: 18:37

Yeah. It's also not necessarily who owns the actual phone number. So, yeah, there's a lot of different parties involved. And as Paul said, it's not easy to figure out what the route of the call is, who the destination provider is, what their key is, or anything like that in advance. And the actual passport, the header that's included in the SIP message, it includes a URL, and that's how we actually get the certificate to verify the passport. But you don't know that in advance.

Deirdre: 19:13

This cert example.org passport pem sort of thing?

Josh: 19:17

Yeah, there you go.

Deirdre: 19:18

Just for fun. JWT is never gonna die. We've got JWT all over this thing.

Josh: 19:25

I guess not. I guess not. I mean, I recall when I first, when Paul and I were first discussing this, and we looked into it and we saw that they were using JWT. I remember Paul and I being like, oh, wow, that was a decision as.

Deirdre: 19:39

Long as you, well, as long as you lock down everything, maybe you can do it. But, okay, so say we deploy stir shaken. Well, we do everything, right. It seemed like there were privacy implications that made you kind of talk about like, this may be a anti spam solution, but it might be a privacy violation when deploying that out. Can you talk about that sort of thing?

Josh: 20:05

Sure. So yeah, we found a few different issues relating to privacy. The first one that we discussed was a deniability problem. And this basically means that because the passport, which is that signature over the metadata, is sent in the clear from the originating provider to the destination provider, all of those intermediary providers have access to it and they can, with possession of the signature, they can prove with cryptographic evidence that a call was placed. And so this creates this kind of deniability problem. It's very similar to the problem with DKIM and email. If your listeners are familiar with that DKIM, the details aren't as important. But DKIM was a system used for emails that similarly tried to reduce fraud and spoofing of emails. And DKIM has been used similarly. Email providers would sign email metadata as well as email contents. And this created a deniability problem for the email system.

Deirdre: 21:18

So my first response to that would basically be, well, we're going from no reliability or authentication on who is making the call or at least what root provider is making this call on behalf of their subscriber. And all of those were in the clear, right? About, I'm claiming that I'm calling you from 123-45-6789 or whatever that was in the clear, right?

Josh: 21:47

Yes. That metadata is still in the clear even after any solution that we implement, the routing information in terms of what phone number is being called and that information that's included in other SIP headers would still be in the plan. Yeah, that's true. In the clear.

Thomas: 22:09

Okay, so I have a question here just about the deniability thing, right. So I think maybe me and David could go back and forth on deniability, but in the email context, it's most famously a problem in email because of hunter Biden emails or whatever that were authenticated with DKim or whatever. Right. Um, so the problem with email and deniability is that people have email spools even now, even today, people have long term records of all the emails they've gotten. And each of those emails you can hit show headers and get the DKim thing right where on my phone, I have no such record. Um, like, there's no like I don't, I can't do a show headers on a call and see what the, uh, by the way, do you. I had to step away because my dogs were doing something silly. Um, and I was sort of listening. Did I hear you guys say that this protocol uses jwts?

Deirdre: 22:56

Yes, it does. ECDsa 56.

Thomas: 23:02

We may come back to this. Anyway, there's also a phone call spool. Right? So who's logging this? Like, where is that? Where is that going?

Josh: 23:12

Yeah. Okay, so good question. So you're correct that, you know, on your basic telephone, you, you can't access all of these headers, but we actually conducted a survey and we spoke with a bunch of different telecoms and we learned that they do indeed log and store a lot of this information after the duration of the call. And this at many times can be for weeks or even months after the call is concluded. And furthermore, again, all of the providers, which on the PSTN is many different providers, between the originating provider and the destination provider, they all have access to the passport as well.

Paul: 23:53

If I could, Josh, if I could jump in another kind of confounding factor. I mean, Thomas, your observation is correct, but you have to recall that the purpose of stir Shaikin is to create a reporting pipeline. And so one of the maybe implicit consequences of stir shaikin seems that if you're doing reporting, you're going to need to log the signed passports just to facilitate reporting spam calls that you receive. So there may not have been a need to log before, but especially if you're going to be collecting data for several weeks about calls that you receive and then reporting them all in one batch, it seems like being able to report really relies on making a log of these signed passports, whereas maybe it would never require this logging before.

Thomas: 24:39

And this is a bit I remember from the talk at real world crypto. Right. But like, there's in a sense a bigger problem here, right. Which is like this idea of keeping a record of the things you can report back later or whatever the things that they're logging are, every phone call.

Deirdre: 24:58

Aren't they already doing that, though? And now they just have a signature from it from origin provider that gets eventually verified by a destination provider.

Thomas: 25:08

Would that have been the case normally in the PSTN and doing multi hop stuff? Does this create an additional log of every phone number or whatever? Or is really the key observation here that because we're doing this non deniable spoofing protection thing, not only do we have a log, but we also have proof that somebody didn't, like, add things to the log that are bogus?

Josh: 25:26

I think so, yeah. It's much more the latter previous, like, even without stir shaking, things are being logged for various different reasons, for business purposes, also maintains for law enforcement purposes. So this is not unusual. But as Paul said, using surfshaken almost requires you to, in many ways store these passports, because you might want to report a call that occurred a few days ago or a few weeks ago. The use of stir shaken. We went from a situation where you may have had to do it for business reasons, but now the protocol kind of very much encourages you to store those passports and that metadata.

David: 26:11

So as cryptographers, we've been like, ooh, deniability, cryptographic property. We like having more of those. Right? Those are good. But is that kind of fundamental, that if the purpose of the protocol is like spam reporting, that we would not get deniability? Is it possible to do this with deniability?

Josh: 26:30

So it is possible to have reportability and deniability. And one of the primitives that allows you to do this is something called AMFS asymmetric message franking. And in fact, I think Paul could probably talk a little bit more about that because he co authored the paper.

Paul: 26:49

Yeah, yeah, David, I mean, in answer to your question, like Josh said, I mean, it is possible to get both. The question is just being clear about the sort of deniability guarantees that are required here. What you cannot have with reportability is for it to be impossible for anyone to verify whether something is legitimate or spoofed. You need at least one party, that is to say, like the person who's making judgments. In the case of stir Shaikin, this would be something like the governance authority who's doing these investigations. You need them to be able to verify that a piece of evidence that's reported is genuine. But you don't need everyone in the whole world to be able to verify a signature, which is the case right now. So asymmetric message franking is part of a line of work that goes back quite far on deniable authentication. If you're familiar with the idea of designated verifier signatures, it's very related to that where you have a conventional cryptographic signature. But when you're signing, you designate a single party, or you designate a single public key, and only the holder of the corresponding secret key can genuinely authenticate verify the signature. And anyone else can't tell whether this is a real signature or a forgery.

David: 27:59

So in terms of, I don't know we'll call it real world privacy properties. Is there a big difference between letting, we'll say, the spam authority that controls, say, a private key for asymmetric message franking? Is there a large difference between letting them verify everything versus letting everybody in the world verify everything? For this use case, do you think that is a considerably better place to be in? And from a privacy standpoint, then the follow up question is, do we really need deniability? Regardless of that, do we really want deniability on phone calls in the first place?

Josh: 28:33

So I think first off, deniability wasn't the only privacy issue that we found, but we believe you guys did great.

David: 28:40

This is not like a statement about.

Paul: 28:41

Your work at all.

David: 28:41

This is just a question about like deniability in the context of phones.

Paul: 28:46

Course.

Josh: 28:46

Of course. But we do believe that deniability is important and we do believe that deniability is a real world concern.

Thomas: 28:55

It's a real world concern with email too. Right? Like David's just wrong about this. It's a piece of information you're revealing to an adversary. Right? Like you need to prove that a message is authentic. Right. But having received the message, you have no obligation to prove to other people. That's like, that is additional information that should be private and it doesn't need to be private. And we're just kind of rationalizing because the protocols that give deniability are annoying to construct and David doesn't want to construct protocols.

Paul: 29:20

Yeah, I know that I don't want.

David: 29:22

To construct protocols, but I mean, like.

Thomas: 29:24

We have just not good ones.

David: 29:26

We have signal for crimes and we have phone numbers for like the normal world. And like maybe we just see deniability for phone numbers.

Paul: 29:34

Yeah, I mean, I think of the deniability concerns that I have for phone numbers are basically twofold. The first is that sort of like in the email setting, it seems like having a very easy way to verify stolen logs will make it more profitable to steal logs of phone calls and therefore incentivize theft and penetration of telecoms and theft of logs from telecoms, which seems bad, but maybe people are already hacking telecoms, so maybe you don't buy that rationalization. So the reason why I think of this as being a problem, maybe on a more philosophical level, is because I think of a phone call as very much an ephemeral act, right? So when I call you on the phone, once we hang up our sort of mental model, this is that it's like that call is just done like it's in the ether now right. And of course, that's not true on a technical level, because there are logs, but we think of the logs as being maybe also ephemeral. Right. But adding cryptographic evidence adds a kind of permanence to the record of a phone call that did not exist before, which is like, maybe this is kind of a squishy philosophical reason, but this is sort of the reason why I believe that it's important to have deniability for phone calls.

Deirdre: 30:48

That's interesting. Can you compare and contrast with, say, if I set up a end to end encrypted call via WebRTC, which has a completely different infrastructure to make that connection over, not a VoIP, but TCP IP or whatever it is under the hood, it might even be a UDP at some level. That's kind of what we have generally architecturally agreed on using when we're trying to set up, at least pairwise. And I think there's work to make it easier to do group end to end encrypted video and voice calling in, like a web like, infrastructure setting. And I have no idea if there's deniability or lack of deniability in that sort of setup.

Thomas: 31:31

Before you answer that, can I just check my intuition on this? I'm probably wrong, but, like, I don't know, maybe somebody will benefit from hearing me like, noodle my way through this. Right. But when you're making like a pairwise WebRTC call, you have some kind of intermediary that you're using to set the call up Zoom, right, or whatever, and you're kind of trusting zoom on, like, both sides of that connection can reliably and can reliably trust Zoom to do that. But you don't have the telephony network problem of having a whole bunch of different providers federated that are then, like, kind of passing along identity information, which is also why email has this problem, right? Is because it's all federated and you have to be able to trust the source of it. Is there more to it than that, or am I missing like, a thing?

Josh: 32:10

I think you, you know, really did a good job of explaining kind of the difference there. I mean, there's, again, when you're using WebRTC, you're probably going to have something like Zoom, as you said, a single party. And again, depending on the specific protocol that's being used, even if many WebRTC calls don't even have any encryption or any type of signatures or anything like that, so it would depend on the protocol. But more generally, there are a ton more parties between the originating provider and the destination provider in the telephone ecosystem. I don't even know when I call somebody, I don't even know what party has access to this cryptographic information, this cryptographic evidence, because I don't know where my phone call is even going. And so I think that needs to be taken into consideration when we're discussing, when we're comparing between a web WebRTC call and something like Zoom and the telephone ecosystem.

Thomas: 33:18

So I have an understanding now of roughly how this system works and our basic problem with it in the pure VoIP sip world. But there's this alternate universe of SS seven where this isn't the protocol that's running over this. I guess one of my questions is how this stuff applies to the classic telephone network.

Josh: 33:37

Sure. So in the legacy telephone network, there is this protocol called SS seven that's used, and it's a legacy protocol. And so changing it is not really easy. And there are in fact multiple different versions of SS seven, so they're also incompatible. So it's just kind of a bit of a mess. And so introducing something like stir shaken is just not feasible in this with these legacy protocols. So the solution that is proposed is called out of band stir shaken. And the basic idea here is that before entering a TDM or legacy section of the call path, the passport, which is that signature with the call metadata, is uploaded to an external network of what we call CPSS or call placement services. This network serves as kind of like a Dropbox, where, for example, an originating provider would upload these passports to that network, to a node on that network. The node would then replicate it across the entire national network of cpSs. And then once the call traverses the legacy section of the call path and ends back on a VoIP or SIP compatible node, they can then retrieve the passport from the CPS network and then insert it back into a SIP invite message, and then you'd continue from there.

Thomas: 35:12

Let me see if I understand this right. So, like for the SS seven TDM network, which can't do sip, can't add headers, can't, you know, carry jwts, and is that's better off, but whatever. For that network, there is a set of sidecar services, is what I'm hearing. Like these CPS's, the call placement services exist to what take this metadata and kind of route it alongside the, you know, the switch TDM network hops, and at the end of it you just kind of mux it back in with the SIP calls as if it was a SiP call.

Josh: 35:43

Yeah, that's the basic idea. The important thing to note is the CPS network is just, you know, on the Internet, and so you're making like an HTTP post request to the. To the CPS, to a CPS node to upload the passport, to publish the passport, and then it's fanned out throughout the entire CPS national network and then eventually retrieved via another HTTP request.

Thomas: 36:04

That was the wacky thing I heard. Yeah. Was like, so if I. If I'm understanding this, if my. At the moment that my call has to go over the legacy TDM network. Right. The metadata for that call gets literally flooded through all of the connected CPS's.

Josh: 36:19

Yeah, that's. That's the basic. That's the basic idea. Now, the kind of good news is that out of band stir shake, and we don't believe is. Is widely deployed at this point, but that is kind of why we want to. Before it is deployed like this, we kind of want to try to work to improve that protocol and perhaps increase the privacy and improve the privacy with something like this.

Thomas: 36:44

Got it.

Paul: 36:45

Just to add to what Josh said, it doesn't seem like you said it's not super widely deployed yet. But from talking to people, from doing our survey, it's clear that a solution to this problem of SS seven hops is desperately needed in the ecosystem. So we've talked to people who are running small VoIP providers and whose calls, legitimate calls, are being marked as spam. Like they're false positive spam, because the bigger telcos that actually run SS seven infrastructure are just stripping the passports off and not restoring them. So the big telcos don't bother to implement out of bands to shake in. And so the VoIP providers that pass calls are just kind of getting hosed in some sense, because their passports, even though they're playing by the rules, their passports are just getting stripped and not added back because no one's using out of bandster shaken. So.

Thomas: 37:33

Yeah. Okay, so the dynamics here are, this is a protocol that exists, but no one uses it like SMMPV three. But there is a huge incentive for this to get adopted because it's screwing over, you know, the smaller. So something's going to happen. And your observation is basically like, you caught it just in time. Like, now there's an opportunity to, like, make this not horrible.

Josh: 37:52

Hopefully, that is. Yeah, hopefully. The goal. The goal is to kind of get in front of this and propose, you know, an alternate solution that. That everybody is happy with and works effectively, but doesn't have, you know, these privacy concerns.

Thomas: 38:07

I think we want to get into, like, the interesting cryptographic side of this, like the, we going, like, going back into, like, you know, message crypto stuff and nerding out about that. But before we do, I want to make sure, did we cover all the things that this system got wrong like that you guys have, or is there more to talk about?

Josh: 38:24

Well, there is a lot more. One of the other things that we found is, besides the cryptographic evidence, there's also just a ton of metadata that is included in these passports that is visible to all the different intermediaries. And right now, that's mostly just the originating telephone number and the destination telephone number. There are proposals to increase the amount of metadata and the type of metadata that would be included in these passports, and that could be memes, physical addresses, birth dates, and any type of information you could imagine. And so we want to try to ensure that one of the other issues we found is, again, the fact that this passport, which includes the metadata, is just sent in the clear through the telephone network, through the PSTN, the bundle.

Deirdre: 39:15

The message that is being signed by the provider, that's the passport.

Paul: 39:19

Right. Just to add one sort of alarming example, there is a document, a draft in the ITF stir working group, that proposes extending stir shake into text messages. And at least one variant of this extension would allow signing the contents of the messages themselves as part of stir shaken. So not just metadata, but also, at least in one case, the data itself would be signed.

Deirdre: 39:43

Yeah, great. Awesome. No, that bad. So some of your solutions proposed to help improve this is literally encrypting the passport.

Josh: 39:54

Yes. Which is easier said than done. One of the difficulties, of course, when you want to encrypt something is, of course, the key discoverability problem. And in this ecosystem, that is a really big challenge. It is very difficult at this point to go from a destination phone number to a destination provider, let alone a destination provider certificate or key. Excuse me. And so that is a challenge we have to work around as well.

Deirdre: 40:24

Okay, so encrypting the passport, but solving PKI, we can figure that out maybe eventually. But you already mentioned, Paul, the message franking, and I think you're proposing to use that in here to allow the reporting of bad actors without literally being, like, keeping the full record of signed call logs forever and ever.

Paul: 40:53

Yeah. Our solution actually for asymmetric message ranking would require PKI, just because of the way these designated verifier signatures require you to know the public key of the designated verifier at signing time so this problem would exist. We were talking a little bit about the flaws and we started talking about metadata leakage and then we sort of got off track. But I'm not sure it was clear to the listener, like our specific concerns about metadata leakage are.

Josh: 41:19

Yeah, sure. So the way that this system works is oftentimes originating providers will use a third party service to actually sign the call metadata. And we call this third party service an authentication service.

Thomas: 41:36

Wait, wait, wait, wait. Hold on. The providers aren't doing this themselves?

Josh: 41:41

Oftentimes. Not based on our survey.

Paul: 41:44

You're as alarmed as I was when I found this out for the first time. Thomas. I remember, Josh, I don't know if you remember this, but I think I remember literally screaming in my office when we were reading these rfcs for the first time.

Thomas: 42:00

Continue.

Josh: 42:02

Yeah. So there is this authentication service, which based on our survey is often a third party that has possession of the originating provider's private key and can then sign the caller metadata. And so basically for each outbound call, the originating provider will send that call metadata to the authentication service, and then the authentication service will sign that metadata and return a signature. And then on the other end, on the destination provider side, the destination provider also oftentimes utilizes a third party called the verification service to verify that passport. And so when the destination provider receives a call with a passport, they will send that passport to the verification service, who will then return, excuse me, a result. Either it passed verification or it failed. So this means that the authentication service is going to have access to all of that metadata, and then the verification service also has access to the metadata within the passport, but also has access to that cryptographic evidence. And so these are further parties that have access to some of this information.

David: 43:09

So to be all negative, again, if there was an authentication service in the verification service, you'd be running this yourself, but you probably are using a server from some hosting provider or something. You're running your code in Amazon, let's say. Maybe you're running it on some public cloud, maybe. And then that public cloud would in theory be able to see everything that's coming through. And so is this really considerably different than using a hosting provider?

Josh: 43:42

So I think, again, I think a good amount. I don't know that we asked this exact question in our survey, but a lot of telecoms have on prem infrastructure for this stuff, so they're not necessarily using a cloud platform.

Paul: 44:00

Yeah, I mean, if I could add to that, it's certainly true that third parties are used for other purposes in telephony. Right. What I think is interesting, and also maybe a bad quality of surshaken, is that especially for smaller providers that don't know how to manage cryptographic keys, in my opinion, and this is a contestable point, so you can argue with it if you like, but in my opinion, this creates a de facto requirement that third party expertise is used to discharge the requirements of the stir shaken protocol. Whereas providers had a choice to use a third party for something like analytics before stir shaken, especially for smaller providers, creates a burden on them that is easiest for them to get rid of just by using a third party. So I think, for me, the alarming thing is really a question of, like, how people in the world were actually deploy and use the stir shaken protocol. Yeah.

Josh: 44:57

Just to add on to that, when we were conducting the survey, a lot of the small telecom providers, when they heard that we were asking about stir shaken, had a lot to say, and they had a lot to say about the fact that they really did not like stir shaken. And because they felt, as Paul said, that it created this burden, this expensive burden to implement this protocol that they oftentimes did not have the technical expertise to do. And so they had to pay some type of third party to kind of do it for them, which for small telecoms can cost quite a bit of money. And so there was a lot of frustration about the fact that this was required of them. And we believe this to be one of the large reasons why third parties are commonly used for these services.

Thomas: 45:46

None of us here are lawyers. Right. But my brain right now is kind of churning on, like, ECPA stuff and, like, pen register stuff. Like, we've created a flow of metadata that goes to a bunch of random third parties who weren't originally contemplated under any of the legal structure that we have for watching telephone calls and all that. But all of them now are maintaining what is, in effect, a pen trace register of every call that's been made where, like, you might be able to get information now under a subpoena instead of an actual wiretap order. That before would have been a lot trickier to get because it's going straight through Verizon's compliance department. Department to get it or that kind of stuff.

Deirdre: 46:25

And I can also see, like, oh, if this is really shoving people to use a third party provider to handle these keys for you, I bet you a dollar that there's going to be several major parties who will serve multiple origin providers. And so there's going to be a lot of eggs in one basket to subpoena or to get those providers used to complying to subpoenas for rod or narrow court orders or requests.

Josh: 46:58

That is a really, really important point because if the same third party operates an authentication service and the verification service for a given call, then they can correlate this information. And that's something.

Paul: 47:13

Yeah, I mean, Deirdre, to your point, just our sort of understanding of the ecosystem indicates that you're absolutely right. I mean, there is a huge amount of centralization in a few providers. I mean, I think the biggest one is called TransNexus. We don't exactly know of the people who use third parties. We don't exactly know what percentage are TransNexus, but it seems like it's quite a large percentage. I mean, you think one of these large providers, theyre just by performing their role as a third party in this ecosystem, are able to collect I would say, an appreciable fraction of all of the metadata of every single phone call that happens. And it might not be a very large fraction, but the fact that they have this outsize view into the activity of the entire telephone ecosystem is really, its interesting that this seemingly innocuous sort of anti spam requirement led to this sort of metadata leakage to a centralized party. Yeah, but I think part of what's interesting to me about Surshaken is that it's sort of a story about the way that cryptography and privacy sort of interact. Maybe not so well in practice, because the stirshaken is a requirement that a bunch of people who don't necessarily know how to use cryptography start using it. And so what happens is these people, instead of having to figure it out, they pay someone to figure it out for them. But this requires you to give this person all your metadata because you have to sign it. And then this is just sort of like a new flow of information to a third party.

Josh: 48:41

One of the other things that I find interesting, and I'm not sure we entirely discussed yet, but because Stur shaken creates this entirely new PKI, it suffers from many of the issues that the web PKI had back in the day. For example, there's no certificate transparency log or anything like that. So there are some things that are technically easy to solve but have really, really big impacts that we would like to encourage and see implemented. Certificate transparency logs is just one of those things.

Deirdre: 49:17

Do these provider signing and verifying keys have any expiration? How long are they supposed to live? Is there a revocation log? Is there anything like that?

Josh: 49:31

Great questions. So yes, certificates do expire, which is a good thing in terms of revocation. So there are revocation lists. Revocation is a little, little bit weird in this ecosystem. So the URL that's included for the URL to the certificate revocation lists that's included in many of the certificates, if not like most of the certificates that we found, doesn't actually is not publicly accessible. So if you try to access it, you're going to get, I don't know what it was probably some type of like a forbidden HTTP or forbidden code. Basically you need a special API token from them. Now everybody should have this API token, but it's not just publicly accessible like most certificate revocation lists are. And if your implementation does not have the ability to insert this API token and you utilize it properly, you may not be able to access those certificate revocation lists.

Deirdre: 50:35

You have a completely opaque, unauditable, untransparent PKI infrastructure.

David: 50:42

Yes, but we do love it. Whenever the web PKI it is good to know that the web PKi is better than it used to be, but a lot. I think people get caught up in all the problems with the web PKi, but it's so much better than it used to be. And it's still probably the best PKI in existence right now.

Paul: 50:59

Isn't the best PKi one that has no identities and no one ever uses for anything? Isn't that the platonic idea?

Deirdre: 51:04

Why do you have a PKI?

Paul: 51:06

The best PKI is no PKI.

David: 51:10

So we've had deniability issues, we've had metadata leakage to just a whole host of parties, we've had centralized metadata, we've had your standard sort of PKI, old PKI issues. Are there any other problems, or can we move on to how you're going to fix this for us?

Josh: 51:27

Yeah, I mean, we could probably talk about issues for the rest of the podcast, but probably, probably a good idea to move on to solutions.

Paul: 51:35

Can I add one piece of context to the discussion of the PKI?

David: 51:39

Sure.

Paul: 51:39

So the way that certificate authorities are credentialed in the stir shaken ecosystem is pretty weird. There's an entity that exists that's called the policy administrator that they certify cas as being able to issue public keys. And the list of qualified, trusted root lists is just on a website somewhere. So when you want to figure out who's trusted in this ecosystem, you just make a get request. And this list is itself signed by a self signed certificate that also just lives on the same web page. So all the trust in this whole PKI is rooted in literally just a web page, which is secured by the.

David: 52:23

Web PKI, which, as discussed, is the better PKI.

Paul: 52:27

Right. So I don't know how to feel about this. Like, maybe it's good that it's simple, but also the fact that there's just this one party, that they have this one self signed cert, that's the root of trust of this whole ecosystem seems really weird to me. We should at least be able to.

David: 52:42

Communicate that key out of band.

Josh: 52:45

Yeah, that is a very big difference. There's no single point of failure in the web PKI, but there is a really big single point of failure in this PKI.

David: 52:55

There's multiple single points of failure in the web PKI, but they take a different form.

Thomas: 52:59

Wow.

Paul: 52:59

Yeah. So when it related to PKI, one of the things that's interesting is, like, we say, like, we want certificate transparency, but like, why do we need certificate transparency in this ecosystem? Well, we, with our industry partners, have been looking at the certificates that people actually use, and mis issuance of certificates is, like, all over the place. There's just tons and tons of malformed, mississued certificates, like certificates that don't have the right extensions. Their extensions are malformed. We found some certificates that don't have any extensions. Not only do they not have the right ones, it's like, they don't have any at all.

Josh: 53:33

Yeah.

Thomas: 53:33

Just to be clear, right, like, when you miss issue a certificate in this system, the consequence of that is you can spoof a call, right?

Paul: 53:40

Well, yes and no. So there are mis issuances that are more syntactic in the sense that the certificate's malformed, but it still binds to a public key to an identity. And there are mis issuances that are severe for security, which is like, if you issue a certificate, a foreign identity to someone who should not have that certificate, then that allows you to spoof calls because you can impersonate someone's identity in the stir shaken ecosystem.

David: 54:05

Okay, so this is another PKI that has not yet discovered linters in terms of the Miss issuance problem. So back to big loop. Back. So we discussed fixing deniability. We could do some form of message franking. So how would that work in this system?

Josh: 54:23

So, right now, the asymmetric message franking amfs aren't compatible with the ecosystem because we don't have the ability to go from a destination phone number to a destination provider and then to a, to the certificate of that destination provider. So right now, that isn't possible to be, uh, used. Um, but we believe that we can create a system, and, and based on our discussions with people in the industry, we do believe that that is something that can be done in the future. And so once we have that system set up, uh, we can basically use AMF. So we would look up the, uh, certificate of the destination provider, uh, and then we would create a signature that's signed to that party. And so that party is the only one that can distinguish between fraudulent signatures and legitimate signatures. And that adds that type of deniability, because anyone can forward signatures, and the forward signatures and the legitimate signatures are computationally indistinguishable unless you possess the private key of the destination provider. But it also has this reportability mechanism where the destination provider can report the call to the, the moderator, which in this case would be the policy administrator, in order to report the originating provider for attesting to some type of fraudulent call.

David: 55:53

And it sounds like the sort of community or ecosystem is open to this type of approach. Like if we could get the necessary infrastructure.

Josh: 56:02

So we've spoken with a few people in the industry and they would be open to it. We hope to eventually, once we have worked out what we want to propose, we will hopefully speak with perhaps some people at EDIs or some people at the FCC and see what they say and hopefully work with them in order to improve this ecosystem.

Paul: 56:28

It's difficult to tell whether they would be open to a sort of, I mean, I guess you, you could call it sort of an advanced cryptographic approach. It seems like in general, the telephony standards community is pretty averse to new technologies. And the fact that it's not just a plain digital signature may scare people off. But I mean, I guess our sense is that, at least in terms of what is the basic purpose of the Stuirshaken ecosystem, there's no incompatibility between the functionality that Stirshaken needs to implement and using some kind of asymmetric message ranking or some other approach based on these kind of designated verifier signatures. With one interesting caveat, which is that some industry people have indicated that, at least in some cases, its important for intermediate hops in the call routing path to be able to verify passports, or that it may at some point in the future be important for them to be able to do this asymmetric message ranking. And really, any approach based on designated verifier signatures by its very nature prevents intermediaries from verifying the signatures. So that's why we're sort of evaluating an alternate approach that's based on a nice paper from a couple of years ago called keyforge. And the basic idea is, the very simple suggestion that people have made for DKIM for a long time is that when you're done with a DKIM signing key, you just publish the key. You preserve deniability just by making sure that anyone after a certain point can actually forge a signature. So key forge is a fancier version of this approach.

Thomas: 58:03

That was an idea from OTR too, wasn't it? For deniability, just publish the key, use ephemeral keys to sign, and then publish them, so it doesn't matter.

Josh: 58:11

Yeah, but what would be important here is we would still want to maintain that reportability aspect. So we would need to improve on the keyforge solution, to add the ability to report a call to the policy administrator, the governance authority, even after the expiration.

Paul: 58:31

Right after you expire the key and publish it, you sort of want to maintain the ability for one party to distinguish a real signature that was created before the key was expired from the time it was after it was expired, which is sort of like an interesting technical challenge that we think we know how to solve, but we haven't written it up yet.

David: 58:51

So message franking is an option. This keysforge approach is an option with slightly different properties that might be more desirable in certain situations. Are there other things that we could do to improve the properties of the system?

Josh: 59:04

Sure. One of the other things that we're discussing is a blind signing system, so that the authentication service wouldn't have access to the metadata, especially when it's a third party. And then on the other end of things, we're thinking about a blind verification scheme, which is a really weird and awkward problem that we don't think has ever been discussed in the cryptography community. And the basic idea here is we want to be able to verify a signature on a passport without revealing the passport to the verification service. So this is a little interesting. And then also we want to kind of integrate those schemes into amfs eventually.

Deirdre: 59:51

Nice.

Josh: 59:51

And then we also have the out of band system, which is a completely different discussion.

Deirdre: 59:56

I've learned a lot more about telephony and metadata than I ever really wanted to know, and I don't like it.

Paul: 1:00:07

Now you're cursed with this knowledge just like we are.

Deirdre: 1:00:10

Thanks.

David: 1:00:11

Somehow it's always the knowledge about certificates that you end up being cursed with. Something about certificates leads to curses. We didn't say it at the beginning, so I do want to note it now. Paul Grubbs is a professor at Michigan, but perhaps more impressive is that Josh Brown is an undergrad at Michigan. As we all know, Michigan is the greatest university in the world.

Josh: 1:00:30

Indeed.

David: 1:00:31

Also the reigning Michigan or the reigning football champions of college football. So we're going to keep riding that high. But massive props to Josh Brown for speaking at real world crypto, especially as an undergrad. And I'm sure he'll go on to do great things or whatever it is that he wants to do, or bad things.

Thomas: 1:00:51

It's fine either way.

Josh: 1:00:52

Or bad things. Thank you. Thank you, David. And I do have to say, go blue.

Deirdre: 1:00:58

Go blue.

David: 1:00:59

Go blue.

Thomas: 1:01:00

I feel like we probably could have gotten another hour of interesting stuff out of this. This is like much deeper than I thought it was going, and this is awesome, you guys. Thank you so much for this.

Josh: 1:01:09

Of course. Thank you.

David: 1:01:13

Security Cryptography Whatever is a side project from Deirdre Connolly, Thomas Ptacek and David Adrian. Our editor is Nettie Smith. You can find the podcast on Twitter@scwpod and the hosts on twitter@durumcrustulum,@tqbf and@davidcadrian. You can buy merchandise at merch dot security cryptography whatever dot com. Thank you for listening.