WEBVTT

1
00:00:00.120 --> 00:00:03.240
<v Speaker 1>Welcome to the deep dive. Today, we're looking into something

2
00:00:03.279 --> 00:00:06.879
<v Speaker 1>that's changing almost everything around us, often without us even noticing.

3
00:00:07.440 --> 00:00:11.919
<v Speaker 1>Think about technology getting smaller, faster, woven into everyday objects.

4
00:00:12.359 --> 00:00:14.640
<v Speaker 1>It reminds me of Mark Weiser's idea, you know, that

5
00:00:14.880 --> 00:00:17.440
<v Speaker 1>tech would weave itself into life until it's just there,

6
00:00:17.920 --> 00:00:21.280
<v Speaker 1>like ubiquitous computing, the Internet of things, all aimed at

7
00:00:21.320 --> 00:00:24.920
<v Speaker 1>making things easier, safer, maybe more comfortable, and right at

8
00:00:24.920 --> 00:00:27.719
<v Speaker 1>the heart of this, maybe even more disruptive than we realize.

9
00:00:27.760 --> 00:00:31.519
<v Speaker 1>Like electricity was is RFID radio frequency identification.

10
00:00:31.839 --> 00:00:34.520
<v Speaker 2>That's a great way to put it. The vision is powerful,

11
00:00:34.679 --> 00:00:38.679
<v Speaker 2>seamless convenience, but it definitely comes with some big strings attached.

12
00:00:39.039 --> 00:00:41.240
<v Speaker 2>So for this deep dive, we're really going to focus

13
00:00:41.240 --> 00:00:44.840
<v Speaker 2>on the security and privacy side of RFID. We're leaning

14
00:00:44.880 --> 00:00:49.960
<v Speaker 2>heavily on a key academic source, RFID security and privacy concepts, protocols,

15
00:00:50.000 --> 00:00:52.759
<v Speaker 2>and architectures. Our goal is basically to pull out the

16
00:00:52.840 --> 00:00:55.200
<v Speaker 2>essential insights, you know, to help understand the challenges and

17
00:00:55.240 --> 00:00:56.840
<v Speaker 2>the solutions being worked on right now.

18
00:00:57.000 --> 00:01:01.640
<v Speaker 1>Absolutely, because this goes way beyond just scanning groceries or

19
00:01:01.840 --> 00:01:05.079
<v Speaker 1>tracking boxes in a warehouse. We're talking about tags, potentially

20
00:01:05.079 --> 00:01:07.760
<v Speaker 1>being in your clothes, your passport, your money, and what

21
00:01:07.799 --> 00:01:09.359
<v Speaker 1>happens when all the things start talking.

22
00:01:09.519 --> 00:01:13.000
<v Speaker 2>Okay, let's unpack this. So RFID one oh one it's

23
00:01:13.040 --> 00:01:18.159
<v Speaker 2>about identifying objects using radio waves electromagnetically different from barcodes, right,

24
00:01:18.400 --> 00:01:19.920
<v Speaker 2>no need for line of sight. You can read them

25
00:01:19.920 --> 00:01:22.359
<v Speaker 2>from a distance, read lots at once, and things like

26
00:01:22.480 --> 00:01:24.760
<v Speaker 2>dust or grime don't stop them. You've basically got the

27
00:01:24.760 --> 00:01:27.680
<v Speaker 2>tag itself, the reader device, and then the computer systems

28
00:01:27.680 --> 00:01:29.519
<v Speaker 2>in the back managing the data exactly.

29
00:01:29.719 --> 00:01:32.760
<v Speaker 1>And that convenience, that ease of reading, well, that's also

30
00:01:32.799 --> 00:01:35.159
<v Speaker 1>its weakness in a way. It makes the service easy

31
00:01:35.159 --> 00:01:37.640
<v Speaker 1>to disrupt, and it throws up all sorts of red

32
00:01:37.640 --> 00:01:42.000
<v Speaker 1>flags for data security and crucially privacy. It's kind of

33
00:01:42.000 --> 00:01:45.439
<v Speaker 1>fascinating how this simple id tex spirals into these really

34
00:01:45.480 --> 00:01:48.640
<v Speaker 1>complex security questions. So quickly, let's look at the tags,

35
00:01:48.760 --> 00:01:51.760
<v Speaker 1>usually an antenna, a microchip, some kind of plastic coding.

36
00:01:51.879 --> 00:01:55.319
<v Speaker 1>And the big difference is passive versus active tags. Passive

37
00:01:55.359 --> 00:01:58.319
<v Speaker 1>tags no battery, they just get power from the reader's

38
00:01:58.319 --> 00:02:01.400
<v Speaker 1>signal when it's close. The cheap ones, the most common

39
00:02:01.439 --> 00:02:04.879
<v Speaker 1>but short range active tags, they have their own battery.

40
00:02:05.359 --> 00:02:08.159
<v Speaker 1>Longer range, more features, but yeah, they cost more and

41
00:02:08.240 --> 00:02:11.080
<v Speaker 1>the battery runs out. Essentially, we'll mostly focus on passive

42
00:02:11.080 --> 00:02:13.719
<v Speaker 1>ones because honestly they're the ones likely to be everywhere.

43
00:02:14.319 --> 00:02:18.000
<v Speaker 2>And even within passive tags there's variations. Some are super simple,

44
00:02:18.159 --> 00:02:20.439
<v Speaker 2>like maybe an anti theft tag with just one bit

45
00:02:20.479 --> 00:02:22.759
<v Speaker 2>of memory. Is that there are not Others can hold

46
00:02:22.960 --> 00:02:26.400
<v Speaker 2>kilobytes of data, different memory types to read only, write once,

47
00:02:26.439 --> 00:02:28.960
<v Speaker 2>read many, or worm as you mentioned, which is useful

48
00:02:29.000 --> 00:02:31.800
<v Speaker 2>for permanent records. Then you have read write tags, and

49
00:02:31.879 --> 00:02:34.599
<v Speaker 2>some cutting edge ones even have tiny e paper displays.

50
00:02:35.039 --> 00:02:37.759
<v Speaker 2>Imagine a price tag that updates wirelessly but holds the

51
00:02:37.800 --> 00:02:38.759
<v Speaker 2>image without power.

52
00:02:39.000 --> 00:02:43.159
<v Speaker 1>Pretty neat, and the economics are key here. Tag costs

53
00:02:43.439 --> 00:02:45.919
<v Speaker 1>right now maybe ten to fifty cents, but the projection

54
00:02:46.080 --> 00:02:48.439
<v Speaker 1>is well weigh down below five cents, maybe even one

55
00:02:48.439 --> 00:02:50.639
<v Speaker 1>cent in the next five years or so. When they're

56
00:02:50.680 --> 00:02:53.479
<v Speaker 1>that cheap, putting them on almost anything becomes practical.

57
00:02:53.840 --> 00:02:57.520
<v Speaker 2>Communication wise, it's layered sort of like network protocols, physical layer,

58
00:02:57.560 --> 00:03:02.960
<v Speaker 2>link layer, application layer, and they use different radio frequencies LFHF, UAHF, microwave.

59
00:03:03.280 --> 00:03:06.280
<v Speaker 2>This effects antenna size, range, how well they work near

60
00:03:06.319 --> 00:03:09.840
<v Speaker 2>metal or liquids, and This is important evesdropping range with

61
00:03:10.000 --> 00:03:12.599
<v Speaker 2>UHF the reader talking to the tag the forward channel.

62
00:03:12.879 --> 00:03:16.479
<v Speaker 2>Theoretically someone could listen in from maybe a kilometer away

63
00:03:16.800 --> 00:03:20.080
<v Speaker 2>and the tag talking back maybe one hundred meters a kilometer.

64
00:03:20.120 --> 00:03:22.840
<v Speaker 1>Wow. Okay, that definitely puts the privacy concerns into perspective.

65
00:03:23.039 --> 00:03:25.919
<v Speaker 1>So how do they handle reading, say, a whole shopping

66
00:03:25.960 --> 00:03:28.879
<v Speaker 1>cart full of tag items at once, without it being chaos?

67
00:03:29.159 --> 00:03:33.280
<v Speaker 2>Uugh? That's anti collision algorithms clever stuff. They let the

68
00:03:33.319 --> 00:03:37.080
<v Speaker 2>readers sort through signals from many tags quickly. Some are probabilistic,

69
00:03:37.280 --> 00:03:40.479
<v Speaker 2>like aloha, relying on tags responding at random times to

70
00:03:40.599 --> 00:03:44.120
<v Speaker 2>avoid talking over each other. Others are deterministic, like binary

71
00:03:44.120 --> 00:03:47.680
<v Speaker 2>tree walking, where the reader systematically isolates each tag. The

72
00:03:47.800 --> 00:03:50.639
<v Speaker 2>goal is bulk reading hundreds of tags per second.

73
00:03:50.800 --> 00:03:54.039
<v Speaker 1>So wrapping this foundation part up, what does it all

74
00:03:54.080 --> 00:03:57.159
<v Speaker 1>mean for you the listener? These features, especially that potential

75
00:03:57.199 --> 00:04:00.000
<v Speaker 1>for long range gas dropping and bulk reading, well, they

76
00:04:00.080 --> 00:04:02.479
<v Speaker 1>really opened the door to some serious privacy issues. We

77
00:04:02.520 --> 00:04:05.120
<v Speaker 1>need to dig into privacy. This is where it gets

78
00:04:05.199 --> 00:04:07.960
<v Speaker 1>really interesting and maybe a little concerning the idea of

79
00:04:08.000 --> 00:04:11.840
<v Speaker 1>privacy isn't new is? It goes way back early Hebrew culture,

80
00:04:11.960 --> 00:04:15.639
<v Speaker 1>ancient Greece, even old English law from the thirteen hundreds

81
00:04:15.639 --> 00:04:18.920
<v Speaker 1>targeting eavesdroppers, and that famous line from seventeen sixty three,

82
00:04:19.000 --> 00:04:22.560
<v Speaker 1>my home is my castle, protecting your physical space exactly.

83
00:04:22.959 --> 00:04:26.199
<v Speaker 2>And then a huge moment was that eighteen ninety article

84
00:04:26.240 --> 00:04:29.319
<v Speaker 2>by Warren and brandised the right to privacy. They gave

85
00:04:29.399 --> 00:04:32.120
<v Speaker 2>us that classic definition, the right to be let alone.

86
00:04:32.199 --> 00:04:35.279
<v Speaker 2>What's so insightful is how they saw technology. Back then.

87
00:04:35.319 --> 00:04:38.759
<v Speaker 2>It was photography and newspapers changing things. Privacy wasn't just

88
00:04:38.800 --> 00:04:43.040
<v Speaker 2>about physical trespasses anymore. It was about protecting your spiritual nature,

89
00:04:43.160 --> 00:04:47.720
<v Speaker 2>your thoughts, your feelings from unwanted public exposure. The definition

90
00:04:47.800 --> 00:04:48.480
<v Speaker 2>had to evolve.

91
00:04:48.639 --> 00:04:52.399
<v Speaker 1>Yeah, and that definition broadened. It's about wanting physical space, sure,

92
00:04:52.600 --> 00:04:56.040
<v Speaker 1>but also being free from interruption, embarrassment, and controlling how

93
00:04:56.079 --> 00:04:58.920
<v Speaker 1>and when your personal information gets shared in different facets right,

94
00:04:59.079 --> 00:05:03.639
<v Speaker 1>territorial privacy, you're space, bodily privacy yourself, communication privacy or calls, emails,

95
00:05:03.879 --> 00:05:05.759
<v Speaker 1>and information privacy your data.

96
00:05:05.800 --> 00:05:08.040
<v Speaker 2>We always say knowledge is valuable when you can apply it,

97
00:05:08.399 --> 00:05:11.560
<v Speaker 2>but privacy makes this really hard today. Why think about

98
00:05:11.560 --> 00:05:16.199
<v Speaker 2>tech trends. Everything's getting smaller, embedded in things, networked everywhere.

99
00:05:16.399 --> 00:05:20.399
<v Speaker 2>Combine that with huge data storage powerful processing, it means

100
00:05:20.439 --> 00:05:24.040
<v Speaker 2>collecting and analyzing info about individuals on a scale never

101
00:05:24.079 --> 00:05:27.959
<v Speaker 2>seen before. So the potential for data misuse, for privacy

102
00:05:27.959 --> 00:05:29.560
<v Speaker 2>invasion is just growing and growing.

103
00:05:29.680 --> 00:05:31.879
<v Speaker 1>You see it everywhere, the data shadows you leave, from

104
00:05:31.920 --> 00:05:35.079
<v Speaker 1>credit cards, your phone, CCTV cameras. There's this quote from

105
00:05:35.079 --> 00:05:37.879
<v Speaker 1>a German paper, pretty blunt in the bedroom. The Germans

106
00:05:37.920 --> 00:05:40.560
<v Speaker 1>are afraid of peeping Tom's at the sales calendar. They

107
00:05:40.560 --> 00:05:43.360
<v Speaker 1>become exhbibionists. It kind of captures that tension, doesn't it.

108
00:05:43.399 --> 00:05:48.560
<v Speaker 1>And governments are collecting more to DNA, biometrics, RFIDs and passports,

109
00:05:48.879 --> 00:05:49.959
<v Speaker 1>health cards.

110
00:05:49.920 --> 00:05:52.920
<v Speaker 2>And that fuels this societal fear, this worry about a

111
00:05:52.959 --> 00:05:57.079
<v Speaker 2>surveillance society emerging where personal freedom gets chipped away. It

112
00:05:57.120 --> 00:06:00.800
<v Speaker 2>creates an imbalance of knowledge, which means analans of power,

113
00:06:01.240 --> 00:06:04.519
<v Speaker 2>and that makes people uncomfortable. Understandably, it raises a really

114
00:06:04.560 --> 00:06:07.879
<v Speaker 2>fundamental question. If you reach a point where you can't

115
00:06:07.920 --> 00:06:12.439
<v Speaker 2>realistically opt out of being tagged or tracked, what happens

116
00:06:12.439 --> 00:06:13.360
<v Speaker 2>to self determination?

117
00:06:14.160 --> 00:06:16.519
<v Speaker 1>So how do we manage this? How do we regulate

118
00:06:16.519 --> 00:06:19.040
<v Speaker 1>privacy in this context? The source talks about three main

119
00:06:19.079 --> 00:06:23.160
<v Speaker 1>ways self regulation by industry, which let's be honest, often

120
00:06:23.199 --> 00:06:27.839
<v Speaker 1>fall short. Then there's legal regulation, laws and rules, and finally,

121
00:06:27.920 --> 00:06:31.120
<v Speaker 1>technical regulation sometimes called privacy by design.

122
00:06:31.360 --> 00:06:34.199
<v Speaker 2>And that last one, privacy by design is arguably the

123
00:06:34.240 --> 00:06:37.439
<v Speaker 2>most proactive. The idea is to build privacy safeguards right

124
00:06:37.519 --> 00:06:40.519
<v Speaker 2>into the technologies architecture from the start. It shouldn't be

125
00:06:40.560 --> 00:06:43.759
<v Speaker 2>an afterthought. It's about making systems transparent and usable so

126
00:06:43.800 --> 00:06:47.000
<v Speaker 2>people can actually trust them, knowing privacy is a core feature,

127
00:06:47.279 --> 00:06:48.600
<v Speaker 2>not just a policy add on.

128
00:06:48.959 --> 00:06:51.920
<v Speaker 1>Okay, So with privacy as the backdrop, let's shift to

129
00:06:51.920 --> 00:06:55.680
<v Speaker 1>the attackers who might want to exploit RFID systems and

130
00:06:55.759 --> 00:06:59.399
<v Speaker 1>how there is even that slightly dramatic quote sometimes used

131
00:06:59.439 --> 00:07:04.160
<v Speaker 1>from rebel about the mark. Yeah, it underscores that potential

132
00:07:04.199 --> 00:07:05.600
<v Speaker 1>for control right well.

133
00:07:05.639 --> 00:07:09.120
<v Speaker 2>Putting aside biblical prophecy, the common threats are pretty grounded,

134
00:07:09.439 --> 00:07:12.639
<v Speaker 2>illegitimate reading, just accessing tag data you're not supposed to,

135
00:07:13.199 --> 00:07:16.920
<v Speaker 2>and eavesdropping listening in on that radio communication which is

136
00:07:16.959 --> 00:07:18.439
<v Speaker 2>often happening out in the open air.

137
00:07:18.560 --> 00:07:22.279
<v Speaker 1>Then there's mimicking or cloning tags, making a copy. If

138
00:07:22.279 --> 00:07:24.879
<v Speaker 1>you can copy a tag, you could potentially trick a system.

139
00:07:25.680 --> 00:07:28.040
<v Speaker 1>Taking a clone can be hard, especially if the tag

140
00:07:28.079 --> 00:07:30.680
<v Speaker 1>doesn't have complex internal states that change over time.

141
00:07:31.040 --> 00:07:32.959
<v Speaker 2>But maybe the most concerning from a day to day

142
00:07:33.000 --> 00:07:37.720
<v Speaker 2>privacy perspective is unwanted recognition and tracking. Our fid's job

143
00:07:37.800 --> 00:07:40.439
<v Speaker 2>is to identify stuff, but that can easily be turned

144
00:07:40.439 --> 00:07:43.279
<v Speaker 2>into tracking people by the tag items they carry, especially

145
00:07:43.319 --> 00:07:46.680
<v Speaker 2>as readers become ubiquitous in doorways, lampposts, stores and get

146
00:07:46.720 --> 00:07:49.959
<v Speaker 2>a network together. And this loops back to that critical question.

147
00:07:50.360 --> 00:07:53.920
<v Speaker 2>If carrying tags becomes unavoidable, how do you possibly protect

148
00:07:53.920 --> 00:07:55.759
<v Speaker 2>your privacy, your location right.

149
00:07:55.800 --> 00:07:59.959
<v Speaker 1>And beyond data thefter tracking, there's simple disruption, denial of service.

150
00:08:00.439 --> 00:08:03.879
<v Speaker 1>You'd physically destroy tags, shield them like those Faraday cage

151
00:08:03.879 --> 00:08:06.600
<v Speaker 1>walls people use for chip cards, or you could just

152
00:08:06.720 --> 00:08:09.959
<v Speaker 1>jam the radio frequencies the readers and tags use, basically

153
00:08:10.000 --> 00:08:11.680
<v Speaker 1>shouting over those they can't communicate.

154
00:08:11.800 --> 00:08:14.720
<v Speaker 2>Our source uses this helpful model, sort of like characters

155
00:08:14.720 --> 00:08:18.079
<v Speaker 2>in a play, to describe attackers based on their capabilities.

156
00:08:18.480 --> 00:08:22.959
<v Speaker 2>It simplifies things nicely. First, Eve Magna think of her

157
00:08:23.000 --> 00:08:26.480
<v Speaker 2>as the passive listener. She just observed the communication back

158
00:08:26.480 --> 00:08:30.480
<v Speaker 2>and forth, trying to grab identifying info. Then Denise, she's

159
00:08:30.519 --> 00:08:34.120
<v Speaker 2>the disruptor. She actively messes with the system, maybe jamming

160
00:08:34.200 --> 00:08:38.440
<v Speaker 2>signals temporarily or just physically destroying tags. Norma is more

161
00:08:38.480 --> 00:08:42.000
<v Speaker 2>active with data. She can query tags like a legitimate reader,

162
00:08:42.120 --> 00:08:45.360
<v Speaker 2>get the public data and potentially use that to mimic

163
00:08:45.399 --> 00:08:48.159
<v Speaker 2>a real tag. Mallory is the really powerful one. She

164
00:08:48.159 --> 00:08:51.320
<v Speaker 2>can intercept messages, change them, delete them. She can exploit

165
00:08:51.399 --> 00:08:54.519
<v Speaker 2>flaws to cause trouble, denial of service, even tricky side

166
00:08:54.600 --> 00:08:57.960
<v Speaker 2>channel attacks to get secret data. And finally, Phyllis she

167
00:08:58.080 --> 00:09:00.440
<v Speaker 2>represents the physical threat, someone who can act actually get

168
00:09:00.440 --> 00:09:03.200
<v Speaker 2>their hands on a tag and physically extract data from

169
00:09:03.200 --> 00:09:04.000
<v Speaker 2>the chip itself.

170
00:09:04.159 --> 00:09:06.840
<v Speaker 1>So it escalates, doesn't it From just listening in to

171
00:09:07.120 --> 00:09:10.600
<v Speaker 1>actively messing with things to outright physical tampering. It's quite

172
00:09:10.600 --> 00:09:12.360
<v Speaker 1>a spectrum of threats.

173
00:09:12.240 --> 00:09:16.320
<v Speaker 2>Absolutely, so to counter these threats, the main goals when

174
00:09:16.360 --> 00:09:21.360
<v Speaker 2>designing secure RFID systems are keeping data secure obviously preventing counterfitting,

175
00:09:21.399 --> 00:09:24.600
<v Speaker 2>stopping unauthorized access, preventing that on one and tracking we

176
00:09:24.639 --> 00:09:27.759
<v Speaker 2>talked about, and being resilient against denial of service.

177
00:09:27.480 --> 00:09:30.399
<v Speaker 1>Attacks, and a key strategy for achieving this, especially the

178
00:09:30.440 --> 00:09:34.120
<v Speaker 1>security part, is often deciding not to store sensitive data

179
00:09:34.159 --> 00:09:36.639
<v Speaker 1>on the tag itself, instead keep it in the back

180
00:09:36.720 --> 00:09:40.039
<v Speaker 1>end systems coy. Let's unpack that. Why is that better? Well?

181
00:09:40.240 --> 00:09:43.440
<v Speaker 2>Several reasons. Flexibility, it's easier to update data in essential

182
00:09:43.519 --> 00:09:48.039
<v Speaker 2>database cost, tag memory is limited and adds expense. But crucially,

183
00:09:48.200 --> 00:09:51.840
<v Speaker 2>security data sitting on the tag is just more vulnerable.

184
00:09:51.879 --> 00:09:55.080
<v Speaker 2>Isn't it vulnerable to physical attacks like Phyllis might attempt

185
00:09:55.240 --> 00:09:59.039
<v Speaker 2>the protocol weakness's Mallory could exploit, or just simple eavesdropping

186
00:09:59.080 --> 00:10:02.679
<v Speaker 2>by eve Magna. Keeping sensitive data off the tag reduces

187
00:10:02.720 --> 00:10:06.039
<v Speaker 2>the attack surface. Now, to secure the communication that does happen,

188
00:10:06.120 --> 00:10:10.240
<v Speaker 2>we rely on cryptographic building blocks. Hash functions are fundamental here.

189
00:10:10.279 --> 00:10:13.519
<v Speaker 2>They're like one way digital fingerprints, easy to create a

190
00:10:13.519 --> 00:10:16.279
<v Speaker 2>hash from data, but practically impossible to go backward from

191
00:10:16.279 --> 00:10:18.440
<v Speaker 2>the hash to the original data. We use them for

192
00:10:18.480 --> 00:10:21.559
<v Speaker 2>integrity checks, making sure a message hasn't been altered, but

193
00:10:21.720 --> 00:10:24.759
<v Speaker 2>implementing even these on tiny, low power tags is a

194
00:10:24.799 --> 00:10:28.840
<v Speaker 2>real challenge. Standard algorithms like SAHA one might need thousands

195
00:10:28.840 --> 00:10:31.639
<v Speaker 2>of logic gates. It's a constant trade off between security

196
00:10:31.679 --> 00:10:34.080
<v Speaker 2>strength and what you can physically fit on a cheap tag.

197
00:10:34.240 --> 00:10:38.240
<v Speaker 1>So the tags need basic functions identification, who are you, authentication,

198
00:10:38.399 --> 00:10:42.440
<v Speaker 1>prove it, and maybe modification changing data but you mentioned

199
00:10:42.440 --> 00:10:46.120
<v Speaker 1>a big hurdle for passive tags. They have no clock,

200
00:10:46.639 --> 00:10:49.679
<v Speaker 1>no internal time source. That makes standard time based security

201
00:10:49.799 --> 00:10:52.759
<v Speaker 1>tricky because if a reader provides the time, an attacker

202
00:10:52.799 --> 00:10:54.240
<v Speaker 1>could just fake that timing.

203
00:10:53.960 --> 00:10:58.000
<v Speaker 2>Info right precisely. It complicates things like preventing replay attacks.

204
00:10:58.240 --> 00:11:01.759
<v Speaker 2>And to tackle unwanted tracking, the key idea is identify

205
00:11:01.840 --> 00:11:04.919
<v Speaker 2>or modification. You have to make the tag change its

206
00:11:04.919 --> 00:11:08.279
<v Speaker 2>apparent ID regularly, because even if the data is encrypted,

207
00:11:08.279 --> 00:11:10.840
<v Speaker 2>if the tag always shuts the same encrypted ID, it

208
00:11:10.840 --> 00:11:14.000
<v Speaker 2>can still be tracked across different locations just by recognizing

209
00:11:14.000 --> 00:11:14.960
<v Speaker 2>that constant signal.

210
00:11:15.240 --> 00:11:18.200
<v Speaker 1>Are there other ways to add security? Maybe not using radio?

211
00:11:18.559 --> 00:11:22.279
<v Speaker 2>Yes, you could use alternative channels, maybe optical codes printed

212
00:11:22.320 --> 00:11:24.840
<v Speaker 2>on an item, or tiny light sensors on the tag,

213
00:11:25.159 --> 00:11:28.799
<v Speaker 2>physical contact points, even using things like temperature changes, but

214
00:11:28.879 --> 00:11:32.480
<v Speaker 2>they all involve trade offs, usually inconvenience. Wireless is just

215
00:11:32.600 --> 00:11:36.480
<v Speaker 2>so much easier. Okay, let's look at some specific protocol

216
00:11:36.519 --> 00:11:39.879
<v Speaker 2>ideas aiming to solve these problems. One is hash based

217
00:11:39.919 --> 00:11:43.639
<v Speaker 2>ID variation. It uses those hash functions we mentioned to

218
00:11:43.679 --> 00:11:49.639
<v Speaker 2>handle identification, authentication, and that crucial ID modification for privacy. Essentially,

219
00:11:49.639 --> 00:11:52.879
<v Speaker 2>the tag calculates a new ID for every interaction, often

220
00:11:52.960 --> 00:11:55.320
<v Speaker 2>using a transaction counter from the reader and its own

221
00:11:55.320 --> 00:11:58.440
<v Speaker 2>internal state to keep things synchronized and resist attacks where

222
00:11:58.440 --> 00:12:02.159
<v Speaker 2>someone just replays an old message and importantly updating the

223
00:12:02.200 --> 00:12:04.639
<v Speaker 2>ID and the internal state has to be atomic, happen

224
00:12:04.679 --> 00:12:07.120
<v Speaker 2>all at once or not at all to prevent sink issues.

225
00:12:07.440 --> 00:12:09.919
<v Speaker 1>How does that compare to something like triggered hash chains.

226
00:12:09.960 --> 00:12:11.600
<v Speaker 1>I've heard that mentioned too, ugh.

227
00:12:12.080 --> 00:12:16.000
<v Speaker 2>Triggered hash chains, it's considered more elegant mathematically speaking. It

228
00:12:16.039 --> 00:12:19.720
<v Speaker 2>offers strong properties like indistinguishability, making tags look random and alike,

229
00:12:19.759 --> 00:12:24.399
<v Speaker 2>and forward secrecy compromising a key later doesn't reveal past communications,

230
00:12:24.879 --> 00:12:26.279
<v Speaker 2>very desirable properties.

231
00:12:26.600 --> 00:12:28.559
<v Speaker 1>But there's always a butt, isn't there?

232
00:12:28.679 --> 00:12:31.720
<v Speaker 2>There often is. Here's where it gets tricky. The big

233
00:12:31.799 --> 00:12:36.080
<v Speaker 2>drawback is scalability. The complexity grows really fast quadratically o

234
00:12:36.320 --> 00:12:40.120
<v Speaker 2>N two with the number of tags. Why mainly synchronization problems.

235
00:12:40.559 --> 00:12:43.639
<v Speaker 2>If a tag talks to different raiders or messages get lost,

236
00:12:43.679 --> 00:12:45.600
<v Speaker 2>it can easily fall out of sync with the back

237
00:12:45.679 --> 00:12:49.240
<v Speaker 2>end database, which then can't identify it efficiently. People have

238
00:12:49.240 --> 00:12:51.360
<v Speaker 2>tried optimizing it, but the core issue is kind of

239
00:12:51.399 --> 00:12:55.960
<v Speaker 2>baked into the design. So elegant, yes, practical for billions

240
00:12:56.000 --> 00:12:57.519
<v Speaker 2>of tags. Hmmm, probably not.

241
00:12:57.759 --> 00:13:00.600
<v Speaker 1>So it's that classic trade off again, perfect secure versus

242
00:13:00.639 --> 00:13:02.919
<v Speaker 1>something that actually works at massive scale.

243
00:13:02.639 --> 00:13:07.519
<v Speaker 2>Exactly now, shifting focus slightly, what about preventing counterfitting, especially

244
00:13:07.600 --> 00:13:10.600
<v Speaker 2>for cheaper items where you can't afford crypto on the tag.

245
00:13:11.240 --> 00:13:15.559
<v Speaker 2>One approach is policy restricted key value pair authentication. It

246
00:13:15.679 --> 00:13:18.159
<v Speaker 2>uses lists of unique codes on the back end linked

247
00:13:18.159 --> 00:13:21.039
<v Speaker 2>to policies to verify tags without needing the tag itself

248
00:13:21.080 --> 00:13:23.840
<v Speaker 2>to do heavy crypto. And then there's a really fascinating

249
00:13:23.879 --> 00:13:28.360
<v Speaker 2>area physical unclonable functions or PUFs. The idea here is

250
00:13:28.399 --> 00:13:32.200
<v Speaker 2>to use the tiny unavoidable variations in the manufacturing process

251
00:13:32.200 --> 00:13:35.720
<v Speaker 2>of the chip itself as a unique unclonable fingerprint, like

252
00:13:35.879 --> 00:13:39.960
<v Speaker 2>microscopic differences in the silicon. It requires far fewer resources

253
00:13:39.960 --> 00:13:42.679
<v Speaker 2>on the tag than traditional crypto, making it potentially great

254
00:13:42.759 --> 00:13:44.120
<v Speaker 2>for low cost authentication.

255
00:13:44.480 --> 00:13:46.919
<v Speaker 1>Okay, so we have these protocols for tags and readers. Yeah,

256
00:13:46.919 --> 00:13:49.720
<v Speaker 1>what about the overall system architecture? How is that evolving?

257
00:13:49.720 --> 00:13:52.399
<v Speaker 1>We've moved beyond just a simple tag reader database model,

258
00:13:52.440 --> 00:13:52.759
<v Speaker 1>haven't we?

259
00:13:52.919 --> 00:13:57.679
<v Speaker 2>Definitely models now incorporate untrusted reading entities. Think maybe your

260
00:13:57.960 --> 00:14:01.320
<v Speaker 2>own smartphone reading a tag, not just an official store reader,

261
00:14:01.720 --> 00:14:04.519
<v Speaker 2>and there's more focus on a push principle for data,

262
00:14:04.639 --> 00:14:08.200
<v Speaker 2>where information is shared proactively rather than just pulled on demand.

263
00:14:08.440 --> 00:14:12.200
<v Speaker 2>And critically, there's this distinction between the tag owner the

264
00:14:12.240 --> 00:14:15.240
<v Speaker 2>company that deployed the tag, and the tag bearer that's you,

265
00:14:15.440 --> 00:14:18.799
<v Speaker 2>the person carrying the tag item. Recognizing the bear as

266
00:14:18.840 --> 00:14:22.840
<v Speaker 2>a distinct entity is vital for addressing consumer control and privacy.

267
00:14:23.279 --> 00:14:25.919
<v Speaker 2>It forces us to ask, how do we manage data

268
00:14:25.919 --> 00:14:28.639
<v Speaker 2>flow when the person carrying a tag isn't the one

269
00:14:28.679 --> 00:14:29.759
<v Speaker 2>who owns the system.

270
00:14:29.879 --> 00:14:32.159
<v Speaker 1>That distinction feels really important. So if I'm the bear,

271
00:14:32.240 --> 00:14:34.480
<v Speaker 1>how do I get control? This leads to the idea

272
00:14:34.519 --> 00:14:37.000
<v Speaker 1>of a personal manager, right, like maybe an app on

273
00:14:37.039 --> 00:14:39.039
<v Speaker 1>my phone that keeps track of the tags I'm carrying

274
00:14:39.039 --> 00:14:41.200
<v Speaker 1>and lets me set rules about who can read them

275
00:14:41.320 --> 00:14:44.200
<v Speaker 1>or access related data like my location, a sort of

276
00:14:44.200 --> 00:14:45.360
<v Speaker 1>personal data gatekeeper.

277
00:14:45.559 --> 00:14:48.840
<v Speaker 2>Precisely, it's about putting some control back in the hands

278
00:14:48.879 --> 00:14:51.480
<v Speaker 2>of the individual and building on that we get to

279
00:14:51.480 --> 00:14:55.039
<v Speaker 2>the ID zone architecture. This is a really interesting attempt

280
00:14:55.080 --> 00:14:59.159
<v Speaker 2>to balance privacy and practicality. The core idea is maybe

281
00:14:59.159 --> 00:15:02.799
<v Speaker 2>you don't need the app solute maximum privacy everywhere inside

282
00:15:02.799 --> 00:15:06.679
<v Speaker 2>a specific zone like a supermarket. Perhaps the privacy requirements

283
00:15:06.720 --> 00:15:10.559
<v Speaker 2>can be slightly relaxed for efficiency, so tag identifiers might

284
00:15:10.600 --> 00:15:13.799
<v Speaker 2>change automatically when you cross a location zone boundary entering

285
00:15:13.919 --> 00:15:17.279
<v Speaker 2>or leaving the store, for example. Within a zone, epoch

286
00:15:17.279 --> 00:15:21.000
<v Speaker 2>announcements from readers can help tags update their identifiers efficiently

287
00:15:21.080 --> 00:15:25.720
<v Speaker 2>without constant back and forth communication, saving battery and reducing networkload.

288
00:15:26.000 --> 00:15:28.759
<v Speaker 1>So the ID zone architecture tries to be pragmatic. What

289
00:15:28.840 --> 00:15:31.519
<v Speaker 1>are the upsides? Sounds like decent security, pretty good privacy

290
00:15:31.559 --> 00:15:35.159
<v Speaker 1>because id still change, just maybe less frequently inside a zone.

291
00:15:35.279 --> 00:15:39.039
<v Speaker 1>Good performance, maybe less drain on tag power, and potentially

292
00:15:39.039 --> 00:15:41.159
<v Speaker 1>automatic so you don't have to contantly manage it. It

293
00:15:41.200 --> 00:15:43.840
<v Speaker 1>could make the system feel transparent while still offering protection.

294
00:15:44.120 --> 00:15:47.799
<v Speaker 2>That's the goal. Good security, effective privacy tailor to context,

295
00:15:47.960 --> 00:15:52.240
<v Speaker 2>good performance, and user friendliness. But like any complex system,

296
00:15:52.360 --> 00:15:55.919
<v Speaker 2>challenges remain. You need solid failover mechanisms if parts of

297
00:15:55.960 --> 00:15:59.840
<v Speaker 2>the system go down. And even with these sophisticated techniques,

298
00:16:00.080 --> 00:16:03.399
<v Speaker 2>the source acknowledge is that current hash based pseudonymization might

299
00:16:03.480 --> 00:16:07.919
<v Speaker 2>not offer bulletproof long term privacy against a really determined

300
00:16:08.000 --> 00:16:11.919
<v Speaker 2>adversary collecting data over years it's an ongoing arms race.

301
00:16:12.440 --> 00:16:14.440
<v Speaker 1>So as we wrap up this deep dive, it's clear

302
00:16:14.559 --> 00:16:18.360
<v Speaker 1>our fight is incredibly powerful, huge potential for making things smoother,

303
00:16:18.600 --> 00:16:21.159
<v Speaker 1>more efficient, but we've also seen it brings these really

304
00:16:21.200 --> 00:16:25.559
<v Speaker 1>deep challenges around security and maybe most fundamentally, are personal privacy.

305
00:16:25.600 --> 00:16:29.120
<v Speaker 2>Absolutely, research is constantly evolving. The solutions we've discussed, hash

306
00:16:29.159 --> 00:16:32.679
<v Speaker 2>based ID variation, triggered hashchains, PuF, the ADZE, and architecture.

307
00:16:32.679 --> 00:16:37.000
<v Speaker 2>They're very promising concepts, but moving from the lab to reliable, secure,

308
00:16:37.200 --> 00:16:39.879
<v Speaker 2>large scale deployment that still needs a lot of work,

309
00:16:40.159 --> 00:16:43.799
<v Speaker 2>rigorous security analysis, reliability testing, and really thinking through the

310
00:16:43.840 --> 00:16:45.240
<v Speaker 2>societal impacts.

311
00:16:44.919 --> 00:16:47.240
<v Speaker 1>Which brings us to a final thought for you, the listener.

312
00:16:47.679 --> 00:16:51.080
<v Speaker 1>We've talked about tags becoming ubiquitous in passports, money, close

313
00:16:51.159 --> 00:16:54.200
<v Speaker 1>things you can't just leave behind. So if opting out

314
00:16:54.200 --> 00:16:57.879
<v Speaker 1>of this tagged world eventually becomes impossible, as things seem

315
00:16:57.919 --> 00:17:01.440
<v Speaker 1>to be heading, how will you navigate that? That tension

316
00:17:01.440 --> 00:17:04.839
<v Speaker 1>between the undeniable convenience and your fundamental right to privacy

317
00:17:04.880 --> 00:17:08.400
<v Speaker 1>and self determination something to think about. We hope this

318
00:17:08.480 --> 00:17:11.079
<v Speaker 1>deep diet has given you some useful tools for understanding

319
00:17:11.119 --> 00:17:14.519
<v Speaker 1>this complex intersection of technology and our personal lives,