 Hey guys, what's going on? We're at 2 o'clock. We've got two of our presentation here. Two new guys, so please give them a good celebration. They'll be fine. I mean, come on. The presentation is called Sparrow, a novel covert communication scheme exploiting broadcast signals in LTE 5G and beyond. Wow, everything. And the presenters are Raza Chakabi and Chuck Macaulay. I still messed it up. I'm so sorry. I guess this is the end of this live. But you guys, start off. Thank you everybody. Nice time afternoon for attending our talk here. We'd like to present a novel covert communication scheme exploiting broadcast signals LTE 5G and beyond. And I add something in this presentation today since you guys are attending in person, be different than what we have recorded and posted on YouTube. So give a hint, it's about exploiting mobile towers for stealth IoT. So I would like to introduce yourself. I'm Raza Chakabi. I have my Twitter handle up there. So I come from the background in math and signal processing. I'm application research lead at application and threat intelligence center at Keysight. We call it the ATI research center. So I do 5G security research and make algorithms for making and breaking things. So in all ways, I have a great experience whenever I try something for the first time. That's the picture of my childhood. I suck at riding horses, but that first time I looked like Napoleon. So it came nice. So here with me, I have Chuck. Thanks Raza. My name is Chuck Macaulay. I go by Noble Trout as well. This is the countless next DEF CON I've ever been to, but it's the first time I made it to the main stage. What I really want as a life goal is to become a ski bum. But in my day to day stuff, I work with Raza. We break a lot of things. We work for a test and measurement company. So you get to test and measure quite a lot of things and think about new ways of breaking things. So there you go. All right. So I want to take a moment here and talk about motivation because what I'm presenting here is not just about discovering a single vulnerability in the standard of all the 5G and LT towers that are deployed down there, but it's more of an idea that can be applied to other wireless technologies. So to do that, I really would like to summarize this, that what this research is product of having a right to vision, being in the right time and the right place. And today, I'm honored to present it to the right people here. So I've been working on IoT security research of published in IEEE around like 2013, 14, and I left my Ph.D. to join industry to get my hands more on experience and try to find better ways to apply mathematics to problems. So I work as an R&D consultant with mobile operators in U.S. and I was a 5G system engineer a while before joining Keysight. So I was away from security for almost seven years. So when I joined ATI, I had the opportunity to kind of get formal education in Infosec and learn about things that are going on down there that are lesser known to people in the wireless world like myself. So that was a key point here. And this is also a product of basically merging my past and present experiences. Another key point here was or support that I received from our organization, particularly our cool boss, Steve here, that one day invited me to an unspecified room in our building and said that, hey, this is a lab with a super expensive cell site emulator. They said that do, find what's wrong with it and do 5G security research here, Greenfield. So I decided to go after something big, so get motivated for that to go after not simulating what is already out there, but what can be the future vulnerability. And of course, we disclosed this in, I mean we discovered this in fall 2019, but we went through the responsible disclosure with GSMA, which is association of all mobile operators and OEMs. And things got slow. I was on parenting leave and the pandemic. So I watched by the way on first time, also attending DEF CON in person. So I watched this very awesome talk on eavesdropping satellite signal in the last year DEF CON. And I got really excited. And I just realized that, okay, this work has to be for the first time presented at the DEF CON. So what was the approach of taking here to discover this kind of vulnerability, or I'm going to call it like a class of vulnerability, was basically taking the holistic approach and putting everything in a big picture and figuring out what is the missing piece in there. So I realized the covert communication a little bit, the wording is a little bit heavy, but it's a big umbrella that can cover data exfiltration, which is very known in the infosec industry, not much too much known in the wireless world. And all sort of unauthorized communication. And it is considered a potential threat. We know that is a part of many kill chains. And it's a matter that has to be treated for defense in depth. So when I was reviewing the literature, I realized that there are two dominant viewpoints from two different types of people. So we have hackers and people in the infosec that have focused on, I mean, that's their mentality to exploit software protocols. And I've done a great job of finding ways to tunnel messages in layer three to seven protocols, like ICMP tunneling, DNS tunneling for data exfiltration, those are very classic ones. But however, there is a problem with doing that because the infosec industry is actively monitoring the research in this area and they develop counter measures. So, and everything that gets to the internet, got to the IP world, we know that it's going to get cached somewhere. So, they find ways to block it or mitigate the impact of them. On the other side, mostly in academia, people who work from the engineering background, they have the mentality to build things from scratch. So they are so much fascinated building an optimal radio for covert communication. So the big of the focus has been on building a new radio physical layer and particularly they have to use low power for that because they want to stay stealth. So high power transmission is going to basically expose where the radios are. And there is a problem with that approach too, because those type of radios, because of the operational power they have, they do not work in an environment where one end is indoor, the other end is outdoor because the RF signal is going to get blocked with multiple trees and buildings, basically we call them clutter. So, when I put these things together, probably you've noticed by the areas that I've kind of blacked out, you see that, I said, okay, how about Mac layer? I didn't find anything in there from either side. So I come up with this idea, I said, okay, let's merge both mentalities here. How about we start finding a way to exploit the Mac layer standard of the wireless infrastructure that has been already deployed out there for all sort of covered communication. And this is basically the question that is driving this talk is all about. And definitely we're going to basically see that we're going to gain some advantages where the existing methods are failing. So also this talk is very related to the theme of this DEF CON this year. You cannot stop the signal and I want to call it like exploiting unstoppable signals if I'm going to put this in three words. So we are right now seeing that like basically right now we are kind of overwhelmed with signals from all the cellular towers and mobile operators and satellite in addition to like, you know, local area network like a Wi-Fi and Bluetooth and et cetera. So what makes those signals basically unstoppable? That why if you deploy Wi-Fi here basically the coverage sucks if we go outside the building but why the towers are up there. And that's the height. So they spend big money to put the antennas high up on towers and also recently some companies are flying them on satellite because the height will give you advantage a clear radio signal path to many users in a wide area. So moving forward how this new what is the basically if we're going to put it in a way to describe this whole thing that's going to apply to any of these type of technologies I would like to present this scenario this hypothetical scenario moving forward. So consider Trudy has intruded a secure air gap building with a programmable low power radio or software defined radio and would like to smuggle some messages to her counterpart Ricky which is sitting couple of miles away in an undisclosed place outdoor and of course there is no clear radio path between them to transmit signal and there isn't they cannot access the network in there to smuggle using the network protocols. However definitely they're going to be receiving signal from a cell site nearby cell tower and they can send and receive signals to it. So this talk is about what if Trudy finds a way to create a set of signals in the protocol standard that tower is operating so that it can send those low power uplink signals to the tower and the tower omnidirectionally broadcast it everywhere so that Ricky few miles away can decode those signals and basically figure out what signal Trudy was sending. So that way they can create a virtual communication channel between them. If I'm going to give an analogy for this to remember is like a Batman movie. So they didn't know where Batman is right so they were like reflecting the light of the sky to make it visible everywhere and that's what how we are exploiting the tower because it has a high power so they can broadcast the signal everywhere can be received everywhere around this coverage area pretty much. So I would like now talk about the example that I've discovered in LTM 5G but I'm sure there's going to be like this talk to motivate people to go after other wireless protocol but LTM 5G was kind of my bread and butter for a while and this is the the CVD code that we disclose with the GSMA. So talking about that I'm going to just brush up quickly on the protocol stack for the people who are coming from the wire line because this talk is going to also be motivating for them hopefully. So when we're talking about protocol stack they always like crank up from bottom to the top that's how my teachers used to explain it means that in every layer there is some initialization handshakes happen right way before it starts transferring data from the top layers. So when we're talking about Mac layer or layer 2 maybe the easiest example of that that everybody knows about is Ethernet so whenever you connect the Ethernet cable to a port on a switch right before the lights start breaking click green there is bunch of like synchronization and handshake messages get exchanged that nobody cares about. So essentially in this work we're going to show that how you can exploit the equivalent of those messages in LTM 5G. Boom. Big Mac. I'm glad that I got this after the before if this talk was before launch probably I would have lost half of audience right get hungry. So the things are a little bit convoluted when we're talking about the 5G and LTE standard because here I'm using the Mac layer or layer 2 in a most general sloppy way that you can imagine is whatever layer that hang there is IP traffic from the user devices. So I know this might be for people who are in this area this might be a little bit of abomination but that's fine. So whenever you turn on your phone and search up for a signal right the first thing that the phone does essentially is that it tries to find attached to a tower and then all the SIM card would stop kicking in and your phone starts exchanging some authentication messages with a lot of core servers in the core network of your operator. So that's because there are so many components in the mobile operator LTM 5G networks that's what you have all those delicious sub layers down there inside the Big Mac. So each of them does something in there and related to that. But that's not what our talk is going to be about today we are going to focus on the one layer we call it RRC. So that layer means that it just is a context that tracks the state of the UI whether you are connected or not connected. And the first thing that the UI does before connecting in here to the cell tower is that it does a random access. And there was some handshake happening down there that is local between the phone and the tower right before any other authenticated handshake happened and never get logged everywhere in the network and that's what we were trying to exploit here. So some quick terminology notes in here is that I probably mentioned it by accident UI user equipment. So in the context of cellular we call anything that interacts with the cell sites user equipment UI can have SIM card cannot have a SIM card whatever it is. And the fun story of the node B that comes from the essentially the GSM. So in LTE they call this cell tower call them E node B enhanced node B. And then in 5G they start calling them G node B. And I was talking to talk about this. And then he said what happened to the F node B. And I said maybe they didn't like to use it. But throughout this call I'm going to use F node B to refer to both of them. Both type of the E node PNG node B because this vulnerability applies to both of them. So this is a normal random access procedure which is very common in most wireless standards. So there are a set of like a preamble signal designated signals that all the towers or F node Bs are responding to waiting for new UIs to come and try to connect to them no matter they have a SIM card or doesn't have a SIM card whatever. So there are bunch of like initial plain text messages for messages that are exchanged before even the SIM card kicks in and authentication session happened. And that's actually where most of the attack vectors on the LTE have taken place so far. So message one is sends a basic random signal from a limited set and then F node B replies with more synchronization configuration parameters those are not the important ones. But then standard requires the phone to do a contention resolution. So what is contention resolution? It is where there is always a chance that two phones, two UIs at the same time try to pick up the same preamble signal and send one message one. But only one of them is going to make it to the tower. And so the tower has to have a way to tell other phones to back off and then only one of them they can succeed. So they don't kind of resolve the race condition. So the standard requires the phone to randomly pick a 40-bit value and embed it in there in the message three and send it to the tower. And the tower is going to respond immediately back and the phone checks what it receives with the tower. If message four, if the message four comes back, it's the same as message three that the UI has sent, sends that okay, I've been selected. If not, I have to back off. So that's the procedure that happens in there and happens very quickly and no encryption, nothing happens down there. So probably realize so far that how this thing can be exploited. That 40-bit message, right? So here is how the Trudy and Ricky are going to exploit that. So they decide what basically frequency and tower they want to use and what preamble signal that Trudy would like to use the first one. And then Ricky is passively listening to message two and message fours. But Trudy, instead of picking a random value, what it does, it encodes a message in there and puts a encoded message in there and sends up and the FNOTB immediately broadcasts everywhere. It's omnidirectional. And then it gets received and decoded by Ricky. So that's how they establish their virtual communication channel between each other. So they can repeat these in multiple attempts, in fact, because per standard they can, if Trudy has a larger message, can break it down to multiple 40-bit messages and repeat it. And this standard requires the phones to pick up a backup value if they want to successively attempt this. But it's up to the phone and phone at this stage of the random access. The tower even doesn't know where the phone is. So they cannot enforce anything. So we can say that Trudy always picks the minimum value, which is 10 milliseconds. And in LTE, that message one to message four normally picks 30 milliseconds. So the total throughput that they can establish to have is on average one kbps, which is comparable to what you can get in Lora as well for some sort of IoT communication. So the range-wise, this vulnerability is better to be used in the lower frequencies. So it existed now over a decade. It started with LTE release eight. So we can get almost around like a five miles, depending on a frequency range that you use. But it's more suitable for the frequency range as FR1, that's now defined in 5G2, below six gigahertz, because when 5G also introduced some limiter wave, but there is lots of RF magic and beamforming and stuff happened down there, that might is going to make it difficult for Ricci to decode signals. And another case that might actually make this more impactful is 5G non-terrestrial network standard that is in development right now. So that's kind of like flying the F-node bees over their head and creating a satellite mesh network up there. So that is going to increase the range for the spiral from maybe five miles to maybe 50 or 100 miles. So hopefully we have a remediation that we are proposing for that. So kind of summarizing it, why a spiral, why I call this a spiral, it's going to be clarified now quickly, is that essentially what compared this back to the existing covert combination techniques that I mentioned early on. So there is no network footprint here. So essentially these messages never get logged anywhere, it's just between the phone and the F-node bee. And there is no spectrum footprint either because the 3D phone is not going to be distinguishable from any other phone. So there is no way it can be like like triangulated and so it's just targeting Mac layer. Another thing is a low hardware complexity. So they can be like built with the SDRs are pointed down here below that you can see. So there are already open source libraries for LTE and 5G called SRSRAN and the SDRs, there are many companies making them in the range of like below $1000, you can buy them in a small form factor. So another thing is you don't need a large antenna. So compared to the ham radio or walkie talkie or any other devices, if they want to get 5 mile range, you need high power. But these are transmitted at the same power level which is 0.2 watts as the phones that are in our pockets. So that they can basically leave off the rechargeable batteries and harvest energy and that's what that's one of the reasons I call them Sparrow because they can't survive everywhere. And the last reason to call them Sparrow is once we disclose this to the mobile operator responsibly, they realize that this is not going to have much of an impact on the other user devices. So they said that categorizes as a kind of like not a very severe vulnerability. So we can, it's open for people to use it and nobody cares about them. Like Sparrow is the bird that nobody cares about them among the bird kingdom. But it is open and it's not, it's going to be basically open because there's a fault in the standard and blocking this would need some changes to the standard. So I will say that thing might take maybe three to five years to be even remediated. So now I will not turn the podium to my colleague Chalk to talk about our demo and some of the applications and what you can do with this, Sparrow. Thanks Reza. So I think you guys all know that but there's a bug going around recently and being able to do this sort of research can be get much more complicated when you work at a large company and there's a lot of stuff all over in different places in the universe of our company. So what you're looking at here is a demo lab set up in Italy by our peers that basically helped us walk through going from theory into concept to prove that this was actually going to work. At the bottom you see a tool that we call a UXM and that's a cell site emulator. It allows you to emulate a F node B or and then you can control all the messaging and signals with it when attaching say your iPhone for testing or you want to test the new LTE chipset or something, right? Above it we have the opposite tool which is we call uesim and that emulates ues connecting to a cell phone tower. So if you're Eric's in and you make a cell phone tower you're going to want to use that tool to emulate thousands of phones connecting to your tower and make sure that you can support it. But you can also put them both together to each other and test out theories on messing around with the RRC message connection requests, right? I think I mentioned this lab got set up in Italy that's because that's where the predominant effort for all that engineering is and it's a bit hard to get all this gear in one place to dedicate to doing something. So when we started working on a demo for this we quickly realized that we needed to rope in additional guys and we got our main man Befe over in Italy to record a quick video proven out that this works. So now you guys get treated to a little four minute vignette of Befe showing this and then we'll talk a little bit about what our current efforts are right now and trying to make this a lower cost sort of solution if I can find the mouse. I'm doing this live so I hope it works. In this video I am going to demonstrate proof of concept for that part of project. With this hermetic graphical user interface we configure UE on ELSU A that's with an IP address of 1048870 as a TX. Therefore we set the mode as a TX and the random access plan will ID 28 and the place the plain text message to be sniffed by the receiver UE is set to welcome to the DEF CONF. Similarly we have set the UE on ELSU B with an IP address of 10488157 as a RX. Therefore we set the mode to RX and the random access plan will ID 28. On the currently torques side the PRT script activated the 5G and standard load cell where the synchronization signal block is broadcasted via the EXIM platform with the periodicity of 20ms. If the master information block is decoded with success on both UE so the cells will get synced and in service if the system information block type 1 is decoded. Since both UE are in service in sync and IDLE we can connect the GUI to the Layer 3 test manager and verify if the CV is decoded and the cell should get in service. We can run the scenario from the RX side first now and from the TX side. It seems that the transmitted message is with success on from the TX side and let's verify if the receiver UE decoded the message successfully. So from the scenario logger here we are decoded that the message will come to the DEF conference. From the TX side it can be verified that the message 2 is decoded with validrar also on the RX side we can check. The message 2 is decoded with the validrar as of TXUE. This is the case we can also verify the message 3 is decoded with success first from the TX side. So here we can confirm that the UE contention resolution ID is decoded with success on the TX side and let's see also on the RX side. So the RX side message 3 is also decoded with success. So since we have implemented CRC decoding if the message is decoded we can see the message on the RX side. So if you can see the message is decoded successfully welcome to the DEF conference. Right. So that's a lot to take in. Right. But the reality is at the end of the day is we use that to prove out that this worked. There's a lot honestly going on in there. But that's how it goes. You basically saw one as a transmitter it sent messages. There were 40 bits so it was multiple ratch messages that were sent and then the other one decoded them sequentially and stitched them back together again. Which is pretty cool. So when we talk about some of the application scenarios that this can imply you've got sort of your good the bad and the ugly. The bad is clearly that you now have an overlay network where you can pass messages from one place to another effectively hiding in plain sight. Everyone's phone here is sending these messages not all the time but if you turned it on then back on it turned it off and back on again it would be beaming it out. So you can effectively now have you know a five mile radius of sending and triggering signals anywhere you want. This allows you to do all sorts of fun nefarious things if you start thinking more creatively. You can use it for command and control or you can use it for data exfiltration or you can even use it as a sort of a part of a supply chain attack where you bake in remote access commands into your phone and trigger them if you send the right set across the tower. However on the good side this is a rather interesting solution for say natural disaster failover scenarios being able to connect two parties together and get important messages across to them when the what's normally called the backhaul or core network data network fails. You still can actually make use of a cell phone tower now to pass messages between first responders or just do citizen notifications. And then finally for the mischief makers among us you can now make yourself your own little party channel. If you see down here in the lower ref this is a courtesy of I think his name's Scott on Twitter. I saw this device at Schmuckern was really cool. But you'll notice that he has a big giant antenna on there. It's called dirt simple communications and it's a custom RF setup that leverages lower range, lower range to communicate. Start talking about this and he's like wait a minute I don't even need an antenna really. I can just curl a little wire inside if I use it right. Same thing as you could also use this as a replacement for other IOT based protocols. And if you didn't mind following a file of the CFAA or wire fraud or anything else you could just use you know some service provider cell phone tower as your means of getting your IOT devices to talk to each other. And now I'm going to hand it back over to Reza again for the rest of the show. Alright so I would like to talk about a little bit of a range extension. We know that like we have a more mileage with these per watts compared to a lot of existing technologies but we don't have to stop there. Because when we talking about most areas there is not only one cellular tower. There are many cellular towers from different mobile operators so that Ricky and Trudit can basically exploit both of them to creating parallel communication channels so that way they can boost their throughput above 1k BPS if they want to. Or they can because this device is operating very low power on rechargeable batteries on solar power and they can deploy these what I call the relay networks. So these are acting like Ricky in one cell and Trudit in the other cell so receiving a message and relaying it in repeating the same process in another cell side so they can extend the range so you can of course there's going to be some more delay but nothing stops you to basically go with several hops to miles and miles and miles with this. So this was one of the areas that actually GSME had some questions so I put together this clarifying thing for people who are in the cellular and RF they're familiar with this map called a sector map so that shows that what every cell side what is their coverage area different color. So as you can see the relay nodes can be deployed at the basically overlap areas between multiple cell side so they can send them receive between multiple of them so you can have a mesh or you can relay message from one end to another end. So now I'm going to start talking about remediation I'm not sure if anybody here are interested in remediation so I know people might be excited to try this but before doing that I would like to present the general weakness model of there's going to be some paper I'm trying to publish on possibly an archive a little bit after the con that's going to have all the details but in case that people who would like to go after these in other wireless standards kind of put together these four conditions that will indicate that a wireless Mac layer protocol standard is vulnerable to similar techniques so that would require essentially to so that the tricky and truly can build a code book so their code book is a M basically is a set of messages uplink low-power messages and that is going to trigger another set of B broadcast messages from the cell side so here in case of LTE that what we discovered B and M are identical right because the tower is just rebroadcasting exactly the same thing but if some people want to do PhD on these they can go very fancy with math and find a way that how you can explore the many scenarios so the condition number one is the passive reception so basically the signal that gets broadcast has to be kind of omni there shouldn't be much out of voodoo stuff in there so it can be decoded everywhere another one is one-to-one relationship between this so that the receiving end when it receives one signal it can be almost sure that what was the original uplink signal that was transmitted from the code book the third one is the is a good to have and we have it in the example but it's not necessary is anonymous uplink so essentially the transmitter and doesn't have to associate with the network or disclose its identity to send the signals which is the case so that way it can stay stealth forever and the last one is stateless uplink which they can do it successively without violating the standard and we had all these four conditions in the simplest way satisfied with the example we just talked about so to remediation for this first we need to understand that what is happening here in the random process access procedure and what is the goal of CRI because it's a very common process is many wireless standards so the the whole purpose of the CRI as we may as I mentioned was that two phones simultaneously attempting and picking the same preamble signal so that one of the signals is going to be received but the tower has to basically tell one of them to back off and at that point there is no identity so it lets them to select their own identity and ping pong the tower and based on that basically figure out whether they should proceed or not to proceed so whatever remediation that we do it has to preserve the functionality of the CRI we don't want to create performance headaches for the normal users right and the culprit is not the uplink part message 3 is mostly message 4 so that's the message 4 that this broadcast goes everywhere so that's the message has to be protected so there are a couple of things basic remediation that I want to present here that do not work before I get to the one that works so one is that okay how about we make the use not to pick randomly like have it something like a MAC address that has been pre-configured or some ID fix ID unique that they can use every time well I think there are people that is still at DEFCON presenting calls on in the catching and stuff so there is a lot of privacy issues with that and these can turn into a basically a way to track users if they always pick the same CRI value because you can track them always based on the broadcast another one is the you know it be the start like a tracking and blocking days it's very hard because there is always a chance of like a false positive and you're blocking the RATCH attempts from the normal users so there is a cost associated with that so and another one is probably many people's favorite crypto so even if we use a crypto with assaulting on message 3 this is the operation that the F-node B does to produce message 4 so instead of replaying back hash it and send the hash but that is going to be a problem in there because there is no shared secret here so you have to ship the salt as well so that they compute essentially Ricky can basically create a rainbow table here and pre-compute the hash value for all the possible messages on their code book and it's still decoded so it's a little bit hard computationally but still it doesn't prevent it so what we really need to prevent is introducing error that's what wireless engineers always are fighting trying to create communication schemes that prevent error but here we are going to introduce error for Ricky and Trudy so they cannot communicate so what we do here is that we take the output of the salted hash function and of course there is a new basically salting techniques that have come up here I will discuss it in my paper called multiplication salting is for getting a good low collision probability with shorter strings because here we are talking about like a 4D to 48 bit strings and then start randomly erasing bits so basically the FNOT bit doesn't broadcast all the bits it randomly selects a set of bits and broadcast those but of course for the CRI to work with normal user this has to tell them that what bits it has selected so it has to ship also a bit mask indicating what bits are selected what bits got erased so the normal UEs probably going to be handling this they have basically they have the salt they have the bit mask so they can recompute the same thing and compare it and they can function as always but for Ricky it's going to be very difficult because to recover the messages to figure out what message it has transferred it they have to build a code book that once it passes through the salted hashing it has error correcting capabilities so I think that one is going to be a very hard problem practically to solve and that's the whole point we rely on because you cannot have a code book a rainbow table that you can control it to be error correcting for you so here I would like also to get some wrap up points here with Chuck with me Chuck you want to join me here some concluding bits here go ahead Chuck so just a few things to take away and I'm sort of echoing what Ian said this morning at her her talk really sort of bring in people with different perspective into your teams I'm an IP networking kind of guy low level layer protocols Mac as it came to me is like I think I got something here with Mac layer I'm like Mac you mean like ethernet on a switch like that's really boring and he's like no no it's over wireless so everyone gets to see them like oh right okay so that that's sort of where that idea sort of came from to begin with also utilized lateral thinking remember that like to get from point A to point Z you always have to go through points B through why and sometimes your box that you're concerned with navigating around might not even be the problem that you want to think outside of near around or whatever just you know look in a different direction we also really don't think that LTE and 5G are the only protocols that are going to be exposed to this type of vulnerability where we haven't looked at any others but there's always going to be some kind of contention resolution that has to occur between two nodes to agree to talk so we're going to start looking at other wireless protocols that also enable this and we encourage you do as well and the last one is just to bring your awareness that pretty much anyone now for a few thousand bucks can build their own 5G network legally and safe it's not technically unlicensed but you don't need to apply for a license it's called CBRS it's in a three and a half gigahertz spectrum and it's designed for basically private LTE and private 5G networks is very cool stuff we're beginning to play around with commodity SDRs ourselves and we're sort of in the process of trying to manipulate SRS ran in order to make this vulnerability work we didn't have enough time to get a proof of concept running here but that sort of brings the dollar cost value of that research way down for people that want to play around with this stuff and we're happy to answer any questions or collaborate on anything like that so here at the end I would like to basically share some concluding remarks and thank you here I have our contacts for both me and Chuck here and I would like to really thank give a big thanks to our people in our Milan office who worked on a demo very quickly in a short amount of time that we had for the CFP and also I would like to give a thank to ATI management or cool bus Steve McCrogory who basically kind of motivated me and supported me through these and of course of Chuck that has been really resourceful in getting the CFP and helping with that many aspect and coming up with applications he has a very great imaginations too and also IP program manager who basically we taught his hard work I was able to basically share talk about their remediation here and we are going to basically have a be available for questions here I was trying to basically hang out in the ham radio village a while but I will be around and also there's going to be a session I think a six and at five yes at five at the chill out room right behind here so I would be glad to be around here if you guys have any questions and thanks for attending our presentation and I'm really glad for joining Defcon my first time here so I'm probably going to be continuing being engaged in this community I really like what you guys are doing and I would like to learn more thank you