WEBVTT

1
00:00:00.120 --> 00:00:02.600
<v Speaker 1>Welcome to the deep dive. You know, trying to keep

2
00:00:02.720 --> 00:00:07.160
<v Speaker 1>up with cybersecurity and forensics. It can feel like information

3
00:00:07.240 --> 00:00:09.359
<v Speaker 1>overload sometimes it just moves.

4
00:00:09.119 --> 00:00:12.080
<v Speaker 2>So fast, it really does. And we've got this great

5
00:00:12.080 --> 00:00:15.279
<v Speaker 2>collection of sources mostly based around the book Advanced Smart

6
00:00:15.320 --> 00:00:17.600
<v Speaker 2>Computing Technologies and Cybersecurity and.

7
00:00:17.519 --> 00:00:23.600
<v Speaker 1>Forensics, right, and it dives into how tech like AI, IoT, blockchain,

8
00:00:23.760 --> 00:00:28.000
<v Speaker 1>machine learning, how they're not just for defense but really

9
00:00:28.120 --> 00:00:30.519
<v Speaker 1>changing how investigations happen exactly.

10
00:00:30.559 --> 00:00:34.200
<v Speaker 2>It's about securing data and investigating digital crime in totally

11
00:00:34.240 --> 00:00:34.759
<v Speaker 2>new ways.

12
00:00:35.039 --> 00:00:37.520
<v Speaker 1>So our mission here and we're sticking just to what

13
00:00:37.560 --> 00:00:41.759
<v Speaker 1>these sources say, is to pull out the really key insights,

14
00:00:41.759 --> 00:00:42.799
<v Speaker 1>the surprising stuff too.

15
00:00:42.960 --> 00:00:44.960
<v Speaker 2>Yeah, kind of cut through the noise for you. Well,

16
00:00:45.000 --> 00:00:47.799
<v Speaker 2>hit several different areas, but you'll see how they all connect.

17
00:00:47.439 --> 00:00:49.799
<v Speaker 1>Absolutely, Like have you ever really thought about how much

18
00:00:49.880 --> 00:00:52.880
<v Speaker 1>your phone knows and how that could be evidence? Or

19
00:00:53.640 --> 00:00:57.560
<v Speaker 1>how a tiny hardware glitch might completely wreck strong encryption.

20
00:00:58.600 --> 00:01:01.560
<v Speaker 2>We'll get into all of that based purely on this material.

21
00:01:01.640 --> 00:01:03.920
<v Speaker 1>Okay, so where should we start? AI seems like the

22
00:01:04.000 --> 00:01:04.799
<v Speaker 1>obvious place.

23
00:01:04.920 --> 00:01:09.519
<v Speaker 2>It's everywhere, definitely, Let's start with AI, specifically machine learning

24
00:01:09.760 --> 00:01:11.319
<v Speaker 2>mL and deep learning.

25
00:01:11.120 --> 00:01:14.599
<v Speaker 1>DL Okay, the sources jump right in calling mL and

26
00:01:14.680 --> 00:01:17.719
<v Speaker 1>DL well revolutionary for information security.

27
00:01:17.840 --> 00:01:19.719
<v Speaker 2>They really frame it that way. I mean, think about

28
00:01:19.719 --> 00:01:23.959
<v Speaker 2>the sheer volume of security logs, network traffic. It's immense.

29
00:01:24.439 --> 00:01:27.239
<v Speaker 2>These technologies are brilliant at spotting patterns and all.

30
00:01:27.159 --> 00:01:30.400
<v Speaker 1>That patterns like what specifically.

31
00:01:30.079 --> 00:01:34.359
<v Speaker 2>Things like identifying commands used by cyber criminals, predicting potential attacks,

32
00:01:34.640 --> 00:01:37.359
<v Speaker 2>or even flagging malicious programs just by looking at the

33
00:01:37.359 --> 00:01:38.480
<v Speaker 2>structure of the code itself.

34
00:01:38.599 --> 00:01:42.480
<v Speaker 1>That pattern recognition does seem crucial, especially with threats changing constantly.

35
00:01:42.920 --> 00:01:47.079
<v Speaker 1>The sources mentioned processing millions of daily logins filtering threats

36
00:01:47.200 --> 00:01:47.719
<v Speaker 1>much better.

37
00:01:47.879 --> 00:01:51.840
<v Speaker 2>Yeah, higher detection rates and fewer false alarms, fewer false positives.

38
00:01:52.159 --> 00:01:52.840
<v Speaker 2>That's a big deal.

39
00:01:52.840 --> 00:01:54.200
<v Speaker 1>Saves a lot of time and effort, I.

40
00:01:54.120 --> 00:01:57.319
<v Speaker 2>Imagine absolutely, And there are concrete examples, like using it

41
00:01:57.359 --> 00:02:00.840
<v Speaker 2>to spot malware signatures or finding crime patterns hidden in

42
00:02:00.920 --> 00:02:01.799
<v Speaker 2>huge data sets.

43
00:02:01.920 --> 00:02:04.319
<v Speaker 1>The sources mentioned some of the specific tech names too,

44
00:02:04.439 --> 00:02:08.199
<v Speaker 1>like convolutional neural networks RNNs gns.

45
00:02:08.599 --> 00:02:13.080
<v Speaker 2>Yeah, convents where current neural networks generative adversarial networks. We

46
00:02:13.120 --> 00:02:15.560
<v Speaker 2>don't need to deep dive on how they work, but

47
00:02:15.800 --> 00:02:18.120
<v Speaker 2>just knowing the terms helps you know.

48
00:02:18.159 --> 00:02:19.719
<v Speaker 1>Right, it gives you a sense of the complexity.

49
00:02:19.960 --> 00:02:23.240
<v Speaker 2>But here's where it gets really, really interesting and maybe

50
00:02:23.280 --> 00:02:27.560
<v Speaker 2>a bit unsettling. Even these super powerful DL models, the

51
00:02:27.560 --> 00:02:30.680
<v Speaker 2>ones built for security, they could be attacked too.

52
00:02:30.879 --> 00:02:33.240
<v Speaker 1>Wait, you can attack the AI model itself, not just

53
00:02:33.319 --> 00:02:35.719
<v Speaker 1>the system it's protecting. How does that even work?

54
00:02:35.879 --> 00:02:38.080
<v Speaker 2>Well, the sources lay out a few ways. One is

55
00:02:38.120 --> 00:02:41.879
<v Speaker 2>called data poisoning. Basically, you sneak bad data into the

56
00:02:41.879 --> 00:02:42.400
<v Speaker 2>training set.

57
00:02:42.599 --> 00:02:45.680
<v Speaker 1>To bad data like fake information.

58
00:02:45.360 --> 00:02:48.719
<v Speaker 2>Exactly inaccurate stuff, so the model learns the wrong lessons

59
00:02:49.159 --> 00:02:52.479
<v Speaker 2>or its decision lines get shifted, making it misclassify things later.

60
00:02:52.719 --> 00:02:56.199
<v Speaker 1>Huh, So you're corrupting it from the inside during training precisely.

61
00:02:56.280 --> 00:02:59.639
<v Speaker 2>Then there are backdoor attacks. This is clever. An attacker

62
00:02:59.840 --> 00:03:02.400
<v Speaker 2>in beds a kind of hidden trigger into the model.

63
00:03:02.520 --> 00:03:05.400
<v Speaker 2>A trigger, yeah, like a secret pattern or connection. The

64
00:03:05.400 --> 00:03:07.479
<v Speaker 2>model works normally most of the time, but if the

65
00:03:07.479 --> 00:03:10.879
<v Speaker 2>attacker sends an input with that specific trigger, boom, the

66
00:03:10.919 --> 00:03:12.159
<v Speaker 2>model does something malicious.

67
00:03:12.400 --> 00:03:15.400
<v Speaker 1>Wow, like a sleeper agent inside the AI. That's kind

68
00:03:15.400 --> 00:03:16.479
<v Speaker 1>of scary, it is.

69
00:03:16.919 --> 00:03:19.919
<v Speaker 2>And the third one is adversarial examples. The source calls

70
00:03:19.919 --> 00:03:22.360
<v Speaker 2>them visual illusions. For computers.

71
00:03:22.840 --> 00:03:24.120
<v Speaker 1>Visual illusion think of.

72
00:03:24.120 --> 00:03:26.960
<v Speaker 2>An image or some input that looks perfectly fine to

73
00:03:27.039 --> 00:03:32.240
<v Speaker 2>us humans, but it has tiny, almost invisible changes deliberately

74
00:03:32.240 --> 00:03:34.280
<v Speaker 2>crafted to fool the algorithm.

75
00:03:34.479 --> 00:03:37.400
<v Speaker 1>So you slightly tweak something and the AI suddenly thinks

76
00:03:37.400 --> 00:03:40.120
<v Speaker 1>a stop sign is a I don't know a cat.

77
00:03:40.000 --> 00:03:42.639
<v Speaker 2>Sort of yeah, it causes the AI to make a

78
00:03:42.680 --> 00:03:47.000
<v Speaker 2>mistake of misclassification, even though the change is minuscule to us.

79
00:03:47.400 --> 00:03:50.639
<v Speaker 1>So the tools we build for defense create their own unique,

80
00:03:50.840 --> 00:03:53.639
<v Speaker 1>subtle weak spots. That feels like a constant theme here.

81
00:03:53.719 --> 00:03:56.240
<v Speaker 2>It absolutely is. Yeah, you can't just build the AI.

82
00:03:56.400 --> 00:03:59.240
<v Speaker 2>You have to constantly think about securing the AI itself.

83
00:03:59.400 --> 00:04:02.159
<v Speaker 1>It's arms, and it's not just these abstract models, right,

84
00:04:02.199 --> 00:04:04.759
<v Speaker 1>It's about securing the actual devices we use every day,

85
00:04:04.879 --> 00:04:06.719
<v Speaker 1>our phones, the systems they connect to.

86
00:04:06.879 --> 00:04:10.159
<v Speaker 2>Exactly, which brings us nicely to well, the devices in

87
00:04:10.199 --> 00:04:12.199
<v Speaker 2>our pockets. Mobile forensics.

88
00:04:12.400 --> 00:04:15.520
<v Speaker 1>Ah yeah. Chapter four calls phones treasure troves of evidence,

89
00:04:15.759 --> 00:04:20.240
<v Speaker 1>and it makes perfect sense. Smartphones log everything, apps, web history,

90
00:04:20.279 --> 00:04:21.920
<v Speaker 1>purchases where you've been.

91
00:04:22.279 --> 00:04:27.120
<v Speaker 2>So much more than old feature phones. The sources listed out, contacts, messages,

92
00:04:27.240 --> 00:04:31.279
<v Speaker 2>call logs, web history, social media activity. It's an incredibly

93
00:04:31.319 --> 00:04:32.959
<v Speaker 2>detailed digital diary.

94
00:04:32.800 --> 00:04:35.399
<v Speaker 1>And the AI the MLDL stuff we just talked about

95
00:04:35.639 --> 00:04:37.360
<v Speaker 1>that comes back here in the forensics part.

96
00:04:37.439 --> 00:04:40.879
<v Speaker 2>Right, analyzing all that mobile data, you can use mL

97
00:04:40.959 --> 00:04:43.920
<v Speaker 2>to trace crime patterns, maybe figure out someone's sentiment from

98
00:04:43.920 --> 00:04:46.800
<v Speaker 2>their texts, or analyze images found on the device.

99
00:04:47.199 --> 00:04:49.959
<v Speaker 1>There's that example with the word clouds from group chats,

100
00:04:50.399 --> 00:04:54.399
<v Speaker 1>visualizing common keywords. Could be drugs, could be anything illicit.

101
00:04:54.639 --> 00:04:57.279
<v Speaker 2>Yeah, it's a neat way to quickly spot potential leads

102
00:04:57.279 --> 00:04:59.399
<v Speaker 2>in huge volumes of text messages.

103
00:04:59.519 --> 00:05:02.759
<v Speaker 1>And there's case study about the fraudster using hacked email

104
00:05:02.800 --> 00:05:06.000
<v Speaker 1>details shows how critical these digital trails on phones and

105
00:05:06.079 --> 00:05:06.920
<v Speaker 1>email really are.

106
00:05:07.120 --> 00:05:10.040
<v Speaker 2>Definitely, but phones don't live in isolation anymore, so much

107
00:05:10.040 --> 00:05:11.399
<v Speaker 2>happens in the cloud, right.

108
00:05:11.360 --> 00:05:15.199
<v Speaker 1>Mobile cloud computing MCC, where the storage and the heavy

109
00:05:15.240 --> 00:05:16.839
<v Speaker 1>processing happens off the device.

110
00:05:17.160 --> 00:05:20.240
<v Speaker 2>YEP. Chapter twelve explains it just like that, your phone

111
00:05:20.319 --> 00:05:22.519
<v Speaker 2>becomes more of an interface to cloud services.

112
00:05:22.639 --> 00:05:24.879
<v Speaker 1>But that creates its own set of problems, doesn't it.

113
00:05:25.120 --> 00:05:29.959
<v Speaker 1>The source mentions MCC environments are really distributed, always changing.

114
00:05:29.839 --> 00:05:33.800
<v Speaker 2>Exactly, so a simple centralized security design just doesn't work well.

115
00:05:33.879 --> 00:05:36.600
<v Speaker 2>You need something scalable, adaptable.

116
00:05:36.279 --> 00:05:39.560
<v Speaker 1>And other challenges pop up too, like a battery life

117
00:05:39.560 --> 00:05:42.560
<v Speaker 1>on the phone, keeping data secure and private when it's

118
00:05:42.600 --> 00:05:45.439
<v Speaker 1>bouncing around, keeping users happy with performance.

119
00:05:45.480 --> 00:05:47.800
<v Speaker 2>It's a long list. Quality of service is a big one, yea.

120
00:05:47.879 --> 00:05:50.920
<v Speaker 2>The source talks about using dynamic device info, mobile agents,

121
00:05:50.959 --> 00:05:53.319
<v Speaker 2>things like that to try and tighten up access control

122
00:05:53.360 --> 00:05:54.560
<v Speaker 2>and keep data confidential.

123
00:05:54.920 --> 00:05:57.199
<v Speaker 1>Okay, so from the single phone we move up. Let's

124
00:05:57.199 --> 00:05:59.279
<v Speaker 1>scale up even more smart cities.

125
00:05:59.639 --> 00:06:03.040
<v Speaker 2>Right. Chapter seven defines a smart city as more than

126
00:06:03.160 --> 00:06:07.839
<v Speaker 2>just connected. It's about using technology ICT for better administration,

127
00:06:08.360 --> 00:06:12.879
<v Speaker 2>managing resources. Safety like those intelligent traffic lights that adapt

128
00:06:12.879 --> 00:06:13.600
<v Speaker 2>to traffic.

129
00:06:13.319 --> 00:06:16.360
<v Speaker 1>Flow and sensors are key here, right. IoT devices everywhere

130
00:06:16.399 --> 00:06:18.360
<v Speaker 1>collecting data absolutely fundamental.

131
00:06:18.639 --> 00:06:22.600
<v Speaker 2>Now that's the huge security challenge securing this massive network

132
00:06:22.839 --> 00:06:27.800
<v Speaker 2>of often quite simple, low power IoT devices. How do

133
00:06:27.839 --> 00:06:30.920
<v Speaker 2>you stop malware spreading? How do you protect all the

134
00:06:31.000 --> 00:06:32.319
<v Speaker 2>data they generate.

135
00:06:32.079 --> 00:06:34.759
<v Speaker 1>Especially when those devices might not have much processing power

136
00:06:34.800 --> 00:06:36.480
<v Speaker 1>for complex security themselves.

137
00:06:36.879 --> 00:06:41.000
<v Speaker 2>Precisely so, privacy protection often needs to happen efficiently, maybe

138
00:06:41.360 --> 00:06:44.319
<v Speaker 2>closer to the device or user you need, things like

139
00:06:44.399 --> 00:06:47.839
<v Speaker 2>data minimization, only collect what you need, and really tight

140
00:06:47.879 --> 00:06:48.680
<v Speaker 2>access controls.

141
00:06:48.720 --> 00:06:51.759
<v Speaker 1>The source also mentions that trend away from passwords towards

142
00:06:51.800 --> 00:06:55.959
<v Speaker 1>biometrics like facial recognition, which has its own security implications

143
00:06:56.000 --> 00:06:56.920
<v Speaker 1>of course for sure.

144
00:06:57.040 --> 00:07:00.759
<v Speaker 2>And even within the smart city infrastructure, the cloud systems

145
00:07:00.800 --> 00:07:05.839
<v Speaker 2>they rely on have vulnerabilities, misconfigurations, weak access management. These

146
00:07:05.839 --> 00:07:07.240
<v Speaker 2>are common problems.

147
00:07:06.839 --> 00:07:09.199
<v Speaker 1>Mentioned, and it connects back to recent events too, like

148
00:07:09.360 --> 00:07:13.199
<v Speaker 1>the pandemic pushing faster digital transformation and cloud use forcing

149
00:07:13.240 --> 00:07:14.959
<v Speaker 1>a rethink of security policies.

150
00:07:15.040 --> 00:07:18.319
<v Speaker 2>It's all interconnected, the device, the network, the cloud, the

151
00:07:18.360 --> 00:07:19.319
<v Speaker 2>city infrastructure.

152
00:07:19.519 --> 00:07:22.079
<v Speaker 1>Okay, so we've gone from the phone to the city.

153
00:07:22.639 --> 00:07:25.399
<v Speaker 1>What about digging right down into the computer itself, like

154
00:07:25.480 --> 00:07:26.560
<v Speaker 1>the absolute core.

155
00:07:26.759 --> 00:07:29.319
<v Speaker 2>Ah, you mean the kernel. Chapter five calls it the

156
00:07:29.319 --> 00:07:32.040
<v Speaker 2>heart of the operating system. It's that crucial piece of

157
00:07:32.079 --> 00:07:35.439
<v Speaker 2>software connecting the hardware and all the other software always

158
00:07:35.480 --> 00:07:35.959
<v Speaker 2>running the.

159
00:07:35.920 --> 00:07:38.319
<v Speaker 1>Bit we don't directly interact with. We just see the logs.

160
00:07:38.519 --> 00:07:41.160
<v Speaker 1>And they're different types, right, micro monolithic.

161
00:07:40.800 --> 00:07:46.360
<v Speaker 2>YEP, micro monolithic, XO, hybrid nanokernels are mentioned, different design philosophies.

162
00:07:46.480 --> 00:07:49.120
<v Speaker 1>So how do you assess risk down at that level?

163
00:07:49.240 --> 00:07:52.120
<v Speaker 1>If there's a vulnerability in the kernel that seems really bad,

164
00:07:52.439 --> 00:07:53.439
<v Speaker 1>it can be very serious.

165
00:07:53.759 --> 00:07:56.399
<v Speaker 2>That's where the sources bring in the Common Vulnerability Scoring

166
00:07:56.439 --> 00:07:57.560
<v Speaker 2>System CBSS.

167
00:07:57.720 --> 00:08:00.000
<v Speaker 1>CBSS. Okay, what's that? Do just give it a score

168
00:08:00.079 --> 00:08:00.480
<v Speaker 1>out of ten.

169
00:08:00.639 --> 00:08:02.319
<v Speaker 2>It's a bit more nuanced than that, but yeah, it

170
00:08:02.360 --> 00:08:05.759
<v Speaker 2>provides a standardized score. It helps prioritize. It looks at

171
00:08:05.759 --> 00:08:10.079
<v Speaker 2>things called base metrics, characteristics of the vulnerability itself, like.

172
00:08:10.120 --> 00:08:13.040
<v Speaker 1>How easy it is to exploit exactly.

173
00:08:12.600 --> 00:08:14.439
<v Speaker 2>Like the attack vector. Does the attacker need to be

174
00:08:14.480 --> 00:08:18.160
<v Speaker 2>local or can they do it remotely? Attack complexity, how

175
00:08:18.199 --> 00:08:21.639
<v Speaker 2>hard is it? Privileges require? Do they need admin rights already?

176
00:08:22.000 --> 00:08:25.399
<v Speaker 2>User interaction? Does the user need to click something? Scope?

177
00:08:25.480 --> 00:08:28.079
<v Speaker 2>Does exploiting this affect other parts of the system?

178
00:08:28.160 --> 00:08:30.800
<v Speaker 1>Okay, that makes sense? And then there's the impact.

179
00:08:30.480 --> 00:08:33.120
<v Speaker 2>Right, the impact metrics? Yeah, what gets damaged if it

180
00:08:33.159 --> 00:08:37.600
<v Speaker 2>is exploited? Confidentiality? Is secret data exposed? Integrity? Can data

181
00:08:37.639 --> 00:08:40.320
<v Speaker 2>be changed? Availability? Does a crash the system?

182
00:08:40.519 --> 00:08:43.279
<v Speaker 1>So CBSS weighs all those factors to give a score.

183
00:08:43.799 --> 00:08:45.320
<v Speaker 1>Helps defenders figure out what to.

184
00:08:45.279 --> 00:08:48.559
<v Speaker 2>Patch first, precisely and guess what comes up again? Here?

185
00:08:48.679 --> 00:08:50.480
<v Speaker 1>Let me guess? Machine learning?

186
00:08:50.679 --> 00:08:54.320
<v Speaker 2>You got it. Chapter five mentions using mL, specifically an

187
00:08:54.320 --> 00:08:58.799
<v Speaker 2>algorithm called random forest to analyze kernel vulnerabilities. They can

188
00:08:58.840 --> 00:09:01.399
<v Speaker 2>even build a model to predict the potential score or risk.

189
00:09:01.559 --> 00:09:05.799
<v Speaker 1>Wow, using AI to analyze the core OS code for weaknesses.

190
00:09:06.000 --> 00:09:09.240
<v Speaker 2>Yeah, and they talk about tuning the algorithm, adjusting parameters

191
00:09:09.279 --> 00:09:11.519
<v Speaker 2>like the number of decision trees to make the prediction better.

192
00:09:11.799 --> 00:09:14.159
<v Speaker 2>It shows how deep these computational techniques go.

193
00:09:14.519 --> 00:09:19.039
<v Speaker 1>It really does, from AI attacking AI, to AI analyzing

194
00:09:19.120 --> 00:09:24.639
<v Speaker 1>kernels to something completely different DNA cryptography using DNA. That

195
00:09:24.679 --> 00:09:25.120
<v Speaker 1>sounds like.

196
00:09:25.080 --> 00:09:27.159
<v Speaker 2>Sci fi It does, doesn't it, But it's right there

197
00:09:27.159 --> 00:09:30.399
<v Speaker 2>in chapter three, it's fascinating. They start by explaining standard

198
00:09:30.440 --> 00:09:31.320
<v Speaker 2>crypto first though.

199
00:09:31.399 --> 00:09:33.480
<v Speaker 1>Okay, yeah, symmetric versus asymmetric.

200
00:09:33.639 --> 00:09:37.000
<v Speaker 2>Right, Symmetric uses the same key for locking and unlocking

201
00:09:37.240 --> 00:09:41.000
<v Speaker 2>like AES. Simple, but if that one key gets out,

202
00:09:41.240 --> 00:09:42.000
<v Speaker 2>you're exposed.

203
00:09:42.279 --> 00:09:44.320
<v Speaker 1>That's the man in the middle attack risk if someone

204
00:09:44.360 --> 00:09:46.159
<v Speaker 1>intercepts the key being shared exactly.

205
00:09:46.240 --> 00:09:50.240
<v Speaker 2>Asymmetric is different. I think RISA two keys, a public

206
00:09:50.279 --> 00:09:52.639
<v Speaker 2>one everyone can use to encrypt messages to you, like

207
00:09:52.679 --> 00:09:55.240
<v Speaker 2>a mailbox slot and a private one, only you have

208
00:09:55.320 --> 00:09:55.919
<v Speaker 2>to decrypt them.

209
00:09:56.039 --> 00:09:59.039
<v Speaker 1>Mailbox key much safer for key sharing because the private

210
00:09:59.080 --> 00:10:01.840
<v Speaker 1>key never needs to be te transmitted. So DNA how

211
00:10:01.840 --> 00:10:02.480
<v Speaker 1>does that fit in?

212
00:10:02.559 --> 00:10:05.279
<v Speaker 2>Well? Chapter three mentions Leonard Adelman's work back in ninety

213
00:10:05.279 --> 00:10:08.759
<v Speaker 2>four using actual DNA strands to solve complex math problems.

214
00:10:08.879 --> 00:10:10.759
<v Speaker 1>Really actual biological DNA.

215
00:10:10.960 --> 00:10:14.279
<v Speaker 2>Yeah, and DNA cryptography bills on that idea. It proposes

216
00:10:14.519 --> 00:10:18.960
<v Speaker 2>using the structure of DNA, the ACGT bases to encode data.

217
00:10:19.039 --> 00:10:21.600
<v Speaker 1>So instead of zeros and ones, you're using combinations of

218
00:10:21.639 --> 00:10:26.799
<v Speaker 1>ACG and T. Maybe mapping binary to base pairs like

219
00:10:27.279 --> 00:10:29.600
<v Speaker 1>A is zero zero, C is zero one.

220
00:10:29.759 --> 00:10:33.399
<v Speaker 2>That's one method they described. Yes, the y is interesting too.

221
00:10:33.759 --> 00:10:37.360
<v Speaker 2>DNA offers potentially massive data storage in a tiny space,

222
00:10:37.919 --> 00:10:42.039
<v Speaker 2>ultra compact, the source says, and huge potential for parallel processing.

223
00:10:42.159 --> 00:10:43.279
<v Speaker 1>Parallel processing.

224
00:10:43.320 --> 00:10:46.759
<v Speaker 2>Yeah, I imagine billions or trillions of DNA strands processing

225
00:10:46.799 --> 00:10:50.000
<v Speaker 2>information simultaneously compared to transistors on a chip. It's a

226
00:10:50.000 --> 00:10:50.639
<v Speaker 2>different scale.

227
00:10:50.799 --> 00:10:54.159
<v Speaker 1>Okay, huge storage, massive parallelism sounds good.

228
00:10:54.399 --> 00:10:57.840
<v Speaker 2>What about security, The sources argue it could be very robust,

229
00:10:57.960 --> 00:11:00.440
<v Speaker 2>especially against things like frequency analysis.

230
00:11:00.039 --> 00:11:02.840
<v Speaker 1>Where attackers guess key is based on how often letters appear.

231
00:11:03.080 --> 00:11:06.879
<v Speaker 2>Right. The proposed DNA system uses compression first, like Hoffman coding,

232
00:11:07.039 --> 00:11:10.600
<v Speaker 2>then transforms the text into these DNA sequences or binary strings.

233
00:11:10.879 --> 00:11:14.240
<v Speaker 2>The example they use makes the final distribution of ACEGT

234
00:11:14.480 --> 00:11:16.159
<v Speaker 2>bases almost perfectly uniform.

235
00:11:16.360 --> 00:11:19.080
<v Speaker 1>Ah, So if all the letters appear equally often. The

236
00:11:19.120 --> 00:11:22.000
<v Speaker 1>attacker can't learn anything from frequency. It hides the original

237
00:11:22.080 --> 00:11:23.080
<v Speaker 1>pattern exactly.

238
00:11:23.159 --> 00:11:24.559
<v Speaker 2>It makes guessing much harder.

239
00:11:24.799 --> 00:11:27.360
<v Speaker 1>Now. The detail that really stuck with me from that

240
00:11:27.480 --> 00:11:30.120
<v Speaker 1>chapter the encryption key example.

241
00:11:30.240 --> 00:11:33.679
<v Speaker 2>Oh yeah, left slightly the finic fox.

242
00:11:34.840 --> 00:11:38.799
<v Speaker 1>The key was based on the genes of a finic fox. Volpaserta.

243
00:11:39.559 --> 00:11:42.519
<v Speaker 1>Why a finic fox is their a reason the.

244
00:11:42.440 --> 00:11:45.159
<v Speaker 2>Source just uses as the example key. It ties into

245
00:11:45.200 --> 00:11:49.240
<v Speaker 2>the biological theme obviously. But yeah, the specific choice seems

246
00:11:49.240 --> 00:11:51.440
<v Speaker 2>a bit random, but memorable.

247
00:11:51.600 --> 00:11:53.919
<v Speaker 1>Definitely memorable. And they didn't just leave it as a theory,

248
00:11:54.000 --> 00:11:55.559
<v Speaker 1>right They tried building something.

249
00:11:55.639 --> 00:11:58.679
<v Speaker 2>Yeah, they mentioned trying a hardware implementation using artweno, some

250
00:11:58.720 --> 00:12:02.679
<v Speaker 2>wireless stuff sensors, even visualizing it with node red for

251
00:12:03.200 --> 00:12:05.759
<v Speaker 2>IoT monitoring. So they were exploring if it could.

252
00:12:05.639 --> 00:12:09.039
<v Speaker 1>Be practical from biological theory to our Dueno boards. That's

253
00:12:09.279 --> 00:12:09.960
<v Speaker 1>quite a leap.

254
00:12:10.039 --> 00:12:11.279
<v Speaker 2>It really covers a lot of ground.

255
00:12:11.399 --> 00:12:13.600
<v Speaker 1>So let's maybe touch on a couple more areas where

256
00:12:13.600 --> 00:12:16.200
<v Speaker 1>this attack defense dynamic plays out, maybe back at the

257
00:12:16.200 --> 00:12:16.879
<v Speaker 1>hardware level.

258
00:12:16.960 --> 00:12:20.279
<v Speaker 2>Okay, yeah, back to IoT devices. Chapter fourteen brings up

259
00:12:20.320 --> 00:12:23.799
<v Speaker 2>fault analysis attacks or FA fault analysis.

260
00:12:23.840 --> 00:12:25.799
<v Speaker 1>What's it sounds it often is.

261
00:12:26.559 --> 00:12:29.799
<v Speaker 2>It's not about network breaches, but about messing with the

262
00:12:29.840 --> 00:12:36.000
<v Speaker 2>device's operation. You deliberately inject faults maybe voltage glitches, clock

263
00:12:36.080 --> 00:12:39.200
<v Speaker 2>manipulation lasers, even while it's doing cryptography.

264
00:12:39.320 --> 00:12:40.279
<v Speaker 1>Why would you do that?

265
00:12:40.720 --> 00:12:44.480
<v Speaker 2>Because causing calculation errors can sometimes make the device leak

266
00:12:44.559 --> 00:12:48.120
<v Speaker 2>information about the secret keys it's using. The faulty output

267
00:12:48.159 --> 00:12:49.240
<v Speaker 2>gives clues.

268
00:12:48.919 --> 00:12:51.480
<v Speaker 1>And for IoT devices, especially ones out in the open,

269
00:12:51.559 --> 00:12:55.039
<v Speaker 1>like you said, cameras or sensors, physical access might be easier,

270
00:12:55.240 --> 00:12:56.960
<v Speaker 1>making fault injections simpler.

271
00:12:57.240 --> 00:13:00.320
<v Speaker 2>That's a major concern raised in the source. Yes, even

272
00:13:00.360 --> 00:13:03.600
<v Speaker 2>if they use lightweight crypto designed for low power, fa

273
00:13:03.679 --> 00:13:06.519
<v Speaker 2>can bypass it. If you can physically mess with the device.

274
00:13:06.279 --> 00:13:08.000
<v Speaker 1>So how do you stop that? Put everything in a

275
00:13:08.039 --> 00:13:09.000
<v Speaker 1>tamper proof box.

276
00:13:09.120 --> 00:13:12.080
<v Speaker 2>That helps. But the source also talks about detecting the

277
00:13:12.080 --> 00:13:17.799
<v Speaker 2>faults electronically techniques like concurrent Error Detection ced CED. It

278
00:13:17.840 --> 00:13:20.720
<v Speaker 2>relies on redundancy. Maybe you do the calculation twice and

279
00:13:20.759 --> 00:13:25.080
<v Speaker 2>compare results, or use redundant hardware or special data encoding.

280
00:13:25.279 --> 00:13:27.879
<v Speaker 2>If a fault occurs, the redundancy lets you spot the error.

281
00:13:28.000 --> 00:13:30.279
<v Speaker 1>Ah okay, so you build in checks to see if

282
00:13:30.279 --> 00:13:31.440
<v Speaker 1>someone's glitching the system.

283
00:13:31.759 --> 00:13:35.320
<v Speaker 2>Basically, yes, Now let's make a really big shift from

284
00:13:35.440 --> 00:13:41.000
<v Speaker 2>hardware faults to people. The human side of investigations.

285
00:13:41.159 --> 00:13:45.240
<v Speaker 1>You mean interrogating suspects. That feels miles away from DNA crypto.

286
00:13:45.440 --> 00:13:49.000
<v Speaker 2>It is, but Chapter thirteen argues it's crucial. You can

287
00:13:49.039 --> 00:13:52.039
<v Speaker 2>have all the fancy digital forensics in the world, but

288
00:13:52.080 --> 00:13:55.279
<v Speaker 2>if the human investigation is flawed or the evidence isn't

289
00:13:55.320 --> 00:13:59.639
<v Speaker 2>handled right legally, it falls apart. The source calls interrogation

290
00:13:59.679 --> 00:14:00.039
<v Speaker 2>proceed to.

291
00:14:00.600 --> 00:14:03.759
<v Speaker 1>Disputable, highlighting how tricky it is. It mentioned stages right,

292
00:14:03.919 --> 00:14:07.600
<v Speaker 1>initial investigators, then maybe a review panel, a disciplinary committee

293
00:14:07.639 --> 00:14:08.159
<v Speaker 1>for insiders.

294
00:14:08.240 --> 00:14:11.039
<v Speaker 2>Yeah, there's a flow chart showing a process, but the

295
00:14:11.159 --> 00:14:15.679
<v Speaker 2>huge emphasis is on independence, following local laws, following un standards,

296
00:14:15.879 --> 00:14:19.759
<v Speaker 2>no intimidation, no harassment, definitely, no torture or public humiliation,

297
00:14:20.279 --> 00:14:21.320
<v Speaker 2>basic human rights.

298
00:14:21.440 --> 00:14:23.879
<v Speaker 1>But even with rules, it sounds like there are massive challenges.

299
00:14:23.960 --> 00:14:26.919
<v Speaker 2>Oh. Absolutely. The source list things like suspects just walking

300
00:14:26.919 --> 00:14:31.440
<v Speaker 2>out or causing disruptions, investigators resigning because cases get bungled politically,

301
00:14:31.799 --> 00:14:34.519
<v Speaker 2>and just finding witnesses. People are scared, they get threatened,

302
00:14:34.639 --> 00:14:36.799
<v Speaker 2>or they just can't afford to keep showing up for court.

303
00:14:36.799 --> 00:14:40.159
<v Speaker 1>If they're low income, really practical difficult problems.

304
00:14:39.960 --> 00:14:42.039
<v Speaker 2>Very much so. And there's a really stark line in

305
00:14:42.080 --> 00:14:44.399
<v Speaker 2>there too about how the death of a key suspect

306
00:14:44.440 --> 00:14:46.200
<v Speaker 2>can just end the whole case.

307
00:14:46.360 --> 00:14:48.799
<v Speaker 1>Boof wow, that just stops everything.

308
00:14:48.960 --> 00:14:52.440
<v Speaker 2>Yeah. So the chapter ends by calling for basically better

309
00:14:52.480 --> 00:14:56.159
<v Speaker 2>ways to conduct interrogations that are effective but still fully

310
00:14:56.200 --> 00:14:58.279
<v Speaker 2>legal and ethical under un standards.

311
00:14:58.919 --> 00:15:02.480
<v Speaker 1>It's a sobering room that technology is only one part

312
00:15:02.519 --> 00:15:06.279
<v Speaker 1>of the puzzle, the human element, the legal framework.

313
00:15:06.799 --> 00:15:09.759
<v Speaker 2>Just as critical couldn't agree more. This deep dive has

314
00:15:09.840 --> 00:15:11.720
<v Speaker 2>really covered a lot of ground, hasn't it.

315
00:15:11.720 --> 00:15:13.679
<v Speaker 1>It really has when you pull it all together. We've

316
00:15:13.679 --> 00:15:18.200
<v Speaker 1>seen advanced computing as this powerful force for both attack

317
00:15:18.240 --> 00:15:21.919
<v Speaker 1>and defense, from AI fighting AI down to kernel code

318
00:15:21.960 --> 00:15:24.399
<v Speaker 1>and tiny IoT hardware flaws, looked.

319
00:15:24.200 --> 00:15:27.840
<v Speaker 2>At uncovering digital lives on phones, the complexities of smart cities,

320
00:15:28.039 --> 00:15:31.840
<v Speaker 2>and even futuristic ideas like DNA encryption, and briefly touched

321
00:15:31.840 --> 00:15:33.960
<v Speaker 2>on quantum computing's potential role too.

322
00:15:33.960 --> 00:15:36.519
<v Speaker 1>And then contrasted all that tech with the very human,

323
00:15:36.720 --> 00:15:40.279
<v Speaker 1>very challenging process of actually investigating the people behind the screens.

324
00:15:40.759 --> 00:15:44.600
<v Speaker 2>It really highlights that cybersecurity and forensics are these incredibly

325
00:15:44.639 --> 00:15:49.559
<v Speaker 2>dynamic fields. Every advance creates new opportunities, but also new vulnerabilities.

326
00:15:49.600 --> 00:15:50.600
<v Speaker 2>It never stands still.

327
00:15:50.679 --> 00:15:54.480
<v Speaker 1>Yeah, and understanding all these layers, from the AI down

328
00:15:54.519 --> 00:15:58.000
<v Speaker 1>to the hardware, the code, the legal stuff, it feels

329
00:15:58.080 --> 00:16:00.600
<v Speaker 1>essential just to navigate the world to which is what

330
00:16:00.639 --> 00:16:02.480
<v Speaker 1>these sources really help unpack.

331
00:16:02.759 --> 00:16:04.559
<v Speaker 2>It definitely leaves you with a lot to think about

332
00:16:04.639 --> 00:16:06.600
<v Speaker 2>regarding the future trajectory, It really does.

333
00:16:06.799 --> 00:16:09.320
<v Speaker 1>Yeah, you know, thinking about how fast AI is moving,

334
00:16:09.399 --> 00:16:12.759
<v Speaker 1>quantum computing on the horizon, the absolute explosion of data

335
00:16:12.840 --> 00:16:16.000
<v Speaker 1>from smart devices, smart cities. Are we heading for a

336
00:16:16.039 --> 00:16:19.440
<v Speaker 1>future where cyber defense is less about people looking at

337
00:16:19.480 --> 00:16:23.679
<v Speaker 1>logs and more about AIS battling other ais at machine speed?

338
00:16:24.000 --> 00:16:26.960
<v Speaker 1>And if so, what does that future look like for privacy,

339
00:16:27.159 --> 00:16:29.919
<v Speaker 1>for trusting these systems, for accountability when things go wrong

340
00:16:29.960 --> 00:16:32.399
<v Speaker 1>at that speed and scale. Well, it's a lot to

341
00:16:32.480 --> 00:16:32.799
<v Speaker 1>chew on.