 I'm really excited about this talk. I have a little bit of background in uh, in GSM and so um, I hope you guys uh, really enjoy this. Uh, we have Campbell Murray, uh, Ann Buckley and um, what, James uh, uh, Koikowski here to talk about uh, GSM. We can hear everyone now. Please give them a warm welcome. Uh, good afternoon everyone. Um, thanks for having us first and foremost and thanks for the scotch. That was really, really good. Great way to start to talk off. Uh, so I'm just gonna take up the first kind of five to ten minutes of the talk today. I'm gonna give you a bit of a background into how we led up to sort of finding uh, some of the issues that we'll be presenting today. So that was a really strong scotch. Uh, and uh, and uh, a little bit of an overview uh, kind of like how uh, our methodology and how we actually um, arrived uh, at this point in time. Um, there's quite a few people. My name's Campbell Murray. I'm uh, I'm kind of a team lead globally for BlackBerry. Uh, but there's a lot of people involved in the team and I'm a real believer in the right person for the right job. I was making sure you've got the, the expertise there. Uh, the concepts behind what we're presenting today were actually originally thought up by Owen. Uh, Owen is our crypto guy. Uh, this guy's forgotten more about crypto than I will ever remember. Uh, we've got with us today also James Koikowski who's our hardware dude. Uh, not with us today sadly but also very important to the team effort in uh, making this presentation that happened was Bartek Piekarski uh, who's our software uh, expert. And there's a few other people that need to be mentioned as well. Uh, in our UK team is Anthony Goodyear uh, senior technical consultants as well. And uh, another one uh, a colleague of Owen's particularly called Tom Martin uh, who sadly couldn't make it today either. Uh, so there's quite a few people, quite a bit of background. Uh, a lot of expertise uh, went into several months of making this happen. Not just from a concept, a concept point of view, from purely looking at the crypto floors, looking at the actual algorithms and developing the concept, but to actually putting it all together. And there's some serious hardware behind it which we'll get to see later. Uh, so I'm only going to take up a few minutes of your time. Uh, I'm going to give you a brief intro to GSM. So uh, just so that everybody's kind of on a level footing, so that everybody, not everyone's a GSM expert although of course this is DEF CON, so I appreciate there's some really, really scarily good technical brains in the audience here. But just so that everyone's, you know, starting out in a fair place, I'll give you a very brief, high level overview of how GSM CONs work. Uh, Owen's then going to pick up with concept overview from a far more uh, deeply technical point of view. Uh, James is going to explain the test lab and all the really, really fun hardware uh, and the amount of money that we spend making this happen, which is just the best part of security research is uh, seeing those dollars going out the door. Uh, and then we'll have a general sort of uh, wrapping it up with a uh, conversation about uh, cellular security. So I'm going to give you a real rough, high level introduction to GSM. And the concept for uh, for GSM has been around since uh, late 80s. Uh, major improvement over the analogue mobile uh, phone system of course. Um, GSM started to be implemented in 90, between 1991 and 1995. And uh, out of all of the mobile phone standards which are several uh, is the first one to have really considered security in its uh, in its actual design. Uh, key features, key functions of GSM which you need to be aware of are because TDMA uh, time division uh, multiple access um, in the way that GSM assigns time slots into communications. Uh, GSM also introduced concept of the SIM uh, subscriber identity module which is completely different to CDMA uh, which is still in use. Now I did some googling earlier and of course Google's like 100% accurate all the time, every time. And this claims that CDMA is still in use in 47% of communications in North America on mobile phones which I find kind of hard to believe. But you know, a Google, right? It's never wrong. Um, so GSM has introduced for us time slots. It's introduced to us uh, individual subscriber identity modules as well. Uh, but it does have several design issues in that there are multiple ciphers that could be used in GSM. Uh, but the prevalent ones that are in use today only support key sizes are less than 64 bits. And uh, the encrypted data contains a redundancy for signal cleaning which I will go into far more detail later. So looking at the time slot concept around um, GSM, I'll speak a little bit about how the actual cipher is generated in the next slide. But uh, GSM introduction on time slots uh, there are eight time slots available uh, in the frame. Uh, when your mobile phone connects to a base station it's negotiating time slot being one of the factors used in generating the cipher key uh, which of course produced in the cipher text. In the GSM ecosystem uh, frames uh, across the base station are put into multi frames and super frames uh, and overriding belong into a hyper frame uh, which has a total time lifespan of just under three and a half hours. So all time slots after three and a half hours are reset and uh, begin again. So time slots within that hyper frame cannot exist beyond that uh, beyond that period of time. The actual cipher itself is based on symmetric encryption, which of course means that there is a shared key uh, between handset and base station. Uh, the actual cipher stream itself is made up uh, sorry the cipher itself, the A5 cipher itself is made up of uh, three key components. Uh, the KC value is produced by KI and RAND value in the SIM card itself. Hence why we mentioned GSM introducing SIMs earlier on. That's one of the values. Uh, the cipher stream element is built up of four bursts of 114 bits each and contains a total of 228 bits for the up and down stream. Uh, the frame number, again as we looked at time slots just a few minutes ago, again all of this being relevant from a very very high level top down view of actually how GSM uh, works as a mechanism also provides uh, an element of entropy into producing the cipher. Uh, currently there are two main ciphers in use, A51 and A53. Uh, there is A54 which does allow 128 bits but it's only in use in very very specific locations and by some uh, very particular actual mobile phone cellular operators. So that whilst uh, obviously a much uh, more daunting proposition for examining the crypto and A54. It's not something that we're actually going to give too much prevalence to today because it is, is quite an issue still. Uh, worth noting that A52 was disallowed uh, sometime in 2000s as a paper by uh, barkham, thank you, uh, Byam and Keller uh, along the GSMA who released a paper in 2006 which discounted the use of uh, A52 encryption. Uh, of course in this guidance for encryption uh, currently and a guidance often being guidance uh, and not always practically implemented is calling for 112 bit security strength uh, based on standards today. So from a very very basic introduction to GSM, what I'm going to do now is hand you over to Owen Buckley who's going to uh, start looking at the concept from the design flaws that uh, been identified in the GSM implementation standard. So please, Owen. Thanks Loc Campbell. So in this section we'll uh, go over from a, from a high level the concept of the, of the attack and uh, what we're going to be focusing in on. So as Campbell mentioned earlier, one of the features that GSM came in, comes in with for A51 and A53 is a small key size up to 64 bits in length and um, yeah with the recommendations from, from this uh, with 112 bit key length, you can see there's a large gap there so uh, that should all, already be of concern. Um, a second um, feature in GSM is uh, the, the use of air control coding. So um, air control coding, it adds redundancy to a packet that's transmitted. It actually has a very good use in wireless communication. When you're transmitting a packet across a channel, there's fading, there's interference from other cells, there's thermal noise in the, in the RF received chain. So it's a very noisy single signal that's received in the baseband. So uh, we've gone through, we add air control coding in order to clean up the signal, to figure out what is the correct message. Now what, what has happened in GSM is they actually perform, perform the air control coding before the encryption. So as we should see on the slide here, first you get your message, second you put it through the air control coding which adds in redundancy and then you carry out the encryption and that's what we're going to make use of because once you have redundancy in a message um, if, if you're in the crypto world you know that's bad, that can be used to figure out what the key is and that's exactly what we're going to show today. Um, we'll mention it again later, but in later standards in like in 3G, 4G, 5G uh, and in most wireless standards what they do is actually carry out the encryption of the message before air control coding. So that's the issue that we're going to be making use of today. Um, yeah. So as, as we say on the slide here, the air control coding is usually used to get rid of the noise on the channel and we're going to be using that to identify the cipher stream and therefore the key that's been used to carry out the encryption. Getting into a little bit more depth, um, in GSM just because of the time that GSM was created in the late 80s or standardized in the late 80s, um, the, the air control code that was used then was the convolutional code. So that's what we're going to be using today. Um, the, in general, uh, an attack isn't really, uh, focused on the convolutional code. Um, if there was any other air control code, um, their in principle should be an approach to use that in from that redundancy that's in the message. Um, what we're going to be doing is we're going to be, uh, capturing the encrypted air control code word that's transmitted across the air. We're going to capture it in a, um, we're going to capture it using an SDR. We're going to do a little bit of, uh, mathematical computation using the characteristics of the air control code which happens to be a convolutional code. And we're going to figure out an indicator. So we're going to use the term indicator a lot. What that is, is, uh, I, I speaking to a pen tester who used a very good phrase, it's a fingerprint for the key. So our indicator will be, uh, the fingerprint for the key that's used for the encryption. Um, and, uh, what will, uh, in principle, our overview of the tack is we'll use that fingerprint to look up a rainbow table to identify what, which, uh, key is being used for the encryption. So specifically in, in our demonstration which was shown a little bit, we're going to go after the Satch channel because it's well known and, um, it's, it's quite regular and it's something we, we, uh, can easily find. Uh, it just makes the demonstration very, very easy. Um, the nice thing about Satch is once you compromise the Satch channel to control channel, um, you also get the key for voice, the same key is used for both cases. And the Satch stands for slow associated control channel. And when you go into a cell, it's used for, it's got several uses. One of them is, uh, to give you information about neighbor cells. Um, so you can go and take measurements on them. Uh, one key feature of, um, using this redundancy in the message is art, or this attack will work for any message on a Satch channel. We don't care what the message is. Uh, we will just be using the redundancy that's added in there to compute the indicator. So, it's not a plain text attack at all. Uh, we'll be just using the party bits that come from the air control code to help us figure out what that indicator is. And it's a great freedom. Uh, so in the past, um, I think Satch has, um, there's only a few messages which are transmitted on the Satch channel. Even if they were randomized, we wouldn't care. We're using the air control code properties. And that's all we need. So, um, this slide, it's getting a bit more down into the details. Um, I'll start off by saying, what I want out of this slide is just to give you, give you an idea of the complexity of, um, computing the indicator. We don't have to understand every detail of this slide. Um, so air control coding and convolutional codes. For the Satch channel, we use what's called a rate one half code. So the rate one half mean, what rate one half means is we take one, um, stream of message input into the air control code and we get two streams out. We get the upper stream, which is called the party one stream and a lower stream, which is called the party two stream. Those streams are then, um, encrypted using the A51 or A53 or A54 cipher. Um, so what's transmitted over the air is the encrypted party one or party two stream, which is shown as by those red arrows. That is what we capture. So, um, just talk, talk a little bit about the mechanics of what goes on with the air control coding itself. The upper stream, uh, that's formed by what's called, um, by using what's called a generator polynomial. And I put that down here as G1. And the lower stream is, is, um, is formed by what's called a, um, a second generator polynomial, which we call G2. These generator poly, polynomials, they're defined by five bits. Okay. Uh, we don't have to go into too many details about the generator polynomials, but really all you're doing is you're putting your message through, uh, a five element register, and then you're tapping off these registers and XORing them together. So for the lower, the G2, um, since it's got 1 1 0 1 1, it means you're taking the first, second, fourth and fifth register, seeing what values of the message are in there, and XORing them together, and that will produce your lower party two stream. Um, I'm sure it's described there in Wikipedia. Just know that it's a register that, that you're just convolving with the, uh, input message stream. And again, as, as we mentioned earlier, then that's put through, um, a five, a five encryption algorithm. What we are gonna do to, to use our, uh, to, to compute our indicator is we're gonna carry out something called a deconvolution. So what we're gonna decon, deconvolve the stream with is the exact same generator polynomials. So, um, for example, for the upper stream, it's gonna, it's of 228 bits long. We're gonna carry out, we're gonna get our five, um, generator polynomial bits and just, uh, deconvolve it in, as, like, as, as a window all the way along the stream to get a 224 bit output. And that 224 bit output we call Q1. And we do, we perform a similar operation, um, on the party two stream and we exo, or them together. Um, the mathematics behind this is given in the appendix. Um, but for, for our purposes, all we need to know here is we're carrying out a deconvolution operation on the top stream, a deconvolution operation on the bottom. And then we're gonna exor the two streams together. As far as how complex that is, um, in the simulations we've run on our accelerated GPUs, um, it takes about half the complexity of running, uh, a cipher to carry out these two deconvolutions and computing our indicator. So it's not a very, very, um, complex action. It can be something, it's a, it's half the complexity of actually running the ciphers themselves. So it's, it's something very feasible. So getting into the indicator itself, um, the indicator we produce is 224 bits long, quite a long indicator. Um, to compute it we need to capture the full four bursts of a satch message. Uh, we have to go through the full process of deinterleaving that, demodulating that, um, and then forming an actual, getting it back into the state of a convolutional code word. Um, the indicator we compute is fully determined by the convolutional code and the cipher stream that's encrypting, uh, the, the, the satch message. The indicator that we, we get is 224 bits long. And you can imagine if we're getting an indicator that's 224 bits long and we're trying to use that to indicate our 64 bit key, we got a lot of redundancy there that's left. We only need 60, a 64 bit indicator. So what we're actually going to do in the demonstration is just take the first 64 bits and use that in our, uh, mini rainbow table that we've got set up. Okay? So next section is James. Alright, so, uh, in this section we're just going to go over what our current lab setup is. Uh, so we actually went through a couple different evolutions of lab setups. Uh, so this first slide just goes over the hardware we're using. Uh, and this just represents, uh, what is currently in the lab. Uh, so right now, uh, we're using multiple different, uh, telephone devices or cellular devices. And the only reason we save various unlocked cellular devices here is that we don't want to target a specific manufacturer because obviously this is a problem with the GSM, uh, standard as a whole and not an individual manufacturer of devices. Uh, additionally for this to work, uh, since we were using open BTS, uh, we were, uh, in need of 2G compliant, uh, programmable SIM cards. Uh, so we ended up picking up a couple of those, uh, that support the Comp 128 v1 and Comp 21, uh, Comp 128 v2, uh, algorithms for generating the, uh, the KC stream, uh, which is required for encryption in A51 and A53. Uh, additionally, uh, to program those, obviously we needed, uh, some hardware to do the, uh, the actual right. Uh, additionally, uh, there we, we ended up using an SDR, uh, multiple SDRs in this case. Uh, so for our actual BTS base station, uh, we used an edis research N210, uh, so pretty hefty piece of machinery there. Uh, and that's running with a WBX daughter board on that as well. Uh, to stabilize the actual clock frequency, uh, we ended up using an external mini GPS reference clock, uh, just to give us a nice 10 megahertz reference. Uh, for our actual captures, I mean, we ended up just using a standard, uh, Air Spy SDR mini. Uh, we did have some other, uh, tools available to us such as, uh, HackRF, you know, BladeRF X40, uh, and some additional things, but, uh, there were a bit overkill for what we actually needed. You can do this with a $15, uh, RTL SDR dongle if you needed to. And then just, uh, various tuned antennas for the 900 megahertz frequency needed in GSM. Uh, moving onto our software side. Uh, so from the software, uh, we actually started out with the range networks open BTS 5.0, uh, which is open source, uh, on the, uh, the range networks GitHub. Uh, but we ended up upgrading to their actual commercial version because it was a bit more stable. Uh, so we ended up getting their software defined mobile networking suite 7.0.4, which is the, the current evolution that's available from them. Uh, for the actual programming of the SIM cards, uh, we just used the standard, uh, PiSIM tool, uh, to do the, uh, setup of our, our MZs and injection of our KI values, uh, into the actual cards themselves. Uh, for the actual captures, uh, from our second device, uh, we had a Cali machine setup using GNU radio, uh, and the GR GSM, uh, tool suite that's available through the, uh, Osmo column, uh, tool sets. And then, uh, from a third laptop that, uh, Owen was running, uh, we had, uh, Octave running. Uh, it's like a modified version of Matlab that allows us to go through and then do the calculations of the indicator. And then for the actual lab configuration itself, so all our testing was actually done under RF isolation. So this is actually a picture of one of our isolation chambers up in our Waterloo office in Canada. Uh, so we ended up going into a nice RF shield room and doing all our stuff there. So that way we weren't affecting any actual cell phone devices in the, uh, local area. Uh, another note here, uh, as Owen mentioned earlier, uh, we ended up using the A53 cipher itself as the, uh, the cipher that we were testing against. And we enabled the support for the Satch random neighbor, uh, protections as well as random padding. So that way we can prove out and show that, you know, this really is not a plain text attack. We're actually looking at, uh, just the message itself when we don't care what the bits are that are actually being transmitted. And actually before we talk about this one, I'll actually jump over to, uh, a video demo of, well, actually let's see if it'll let me jump over. We've got a quick video here that goes through the actual capture process. So the first thing that you'll see come up on the screen is actually a, uh, visual dashboard that's available within the software defined mobile networking suite. Uh, so all this is showing is just the, the signal levels available, RSSI values and things of that net nature, uh, from the devices that are available on the network. Uh, so what you're seeing here right now is the first, uh, device starting to communicate in. And then, uh, we'll see another, uh, an actual IMZ, uh, connect to the, uh, the system here in a second. And this will actually be the start of our, our first phone call that we'll, we'll be capturing. Uh, and as, as we continue to capture here, you'll see a second IMZ pop up for that second telephone, uh, that's on that same network. Uh, and in a moment here, you'll see, uh, an overlay, uh, pop up. And in this overlay, this is, uh, our second machine actually going through on Cali using GRGSM, uh, with the capture tool, just to capture the, uh, the packets, uh, and record them out to a offline file for, uh, additional processing. Uh, and this is just in verbose mode so you can see all the bits running through the screen. Uh, it, you don't necessarily need to do this in real time, real life. It, uh, it's just a lot of garbage across the screen, right? So. And this will go on for about another 30 seconds here as the, uh, the call, uh, continues. And then we'll see the, uh, the hang up action occur as the, uh, the signal tails off there on the other side of the screen. A little bit longer than I remember. Yeah, so our call should be hanging up there. We just saw the signal drop and, uh, should tail off. Yep. And that's the, the end of our transmission on those, uh, traffic channels. Uh, so now what's happening here is we've actually taken that file and sent it over to, uh, BarTech. Uh, so BarTech is actually going to do and run through the signal processing. So this is using a, a custom flow graph, uh, with the GRGSM, uh, blocks within, uh, GNU radio. So he added his own FFT in here and also a burst printer. So what we're doing is we're actually looking only for Satch messages, uh, explicitly. And then printing those Satch messages out, uh, to both, uh, Wireshark for output over the local host. And then to a, uh, text file that we can then parse and pull out the extracted burst that we need. So here, uh, he's highlighting the time slots that are actually used for the call. So you can see the two separate calls here, uh, running on time slot six and time slot seven. And then we're just going to open up that file here. So this is the actual burst messages in that text file that's generated through the, uh, the custom flow graph he generated. And we're going to select a, uh, full set of four bursts for time slot seven. And then copy that into a separate file here. And then we're going to do the same thing for the, uh, time slot six. So we're going to scroll down through the, the section here and grab that last four, uh, complete messages for, uh, the time slot six. And again, we're just dropping that into the, uh, a separate text file. And now this text file is being sent over to, uh, Owen, that he's going to run through his, uh, tool, uh, with this command satch, uh, satch crack. And right here what's happening is it's, uh, now analyzing that indicator. Uh, so we see the, the, uh, full indicator that's generated. And we determine our key, uh, from that indicator. And then go back and validate that the key that we, we actually get here is the key we expect, uh, by then calculating another message using that key and validating that the signatures are both, uh, identical. Yeah, so that's the real magic part right there. And then we jump into actually extracting audio. So this is probably stuff that you've seen before, uh, using the same tools with GRGSM. Uh, but what we're really doing here is now just going back, uh, through GRGSM, looking at the packets, uh, finding the, uh, point where the calls are initiated. Uh, and then identifying what, uh, Cypher was actually being used. Uh, so in this case we'll see, uh, in that first message here, that we're using the A53 Cypher. So this is where it's at the, uh, the Cypher, uh, mode connection command here. Uh, so in this second command now what we're doing is we're telling it, uh, we know that, uh, we're using the, uh, Cypher, uh, mode A53. Uh, we're going to select our, uh, calculated key, uh, pass that to the tool. And this is going to allow us to decrypt the Satch messages, uh, that we, uh, were unable to see previously. Uh, so now we're looking back through that same set of commands, verifying that we can actually see the decrypted Satch messages. Uh, so we're seeing that we're using, uh, TCH, uh, TCH full, full rate for the audio. Uh, and what the time slot was for that specific call, uh, in the last command here that we run is now, uh, changing the mode for the, uh, decoder to TCH full rate. And then decoding that actual speech out to a output file. And then we watch this through, uh, Wireshark because there is, um, uh, problems with the GRGSM tool now where it does tend to hang when doing a decryption of the, uh, audio and outputting it to a speech file. Uh, so what we end up doing is just, uh, following the traffic until we see the actual hang up, uh, and release command. And then killing our, uh, our session in Cali. And then, uh, shortly after this, what you'll hear, uh, is the audio clip that was, uh, decoded from this, uh, this capture. Uh, and it's just cleaned up with audacity and, uh, thrown into an MP3 file. If our audio is working. Hello. Hey. Hey, this is Michael. How you doing? I was off and except for these zombies. Do you see all the zombies around? Yeah. Good gosh. They're everywhere. Yeah. Somebody even has all, um, a blonde hair. We don't have blonde hair, man. I think those are the scary ones. Those are the real scary ones. They even go laughing. Laughing blonde hair and zombies. Who could imagine? So, so what are we going to do about them, though? I have a question. I don't know. Maybe we'll have to change their hair color. I hear some of them might be coming up to DEFCON. So hopefully we can change their hair to blue by then. That's a good idea. It all works. So whoever sees the blue hair zombie up on stage at DEFCON gets, gets surprised after the talk. Absolutely. Yeah. So obviously that was them talking about me. Thanks. Yeah. So that, that call was actually about two weeks ago in our Illinois office with a gentleman by the name of Tom Martin and that we captured just for this demo. And then we'll jump back over to our slide where here. So this is that, that flow graph I mentioned earlier that we saw in the demo. So this is just the modified flow that we ended up using, which is just a combination of the GRGSM blocks and an output burst printer that allows us to take all seven time slots, sorry, eight time slots and then output them to our text file in raw format. And from here I'm going to pass it back to Owen. Thank you. So I just actually want to speak a little bit more about the demo we just did. So we did produce two indicators there. The first one was of the encrypted such message. And in the second one, the way we generated, we got the second indicator, we took the encryption stream itself without any message. And then we performed the same deconvolution operations. And of course, we got the same indicator showing that the message does not matter. We still end up with the same indicator just to clarify that. So regarding this attack itself, the only reason why it's one, one of the issues why it's possible is due to the small key size. It's actually a bit unfair on GRGSM. I understand they were during the standardization process. They were required due to export control regulations to have key sizes of maximum 64 bits, but it ended up in the standard. And the organization was caught between a rock and hard place. And regarding the rainbow table computation, we've actually implemented the bones or a proof of concept for computing the rainbow table. And it would require a significant amount of effort. So this isn't something that one person could do. It would require at least a mid level organization if not a large level organization. So we do want to emphasize that. But in what we did in the demo, it was enough, we would produce a rainbow table enough to at least show the concept. Regarding cellular security itself, yeah, one of the reasons why this is all possible again is a small key size. In GRGSM today, phones support A51, A53 and A54. I understand, we understand A54 is deployed in some areas of the world. But many other areas continue to use the 64 bit key size, which again, is much less than what NIST guidance on what would be what should be used 112 bit security for today. And then the second issue which we've shown here is ciphering is performed after control coding. Without that, we don't again don't get our redundancy that we can go and crunch those bits together, which will provide us the indicator to choose the key. And for just like with the demo, any test that we've done has been in a lab environment. We haven't gone out there and tested on a real network for one thing. I like my freedom. I want to have a few beers after this and not spend time in jail. So, there you go. What we're showing today is actually just one of the several attacks that have been shown on GRGSM. Almost 10 years ago, Carsten Nol showed how to attack phone privacy using plain text. There was a paper that Campbell referred to earlier by Barken et al. in 2006, which also used error control code redundancy to figure out what the key was. And then what receives a lot of press is the false space station attacks. So we've all heard about sting rays and stuff like that. So this is just like another issue that's there against GRGSM. And I don't want to knock GRGSM. GRGSM is a great standard. It really brought mobile telephony, digital telephony to the world. But you live and learn. It's a 30 year old standard. I mean, it's easy to complain in hindsight, right? But the fact is there. It's using a small key size. And the cyphering is performed after error control coding is added. So beyond GRGSM into 3G and 4G and 5G, in those later standards, error control coding was applied after encryption, like it should be, right? So the message should be, I mean, ideally, be totally random. So there shouldn't be any redundancy in there, which you can use. And also the key sizes that they support when performing encryption are at least 128 bits long. So those two factors together prevent any concern like we're showing today. Additionally, the industry is very proactive. They are constantly trying to secure the seller industry. They have a study item ongoing in SA3, one of the three GPP working groups, on looking at security enhancements of fall space stations. So they are actively working and trying to protect us all. So I don't want to knock their efforts. And we're talking with the GSMA organization, and they're being very proactive on mitigations against what we're showing here as well today. So, you know, we do think there's good work going on there. And I think that is it. So thank you all for your attention. We'll be outside.