Sarah Delphey: Hi, everybody. Welcome to Tuesday Talks. It's good to see you again on this Election Day, with the goal being to bring truth and shed light across the brand identity and communications industry. For those who haven't been in our past podcast sessions, I think this is the second Tuesday Talks I've hosted. I am Sarah Delphey, Numeracle's VP of Trust Solutions, and today I am incredibly excited to be joined by Bradley Reaves, who is an Assistant Professor of Computer Science at North Carolina State University. Welcome Brad!
It's great to have you having me and I have so many questions for you. I'm so excited to be able to talk to you today. For anybody who is more interested in me and wants more info on my background, our team has put together a very flattering Inside the Innovators article. If you want more background information on me and why I'm here talking to you today, please feel free to take a look at that! For now, I'm going to focus on Brad's expertise because he's someone that has a lot to say about the telecom industry that many may not necessarily recognize or expect.
Could you tell us about how you came to be involved in telecom while a professor of computer science?
Bradley Reaves: It's a really funny story. I was in the middle of my PhD in computer science and up until that point I had been working in computer security and researching traditional topics like malware, viruses, stuff like that. One of the gauntlets or dark nights of the soul that you go through during a PhD is, what am I going to do my dissertation on? In the first year or two, you don't know what's been done and you don't know what hasn't been done yet.
Every idea you have has already been done and it's terrifying and you think you're never going to have anything interesting to say or do. In the middle of this, I went to visit my grandparents over Christmas break and I remember watching one of the football games. I can't remember which, but I remember that their phone was ringing off the hook. I think they've had the same landline number since 1972 and they were getting hammered with robocalls. I thought to myself, man, somebody should be doing something about this. Then about six months later, it occurred to me maybe I could be the someone who did something about it.
I started working with my PhD adviser who had done some work in cellular and telco himself. We started to look at the problem of robocalls in particular and where we dialed in was this concept of positive authentication. In other words, knowing that when you get a call, it's actually from who it says it's from. The thinking being that is if you have that, then perhaps people who are spoofing and things like that aren't really going to be all that effective. Telco isn't really a common topic in the ivory halls of academia, especially not in computing. But the more I dug into telco, the more I realized that telco faces a lot of the same problems with fraud and abuse, admittedly with some unique and really interesting twists.
There is a lot that we can apply that we've learned from, say, other forms of Internet abuse talking about email spam or phishing, email links, etc., Or other things that maybe we don't think of on a day-to-day basis, or even the concept of identity in the network. The theme of my dissertation was trying to figure out how we can provide positive authentication with phone calls using the types of things that worked on the Internet.
So when you go to Amazon.com and you pull up that, you pull up the browser. If you do what the security people tell you to, you look for the little lock in the top left corner and you feel warm and fuzzy about typing in your credit card number.
Sarah Delphey: Well, maybe not warm and fuzzy, but slightly more warm.
Bradley Reaves: Maybe I reconsider if I have a shopping problem if I feel that warm and fuzzy about it. Anyway, the key idea was, can we take the mechanisms that worked for the web in solving the problem of identity and bring them into telco? So we built a couple systems that looked at this and at the top of our minds were two things. One, we were outsiders. What that meant was that if we wanted to build something that had a snowball's chance of actually working, we needed to be able to do it in such a way that end users could decide to do it themselves.
So on an end-to-end basis rather than having networks have to come to an agreement. Part of that was practical. I wanted to graduate in this century so I wasn't going to be able to convince a telco to let me jump into their network and start messing with them. We really focused on what could we do with a smartphone; that was the main perspective we were thinking about. The other thing that was top of mind was the heterogeneity of the network. That's a big word that I managed to fit it into the title of my dissertation somehow. We didn't want to be looking at a system that was only VoIP, because we knew that, especially at the time I was doing this work starting in 2015, TDM was still alive and well and it still is.
We wanted to be able to deal with all of the different variations of networks because the old stuff sticks around a lot longer than anybody expects. Telco is also really interesting in that it's not as ossified as the Internet. We've been stuck on IPv4 as long as I've been alive. If you look at telco, the transition to VoIP has happened within the careers of everyone on this call and listening in on the podcast. If you look at what happens in cellular, every ten years, you completely redesign the network.
Sarah Delphey: It's crazy to think about because I tend to think of telecom as a slow moving industry, but you're right. I guess with a lot of the protocol systems and technologies that we've used, one of the challenges we have today, when we think about a system of authentication to rule them all, is this innovation we've had has made the industry so competitive and diverse and brought a lot of new players in. Now we have to reconcile all of those. Which is why it was so crazy when I went back and looked at your dissertation and thinking about how in 2017 you were already writing an entire framework for call authentication.
Bradley Reaves: Yes. This was around the time that STIR and what was happening with the STIR Task Force; it was happening concurrently. We were a little aware of what was happening over there, but we were almost strictly focused on dealing with the non-VoIP cases and assuming or not really caring about whether we were dealing with VoIP or TDM or carrier pigeon or two tin cans and a string, whatever the case was. Part of that was simply because when you start a phone call, if you're thinking end-to-end, I can't tell you what technologies it's going to use from beginning to end.
Sarah Delphey: The industry is seeing a lot of that now with a lot of the lack of end-to-end STIR/SHAKEN authentication that's happening. I've seen estimates from different parties of maybe 15-25% of calls are reaching their destination with a signature attached. A lot of that loss is being attributed to non-IP network in the middle that are not transmitting the data. Without us reading your dissertation, how can we solve for this?
Bradley Reaves: This is a fantastic question, and there's a couple of ways of thinking about it. We took a couple of different whacks at this particular problem. Our first whack was in thinking about leveraging the fact that for voice we moved away from dumb-end points to smart-end points without really realizing it. By that, I mean the transition from standard Pots and phones to smart VoIP phones or smartphones. What we keyed in on is that there's a lot of computation that you can do that you couldn't do before.
That enables us to do things like use strong cryptography to provide authentication of identity, and this is what you were hitting at. The problem is, how do I get my identity from my phone to yours, especially if I have no idea what path the call is taking? In our first look at this problem, we didn't know anything about the call except that we can transmit audio, it's band limited, it's compressed, and it's noisy and lossy, but it's audio. We built our own modem and we figured out how to do really strong cryptographic authentication in a tiny amount of space and transmit it over the phone line.
Now, most folks probably remember the old days of the V.92 modems that you used for dial up internet. It turns out that it doesn't work if your call is being compressed in route because compression, by definition, takes out all of the extra space that you would use for data. The chief technical challenge was how to shove data into the voice channel. The problem with that is, to have a voice channel you have to answer the phone.
Especially with the current regime of robocalls, this is something that we don't want to be doing. So our second approach was to have out-of-band authentication that happens over the data network, over IP. The idea is that you would have a central meeting server, similar to the role that STUN and TURN servers play in VoIP.
Sarah Delphey: For the newbies regarding out-of-band, my understanding is if you're not transmitting the information over the pathway of the actual call itself, you and the initiator and the recipient are separately accessing a common data source where you're both agreeing this is where all of our credentials are essentially going to be stored.
Bradley Reaves: That's exactly the case. When you place a phone call, what you do is you place the call as if through the phone/voice network, whether that's cellular landline or something else, but simultaneously you send a data request to a central server. The server does a little bit of authentication on its own, but mostly it just does some matchmaking.
When the call request gets to the other destination, it can contact the server and say, hey, I'm seeing a call from this number, can you tell me anything about it? They can pass something like a token that says this is the actual identity who's calling you at this particular point.
Sarah Delphey: That being a way of resolving this transmission loss that could theoretically happen, how does that compare with STIR/SHAKEN as it exists today? I'd love to hear your thoughts on STIR/SHAKEN as a solution. What are some pros, what are some cons? To be fair, I think we've got some folks on the call that are heavily involved in STIR/SHAKEN. For those that are listening live and after the fact. There are some compromises that have to be made for doing that transmission in call, but I'm curious to hear your thoughts on it as a solution.
Bradley Reaves: I'm going to do the professor thing and start really far away from your question and then hone in. The first thing I would say is that if we were trying to build telephony today from scratch, even VoIP, we would have made a lot of decisions differently. Something like STIR is what would have been the ideal design for a clean start network. I think the STIR folks would agree on this, that if everybody is VoIP compliant, STIR works great, at least in terms of the technology and moving things. You still have the problem of mapping the cryptography to identities.
Sarah Delphey: Right, and are phone numbers still good in terms of the actual calling party identity, on and on and on... At least the outside goal is determining if a phone number being spoofed.
Bradley Reaves: Right, exactly. Identity is one of those things where there's a large technical component to it, but there's always going to be a social or extra-technical or beyond technical aspect to it that you can't solve with technology. I think that STIR was the solution to the problem that we would have had if everybody had done a flag day and moved on to VoIP at the same time. As you pointed out, I actually hadn't heard the numbers on this until today, but something like 25% of calls are losing their information. Is that what you said a few minutes ago?
Sarah Delphey: I've seen several different sources and they're all operating on their own in their data and pool of call information. I've seen some estimates as low as 25% of calls are reaching their destination with STIR/SHAKEN information attached. So 75% of calls being delivered unsigned at this point. That figure may not be exactly right, but the majority, I think I would agree, are unsigned at this point.
Bradley Reaves: That matches my experience as well, but I had been attributing that mostly to the small carrier exception that has been in the FCC rules. Still, the problem is that we're stuck with TDM and non-compliant transit operators and other issues where things get lost in the shuffle. So the STIR folks in the Working Group, I think going back as far back as 2017 or maybe even earlier, had a Working Group on doing things out-of-band.
Their solution, if I recall correctly, worked similar to what we were doing, except there is a big philosophical difference. I'm coming from an Internet and computing background and the thing I teach my students about the difference between what you typically see in CS and Telco, which is a difference in philosophy and mindset. Telco has always had a smart network with fairly dumb and untrustworthy endpoints and the Internet flipped that around entirely. Unless you want to do anything other than moving a packet across the Internet, good luck. That's all the internet will likely ever do in the core.
The initial proposals for STIR out-of-band from the IETF Working Group continued that approach in STIR of making the network the arbiter of identity and the source of truth for the authentication of a particular signaling. Obviously, there are pluses and minuses to either direction. You mentioned earlier to me, that the FCC has a Request for Comments out now on non-IP STIR/SHAKEN. I would encourage folks to really consider the possibilities that could come about from involving the endpoint more in the process.
Sarah Delphey: Could you talk more about the computer science world? Maybe provide an example of bringing back an end-point focused solution that you've seen be successful or at least nominally successful in another industry?
Bradley Reaves: This is a great question. The truth is that where you see centralized solutions being most effective are in situations where you want global or where you need a lot of visibility to be able to make good decisions. The classic example of this is spam filtering. I could run my own mail server and I can send and receive email. I can build my own AI classifiers to try to label spam but I will never beat Gmail because they have better visibility and better training data.
Where decentralized solutions are really helpful are in situations where the network is not in a position to see or control everything and that might be for scalability or performance or just practicality. Let me give you a couple of examples of that. If we want to talk about why distributed systems work across the Internet, the best example is the domain name system. If you need a refresher, this is the system that takes something like Google.com and converts it into the IP address that you actually need to put on your packets so that they get to Google.
The way that the system works is hierarchical. That's what all the dots are doing. the.com runs itself differently from.org different from US and UK and so on, and then the domains below that, say Google.com. Google.com is actually responsible for serving its own names and that's true for every domain, whether we're talking Google.com or BradReaves.Net. Each level you go, there's the possibility for even further delegation. This is really important because your computer is making potentially dozens of DNS requests every second. That's just one machine and you multiply that by the size of the Internet. A centralized solution just would never, ever scale.
Sarah Delphey: You can't have somebody sitting in the middle. Email is one thing where it's not a real time transaction and there's time in the middle. It strikes me that telecom is a unique hybrid problem with a decentralized enormous group of actors all over the place and real time communications, at least certainly for voice and ideally for messaging, you have close to real time, if not real time. It's the worst of both worlds, so to speak, in terms of forming a solution.
Bradley Reaves: That's an interesting way of thinking about it. To come back to your earlier question, since you asked about what are some places where end-point focused or decentralized solutions make more sense, specifically thinking in terms of fraud abuse and authentication. Going back to the little lock that I talked about, that gives me more than fuzzy feelings, that's the web ecosystem for TLS (transport layer security) that provides a sense of identity for the entire web. It's also completely decentralized and it's largely run by the endpoints. It's Amazon or Google or whoever's job to get a certificate that clearly identifies them as Google, binds them to their cryptographic material, and allows them to figure out exactly how it is that they want to manage identity internally.
If you want to really geek out, you can go into the details, click the lock, and go deep into the menus on the different Google properties. What you'll see is that Google does a good job of having separate and distinct identities for most of their properties. This is a nice separation of concerns so that if, for example, a Gmail is compromised, it's not necessarily going to affect Docs or some other part of the platform.
Sarah Delphey: That makes sense and that leads back to this idea of having decentralized actors and real time communications. Based on what you've outlined, it really seems like decentralized identity + consolidated spam analytics to an extent, or at least consolidated by a platform where there can be a marketplace a la Gmail of, "this person does the best job, I really want to work with them as my email provider." Both of those can come into play.
I do want to jump into a couple pieces and I have a question for you as well. We don't see much of academia in telecom. In your experience, having worked in security and other industries, is that common? If not, why do you think telecom is different from those other industries?
Bradley Reaves: That's a fantastic question. There's the stereotype of the ivory tower full of academics and all they want to do is spend time thinking about things that are unrealistic that will never matter and can't ever be relevant to anything in the real world. In computing, that's almost never the case. Computing professors like myself and most of my colleagues at NC State spend a lot of time doing our best to talk to industries to find out where the real problems are and how our position, as a neutral party without a profit margin in the game, can think about different ways to solve important problems.
Speaking for myself in particular, all I want to do is do something that matters. My experience has been, talking about telco now, is I don't think folks in fraud, security, and authentication realize how much of a resource academics can be. We've seen things in other domains that might be helpful. We also have access to the best students that you might want to recruit for your company. Most of all, we can do things that might be on a longer time frame than hitting your numbers next quarter.
Sarah Delphey: Or finding the resources to answer interesting questions that may not be of immediate business importance to you individually. I do want to give a quick plug to a question that was submitted, which I really appreciate. This is a shout out to your department's 2020 paper which we can share a link to so everyone can see some of the conclusions that your department, your students, and yourself came up with through analyzing honey pots and verbal calls and some of the conclusions that can be drawn from that.
I think it's a perfect example of what you were just talking about, where maybe it doesn't make financial sense and it's not in the business interests of a telecom provider to look and find those answers. But they have so much value to challenging our assumptions about what robocalls actually look like and what we need to do about them. We should absolutely do a follow-up session of this, but in the interest of time, I just want to say thank you again, Brad, for joining us.
We're definitely going to see more of you. I would encourage those that are listening to reach out if they see another opportunity for Brad and his team to consult on anything that's going on in the wide world of telecom. Our next live Tuesday Talk episode will be on Tuesday, November 22. Thank you again, Brad, for joining and for the insights. It was great, as always!
Bradley Reaves: Thanks for having me!
