WEBVTT

1
00:00:00.080 --> 00:00:03.919
<v Speaker 1>Welcome back to the deep dive. Today, we are cracking

2
00:00:03.919 --> 00:00:09.800
<v Speaker 1>open the essential digital infrastructure that connects us all telecommunications networks.

3
00:00:09.919 --> 00:00:11.080
<v Speaker 2>Yeah, absolutely essential.

4
00:00:11.160 --> 00:00:13.679
<v Speaker 1>We depend on them for everything, I mean really.

5
00:00:13.560 --> 00:00:16.600
<v Speaker 2>Everything, which makes them, you know, incredibly attractive targets for.

6
00:00:16.640 --> 00:00:20.679
<v Speaker 1>Any serious adversary, right, nation states, organized crime exactly.

7
00:00:21.199 --> 00:00:24.719
<v Speaker 2>So our mission today is a deep dive into the

8
00:00:25.600 --> 00:00:29.879
<v Speaker 2>emerging state of security in these crucial systems. Okay, we've

9
00:00:29.920 --> 00:00:36.079
<v Speaker 2>pulled together analysis on vulnerabilities cellular data, SMS, voiceover IP, and.

10
00:00:36.039 --> 00:00:39.159
<v Speaker 1>We're focusing on why, right, why are these networks sometimes

11
00:00:39.159 --> 00:00:39.799
<v Speaker 1>so fragile?

12
00:00:39.880 --> 00:00:42.920
<v Speaker 2>Precisely, the sources suggest it really comes down to this

13
00:00:43.039 --> 00:00:45.200
<v Speaker 2>collision old meets new.

14
00:00:45.200 --> 00:00:47.479
<v Speaker 1>The old phone system architecture, yeah.

15
00:00:47.359 --> 00:00:49.840
<v Speaker 2>The legacy stuff bumping right into the modern Internet.

16
00:00:49.920 --> 00:00:53.359
<v Speaker 1>But maybe first let's quickly define security in this context.

17
00:00:53.640 --> 00:00:55.399
<v Speaker 1>Our sources put it pretty simply.

18
00:00:55.280 --> 00:00:58.039
<v Speaker 2>Right, Security is just the expectation that a system will

19
00:00:58.079 --> 00:00:58.600
<v Speaker 2>behave like.

20
00:00:58.600 --> 00:00:59.960
<v Speaker 1>You think it should as anticipate.

21
00:01:00.240 --> 00:01:02.600
<v Speaker 2>Yeah, and we're going to look at where that expectition

22
00:01:02.719 --> 00:01:06.840
<v Speaker 2>just gets completely well betrayed. We'll show how these fundamental

23
00:01:06.840 --> 00:01:10.319
<v Speaker 2>conflicts in the design things inherited from frankly an era

24
00:01:10.480 --> 00:01:14.040
<v Speaker 2>of blind trust. They don't just create gaps, They actually

25
00:01:14.079 --> 00:01:19.239
<v Speaker 2>create mechanisms for amplification. Amplification meaning meaning simple low effort

26
00:01:19.280 --> 00:01:24.239
<v Speaker 2>attacks can cause catastrophic denial of service, much bigger impact

27
00:01:24.280 --> 00:01:25.000
<v Speaker 2>than you'd expect.

28
00:01:25.079 --> 00:01:28.280
<v Speaker 1>Okay, so let's dig into those roots. The historical side.

29
00:01:29.000 --> 00:01:30.200
<v Speaker 1>You mentioned blind trust.

30
00:01:30.680 --> 00:01:33.480
<v Speaker 2>Yeah, the first failure point was really architectural. It was

31
00:01:33.480 --> 00:01:34.359
<v Speaker 2>built on trust.

32
00:01:34.560 --> 00:01:38.959
<v Speaker 1>Traditional systems like the old digital backbone SS seven Signaling

33
00:01:39.040 --> 00:01:40.599
<v Speaker 1>System number seven exactly.

34
00:01:40.640 --> 00:01:43.480
<v Speaker 2>They were built assuming a totally controlled.

35
00:01:43.040 --> 00:01:44.560
<v Speaker 1>Environment like a walled garden.

36
00:01:44.640 --> 00:01:48.560
<v Speaker 2>Pretty much the phone company was a fortress. Why authenticate

37
00:01:48.680 --> 00:01:52.799
<v Speaker 2>signals between core machines if they're all supposedly inside your trusted.

38
00:01:52.439 --> 00:01:54.439
<v Speaker 1>Walls, right, makes sense in that old context.

39
00:01:54.519 --> 00:01:57.879
<v Speaker 2>But that lack of authentication between say, routers and switches

40
00:01:57.920 --> 00:02:02.040
<v Speaker 2>back then, that vulnerability state echoes today in parts of

41
00:02:02.040 --> 00:02:04.799
<v Speaker 2>our cellular infrastructure. It's foundational.

42
00:02:04.959 --> 00:02:07.319
<v Speaker 1>And even before s S seven was really a big target,

43
00:02:07.840 --> 00:02:10.400
<v Speaker 1>you had the originals, the phone freaks.

44
00:02:10.639 --> 00:02:13.280
<v Speaker 2>The phone freaks, yes, which is just wild when you

45
00:02:13.280 --> 00:02:13.919
<v Speaker 2>think about it.

46
00:02:14.280 --> 00:02:18.199
<v Speaker 1>They proved you could exploit that trust with like the

47
00:02:18.280 --> 00:02:19.319
<v Speaker 1>simplest tools.

48
00:02:19.400 --> 00:02:23.319
<v Speaker 2>It's true. Back then, the signals managing your call routing,

49
00:02:23.520 --> 00:02:26.759
<v Speaker 2>set up billing traveled on the same physical line as your.

50
00:02:26.719 --> 00:02:28.439
<v Speaker 1>Voice that was inband signaling.

51
00:02:28.520 --> 00:02:32.199
<v Speaker 2>In band signaling, and the freaks figured out that if

52
00:02:32.240 --> 00:02:35.319
<v Speaker 2>they played a specific tone twenty six hundred hertz, the

53
00:02:35.360 --> 00:02:38.560
<v Speaker 2>magic twenty six hundred hertz tone. Yeah, the network heard

54
00:02:38.560 --> 00:02:41.680
<v Speaker 2>that and thought, okay, hang up the trunk line, stop billing.

55
00:02:41.759 --> 00:02:44.000
<v Speaker 1>But the call was already connected exactly.

56
00:02:43.680 --> 00:02:46.080
<v Speaker 2>So they just kept talking free long distance.

57
00:02:45.840 --> 00:02:49.719
<v Speaker 1>Using things like a blue box or I love this

58
00:02:50.319 --> 00:02:52.639
<v Speaker 1>the whistle from a cap'n Crunch cereal box.

59
00:02:52.759 --> 00:02:55.719
<v Speaker 2>Yeah, the cap'n Crunch whistle. It's almost unbelievable. A kid's

60
00:02:55.800 --> 00:02:58.639
<v Speaker 2>toy defeated this massive infrastructure just.

61
00:02:58.599 --> 00:03:01.000
<v Speaker 1>By speaking the network's interurn old secret language.

62
00:03:01.039 --> 00:03:03.800
<v Speaker 2>That vulnerability was so deep they had to completely rip

63
00:03:03.840 --> 00:03:05.719
<v Speaker 2>out in band signaling, move it.

64
00:03:05.639 --> 00:03:07.360
<v Speaker 1>Out of ban a whole redesign.

65
00:03:07.520 --> 00:03:11.759
<v Speaker 2>But then history repeats. We moved to digital celluler GSM.

66
00:03:11.319 --> 00:03:13.439
<v Speaker 1>Networks and made a similar mistake.

67
00:03:13.199 --> 00:03:15.520
<v Speaker 2>Basically, yes, this time with weak cryptography.

68
00:03:15.800 --> 00:03:18.719
<v Speaker 1>Okay crypto. We hear about strong crypto, and there's this

69
00:03:18.840 --> 00:03:21.520
<v Speaker 1>core idea Kirkoff's principle, right.

70
00:03:21.680 --> 00:03:25.000
<v Speaker 2>Kirkhoff's principle says, a strong system assumes the bad guy

71
00:03:25.159 --> 00:03:27.680
<v Speaker 2>knows how it works. The only secret should be.

72
00:03:27.680 --> 00:03:30.280
<v Speaker 1>The key, the algorithm itself should be public.

73
00:03:30.000 --> 00:03:34.639
<v Speaker 2>And strong, precisely, But early GSM ciphers like A fifty one,

74
00:03:34.719 --> 00:03:38.159
<v Speaker 2>and especially the deliberately weakened export version.

75
00:03:38.000 --> 00:03:40.280
<v Speaker 1>A fifty two, they weren't strong.

76
00:03:40.159 --> 00:03:43.960
<v Speaker 2>Not even close, and they relied on keeping the algorithm's secret,

77
00:03:44.039 --> 00:03:47.800
<v Speaker 2>which is the opposite of Kirkoff's why weakened Well, The

78
00:03:47.840 --> 00:03:51.039
<v Speaker 2>sources point to political pressure. Back then, governments didn't want

79
00:03:51.080 --> 00:03:53.879
<v Speaker 2>strong encryption getting out, especially overseas.

80
00:03:53.479 --> 00:03:54.560
<v Speaker 1>A export controls.

81
00:03:54.680 --> 00:03:58.360
<v Speaker 2>Yeah, but that political choice led directly to a massive

82
00:03:58.400 --> 00:04:01.879
<v Speaker 2>security failure. How bad was Researchers like ber Ucov later

83
00:04:01.919 --> 00:04:04.360
<v Speaker 2>showed A fifty one the main cipher. You could get

84
00:04:04.400 --> 00:04:05.479
<v Speaker 2>the key on a standard PC.

85
00:04:05.599 --> 00:04:06.479
<v Speaker 1>Yeah, how long did it take?

86
00:04:06.599 --> 00:04:07.319
<v Speaker 2>Under a second?

87
00:04:07.599 --> 00:04:07.879
<v Speaker 1>Wow?

88
00:04:07.919 --> 00:04:13.120
<v Speaker 2>And a fifty two the weekend one ten milliseconds basically instantaneous.

89
00:04:12.560 --> 00:04:14.919
<v Speaker 1>So real time decryption of calls was.

90
00:04:14.879 --> 00:04:21.560
<v Speaker 2>Possible, absolutely, and it wasn't just eavesdropping. The authentication algorithm comp.

91
00:04:20.920 --> 00:04:23.240
<v Speaker 1>One eight, the one that checks if your phone is legit.

92
00:04:23.439 --> 00:04:27.120
<v Speaker 2>Yeah, it was so flawed attackers could potentially clone sim

93
00:04:27.199 --> 00:04:31.360
<v Speaker 2>cards or worse craft messages to lock legitimate users out

94
00:04:31.399 --> 00:04:33.079
<v Speaker 2>completely denial of service.

95
00:04:33.120 --> 00:04:35.519
<v Speaker 1>Again, that sounds like a nightmare to fix it was.

96
00:04:35.680 --> 00:04:39.879
<v Speaker 2>Took years replacing millions of SIM cards worldwide to patch

97
00:04:39.920 --> 00:04:41.399
<v Speaker 2>those fundamental digital holes.

98
00:04:41.480 --> 00:04:46.120
<v Speaker 1>Okay, so we had trust issues, crypto issues. Let's talk

99
00:04:46.199 --> 00:04:49.639
<v Speaker 1>architecture now. Yeah, where's the design conflict causing these new problems?

100
00:04:49.720 --> 00:04:54.120
<v Speaker 2>Right? The core conflict now is really rigidity versus flexibility,

101
00:04:54.399 --> 00:04:57.360
<v Speaker 2>Meaning well, think about how old phone networks were built

102
00:04:57.600 --> 00:04:59.639
<v Speaker 2>for voice calls. Right, that's rigid.

103
00:05:00.120 --> 00:05:02.800
<v Speaker 1>Get switched traffic, like reserving a dedicated pipe for.

104
00:05:02.800 --> 00:05:07.639
<v Speaker 2>The whole call exactly, a guaranteed connection, no sharing, no interruptions, ideally,

105
00:05:08.079 --> 00:05:09.839
<v Speaker 2>very predictable, very rigid.

106
00:05:09.879 --> 00:05:14.000
<v Speaker 1>But now everything runs on packet switch data the Internet model.

107
00:05:13.839 --> 00:05:17.399
<v Speaker 2>Right, data chopped into little packets, routed flexibly, sharing the

108
00:05:17.399 --> 00:05:22.680
<v Speaker 2>network efficiently. Total opposite philosophy, and this clashes massively. It

109
00:05:22.759 --> 00:05:25.680
<v Speaker 2>leads to violations of a key Internet principle, the end

110
00:05:25.720 --> 00:05:26.560
<v Speaker 2>to end argument.

111
00:05:26.720 --> 00:05:27.759
<v Speaker 1>Okay, what's that argue?

112
00:05:27.959 --> 00:05:30.639
<v Speaker 2>It basically says the network itself should be done just

113
00:05:30.759 --> 00:05:32.360
<v Speaker 2>forward packets, keep it simple.

114
00:05:32.519 --> 00:05:35.439
<v Speaker 1>All the complex of like making sure data arives reliably

115
00:05:35.920 --> 00:05:37.839
<v Speaker 1>or managing a session you should happen.

116
00:05:37.639 --> 00:05:40.079
<v Speaker 2>At the ends on your phone, on the server, not

117
00:05:40.199 --> 00:05:41.360
<v Speaker 2>in the middle of the network.

118
00:05:41.480 --> 00:05:44.360
<v Speaker 1>But cellular networks do put intelligence in the middle, don't they.

119
00:05:44.439 --> 00:05:46.639
<v Speaker 2>They absolutely do. They have to think about it. They

120
00:05:46.639 --> 00:05:49.680
<v Speaker 2>need to know where your phone is, manage battery life

121
00:05:49.759 --> 00:05:50.920
<v Speaker 2>by putting it to sleep.

122
00:05:51.240 --> 00:05:53.199
<v Speaker 1>Stuff. The basic Internet doesn't worry.

123
00:05:53.040 --> 00:05:58.000
<v Speaker 2>About exactly, but building that intelligence, that state management into

124
00:05:58.079 --> 00:06:01.199
<v Speaker 2>the network core that creates rigidity.

125
00:06:00.759 --> 00:06:03.279
<v Speaker 1>And that rigidity that's the weakness.

126
00:06:03.399 --> 00:06:07.519
<v Speaker 2>It creates the opportunity for weakness, especially amplification. Here's why.

127
00:06:08.800 --> 00:06:12.839
<v Speaker 2>In the packet world, the basic unit is one small packet. Okay,

128
00:06:12.959 --> 00:06:16.439
<v Speaker 2>in the cellular world, especially older standards, receiving even one

129
00:06:16.600 --> 00:06:20.720
<v Speaker 2>packet can trigger this expensive, complex sequence of actions to

130
00:06:20.800 --> 00:06:23.480
<v Speaker 2>do what to set up a much larger virtual resource

131
00:06:23.480 --> 00:06:27.160
<v Speaker 2>for your phone, a channel. It allocates resources based on

132
00:06:27.199 --> 00:06:28.240
<v Speaker 2>that old voice model.

133
00:06:28.279 --> 00:06:31.240
<v Speaker 1>So a tiny input triggers a big, heavyweight response from

134
00:06:31.279 --> 00:06:31.759
<v Speaker 1>the network.

135
00:06:32.000 --> 00:06:35.680
<v Speaker 2>Precisely, It's like you knock lightly on a bank vault door,

136
00:06:36.040 --> 00:06:38.279
<v Speaker 2>and instead of just checking who's there, they swing the

137
00:06:38.360 --> 00:06:41.639
<v Speaker 2>whole mass door open, call in extra guards, block off

138
00:06:41.680 --> 00:06:42.160
<v Speaker 2>the hallway.

139
00:06:42.240 --> 00:06:43.480
<v Speaker 1>Okay, I get the analogy.

140
00:06:43.560 --> 00:06:46.480
<v Speaker 2>When an attacker sends thousands of those little knocks, the

141
00:06:46.519 --> 00:06:50.120
<v Speaker 2>network exhausts itself doing these heavyweight setups over and over.

142
00:06:50.319 --> 00:06:52.519
<v Speaker 1>It overreacts based on its rigid design.

143
00:06:52.680 --> 00:06:57.680
<v Speaker 2>That's the amplification exploiting the network's mandatory, expensive procedures.

144
00:06:57.720 --> 00:07:02.120
<v Speaker 1>Okay, let's see this amplification play out the SMS bottleneck attack.

145
00:07:02.560 --> 00:07:04.560
<v Speaker 1>It sounds counterintuitive, it really does.

146
00:07:04.680 --> 00:07:07.759
<v Speaker 2>But yeah, you can weaponize text messages to block voice calls.

147
00:07:07.959 --> 00:07:10.120
<v Speaker 1>How on earth does that work? It seems like such

148
00:07:10.120 --> 00:07:11.000
<v Speaker 1>a basic function.

149
00:07:11.199 --> 00:07:14.279
<v Speaker 2>It works because of a shared resource conflict deep in

150
00:07:14.319 --> 00:07:18.199
<v Speaker 2>the architecture. Both voice calls and incoming SMS messages need

151
00:07:18.240 --> 00:07:20.680
<v Speaker 2>the same thing to get started, which is these things

152
00:07:20.720 --> 00:07:26.800
<v Speaker 2>called standalone dedicated control channels sdcchs. Okay, sdcs, think of

153
00:07:26.839 --> 00:07:29.279
<v Speaker 2>them as the on ramps or the setup coordinators for

154
00:07:29.319 --> 00:07:33.079
<v Speaker 2>the cell tower. Very limited capacity. How limited The sources

155
00:07:33.120 --> 00:07:36.600
<v Speaker 2>give examples like maybe only nine hundred SMS sessions per

156
00:07:36.680 --> 00:07:37.680
<v Speaker 2>hour per channel.

157
00:07:37.959 --> 00:07:40.759
<v Speaker 1>That sounds tiny, especially for a busy city.

158
00:07:40.839 --> 00:07:44.639
<v Speaker 2>It is incredibly low, So the exploit is painfully simple.

159
00:07:44.920 --> 00:07:47.560
<v Speaker 2>An attacker uses just a little bit of bandwidth like

160
00:07:47.600 --> 00:07:50.759
<v Speaker 2>a home internet connection, yeah, comparable to a cable modem.

161
00:07:50.959 --> 00:07:54.240
<v Speaker 2>They just pump enough bogus SMS set up requests into

162
00:07:54.240 --> 00:07:58.000
<v Speaker 2>the network to keep those sdcchs constantly busy.

163
00:07:57.879 --> 00:07:59.839
<v Speaker 1>Like creating a traffic jam on those critical on.

164
00:07:59.839 --> 00:08:04.680
<v Speaker 2>Ramp exactly gridlock. And here's the aha moment. As you said, ye,

165
00:08:05.000 --> 00:08:10.160
<v Speaker 2>once those sdcchs are saturated with fake SMS traffic, they

166
00:08:10.199 --> 00:08:12.000
<v Speaker 2>can't be used to set up voice calls either.

167
00:08:12.199 --> 00:08:15.519
<v Speaker 1>Oh wow, So blocking texts also blocks calls because they

168
00:08:15.560 --> 00:08:16.879
<v Speaker 1>share that initial choke point.

169
00:08:17.040 --> 00:08:20.279
<v Speaker 2>That's it. Legitimate calls, legitimate texts, nothing can get established.

170
00:08:20.360 --> 00:08:21.720
<v Speaker 1>What's the impact In reality?

171
00:08:22.079 --> 00:08:25.519
<v Speaker 2>The researchers modeled this for a major city like Manhattan,

172
00:08:25.560 --> 00:08:28.680
<v Speaker 2>minimal attack resources could block seventy one percent of call and.

173
00:08:28.639 --> 00:08:31.839
<v Speaker 1>Text attempts seventy one percent. That's basically taking the network.

174
00:08:31.560 --> 00:08:34.679
<v Speaker 2>Down pretty much, near total denial of service with almost

175
00:08:34.720 --> 00:08:38.000
<v Speaker 2>no attack or bandwidth, just by exhausting those rigid set

176
00:08:38.039 --> 00:08:38.759
<v Speaker 2>up resources.

177
00:08:38.799 --> 00:08:42.919
<v Speaker 1>And this extends to data too. GPRS edge the older

178
00:08:43.039 --> 00:08:44.320
<v Speaker 1>data standards.

179
00:08:44.039 --> 00:08:48.360
<v Speaker 2>Directly similar principle, different mechanism. Remember the network managing device

180
00:08:48.399 --> 00:08:52.559
<v Speaker 2>states idly standby ready to save battery.

181
00:08:52.919 --> 00:08:53.080
<v Speaker 1>Right.

182
00:08:53.399 --> 00:08:55.600
<v Speaker 2>Getting a device into that ready state where it can

183
00:08:55.600 --> 00:08:59.679
<v Speaker 2>actually send and receive data involves paging it, locating it,

184
00:09:00.000 --> 00:09:03.480
<v Speaker 2>setting up this packet data protocol context. It's expensive for.

185
00:09:03.480 --> 00:09:06.039
<v Speaker 1>The network, lots of overhead each time, right.

186
00:09:06.120 --> 00:09:09.840
<v Speaker 2>So to avoid doing that constantly. The network uses delayed teardown,

187
00:09:10.080 --> 00:09:12.679
<v Speaker 2>meaning it keeps your phone in that costly ready state

188
00:09:12.759 --> 00:09:15.159
<v Speaker 2>for a few seconds after the last data packet goes through,

189
00:09:15.240 --> 00:09:16.440
<v Speaker 2>just in case more data is coming.

190
00:09:16.519 --> 00:09:19.720
<v Speaker 1>Okay, seems sensible, but exploitable highly.

191
00:09:20.159 --> 00:09:23.480
<v Speaker 2>The attacker just needs to send tiny, infrequent data packets to.

192
00:09:23.480 --> 00:09:26.320
<v Speaker 1>Your phone, just enough to reset that timer exactly.

193
00:09:26.720 --> 00:09:29.440
<v Speaker 2>Each tiny packet makes the network think, oh, still active,

194
00:09:29.879 --> 00:09:33.120
<v Speaker 2>and it keeps that expensive ready state along with associated

195
00:09:33.159 --> 00:09:38.919
<v Speaker 2>resources like TBFS and tfis, the traffic channels allocated indefinitely.

196
00:09:38.399 --> 00:09:40.639
<v Speaker 1>Like keeping the bank vault door open with the toothpick.

197
00:09:40.720 --> 00:09:43.000
<v Speaker 2>That's a good way to put it, and the impact

198
00:09:43.039 --> 00:09:45.919
<v Speaker 2>is huge. The analysis showed just one hundred and sixty

199
00:09:45.960 --> 00:09:50.120
<v Speaker 2>kilobits per second of attack praffic. That's minuscule, tiny, It

200
00:09:50.120 --> 00:09:53.679
<v Speaker 2>was enough to block over ninety six percent of legitimate

201
00:09:53.840 --> 00:09:55.840
<v Speaker 2>data requests across Manhattan.

202
00:09:55.919 --> 00:09:57.200
<v Speaker 1>Ninety six percent. Yeah.

203
00:09:57.279 --> 00:10:00.559
<v Speaker 2>Again, the attack isn't flooding the data pipes. It's exhausting

204
00:10:00.600 --> 00:10:04.120
<v Speaker 2>the network's administrative resources, the virtual channels and set up

205
00:10:04.200 --> 00:10:07.159
<v Speaker 2>processes dictated by that rigid state management.

206
00:10:07.279 --> 00:10:11.279
<v Speaker 1>So as we move more towards voiceover IP VoIP and

207
00:10:11.399 --> 00:10:14.759
<v Speaker 1>this ims architecture that's supposed to fix the old rigidity.

208
00:10:14.840 --> 00:10:14.960
<v Speaker 2>Right.

209
00:10:15.039 --> 00:10:17.320
<v Speaker 1>Yeah, moving voice onto packet networks, it.

210
00:10:17.399 --> 00:10:19.799
<v Speaker 2>Solves some old problems, definitely gets rid of some of

211
00:10:19.799 --> 00:10:24.279
<v Speaker 2>that circuit switched baggage, but it inherits a whole new set.

212
00:10:24.039 --> 00:10:26.159
<v Speaker 1>Of problems, problems from the Internet side of things.

213
00:10:26.200 --> 00:10:28.879
<v Speaker 2>Exactly all the lovely security risks we know from the

214
00:10:28.879 --> 00:10:32.039
<v Speaker 2>open Internet now applied directly to voice. Okay, Like what, well,

215
00:10:32.120 --> 00:10:36.399
<v Speaker 2>take call setup. We use protocols like SIP Session Initiation Protocol,

216
00:10:36.679 --> 00:10:40.080
<v Speaker 2>and there's an encrypted version SIPs using TLS.

217
00:10:39.799 --> 00:10:41.440
<v Speaker 1>Like each TTPs for websites.

218
00:10:41.559 --> 00:10:44.360
<v Speaker 2>Sounds secure, it is, but only hop by hop Your

219
00:10:44.440 --> 00:10:47.120
<v Speaker 2>phone connects securely to the first server, that server connects

220
00:10:47.159 --> 00:10:48.039
<v Speaker 2>securely to the next.

221
00:10:48.200 --> 00:10:49.159
<v Speaker 1>What happens at the server?

222
00:10:49.480 --> 00:10:53.200
<v Speaker 2>Ah, that's the catch. At every intermediate proxy server, the

223
00:10:53.279 --> 00:10:56.360
<v Speaker 2>session has to be decrypted, looked at, and then re

224
00:10:56.480 --> 00:10:59.320
<v Speaker 2>encrypted to send it to the next hop. Wait decrypted

225
00:11:00.240 --> 00:11:04.039
<v Speaker 2>in the middle, Yes, which means your supposedly secure call

226
00:11:04.039 --> 00:11:08.480
<v Speaker 2>set up information is exposed in plaintext on potentially many

227
00:11:08.519 --> 00:11:09.360
<v Speaker 2>machines along the.

228
00:11:09.279 --> 00:11:13.200
<v Speaker 1>Path, so malicious insiders or just a compromise server.

229
00:11:13.200 --> 00:11:16.600
<v Speaker 2>Can see everything about the call setup. There's no true

230
00:11:17.039 --> 00:11:18.919
<v Speaker 2>end to end privacy guarantee.

231
00:11:18.440 --> 00:11:21.639
<v Speaker 1>There, What about entrypting the actual voice conversation itself?

232
00:11:21.679 --> 00:11:25.240
<v Speaker 2>For that, we have secure RTP or SRTP that can

233
00:11:25.279 --> 00:11:27.879
<v Speaker 2>provide true end to end encryption of the audio.

234
00:11:28.080 --> 00:11:29.600
<v Speaker 1>But there's always a butt.

235
00:11:29.840 --> 00:11:32.519
<v Speaker 2>The butt is key management. How do you and the

236
00:11:32.519 --> 00:11:35.799
<v Speaker 2>person you're calling securely exchange the encryption keys before the

237
00:11:35.799 --> 00:11:39.279
<v Speaker 2>call starts without someone intercepting them. It's a hard problem.

238
00:11:38.919 --> 00:11:40.440
<v Speaker 1>And sometimes it just doesn't happen.

239
00:11:40.639 --> 00:11:44.200
<v Speaker 2>Worse, the standards often allow endpoints to negotiate down to

240
00:11:44.279 --> 00:11:47.480
<v Speaker 2>using no encryption at all the NUL cipher. So you

241
00:11:47.559 --> 00:11:49.399
<v Speaker 2>might think you're secure, but the call is going out

242
00:11:49.399 --> 00:11:53.320
<v Speaker 2>completely unencrypted. It it seems bad, it's not ideal. But honestly,

243
00:11:55.000 --> 00:12:00.080
<v Speaker 2>beyond these protocol issues, the biggest modern threat is probably.

244
00:11:59.600 --> 00:12:01.440
<v Speaker 1>Malware on the device itself.

245
00:12:01.559 --> 00:12:04.799
<v Speaker 2>Exactly, if your smartphone or your computer gets compromised, it

246
00:12:04.799 --> 00:12:08.320
<v Speaker 2>doesn't matter how good the network encryption is, because.

247
00:12:07.960 --> 00:12:11.879
<v Speaker 1>The malware sees the data before encryption or after decryption.

248
00:12:12.039 --> 00:12:14.399
<v Speaker 2>Precisely, game over for privacy at that point.

249
00:12:14.480 --> 00:12:17.399
<v Speaker 1>Okay, but let's say you avoid malware, you use strong

250
00:12:17.600 --> 00:12:21.879
<v Speaker 1>SRTP with good key exchange. Yeah, are you safe then?

251
00:12:22.440 --> 00:12:26.840
<v Speaker 2>Still maybe not completely hidden. There's this fascinating area of traffic.

252
00:12:26.519 --> 00:12:28.799
<v Speaker 1>Analysis analyzing the encrypted traffic pattern.

253
00:12:28.919 --> 00:12:32.519
<v Speaker 2>Yeah, even perfectly encrypted voice data leaks information. When you

254
00:12:32.559 --> 00:12:35.200
<v Speaker 2>speak different languages, The way voice codecs chop up the

255
00:12:35.240 --> 00:12:38.519
<v Speaker 2>sound results in different patterns of packet sizes, a distinct

256
00:12:38.559 --> 00:12:40.720
<v Speaker 2>packet length profile for each language.

257
00:12:40.759 --> 00:12:43.159
<v Speaker 1>Seriously, you can tell the language just from packet sizes

258
00:12:43.200 --> 00:12:44.519
<v Speaker 1>even if you can't read the content.

259
00:12:44.679 --> 00:12:47.840
<v Speaker 2>The research shows you can with surprisingly high accuracy, up

260
00:12:47.879 --> 00:12:50.799
<v Speaker 2>to ninety percent in some studies. So even if the

261
00:12:50.840 --> 00:12:54.480
<v Speaker 2>content is secret, an observer might figure out what language

262
00:12:54.480 --> 00:12:57.759
<v Speaker 2>you're speaking, which could reveal who you're talking to or

263
00:12:57.759 --> 00:13:02.399
<v Speaker 2>what kind of conversation it is. Sensitive metadata leakage, hashtags,

264
00:13:02.440 --> 00:13:04.080
<v Speaker 2>tag tag outro Okay.

265
00:13:04.120 --> 00:13:07.519
<v Speaker 1>So wrapping this all up, what's the big takeaway from

266
00:13:07.519 --> 00:13:08.360
<v Speaker 1>this deep dive?

267
00:13:09.360 --> 00:13:12.159
<v Speaker 2>I think the central lesson is pretty stark. These really

268
00:13:12.279 --> 00:13:15.519
<v Speaker 2>dangerous vulnerabilities, especially the denial of service ones we talked about.

269
00:13:15.519 --> 00:13:17.240
<v Speaker 1>You have the SMS and data attacks.

270
00:13:17.639 --> 00:13:22.120
<v Speaker 2>They're fundamentally rooted in that architectural rigidity that clash between

271
00:13:22.159 --> 00:13:25.240
<v Speaker 2>the old assumptions of circuit switching and the reality of

272
00:13:25.320 --> 00:13:26.519
<v Speaker 2>flexible packet data.

273
00:13:26.759 --> 00:13:29.879
<v Speaker 1>The network trying to provide old guarantees in a new world.

274
00:13:29.799 --> 00:13:34.279
<v Speaker 2>Exactly, and things like rate limiting SMS messages that's just treating.

275
00:13:33.960 --> 00:13:35.600
<v Speaker 1>A symptom the band aid right.

276
00:13:36.120 --> 00:13:39.960
<v Speaker 2>Real fixes require systemic change, addressing that core problem of

277
00:13:40.000 --> 00:13:44.879
<v Speaker 2>resource amplification and the expensive rigid session handling. Until the

278
00:13:45.000 --> 00:13:48.480
<v Speaker 2>architecture truly modernizes, will likely keep finding these kinds of

279
00:13:48.600 --> 00:13:51.320
<v Speaker 2>low effort, high impact vulnerabilities, which leads.

280
00:13:51.200 --> 00:13:53.159
<v Speaker 1>Us with a final thought, maybe something for you the

281
00:13:53.240 --> 00:13:54.519
<v Speaker 1>listener to think about.

282
00:13:54.840 --> 00:13:58.039
<v Speaker 2>Yeah, the really big challenge now is this convergence SS seven,

283
00:13:58.120 --> 00:14:02.639
<v Speaker 2>the old stuff, IMS, the vulip stuff, and the open Internet.

284
00:14:02.759 --> 00:14:03.960
<v Speaker 2>They all have to talk to each other.

285
00:14:04.000 --> 00:14:06.399
<v Speaker 1>You need your cell phone VoIP call to connect to

286
00:14:06.399 --> 00:14:08.120
<v Speaker 1>Grandma's old landline precisely.

287
00:14:08.639 --> 00:14:13.679
<v Speaker 2>But the security implications of stitching these vastly different systems together, honestly,

288
00:14:13.679 --> 00:14:14.960
<v Speaker 2>they're not fully understood yet.

289
00:14:15.039 --> 00:14:18.159
<v Speaker 1>We're connecting systems with known but different.

290
00:14:17.879 --> 00:14:22.000
<v Speaker 2>Flaws and creating new connection points between them. Could an

291
00:14:22.039 --> 00:14:26.159
<v Speaker 2>attacker exploit a weakness in one system, say the Internet side,

292
00:14:26.240 --> 00:14:29.360
<v Speaker 2>to disrupt traffic in another, like the core phone network.

293
00:14:29.679 --> 00:14:34.080
<v Speaker 2>Through these new gateways across system attack vector Potentially, are

294
00:14:34.120 --> 00:14:37.840
<v Speaker 2>we building something more interconnected but ultimately less resilient than

295
00:14:37.879 --> 00:14:40.879
<v Speaker 2>the sum of its parts. That's the ongoing challenge, ensuring

296
00:14:40.919 --> 00:14:45.039
<v Speaker 2>security without breaking the performance we need for real time communication.

297
00:14:44.720 --> 00:14:46.919
<v Speaker 1>Constant vigilance and research needed there.

298
00:14:47.039 --> 00:14:48.759
<v Speaker 2>Absolutely, the work is far from over