WEBVTT 1 00:00:00.080 --> 00:00:02.879 Welcome curious minds to another deep dive. Today. 2 00:00:02.919 --> 00:00:06.679 We're plunging into a topic that it touches nearly every 3 00:00:06.759 --> 00:00:11.560 aspect of our modern lives, Mobile telecommunication security. We're talking 4 00:00:11.560 --> 00:00:15.039 about that invisible shield, the one that protects your calls, 5 00:00:15.039 --> 00:00:17.440 your texts, your data as you move through the world. 6 00:00:17.600 --> 00:00:19.600 It really is, and it's a field that has evolved 7 00:00:19.719 --> 00:00:22.399 so dramatically over the decades. It's kind of driven by 8 00:00:22.480 --> 00:00:24.960 this constant cat and mouse game, isn't it, between the 9 00:00:24.960 --> 00:00:28.960 people building the systems and those trying to compromise them. 10 00:00:28.960 --> 00:00:32.359 We're going to explore that fascinating journey today, how mobile 11 00:00:32.399 --> 00:00:38.280 security went from well, almost non existent to incredibly sophisticated systems. 12 00:00:37.920 --> 00:00:39.439 We rely on now exactly. 13 00:00:39.640 --> 00:00:42.359 And our mission for this deep dive, crafted just for you, 14 00:00:42.799 --> 00:00:46.200 is to unpack a stack of comprehensive research. We've got 15 00:00:46.200 --> 00:00:49.399 the second edition of LTE Security by forstburg Horn and 16 00:00:49.439 --> 00:00:52.280 Dietrich here, among other sources. We want to pull out 17 00:00:52.320 --> 00:00:55.280 the most critical insights, maybe some surprising facts, those real 18 00:00:55.359 --> 00:00:58.520 aha moments, so you'll understand not just what these systems are, 19 00:00:58.679 --> 00:01:01.280 but crucially why they're built the way they are and 20 00:01:01.320 --> 00:01:03.960 what it all means for your daily life. 21 00:01:03.840 --> 00:01:08.680 Right well, trace that evolution starting from the early days 22 00:01:08.719 --> 00:01:13.359 of analog mobile communication, then through the groundbreaking advancements of 23 00:01:13.519 --> 00:01:16.439 two G, three G right up to the cutting edge 24 00:01:16.480 --> 00:01:20.159 security of today's four G LTE and the broader evolved 25 00:01:20.200 --> 00:01:23.599 Packet system, or EPs as it's known. And we'll even 26 00:01:23.719 --> 00:01:26.680 touch on some specialized areas things people don't often think about, 27 00:01:26.719 --> 00:01:29.920 like home base stations and machine type communications. They bring 28 00:01:29.959 --> 00:01:32.439 their own unique security challenges. 29 00:01:32.599 --> 00:01:34.560 Okay, So if you've ever wondered how your phone actually 30 00:01:34.640 --> 00:01:37.840 stays secure or what encryption really means when you're just 31 00:01:37.959 --> 00:01:40.159 using your phone, this is the deep dive for you. 32 00:01:40.239 --> 00:01:43.200 Let's unpack this all right, so really appreciate where we 33 00:01:43.200 --> 00:01:44.680 are today. We probably need to look back. 34 00:01:44.519 --> 00:01:45.040 A bit, don't we. 35 00:01:45.120 --> 00:01:47.400 Can you maybe set the scene. What were things like 36 00:01:47.519 --> 00:01:50.400 in the say, the early to mid nineteen eighties in 37 00:01:50.439 --> 00:01:52.920 Europe when mobile phones were just starting to appear. 38 00:01:53.120 --> 00:01:56.640 Absolutely yeah, imagine that time. Mobile phones were well a 39 00:01:56.719 --> 00:01:59.799 real novelty and these were analog systems. All the research 40 00:01:59.840 --> 00:02:02.920 we looked at pains a really clear picture, basically a 41 00:02:02.959 --> 00:02:05.280 total accents of adequate security features. 42 00:02:06.560 --> 00:02:08.639 What's kind of striking is just how easy it was 43 00:02:08.680 --> 00:02:11.560 for calls to be eavesdropped on right over the air, 44 00:02:12.159 --> 00:02:16.080 often with you know, relatively inexpensive devices anyone could get. 45 00:02:16.199 --> 00:02:18.879 Oh it's honestly hard to imagine that now. But you 46 00:02:18.919 --> 00:02:21.520 mentioned something before a well known example of this vulnerability. 47 00:02:21.560 --> 00:02:24.639 Oh yes, a very vivid one actually from that era, 48 00:02:25.120 --> 00:02:28.719 the infamous Squidgy takes. These were recorded private mobile calls 49 00:02:29.240 --> 00:02:31.759 between members of the British royal family and they were 50 00:02:31.759 --> 00:02:34.199 widely publicized. This wasn't just some technical issue. It was 51 00:02:34.199 --> 00:02:37.560 a huge privacy invasion and it really really drove home 52 00:02:37.599 --> 00:02:40.879 the urgency for better security for the operators and their customers. 53 00:02:40.879 --> 00:02:43.199 The problem wasn't just theoretical anymore. It was you know, 54 00:02:43.240 --> 00:02:44.120 front page news. 55 00:02:44.560 --> 00:02:49.159 Okay, so the demand for better security was absolutely clear, undeniable. 56 00:02:49.319 --> 00:02:52.280 This must have set the stage then for a pretty 57 00:02:52.280 --> 00:02:56.520 significant transformation in mobile tech. What was that first big leap? 58 00:02:56.560 --> 00:02:59.879 How did they start tackling these frankly huge security issues. 59 00:03:00.080 --> 00:03:02.800 Well, that takes us right into the digital revolution with 60 00:03:02.879 --> 00:03:06.680 the arrival of the Global System for Mobile Communications or GSM. 61 00:03:06.759 --> 00:03:08.800 Most people know it as two g This was the 62 00:03:08.800 --> 00:03:12.039 early nineteen nineties and it was a true game changer 63 00:03:12.159 --> 00:03:14.080 because it was designed from the get go as a 64 00:03:14.199 --> 00:03:19.680 digital standard that inherently offered a much better foundation for security. 65 00:03:19.360 --> 00:03:22.479 Right digital And what were the sort of foundational security 66 00:03:22.479 --> 00:03:25.520 innovations that GSM brought in? How did it directly tackle 67 00:03:25.599 --> 00:03:27.960 those privacy problems we saw with the analog phones. 68 00:03:28.120 --> 00:03:32.039 GSM was groundbreaking. It introduced two main pillars really to 69 00:03:32.120 --> 00:03:35.719 address those early weaknesses. First, encryption on the air interface, 70 00:03:36.120 --> 00:03:40.439 finally protecting user traffic, especially voice calls, from basic eavesdropping. 71 00:03:40.800 --> 00:03:45.560 And second, just as critical, was authentication. Robust authentication. Network 72 00:03:45.560 --> 00:03:49.000 operators could finally verify their customers individually every time they 73 00:03:49.000 --> 00:03:49.719 tried to connect. 74 00:03:50.000 --> 00:03:53.199 Okay, authentication is obviously key, but how does that actually 75 00:03:53.199 --> 00:03:56.280 work in practice? How does the network know it's really 76 00:03:56.319 --> 00:03:58.599 you calling and not someone pretending to be you. 77 00:03:58.879 --> 00:04:02.520 It works using this really clever challenge response system. You 78 00:04:02.520 --> 00:04:06.280 could call it a kind of secret handshake. Your phone 79 00:04:06.319 --> 00:04:09.840 has a simcard, right, a subscriber identity module. Inside that 80 00:04:09.960 --> 00:04:13.520 SIM is your unique ID, the IMSI International Mobile Subscriber 81 00:04:13.560 --> 00:04:16.920 Identity and crucially, a secret one hundred and twenty eight 82 00:04:17.000 --> 00:04:20.800 bit key. It's called key. Now. This key is absolutely 83 00:04:20.839 --> 00:04:23.079 vital because it never leaves your simcard or the network 84 00:04:23.120 --> 00:04:26.959 secure database the authentication center or AUC. So when you 85 00:04:27.000 --> 00:04:29.680 try to connect, the network sends a random string a 86 00:04:29.759 --> 00:04:32.480 challenge to your phone. Your sim then uses a special 87 00:04:32.560 --> 00:04:35.319 one way function. Think of it like a mathematical blender, 88 00:04:35.399 --> 00:04:38.199 easy to mix things up, but basically impossible to unmixed by. 89 00:04:38.519 --> 00:04:41.240 It combines that random challenge with your secret key and 90 00:04:41.279 --> 00:04:45.120 produces a unique signed response or SRES. That SRAS gets 91 00:04:45.120 --> 00:04:47.000 sent back to the network If it matches what the 92 00:04:47.040 --> 00:04:50.040 network calculated using its copy of your key. Boom, you're in. 93 00:04:50.120 --> 00:04:50.920 You're authenticated. 94 00:04:51.160 --> 00:04:54.639 Okay, so it proves it's you without ever actually sending 95 00:04:54.680 --> 00:04:57.959 that secret key over the air. Yeah, that's that's brilliant. 96 00:04:58.279 --> 00:05:01.639 And you mentioned encryption two detecting the calls. How does 97 00:05:01.720 --> 00:05:03.600 that happen? Is it like a separate thing from the 98 00:05:03.639 --> 00:05:05.079 authentication No, it. 99 00:05:05.040 --> 00:05:07.959 Happens almost at the same time, during that very same 100 00:05:08.120 --> 00:05:12.040 authentication process. Another one way function uses the same challenge 101 00:05:12.040 --> 00:05:15.519 and your key to generate a temporary session key. This 102 00:05:15.560 --> 00:05:19.480 one's called KASIK. This kkey, usually sixty four or maybe 103 00:05:19.519 --> 00:05:21.879 one hundred and twenty eight bits depending on the algorithm, 104 00:05:22.279 --> 00:05:25.920 is then used specifically for encrypting all your communication over 105 00:05:25.920 --> 00:05:29.399 the radio link using algorithms like a fifty one or 106 00:05:29.399 --> 00:05:31.920 maybe a fifty three. And this is a really crucial 107 00:05:31.959 --> 00:05:35.879 concept in crypto. You limit the exposure of that permanent key. 108 00:05:35.920 --> 00:05:38.360 You're constantly deriving these temporary session keys. So even if 109 00:05:38.399 --> 00:05:41.120 an attacker somehow managed to break single session key, they 110 00:05:41.160 --> 00:05:43.079 don't get your master key. They can't unlock all your 111 00:05:43.120 --> 00:05:45.680 past or future calls. It's like changing the lock for 112 00:05:45.720 --> 00:05:47.439 every package you sent, even though you keep the same 113 00:05:47.480 --> 00:05:48.399 master key for your house. 114 00:05:48.560 --> 00:05:48.720 Right. 115 00:05:48.720 --> 00:05:51.560 Okay, that makes perfect sense for protecting the data. But 116 00:05:51.639 --> 00:05:54.759 what about your identity itself? Is your permanent IMSI just 117 00:05:54.959 --> 00:05:57.800 broadcast all the time for anyone to potentially grab a 118 00:05:58.000 --> 00:05:58.600 good question? 119 00:05:58.879 --> 00:06:03.279 Thankfully no. GSM also introduced something called temporary Mobile Subscriber 120 00:06:03.319 --> 00:06:07.079 Identities or TMS size. These are temporary IDs used on 121 00:06:07.120 --> 00:06:10.439 the radio interface instead of your permanent IMSI, So even 122 00:06:10.439 --> 00:06:13.160 if someone is passively listening in, they shouldn't immediately know 123 00:06:13.199 --> 00:06:16.079 it's you. It adds this layer of pseudonymity, makes it 124 00:06:16.160 --> 00:06:19.519 much harder for someone to say, track your movements or 125 00:06:19.560 --> 00:06:22.000 profile you just based on your mobile activity. 126 00:06:22.319 --> 00:06:26.319 So GSM clearly a monumental step forward bringing real digital 127 00:06:26.319 --> 00:06:28.839 security to mobile phones. For the first time, but then 128 00:06:29.040 --> 00:06:31.279 roughly a decade later we see the introduction of three 129 00:06:31.319 --> 00:06:35.439 G third generation technologies. What were the shortcomings in GSM 130 00:06:35.480 --> 00:06:38.399 that three G was trying to fix, especially thinking about 131 00:06:38.399 --> 00:06:40.240 maybe more sophisticated attacks. 132 00:06:40.560 --> 00:06:43.160 Yeah. While GSM was a huge success, it definitely had 133 00:06:43.199 --> 00:06:47.199 some limitations, particularly against what we call active attacks. For instance, 134 00:06:47.480 --> 00:06:50.199 an attacker could potentially set up a fake base station 135 00:06:50.319 --> 00:06:53.240 right try and trick your phone into connecting to it, 136 00:06:53.319 --> 00:06:55.680 pretending to be your real network. And this is where 137 00:06:55.720 --> 00:07:00.399 three G security, specifically UMTS, the Universal Mobile Telecommunication System, 138 00:07:00.439 --> 00:07:03.839 came in. It really built on GSM's foundations but added 139 00:07:03.839 --> 00:07:07.560 some crucial enhancements. The biggest one mutual authentication. 140 00:07:08.120 --> 00:07:11.240 Mutual authentication. Okay, let's unpack that phrase. What does it 141 00:07:11.279 --> 00:07:14.199 actually mean and how does it stop that fake base 142 00:07:14.240 --> 00:07:15.079 station scenario? 143 00:07:15.199 --> 00:07:18.680 Okay, so in GSM, the network authenticates you, but you 144 00:07:18.720 --> 00:07:21.319 don't really authenticate the network. It's a one way street. 145 00:07:21.759 --> 00:07:24.680 In three G it becomes mutual. Your phone authenticates the 146 00:07:24.680 --> 00:07:27.839 network it's connecting to, and the network authenticates your phone. 147 00:07:28.160 --> 00:07:31.680 It goes both ways. This directly counters that false base 148 00:07:31.759 --> 00:07:34.560 station attack or man in the middle attack. Now your 149 00:07:34.560 --> 00:07:37.639 phone actively checks if it's talking to a legitimate network. 150 00:07:37.839 --> 00:07:41.199 If some attacker tries to impersonate your operator, your phone 151 00:07:41.199 --> 00:07:44.279 should detect it, refuse to connect, maybe even alert you. 152 00:07:44.639 --> 00:07:47.560 It just makes those kinds of active attacks much much 153 00:07:47.600 --> 00:07:49.120 harder to pull off successfully. 154 00:07:49.240 --> 00:07:51.519 That sounds like a huge step forward and just building 155 00:07:51.560 --> 00:07:53.879 trust in the whole system. How does three G actually 156 00:07:53.879 --> 00:07:56.319 achieve this? Are the keys handled differently than in GSM? 157 00:07:56.480 --> 00:08:00.319 Well, the underlying principle is similar, but definitely strengthened. Uses 158 00:08:00.319 --> 00:08:03.319 a permanent key still shared between your phone's smart card 159 00:08:03.399 --> 00:08:07.360 now called a USIM Universal SIM and your home networks database. 160 00:08:08.040 --> 00:08:11.120 This key, called K, is now one hundred and twenty 161 00:08:11.160 --> 00:08:14.680 eight bits, and just like GSMSK, this kkey never gets 162 00:08:14.720 --> 00:08:18.000 transferred out of those two secure spots. During that mutual 163 00:08:18.040 --> 00:08:21.319 authentication process, temporary one hundred and twenty eight bit keys 164 00:08:21.319 --> 00:08:24.959 are derived, one for encryption called K and another for 165 00:08:25.040 --> 00:08:29.279 something new integrity protection called IK. So again, the emphasis 166 00:08:29.399 --> 00:08:32.480 is on deriving temporary keys for the actual data protection, 167 00:08:32.879 --> 00:08:35.679 limiting any exposure of that really valuable permanent key. 168 00:08:35.720 --> 00:08:38.200 Okay, so mutual authentication was the big one. What other 169 00:08:38.279 --> 00:08:40.519 key security improvements did three. 170 00:08:40.399 --> 00:08:41.360 G bring to the table. 171 00:08:41.440 --> 00:08:46.240 Well, three G significantly boosted integrity protection, especially for signaling messages. 172 00:08:46.399 --> 00:08:48.320 Signaling messages like the control. 173 00:08:48.000 --> 00:08:51.399 Stuff exactly, there's critical messages that set up your calls, manager, 174 00:08:51.440 --> 00:08:54.679 data sessions, all that backstage stuff. Integrity protection means they 175 00:08:54.679 --> 00:08:56.759 can't be tampered with while they're flying through the air. 176 00:08:57.360 --> 00:09:00.440 Another important improvement was actually moving the start and end 177 00:09:00.519 --> 00:09:04.360 points of the ciphering the encryption further into the network, 178 00:09:04.399 --> 00:09:07.799 away from the base stations which are physically more exposed. 179 00:09:08.039 --> 00:09:11.440 Adds another layer. And our research also shows that three 180 00:09:11.559 --> 00:09:15.000 G introduced a whole new suite of cryptographic algorithms, things 181 00:09:15.039 --> 00:09:18.679 like Kasumi and s now. Three G. These benefited from 182 00:09:18.679 --> 00:09:21.879 a lot of public scrutiny and analysis by experts, which 183 00:09:21.919 --> 00:09:25.200 is really vital for building confidence that they're actually strong. 184 00:09:25.600 --> 00:09:25.759 Right. 185 00:09:25.799 --> 00:09:30.159 Public scrutiny helps find weaknesses before the bad guys do. Okay, 186 00:09:30.320 --> 00:09:32.399 So that brings us more or less up to today's 187 00:09:32.639 --> 00:09:36.519 mobile landscape, mostly for G technology. Now, what should we 188 00:09:36.559 --> 00:09:40.039 know about the security of LTE long term evolution and 189 00:09:40.279 --> 00:09:43.799 this broader thing you mentioned the Evolved Packet System or EPs. 190 00:09:44.000 --> 00:09:46.600 Yeah, today, when we talk four G, the radio part 191 00:09:46.679 --> 00:09:51.559 is LTE long term evolution, but the complete system, including 192 00:09:51.600 --> 00:09:55.399 the core network and everything is the Evolved Packet System EPs. 193 00:09:56.200 --> 00:10:00.039 That LTE Security book really emphasizes EPs because it's the 194 00:10:00.080 --> 00:10:03.879 whole architecture, and one of its key security innovations is 195 00:10:03.879 --> 00:10:09.360 this concept of local master keys called KSME pay asme. 196 00:10:09.120 --> 00:10:12.320 Local master keys. Okay, what does that mean for someone 197 00:10:12.399 --> 00:10:14.759 just using their phone? Why is that important for security? 198 00:10:15.159 --> 00:10:18.399 Well, what we learned is that EPs introduced these KSME 199 00:10:18.559 --> 00:10:21.360 keys that are specific to the serving network you're currently 200 00:10:21.360 --> 00:10:24.720 connected to. They're derived from the core network's permanent keys, 201 00:10:24.759 --> 00:10:28.759 but they're localized. This enables something called cryptographic network. 202 00:10:28.440 --> 00:10:30.759 Separation separation meaning think of it like this. 203 00:10:30.840 --> 00:10:34.320 If hypothetically the network you use while roaming in say Germany, 204 00:10:34.720 --> 00:10:37.799 was somehow compromised, an attacker couldn't just take those keys 205 00:10:37.799 --> 00:10:39.720 and use them to compromise your connection when you fly 206 00:10:39.799 --> 00:10:42.679 home or room somewhere else like Japan. It limits the 207 00:10:42.720 --> 00:10:46.360 blast radius of a security breach. Makes each network segment 208 00:10:46.440 --> 00:10:49.159 kind of its own fortress. It's a really strategic way 209 00:10:49.200 --> 00:10:50.840 to contain potential damage. 210 00:10:51.000 --> 00:10:54.159 Ah, Okay, that makes a lot of sense containing the damage. 211 00:10:54.200 --> 00:10:57.480 So how is the security architecture of EPs actually designed? 212 00:10:58.000 --> 00:11:00.000 Is it just a bunch of different technologies thrown together 213 00:11:00.200 --> 00:11:03.159 or is there a more systematic process. 214 00:11:03.159 --> 00:11:06.159 Oh, it's very systematic, definitely, not just thrown together. The 215 00:11:06.240 --> 00:11:09.919 EPs security architecture follows these core principles you'd find in 216 00:11:10.000 --> 00:11:14.720 any robust security system design. It starts with threat analysis, 217 00:11:14.799 --> 00:11:17.679 identifying all the possible ways someone might attack the system. 218 00:11:18.200 --> 00:11:20.639 Then you do risk analysis, figuring out how likely and 219 00:11:20.679 --> 00:11:23.879 how bad each threat is. That leads to requirements capture, 220 00:11:23.960 --> 00:11:27.360 deciding exactly what protection you actually need, and finally the 221 00:11:27.399 --> 00:11:31.360 design phase where you build the actual security mechanisms. What's 222 00:11:31.559 --> 00:11:34.720 absolutely critical, and the sources emphasize this, is that security 223 00:11:34.720 --> 00:11:38.120 has to be designed from the start, integrated with the system, 224 00:11:38.200 --> 00:11:40.919 not just bolted on afterwards. Think of it like trying 225 00:11:40.919 --> 00:11:43.320 to make a house fireproof by just adding sprinklers and 226 00:11:43.399 --> 00:11:46.679 alarms after it's built, instead of using fire resistant materials 227 00:11:46.720 --> 00:11:50.039 from the foundation up. Bolting on security later rarely works 228 00:11:50.080 --> 00:11:51.679 well and often lays critical gaps. 229 00:11:51.840 --> 00:11:54.840 Yeah, that analogy makes it crystal clear. Okay, So with 230 00:11:54.840 --> 00:11:58.200 all these different keys floating around, permanent keys, temporary keys, 231 00:11:58.519 --> 00:12:01.960 local keys, how does EPs manage them all without it 232 00:12:02.000 --> 00:12:03.159 becoming a complete mess. 233 00:12:03.200 --> 00:12:06.759 That's where key derivation functions, or kdfs come in. They're crucial. 234 00:12:07.080 --> 00:12:11.720 EPs standardizes these functions often uses really strong cryptographic hash 235 00:12:11.759 --> 00:12:15.840 functions like HMAC SAHA two five fifty six. Think of 236 00:12:15.919 --> 00:12:18.960 kds like a master recipe book. They take some input 237 00:12:19.080 --> 00:12:22.559 keys and parameters and they generate specific, unique keys for 238 00:12:22.759 --> 00:12:27.440 very specific tasks downstream. This ensures something called key separation, 239 00:12:27.639 --> 00:12:30.440 meaning a key used for say, encrypting your voice call 240 00:12:30.559 --> 00:12:32.679 can't somehow be used to figure out the key used 241 00:12:32.679 --> 00:12:36.159 for protecting signaling messages or vice versa. It's fundamental for 242 00:12:36.240 --> 00:12:39.200 limiting the attack surface. If some keys do get compromised, 243 00:12:39.200 --> 00:12:41.519 the damage is localized. It doesn't cascade through the whole 244 00:12:41.559 --> 00:12:42.279 key hierarchy. 245 00:12:42.480 --> 00:12:45.840 Okay, what about the actual encryption and integrity algorithms used 246 00:12:45.840 --> 00:12:47.360 in the EPs? Are they the same as three G 247 00:12:47.720 --> 00:12:48.600 or have they evolved too? 248 00:12:48.879 --> 00:12:53.759 They've definitely evolved. For confidentiality that secrecy and integrity preventing 249 00:12:53.799 --> 00:12:59.080 tampering EPs relies on really robust, publicly vetted algorithms. We're 250 00:12:59.080 --> 00:13:03.120 talking AES, the Advanced Encryption Standard, which is widely used everywhere, 251 00:13:03.360 --> 00:13:06.399 plus updated versions of algorithms like s and OW, three 252 00:13:06.440 --> 00:13:10.039 G and a newer one called ZUC. The system is 253 00:13:10.080 --> 00:13:13.440 also designed for what's called algorithm agility. Agility, Yeah, it 254 00:13:13.440 --> 00:13:16.840 means the system's flexible. It's design so you can introduce new, 255 00:13:17.080 --> 00:13:20.519 stronger algorithms and phase out older, maybe weaker ones as 256 00:13:20.600 --> 00:13:24.960 threats evolve or cryptanalysis gets better. This adaptability is just 257 00:13:25.240 --> 00:13:28.399 vital in that ongoing security cat and mouse game. You 258 00:13:28.480 --> 00:13:30.279 have to be able to upgrade your defenses. 259 00:13:30.440 --> 00:13:33.120 That adaptability makes sense. Now you mentioned something I found 260 00:13:33.120 --> 00:13:35.919 really fascinating when I was reading null algorithms. What on 261 00:13:36.000 --> 00:13:38.320 earth are those? Why would you include an algorithm that 262 00:13:38.360 --> 00:13:41.120 does nothing in such a high tech security system. 263 00:13:41.320 --> 00:13:44.960 Huh? Yeah, it does sound counterintuitive, doesn't it. But null 264 00:13:45.000 --> 00:13:49.200 algorithms actually serve a very specific purpose. They're intentionally designed 265 00:13:49.240 --> 00:13:53.159 for situations where cryptographic protection either isn't possible or maybe 266 00:13:53.200 --> 00:13:57.240 isn't desired. Like think about emergency calls for ciphering. The 267 00:13:57.320 --> 00:14:00.879 null algorithm literally means the output ciphertext is identical to 268 00:14:00.919 --> 00:14:04.480 the input plaintext. It does nothing for integrity. It just 269 00:14:04.559 --> 00:14:07.960 depends a fixed string of I think thirty two zeros. 270 00:14:08.399 --> 00:14:10.879 The whole point isn't to provide security in those cases, 271 00:14:11.120 --> 00:14:13.879 but to make it absolutely explicit that no protection is 272 00:14:13.919 --> 00:14:17.639 being applied. It avoids silent failures or system errors when 273 00:14:17.639 --> 00:14:20.519 security just can't be used. It kind of maintains procedural 274 00:14:20.559 --> 00:14:23.440 consistency even when you're intentionally not protecting something. 275 00:14:23.879 --> 00:14:27.159 Okay, interesting, So it's like a placeholder that says security 276 00:14:27.200 --> 00:14:28.320 intentionally often. Yes. 277 00:14:28.600 --> 00:14:31.559 Now, mobile networks aren't just those just at cell towers anymore, 278 00:14:31.559 --> 00:14:34.840 are they. Our research also talks about these specialized network elements, 279 00:14:35.039 --> 00:14:37.919 things that bring unique security challenges because they're often in 280 00:14:37.960 --> 00:14:40.879 less secure places, like homy node bes or hay in 281 00:14:41.000 --> 00:14:43.799 bees and relay nodes are ins. Let's start with hay 282 00:14:43.840 --> 00:14:46.720 and bees. What are they and what makes securing them 283 00:14:46.720 --> 00:14:50.440 so tricky? Right? Hey and bees are basically miniature based stations. 284 00:14:50.759 --> 00:14:52.120 You might have one in your home or maybe a 285 00:14:52.159 --> 00:14:56.480 small office primarily to boost indoor coverage. And because they're 286 00:14:56.519 --> 00:14:59.679 in what the standards call an expose location, meaning not 287 00:14:59.720 --> 00:15:03.240 in sie to secure, lockdown, operate a facility, they require 288 00:15:03.279 --> 00:15:08.080 really robust platform security. The threat model is completely different 289 00:15:08.080 --> 00:15:11.519 from a big cell tower in a controlled compound. Someone 290 00:15:11.559 --> 00:15:14.360 could potentially get physical access to a hand bee in 291 00:15:14.399 --> 00:15:15.080 someone's house. 292 00:15:15.240 --> 00:15:18.120 That's a really good point. Physical access changes everything. So 293 00:15:18.200 --> 00:15:20.799 if these devices are sitting out there in homes and offices. 294 00:15:21.360 --> 00:15:24.279 How do you establish trust? How does the main network 295 00:15:24.360 --> 00:15:26.960 not it's talking to a legitimate hand bee and not 296 00:15:27.080 --> 00:15:29.480 some rogue device someone's plugged in or tampered with. 297 00:15:29.639 --> 00:15:34.360 The solution relies heavily on public key infrastructure or PKI. Essentially, 298 00:15:34.399 --> 00:15:38.080 PKI is a system for issuing and managing digital certificates 299 00:15:38.200 --> 00:15:42.759 like digital passports to verify identity. The hand bee authenticates 300 00:15:42.759 --> 00:15:45.879 itself to the operator's network using these digital certificates, which 301 00:15:45.879 --> 00:15:48.720 are usually issued by the operator or the device manufacturer. 302 00:15:49.080 --> 00:15:52.159 These certificates buying the handbe's identity to its public. 303 00:15:52.000 --> 00:15:55.799 Key okay certificates. And what about this idea of autonomous 304 00:15:55.879 --> 00:16:00.159 validation in handb's How does that add another layer of trust? 305 00:16:00.559 --> 00:16:04.360 Ah? Yeah, this is really clever stuff. Autonomous validation haynbs 306 00:16:04.360 --> 00:16:08.159 are designed with something called a trusted execution environment or TRE. 307 00:16:08.919 --> 00:16:11.240 Think of it as a secure vault inside the device, 308 00:16:11.399 --> 00:16:15.159 anchored by a hardware root of trust. During the handbe's 309 00:16:15.200 --> 00:16:19.840 secure boot up process, this tre verifies its own software 310 00:16:19.879 --> 00:16:23.279 integrity and the integrity of other critical software components on 311 00:16:23.360 --> 00:16:27.240 the device only after a successful integrity check, meaning it 312 00:16:27.279 --> 00:16:30.759 confirms nothing has been tampered with. Will the TRE release 313 00:16:30.799 --> 00:16:34.480 the device's private key, the one needed for authentication using 314 00:16:34.480 --> 00:16:38.559 those certificates. So when the network successfully authenticates the HAYMB 315 00:16:38.759 --> 00:16:42.000 using its certificate, the network implicitly knows the device itself 316 00:16:42.080 --> 00:16:45.799 is likely untampered because that secure TRE guarantees the private 317 00:16:45.879 --> 00:16:49.120 keys only usable if the device passes its internal self checks. 318 00:16:49.320 --> 00:16:51.399 It's a really deep rooted security mechanism. 319 00:16:51.480 --> 00:16:54.200 Wow, okay, that's pretty sophisticated self checking. Now what about 320 00:16:54.200 --> 00:16:56.519 these relay nodes or our ends you mentioned? It seem 321 00:16:56.600 --> 00:16:57.840 to play a sort of dual role. 322 00:16:58.080 --> 00:17:00.080 Can you explain how they work in their secure pre 323 00:17:00.240 --> 00:17:00.559 set up? 324 00:17:00.759 --> 00:17:04.559 Absolutely so. A relay node an RN is basically a 325 00:17:04.559 --> 00:17:07.359 base station that connects back to the main network wirelessly, 326 00:17:07.759 --> 00:17:10.920 not with a physical cable. It connects wirelessly to another 327 00:17:11.119 --> 00:17:14.599 regular base station, which is called the donor eNB or DNB, 328 00:17:15.319 --> 00:17:18.119 and our research details how these RNs really do play 329 00:17:18.119 --> 00:17:20.680 a dual role, which is key to their security. On 330 00:17:20.680 --> 00:17:23.599 one hand, the RN acts like regular user equipment like 331 00:17:23.640 --> 00:17:26.279 your phone when talking to its donor eNB. On the 332 00:17:26.279 --> 00:17:28.279 other hand, it acts as a base station for other 333 00:17:28.400 --> 00:17:31.519 actual user devices connecting through it. Now, for security, this 334 00:17:31.640 --> 00:17:34.279 dual role is split When the RN first powers up, 335 00:17:34.319 --> 00:17:37.440 it needs to establish initial connectivity just to get configured. 336 00:17:37.480 --> 00:17:41.640 That's Phase one attached for RN pre configuration. For this 337 00:17:41.680 --> 00:17:45.119 phase it uses a special dedicated USIM called the USMIN. 338 00:17:45.720 --> 00:17:48.839 This USIM has very very minimal access rights. It basically 339 00:17:48.920 --> 00:17:51.920 can only talk to the network for configuration. Then, once 340 00:17:51.960 --> 00:17:54.039 it's configured and ready to act as a proper base 341 00:17:54.039 --> 00:17:56.759 station for users, it switches to Phase two attach for 342 00:17:56.960 --> 00:18:00.000 RN operation. For this operational phase, it uses a set 343 00:18:00.000 --> 00:18:04.279 separate fully functional use are in. This whole separation, especially 344 00:18:04.319 --> 00:18:07.119 the restricted access for that initial use of meaning is crucial. 345 00:18:07.200 --> 00:18:09.599 It prevents misuse. If the RN, which might also be 346 00:18:09.640 --> 00:18:13.119 in an exposed location, gets compromised, that initial us IN 347 00:18:13.240 --> 00:18:15.480 just can't be used for making normal calls or accessing 348 00:18:15.519 --> 00:18:16.039 the Internet. 349 00:18:16.200 --> 00:18:20.759 That separation makes sense limiting the capability of that initial identity. Okay, 350 00:18:20.799 --> 00:18:23.920 looking ahead, now, our research also gets into machine type 351 00:18:23.920 --> 00:18:27.400 communications MTC. These are devices not really attended by humans 352 00:18:27.480 --> 00:18:31.599 right like smart meters, asset trackers, industrial sensors, things like that. 353 00:18:32.000 --> 00:18:35.279 And this area presents a whole new wave of security 354 00:18:35.319 --> 00:18:38.519 and privacy challenges as these devices become well everywhere. 355 00:18:38.519 --> 00:18:39.480 What's the core challenge? 356 00:18:39.480 --> 00:18:42.559 Here, you've hit it exactly. The core challenge with MTC 357 00:18:43.319 --> 00:18:46.400 is partly the sheer volume of devices we're talking about 358 00:18:46.400 --> 00:18:49.920 potentially billions, but it's also the nature of their operation 359 00:18:50.039 --> 00:18:52.960 and the data they handle. They often need automated management, 360 00:18:53.359 --> 00:18:56.440 minimal human interaction. You can't rely on a user to 361 00:18:56.519 --> 00:18:59.440 install security updates or type in passwords on a smart 362 00:18:59.440 --> 00:19:02.640 water meter right and the data they collect it can 363 00:19:02.680 --> 00:19:07.440 be incredibly revealing resource usage patterns in your home, potentially 364 00:19:07.519 --> 00:19:11.240 your precise location over time from a tracking device. Imagine 365 00:19:11.240 --> 00:19:14.640 if compromise smart meter data could tell a burglar exactly 366 00:19:14.680 --> 00:19:18.720 when you're not home. Protecting this vast, often unattended ecosystem 367 00:19:18.880 --> 00:19:21.480 and the privacy of the individuals linked to that data, 368 00:19:21.759 --> 00:19:25.400 it's a massive defining challenge for the future of mobile security. 369 00:19:25.079 --> 00:19:27.359 It really is, and that raises a really important question 370 00:19:27.400 --> 00:19:28.920 for you, the listener, to think about, how do we 371 00:19:29.039 --> 00:19:33.039 secure billions of these interconnected, often unintended devices and what 372 00:19:33.079 --> 00:19:35.680 does all that connected data mean for our personal privacy? 373 00:19:35.720 --> 00:19:37.839 What approaches are being looked at based on. 374 00:19:37.799 --> 00:19:40.759 The research Well, the material we explored points towards a 375 00:19:40.799 --> 00:19:44.720 couple of key approaches. Mainly, the first involves building these 376 00:19:44.759 --> 00:19:48.440 devices as trusted platforms. That means designing them with hardware 377 00:19:48.480 --> 00:19:53.480 secured routes of trust, trusted computing bases or TCBs, providing 378 00:19:53.480 --> 00:19:56.119 a foundation of security that's hard to tamper with, much 379 00:19:56.160 --> 00:19:59.440 like we discussed with hay mbs. The second major approach 380 00:19:59.519 --> 00:20:03.279 involves embedded uic cs or uic cs you might have 381 00:20:03.319 --> 00:20:07.839 heard of eSIMs ah. This is where the USM functionality 382 00:20:07.880 --> 00:20:10.839 that secure chip is actually soldered directly onto the device's 383 00:20:10.880 --> 00:20:14.839 circuit board. It's non removable. This allows for things like 384 00:20:14.920 --> 00:20:17.880 remote provisioning, activating the device, and assigning it to a 385 00:20:17.880 --> 00:20:21.759 network operator over the air without physically swapping a simcard. 386 00:20:22.079 --> 00:20:24.960 You can even change operators remotely. The overall goal for 387 00:20:25.039 --> 00:20:28.839 both these approaches is really automated registration, automated management, maybe 388 00:20:28.839 --> 00:20:32.920 even automated operator changes, all without needing physical intervention. But 389 00:20:33.079 --> 00:20:36.319 doing all that while maintaining strong security and critically addressing 390 00:20:36.359 --> 00:20:39.640 those really significant privacy concerns, both at the level of 391 00:20:39.680 --> 00:20:42.880 the application using the data and at the network level 392 00:20:42.920 --> 00:20:45.240 carrying it. It's going to be a huge focus area 393 00:20:45.279 --> 00:20:45.920 going forward. 394 00:20:46.200 --> 00:20:49.599 Wow, what a journey indeed, I mean, starting from those 395 00:20:49.680 --> 00:20:53.759 analog squidgy tapes and essentially zero security all the way 396 00:20:53.799 --> 00:20:57.680 to the incredibly complex, multi layered security we see in 397 00:20:57.720 --> 00:21:01.519 today's four GLT and EPs systems. It really has been 398 00:21:01.559 --> 00:21:05.319 a constant evolution. We've touched on everything from those fundamental 399 00:21:05.319 --> 00:21:09.119 cryptographic functions keeping your data private to the really innovative 400 00:21:09.119 --> 00:21:12.559 ways things like home based stations and even machines authenticate 401 00:21:12.599 --> 00:21:13.440