1
00:00:00,000 --> 00:00:07,080
okay so first of all thank you very much for attending this talk and welcome to

2
00:00:07,080 --> 00:00:11,780
video based analysis extracting cryptographic keys from video footage

3
00:00:11,780 --> 00:00:20,500
for devices power LED I will start by introducing ourselves my name is Ben I'm

4
00:00:20,500 --> 00:00:24,240
a Black Hat board member I also do some freelancing in a postdoc at Cornell Tech

5
00:00:24,240 --> 00:00:29,760
I have a PhD in security and privacy and together with me is Ofec which is

6
00:00:29,760 --> 00:00:36,860
a master of science student at the Ben Gurion University of the negative this

7
00:00:36,860 --> 00:00:42,340
work relies on two papers that we have recently published which are video based

8
00:00:42,340 --> 00:00:47,040
analysis and optical analysis you can find them online if you just look for

9
00:00:47,040 --> 00:00:54,080
them and moreover no prior knowledge of cryptography is required to understand

10
00:00:54,080 --> 00:00:58,180
this talk we try to keep it as simple as possible so the entire audience will be

11
00:00:58,180 --> 00:00:59,040
able to enjoy it

12
00:00:59,760 --> 00:01:04,100
some of the implement some of the specifics of the implementations are not

13
00:01:04,100 --> 00:01:08,720
I will not discuss them in the talk you will be able to find them in the papers

14
00:01:10,020 --> 00:01:14,760
now with that in mind let's have some fun so here is a question for the

15
00:01:14,760 --> 00:01:22,420
audience what do you associate with the term cryptanalysis now some of you

16
00:01:22,420 --> 00:01:28,880
probably associate servers and quantum computers

17
00:01:29,760 --> 00:01:33,780
and data centers and in general you probably tend to associate high level

18
00:01:33,780 --> 00:01:41,920
of computing capabilities with the term cryptanalysis others might associate

19
00:01:41,920 --> 00:01:46,840
spatialized hardware for example oscilloscopes as the hardware that is

20
00:01:46,840 --> 00:01:47,660
needed to conduct crypt

21
00:01:59,760 --> 00:02:09,560
some spatial agencies might appear as well. However, I tend to believe that the

22
00:02:09,560 --> 00:02:16,900
vast majority of you do not associate this iPhone with the term cryptanalysis

23
00:02:16,900 --> 00:02:23,740
because smartphones in general have weak computing capabilities. They are very

24
00:02:23,740 --> 00:02:29,160
popular devices. They cannot be used to apply any complex attack and the vast

25
00:02:29,160 --> 00:02:35,460
majority of you do not consider yourself as an entity who owns a smartphone as

26
00:02:37,400 --> 00:02:46,280
somebody who is interested in recovering cryptographic keys. And here is

27
00:02:46,280 --> 00:02:54,260
our message for today, okay? Think again. By the end of this talk, you will

28
00:02:54,260 --> 00:02:59,140
understand that power LEDs pose a great risk to information confidentiality and

29
00:02:59,140 --> 00:03:06,240
video cameras, whether they are security video cameras or video cameras of a

30
00:03:06,240 --> 00:03:15,500
smartphone, provide the needed infrastructure to exploit this risk. Now, by the end of

31
00:03:15,500 --> 00:03:22,620
this talk, we will discuss on how to recover cryptographic keys from a device by using or

32
00:03:22,620 --> 00:03:29,120
by obtaining a video footage of its power LED. But first of all, I would like to thank you

33
00:03:29,140 --> 00:03:33,500
for joining us today. First, let's try to answer where did the idea of using a video camera

34
00:03:33,500 --> 00:03:42,780
to recover secret keys from a device's power LED come from? Now, this is actually takes us to

35
00:03:42,780 --> 00:03:51,220
2014 where the visual microphone was published by a group of researchers from MIT. These guys

36
00:03:51,220 --> 00:03:58,480
were able to demonstrate a speech recovery technique using a video camera where they analyzed

37
00:03:59,140 --> 00:04:04,020
the movement of an object. It was demonstrated on various objects, but the most iconic

38
00:04:04,020 --> 00:04:09,620
demonstration was the one with the bag of chips. And they were able to analyze the movement of a bag

39
00:04:09,620 --> 00:04:17,680
of chips from the video footage and recover the speech played nearby the bag of chips, okay? And

40
00:04:17,680 --> 00:04:24,120
they demonstrated it with the use of two types of video cameras. The first one was a professional

41
00:04:24,120 --> 00:04:28,800
video camera, a high frequency video camera that is able to provide

42
00:04:29,140 --> 00:04:38,540
20,000 frames per second. And the second one was a regular video camera. And they exploited the

43
00:04:38,540 --> 00:04:43,480
rolling shutter in order to do so. And we will discuss the rolling shutter later on in this

44
00:04:43,480 --> 00:04:55,840
talk. In 2016, I started my Ph.D. And a few years later, we published the LAMPFON ATT&CK. The

45
00:04:55,840 --> 00:04:59,120
LAMPFON ATT&CK is a method to recover speech by using a video camera. And this is the first

46
00:04:59,140 --> 00:05:03,440
example. By using a photo diode. Now, a photo diode is the sensor that you can see on the right side.

47
00:05:03,640 --> 00:05:12,620
Okay? It's an optical sensor which converts light into electricity. Okay? Not for pictures, but for

48
00:05:12,620 --> 00:05:21,320
electricity. And then it needs to be digitized with an A to D. We show that attackers can

49
00:05:21,320 --> 00:05:28,820
analyze the movement of a desktop light bulb such as the one that you can see in the picture by

50
00:05:29,140 --> 00:05:35,760
by obtaining optical measurements using the photo diode. And then to re-cover the speech played by

51
00:05:35,760 --> 00:05:43,540
the speakers that you can see. Uh, that are placed nearby the, uh, desktop. Okay? And we

52
00:05:43,540 --> 00:05:48,780
demonstrated speech recovery from very distances up to 35 meters away. You can see the

53
00:05:48,780 --> 00:05:54,020
experimental set-up at the bottom. The photo diode was mounted into a telescope. The telescope was

54
00:05:54,020 --> 00:05:59,120
directed to the light bulb that was placed on top. ten. I call this CAT, because it has a similar

55
00:05:59,120 --> 00:06:05,380
on top of the desktop and the speakers were used in order to play the speech. Now I want to play

56
00:06:05,380 --> 00:06:12,520
to you the speech recoveries in order to convince you that you are able to recover speech at

57
00:06:12,520 --> 00:06:23,560
very high quality. The guys from the audio, can I play it? Okay. Let's try. We will make

58
00:06:23,560 --> 00:06:47,000
America great again. This is the original. This is from 15 meters. 25 meters away. Now the

59
00:06:47,000 --> 00:06:53,540
last one was recovered 35 meters away from the light bulb. And very much like the original,

60
00:06:53,560 --> 00:07:00,100
this was recovered from light measurements obtained via the photodiode that was directed to

61
00:07:00,100 --> 00:07:07,940
the rotating or to the vibrating light bulb. Now interestingly, in one of the experiments that

62
00:07:07,940 --> 00:07:14,180
we conducted, we found that not only we can recover speech from by obtaining optical

63
00:07:14,180 --> 00:07:20,680
measurements from the light bulb, we can also recover speech from the power LED that we used,

64
00:07:20,740 --> 00:07:23,540
from the power LED of the speakers that we used in order to recover speech from the light bulb.

65
00:07:23,560 --> 00:07:31,720
We used to project the sound nearby the light bulb. Okay? And this is actually led us to write or to

66
00:07:31,720 --> 00:07:37,420
publish an additional research that we named the Glom attack. Now the Glom attack is the exact same

67
00:07:37,420 --> 00:07:42,060
technique. Okay? We use, we recover speech using optical measurements obtained by an optical

68
00:07:42,060 --> 00:07:48,860
sensor, the photodiode. But in this specific case, we analyzed the speaker's power LED intensity,

69
00:07:49,080 --> 00:07:53,540
okay, when speech is played by the speakers and recovers the speech. So, this is the Glom attack.

70
00:07:53,540 --> 00:07:59,720
And again, you can see the exact same flat model. The photodiode is mounted to a telescope.

71
00:07:59,880 --> 00:08:05,800
The telescope is directed towards the power LED. You can see it in here. It's the green LED of the

72
00:08:05,800 --> 00:08:13,040
speakers. And we recovered again speech at very high quality. I will play to you the speech

73
00:08:13,040 --> 00:08:18,480
recoveries again. This time we recovered from five meters up to 35 meters away.

74
00:08:40,920 --> 00:08:45,980
Okay. As you can see, the speech or the quality of the speech deteriorates with distance. But then

75
00:08:45,980 --> 00:08:52,360
again, it was recovered by optical measurements obtained by the photodiode and optical measurements

76
00:08:52,360 --> 00:08:52,820
at the...

77
00:08:53,540 --> 00:09:00,560
optical measures taken from the power LED of the speakers. Now, this is very surprising in a way

78
00:09:00,560 --> 00:09:07,160
because probably some of you wonder, why can the intensity of a speaker's power LED can even be

79
00:09:07,160 --> 00:09:13,860
used to recover speech? And in order to answer it, we actually conducted an experiment where we

80
00:09:13,860 --> 00:09:19,800
took the USB speakers and played the frequency scan from the USB speakers between zero to four

81
00:09:19,800 --> 00:09:22,960
kilohertz. Now, we obtained...

82
00:09:23,540 --> 00:09:32,160
two traces. The first trace was a power trace that we obtained via an oscilloscope that was

83
00:09:32,160 --> 00:09:38,500
connected to the USB connector of the speakers. And the second trace that we obtained was an

84
00:09:38,500 --> 00:09:45,500
optical trace that was obtained by directing the photodiode towards the LED of the USB speakers.

85
00:09:45,780 --> 00:09:53,520
Okay? You can see them at the bottom. Now, we made very interesting observations, but in the very

86
00:09:53,540 --> 00:09:56,740
but I think that the most interesting observation among them

87
00:09:57,140 --> 00:09:59,180
was the fact that you can see that the power consumption

88
00:09:59,980 --> 00:10:02,120
correlates with the intensity of the power LED

89
00:10:02,120 --> 00:10:04,740
of the speakers, okay?

90
00:10:04,880 --> 00:10:07,600
Now this is very nice and very interesting,

91
00:10:08,220 --> 00:10:13,860
but is this correlation between the intensity

92
00:10:13,860 --> 00:10:15,720
of the power LED and the power consumption

93
00:10:15,720 --> 00:10:18,260
can also be seen in additional speakers

94
00:10:18,260 --> 00:10:22,140
or is it just limited to this specific model

95
00:10:22,140 --> 00:10:22,940
that we've used?

96
00:10:24,080 --> 00:10:29,120
So then again, we conducted a few additional experiments.

97
00:10:30,640 --> 00:10:33,120
We took various, we actually repeated

98
00:10:33,120 --> 00:10:34,280
the exact same experiment,

99
00:10:34,340 --> 00:10:36,420
but with different models of speakers.

100
00:10:36,700 --> 00:10:41,520
Among them there are Sony speakers, Google's Assistant,

101
00:10:42,340 --> 00:10:44,340
there is also JBL and Creative.

102
00:10:44,420 --> 00:10:46,920
You can see that we took the best one among them, okay?

103
00:10:47,760 --> 00:10:49,460
You can see that the correlation appears

104
00:10:50,100 --> 00:10:51,480
in each and every one of them.

105
00:10:52,140 --> 00:10:54,380
This is, by the way, spectrograms that were obtained

106
00:10:55,080 --> 00:10:56,160
from the optical measurements.

107
00:10:58,200 --> 00:11:00,580
And as you can see, the intensity of the power LED

108
00:11:00,580 --> 00:11:04,140
of various speakers correlates with the power consumption

109
00:11:04,920 --> 00:11:06,960
in the range of zero to four kilohertz.

110
00:11:08,100 --> 00:11:10,540
This is what we consider the universal phenomenon.

111
00:11:13,240 --> 00:11:16,060
Now some of you still probably wonder

112
00:11:16,060 --> 00:11:17,620
why do we see this correlation?

113
00:11:18,720 --> 00:11:21,420
So the fact is that in various,

114
00:11:21,420 --> 00:11:22,800
in various electrical circuits,

115
00:11:23,120 --> 00:11:26,060
the integrated power LED is connected directly

116
00:11:26,060 --> 00:11:27,640
to the power line, okay?

117
00:11:29,720 --> 00:11:33,280
Moreover, dedicated means intended to decouple

118
00:11:33,280 --> 00:11:35,360
the correlation between the power consumption

119
00:11:36,560 --> 00:11:39,640
and the optical and the power correlation

120
00:11:40,240 --> 00:11:44,200
are either not integrated to the circuit at all,

121
00:11:44,320 --> 00:11:47,200
or in some cases they are integrated,

122
00:11:47,440 --> 00:11:49,780
but they are ineffective, okay?

123
00:11:49,840 --> 00:11:50,640
And as a result,

124
00:11:52,020 --> 00:11:53,980
the power consumption of the device,

125
00:11:54,140 --> 00:11:55,940
which is essentially the power supply

126
00:11:56,500 --> 00:11:58,140
to the integrated power LED,

127
00:11:59,100 --> 00:12:00,740
affects the intensity of the LED.

128
00:12:03,160 --> 00:12:04,540
And due to this fact,

129
00:12:04,760 --> 00:12:08,180
the optical measurements reflect the power consumption

130
00:12:08,460 --> 00:12:09,700
of the device, okay?

131
00:12:12,360 --> 00:12:15,200
Now, at this specific point in time,

132
00:12:15,300 --> 00:12:16,960
I decided to leverage these findings

133
00:12:16,960 --> 00:12:18,120
to conduct cryptanalysis.

134
00:12:18,960 --> 00:12:26,760
And the idea was to apply the previously suggested

135
00:12:27,500 --> 00:12:31,680
cryptanalytic attacks that first relied on power traces

136
00:12:31,680 --> 00:12:32,900
in order to conduct them.

137
00:12:33,400 --> 00:12:35,180
This time we wanted to apply them

138
00:12:35,680 --> 00:12:38,340
using optical measurements obtained from the power LED.

139
00:12:41,320 --> 00:12:46,960
And this actually led us to optical cryptanalysis.

140
00:12:47,080 --> 00:12:48,100
It is a paper, it's called Optical Cryptoanalysis.

141
00:12:48,100 --> 00:12:48,560
And this is a paper, again,

142
00:12:48,660 --> 00:12:50,360
it is about to be presented at CCS,

143
00:12:50,380 --> 00:12:51,320
but you can find it online.

144
00:12:52,680 --> 00:12:54,820
Optical cryptanalysis is a key recovery technique

145
00:12:55,480 --> 00:12:57,960
to recover the key from a device

146
00:12:59,060 --> 00:13:01,240
using optical measurements obtained from

147
00:13:01,240 --> 00:13:04,960
the power LED of the device using a photodiode, okay?

148
00:13:05,960 --> 00:13:09,240
As you can see, we directed the photodiode

149
00:13:09,820 --> 00:13:13,280
towards the LED of a Raspberry Pi.

150
00:13:13,480 --> 00:13:16,200
And one of the first observations that we made is that

151
00:13:18,100 --> 00:13:23,380
The intensity of the power LED of various devices, it's not only Raspberry Pi, there

152
00:13:23,380 --> 00:13:24,640
are additional devices as well.

153
00:13:25,380 --> 00:13:32,260
So the intensity of the power LED correlates with the power consumption of the device in

154
00:13:32,260 --> 00:13:34,540
much wider spectrum that we initially thought.

155
00:13:35,020 --> 00:13:39,360
We analyzed zero to four kilohertz, you can see that in this specific case, it reaches

156
00:13:39,920 --> 00:13:43,840
up to 500 kilohertz, which was the upper limit of our equipment.

157
00:13:43,840 --> 00:13:46,960
The potential is actually much greater than 500 kilohertz.

158
00:13:51,520 --> 00:14:00,240
Interestingly, we conducted an additional experiment where we took GnuPG, run it on

159
00:14:00,240 --> 00:14:06,920
the Raspberry Pi, and extracted and obtained optical measurements from the power LED using

160
00:14:06,920 --> 00:14:07,620
the photodiode.

161
00:14:08,560 --> 00:14:12,140
As you can see in the spectrogram that appears in the right side.

162
00:14:12,760 --> 00:14:20,320
We can distinguish between the decrypt operations and the slip operations of the device, which

163
00:14:20,320 --> 00:14:21,440
we consider as an ideal.

164
00:14:22,320 --> 00:14:28,840
And moreover, as you can see, we can detect the beginning and the end of the cryptographic

165
00:14:28,840 --> 00:14:30,380
operations performed by the CPU.

166
00:14:31,520 --> 00:14:35,220
This is very bad for information confidentiality.

167
00:14:35,540 --> 00:14:42,120
This is very bad because it now opens a door to conduct the pre-testing.

168
00:14:42,120 --> 00:14:47,560
The previous timing cryptanalytic attacks that were demonstrated in the past, but in this

169
00:14:47,560 --> 00:14:54,760
specific case, they can now be demonstrated using optical measurements obtained from the

170
00:14:54,760 --> 00:15:00,440
power LED of the, obtained by the photodiode that was directed to the power LED of the

171
00:15:00,440 --> 00:15:00,720
device.

172
00:15:02,680 --> 00:15:11,340
And we used this understanding in order to recover RSA, ECDSA, and PSI keys, again, you

173
00:15:11,340 --> 00:15:14,260
can find this information in the paper.

174
00:15:16,040 --> 00:15:17,940
Now this is very interesting, okay?

175
00:15:20,900 --> 00:15:25,360
Having the ability to recover cryptographic keys using optical measurements instead of

176
00:15:25,360 --> 00:15:27,440
power traces is something which is very interesting.

177
00:15:27,920 --> 00:15:36,200
However, the primary disadvantage of this entire method is the fact that photodiodes

178
00:15:36,200 --> 00:15:37,820
aren't commonly used sensors, okay?

179
00:15:37,920 --> 00:15:41,320
The vast majority of you do not own a photodiode, or at least the photodiode that you have.

180
00:15:41,340 --> 00:15:44,240
So you can't use a photodiode that can be used to recover these cryptographic keys.

181
00:15:46,440 --> 00:15:53,120
Moreover, in order to obtain optical measurements from a photodiode, attackers must connect

182
00:15:53,120 --> 00:15:59,840
them to a dedicated A2D in order to sample the electricity, the output of the autodiode,

183
00:15:59,920 --> 00:16:00,280
okay?

184
00:16:01,400 --> 00:16:10,460
And the idea we had back then was to go from a photodiode to a video camera, okay?

185
00:16:11,340 --> 00:16:17,740
Instead of using a photodiode, we will use a video camera to obtain the optical, to obtain

186
00:16:17,740 --> 00:16:20,860
the video footage from the power LED of the device.

187
00:16:22,180 --> 00:16:27,180
Now with that in mind, I will let Ofik to discuss the threat models and the rolling

188
00:16:27,180 --> 00:16:27,620
shutters.

189
00:16:33,400 --> 00:16:33,920
Okay.

190
00:16:34,120 --> 00:16:36,100
So let's discuss the threat models.

191
00:16:36,540 --> 00:16:40,700
Our objective is to perform cryptanalysis and recover secret keys.

192
00:16:40,700 --> 00:16:45,220
From a device's power LED, using video cameras instead of photodiodes.

193
00:16:45,480 --> 00:16:47,700
Now we have two different threat models.

194
00:16:48,000 --> 00:16:50,020
The first one is closed video acquisition.

195
00:16:51,640 --> 00:16:54,660
Closed video acquisition uses a smartphone's video camera.

196
00:16:55,820 --> 00:17:02,020
It targets any type of power LED and requires physical access to the device.

197
00:17:03,540 --> 00:17:07,080
The second threat model is over the internet video acquisition.

198
00:17:07,080 --> 00:17:10,420
It uses an internet-connected video camera.

199
00:17:11,920 --> 00:17:18,440
It targets only type 2 power LEDs, which turn on when an operation is executed and turn

200
00:17:18,440 --> 00:17:23,180
off when the operation is stopped being executed and are commonly used in smart code readers.

201
00:17:24,460 --> 00:17:28,840
And it can be applied remotely over the internet using a hijacked video camera.

202
00:17:31,200 --> 00:17:36,460
So far, we have used photodiodes, which are analog sensors that can be sampled at a few

203
00:17:36,460 --> 00:17:36,900
gigahertz.

204
00:17:38,040 --> 00:17:42,720
Video cameras can record 60 or 120 frames per second.

205
00:17:43,800 --> 00:17:48,400
A sampling rate of 60 frames per second is not sufficient to perform cryptanalysis.

206
00:17:49,380 --> 00:17:50,280
Or is it?

207
00:17:52,780 --> 00:17:58,140
We used to think that a picture is the result of one atomic snapshot taken by the video

208
00:17:58,140 --> 00:17:58,480
camera.

209
00:17:59,080 --> 00:18:05,120
However, 99% of the video cameras use a rolling shutter to record the video.

210
00:18:05,720 --> 00:18:07,060
A single picture is the result of one atomic snapshot taken by the video camera.

211
00:18:07,060 --> 00:18:11,180
Any other picture is the result of multiple snapshots taken at different times by the

212
00:18:11,180 --> 00:18:11,660
video camera.

213
00:18:12,710 --> 00:18:17,260
A video camera uses a rolling shutter to scan an object vertically or horizontally.

214
00:18:17,820 --> 00:18:20,540
And combines the scanned pieces into a single frame.

215
00:18:21,640 --> 00:18:24,780
Only few rows are captured atomically each time.

216
00:18:25,220 --> 00:18:28,960
And the entire picture consists of multiple snapshots of an object.

217
00:18:31,400 --> 00:18:35,880
Here you can see an example of a picture captured using a rolling shutter.

218
00:18:36,460 --> 00:18:37,040
The picture has a single frame.

219
00:18:37,040 --> 00:18:42,700
On the left there is a moving object and on the right there is a captured image. As you can see

220
00:18:43,580 --> 00:18:50,200
because each a couple of rows are captured uh in different times, distortions appears in

221
00:18:50,200 --> 00:18:56,680
pictures of fast moving objects. Such distortions should not appear if the picture was taken

222
00:18:56,680 --> 00:19:06,240
using one atomic snapshot of the object. Now let's describe an experiment we conducted to

223
00:19:06,240 --> 00:19:12,100
visualize the effect of the rolling shutter. First we programmed an Arduino Uno to turn its

224
00:19:12,100 --> 00:19:27,120
power led on and off every 250 microseconds. And here's what we can see. Now we cannot see the

225
00:19:27,120 --> 00:19:33,600
LED turns its power on and off at 4 kilohertz because the sampling rate is only 60 frames per

226
00:19:33,600 --> 00:19:36,220
second. Now let's see what happens if the LED turns its power on and off every 250 microseconds.

227
00:19:36,240 --> 00:19:43,320
Second, an extra lens was used to direct the camera of a Samsung Galaxy S22 Ultra to the

228
00:19:43,320 --> 00:19:49,120
Arduino's power LED so that the video of the LED fills the entire frame. And here's what we can

229
00:19:49,120 --> 00:20:06,000
see. Now because the LED turns its power on and off few times in each frame there are red rows

230
00:20:06,000 --> 00:20:11,640
that were captured when the LED was turned on and black rows that were captured when the LED was

231
00:20:11,640 --> 00:20:20,880
turned off. And this is why we can see those black and red stripes across each frame. So by filling

232
00:20:20,880 --> 00:20:26,760
the frame with the video of the LED we exploit the video camera's rolling shutter to increase the

233
00:20:26,760 --> 00:20:34,100
number of measurements obtained at different times. This allows us to detect the 4 kilohertz flicker.

234
00:20:36,220 --> 00:20:41,340
Theoretically, by exploiting the video camera's rolling shutter we can increase the sampling

235
00:20:41,340 --> 00:20:47,540
rate by 3 orders of magnitude. From the FPS rate, 60 measurements per second, to the rolling

236
00:20:47,540 --> 00:20:59,000
shutter rate, 60K. In reality, there is a delay, a transition time, between consecutive frames.

237
00:21:00,140 --> 00:21:05,980
The transition time between frames is a period of time during which no object is captured by a

238
00:21:05,980 --> 00:21:11,180
video camera. You can see it here in the figure but that between two consecutive frames there

239
00:21:11,180 --> 00:21:19,320
is a transition time. This should be taken into account when analyzing the video footage of

240
00:21:19,320 --> 00:21:35,960
the power LED. Now, I will let Ben to discuss the ACDSA key recovery. Now, I will let Ben to

241
00:21:35,980 --> 00:21:42,560
discuss the ACDSA key recovery. Okay, so before we will discuss the ACDSA key recovery or in order

242
00:21:42,560 --> 00:21:48,960
to discuss the ACDSA key recovery, we need to briefly discuss the Minerva attack. The Minerva

243
00:21:48,960 --> 00:21:55,480
attack introduced or published three years ago and one of the most interesting revelations that

244
00:21:56,040 --> 00:22:05,800
researchers did was the fact that they found that various cryptographic libraries apply some runtime

245
00:22:05,980 --> 00:22:15,900
optimizations in the code. Okay, and I refer to the code of the elliptical of 256 R1 implementation

246
00:22:16,520 --> 00:22:23,720
of the ACDSA. And they found the number of iterations of the main loop is actually determined by

247
00:22:23,720 --> 00:22:30,000
the number of leaving zeros in the nonce. Okay, and as a result it created the time dependency

248
00:22:30,640 --> 00:22:35,520
between the number of leading zeros in the nonce and the execution time of the main loop and the

249
00:22:35,980 --> 00:22:46,540
the EC-DSA signing time. And the Minerva attack introduced a technique to recover the EC-DSA key

250
00:22:48,540 --> 00:23:01,480
by analyzing the EC-DSA signing measurements of a set of EC-DSA signatures. You need to have

251
00:23:01,480 --> 00:23:07,200
about 4,000 signatures in order to recover and the associated EC-DSA signing time in order to recover

252
00:23:07,200 --> 00:23:15,280
the complete key. Now the original Minerva attack required the attackers to obtain measurements

253
00:23:15,280 --> 00:23:20,720
from the CPU. The timing measurements obtained by querying the CPU. And essentially it required

254
00:23:20,720 --> 00:23:28,660
the attackers to compromise the host machine. The authors were unable to demonstrate the attack

255
00:23:28,660 --> 00:23:30,840
remotely over the internet due to the noise.

256
00:23:31,480 --> 00:23:40,300
The Minerva attack is very sensitive to errors in the timing measurements. You are about to see it now

257
00:23:40,300 --> 00:23:49,420
demonstrated over the internet. Without getting into too much specifics and details regarding the

258
00:23:49,420 --> 00:23:55,040
Minerva attack, you can think about it as a black box. The black box receives a set of signatures

259
00:23:55,040 --> 00:24:00,060
and their associated signing time and returns the EC-DSA key out of them.

260
00:24:03,620 --> 00:24:09,900
So essentially what we need to answer is how can the EC-DSA signing time of a signature be estimated

261
00:24:10,350 --> 00:24:17,200
from video footage. If we will be able to answer it, we will be able to recover the complete EC-DSA key

262
00:24:17,200 --> 00:24:31,260
using video footage. Now this was the experimental setup in our experiment. We used it, we placed an internet

263
00:24:31,480 --> 00:24:41,240
connected video camera and directed it to the power led of the smart card reader. Inside the smart card

264
00:24:41,240 --> 00:24:49,640
reader there was a smart card with an EC-DSA key. And we wanted to recover the EC-DSA key from the

265
00:24:49,640 --> 00:24:55,520
smart card using video footage of the power LED of the smart card reader by using this internet connected

266
00:24:55,520 --> 00:25:00,060
video camera that was placed 16 meters away from the camera.

267
00:25:01,840 --> 00:25:11,000
From this desktop. Okay, and this is the experimental setup. I want to show to you the video. You can see on the left side

268
00:25:11,720 --> 00:25:23,640
this was the smart card reader that we use. We actually focus on the right power LED of it. And let me show to you.

269
00:25:23,740 --> 00:25:31,460
Now you can see that we zoom into the power LED of the smart card reader. It is located on the right side.

270
00:25:31,460 --> 00:25:35,740
card. And interestingly, the smart card actually provides you with indication regarding

271
00:25:35,740 --> 00:25:40,680
whether the smart card reader actually provides you with indication regarding the smart card

272
00:25:41,040 --> 00:25:47,180
whether an operation actually taking place or not. And this is done by changing the color of

273
00:25:47,180 --> 00:25:53,740
the LED between blue or basically turn it off. Okay. Any time it's blue, the smart card is

274
00:25:53,740 --> 00:26:02,000
in idle. Any time it's off, the smart card is being used to sign. So as you can see from the

275
00:26:02,000 --> 00:26:06,840
video on the right side, there are differences between black and blue colors, okay, which

276
00:26:06,840 --> 00:26:16,800
indicate whether the smart card is currently being used to sign on stuff or not. So as you can

277
00:26:16,800 --> 00:26:23,480
see, this actually the picture on the left side is actually the result of averaging the

278
00:26:23,740 --> 00:26:29,080
each row in a frame to a single volume and arrange them in a time series, okay? And we did

279
00:26:29,080 --> 00:26:34,880
it for the red, green, and blue channels. You can see that we can distinguish between the

280
00:26:34,880 --> 00:26:39,800
sign operations where the power LED is off and the idle operations where the color of the

281
00:26:39,800 --> 00:26:47,820
power LED is blue based on the blue channel. Now we need to answer how can we calculate the

282
00:26:47,820 --> 00:26:53,720
signing time out of it? Now in order to calculate the time out of the power LED, we need to

283
00:26:53,740 --> 00:26:59,040
calculate the EC-DSA time of the signature, we extract the series frames associated with each

284
00:26:59,040 --> 00:27:08,700
signature from the video, okay? You can see examples of them on the bottom of the slide. Now

285
00:27:08,700 --> 00:27:15,500
we kept series that contained the indication of the switch between the beginning and the end of

286
00:27:15,500 --> 00:27:22,960
the signing. Meaning that we kept series that the beginning and the end of the signing were kept in

287
00:27:23,740 --> 00:27:25,860
the beginning of the signature. Now we can see in the first series, where you can see in this

288
00:27:25,860 --> 00:27:32,200
specific case, this is the series that you can see on top, okay? Each series that missed or

289
00:27:32,200 --> 00:27:37,960
lacks one of these indications regarding the switch between the beginning of the signature and the

290
00:27:37,960 --> 00:27:45,600
end of the signature, we filtered it off, okay? You can see that how the in the frames that

291
00:27:45,600 --> 00:27:53,420
appear in the first series, the color is changed inside the frame between blue and black and vice

292
00:27:53,740 --> 00:27:59,480
versa. Okay? This is what we considered as the indication that the operation started and ended.

293
00:27:59,620 --> 00:28:08,860
Okay? And these are only the type of series that we kept. Now, first of all, we calculated T1,

294
00:28:09,020 --> 00:28:16,560
which T1 in our case is the execution time of all of the full black frames that you can see in

295
00:28:16,560 --> 00:28:23,580
here. This is actually done just by counting the number of full black frames and multiplying them by

296
00:28:23,740 --> 00:28:31,640
this constant. This gives you T1. T2 is the execution time of the first frame, okay, in which the

297
00:28:31,640 --> 00:28:40,940
color changed between, as you can see in here, between blue to black. So we calculated this as

298
00:28:40,940 --> 00:28:47,400
follows. We counted the number of rows that are associated with the sign, which you can see in

299
00:28:47,400 --> 00:28:53,720
here. They are in black. And divided them by the total number of rows in the frame. So this is the

300
00:28:53,740 --> 00:29:00,080
time. Okay? This actually gives us the relative time in the frame. We multiply it by the scanning

301
00:29:00,080 --> 00:29:06,600
time and added the transition time. Now, so far, Ofik discussed about the scanning time and the

302
00:29:06,600 --> 00:29:11,220
transition time, but he did not mention how you can determine the scanning time and the

303
00:29:11,220 --> 00:29:17,000
transition time. So let's discuss how we can find S, which stands for the scanning time, and T,

304
00:29:17,060 --> 00:29:23,720
which stands for the transition time. So I remind you the experiment that we did at the beginning.

305
00:29:23,740 --> 00:29:30,780
With the flickering LED of the Arduino. You can just take one of the you can repeat the exact same

306
00:29:30,780 --> 00:29:39,380
experiment with the flicker. Take only one of the frames from the video. Count the number of

307
00:29:39,380 --> 00:29:47,400
changes between black and red that you have in the frame and multiply it by the time that the

308
00:29:47,400 --> 00:29:52,620
flicker was on and off. In this specific case, the on and off periods were equal. Okay?

309
00:29:53,740 --> 00:30:02,000
And by doing so, this will gives you the scanning time of the video camera. And the beauty of it is

310
00:30:02,000 --> 00:30:07,400
then when you get the scanning time out of this experiment, you get the transition time for free by

311
00:30:07,400 --> 00:30:15,360
deducting the scanning time out of this constant. Now, with that in mind, returning to T2, you now

312
00:30:15,360 --> 00:30:23,660
have S and T and everything needed to calculate T2. Now, T3 is actually calculated at the exact

313
00:30:23,660 --> 00:30:31,600
exact same way, okay? But in this specific case, we do not add the transition time because

314
00:30:31,600 --> 00:30:39,380
the ECDSA sign stopped or ended in the middle of the frame, so the transition time happened

315
00:30:39,380 --> 00:30:46,400
after the frame, so there is no need to add it to this specific, to T3. And the sign time

316
00:30:46,400 --> 00:30:53,520
is actually the sum of T1, T2, and T3. Now, the beauty of it is that if you will do it

317
00:30:53,520 --> 00:30:59,460
to enough signatures, for about 4,000 signatures, you can see that this is the result that we

318
00:30:59,460 --> 00:31:08,440
got. We were able to recover the ECDSA key out of it using the Minerva script that the

319
00:31:08,440 --> 00:31:13,500
orders were published, again, using an internet-connected video camera that was directed to a power

320
00:31:13,500 --> 00:31:18,540
LED of a smart card reader. Thank you.

321
00:31:26,040 --> 00:31:33,000
Okay. Now, moreover, there are many additional smart card readers available

322
00:31:33,000 --> 00:31:39,480
to purchase on Amazon that are vulnerable to this attack, and the distance between them

323
00:31:39,480 --> 00:31:46,300
and the video camera might vary based on the intensity of their own power LED, but we were

324
00:31:46,300 --> 00:31:52,440
able to recover the same ECDSA key from the smart card, inserting it to five additional

325
00:31:53,520 --> 00:31:56,420
smart card readers. Again, all of them are available online.

326
00:31:58,880 --> 00:32:06,800
Okay. Now, let's discuss recovering a side key from a device. And again, recovering a side key

327
00:32:06,800 --> 00:32:11,480
from a device, so in order to understand how to recover a side key from a device, we need

328
00:32:11,480 --> 00:32:16,580
to briefly discuss the Herzblitz attack. The Herzblitz attack introduced a year ago.

329
00:32:16,760 --> 00:32:22,380
They also presented their talk at Black Hat, and they were able to...

330
00:32:23,700 --> 00:32:28,320
Suggest or introduce a new timing attack to recover the complete side key from a server.

331
00:32:30,160 --> 00:32:35,580
The Herzblitz attack, unlike the Minerva attack that I showed you before, is not the result

332
00:32:35,580 --> 00:32:40,620
of the implementation of the code. Okay? It's the result of the execution of the device.

333
00:32:41,120 --> 00:32:46,060
The code should be resilient to timing attack, but the execution actually reveals something

334
00:32:46,540 --> 00:32:52,660
in terms of the time that it was executed regarding the data being executed by the device.

335
00:32:53,520 --> 00:32:59,020
And this is happening due to the dynamic voltage frequency stabilizers. Maybe you are more

336
00:32:59,020 --> 00:33:06,200
familiar with a DVFS, okay, which yields different execution times based on the data that

337
00:33:06,200 --> 00:33:09,940
was recovered, that is being processed by the device.

338
00:33:11,300 --> 00:33:17,020
And the researchers were able to show that for each index of the bit, they can

339
00:33:17,020 --> 00:33:23,500
craft a dedicated cryptogram that relies on the indexes that they were already produced.

340
00:33:23,520 --> 00:33:26,920
recovered. Okay, it's an adaptive attack for those of you who are familiar with cryptography.

341
00:33:28,120 --> 00:33:37,940
And determine whether the value of the bit under attack is similar to the value that

342
00:33:37,940 --> 00:33:44,280
was recovered in the previous index or changed. Okay, and this is all done based on a timing

343
00:33:44,280 --> 00:33:51,640
threshold. Now, the original attack was implemented using timing measurements obtained by querying

344
00:33:51,640 --> 00:33:58,040
the API of a server over the Internet. They deducted the request time from the response

345
00:33:58,040 --> 00:34:05,740
time. And, again, due to the noise that was added by the network latency, it took a few days

346
00:34:05,740 --> 00:34:14,820
to recover the keys . Now, this was our attack, okay? And this is the experimental

347
00:34:14,820 --> 00:34:19,660
setup of our attack. We tried to recover the secret key, the side key, from the Samsung

348
00:34:19,660 --> 00:34:20,600
Galaxy S8.

349
00:34:20,640 --> 00:34:21,620
The Samsung Galaxy S8 started 8 years ago. It was theरÁ dares to beat my souha?емся

350
00:34:21,620 --> 00:34:25,180
Galaxy S8 is the smartphone that you can see on the right side. It's not the smartphone

351
00:34:25,180 --> 00:34:29,960
that you can see on top. The Samsung Galaxy S8 was the device that

352
00:34:29,960 --> 00:34:39,360
holded the side key. Okay? Now, interestingly, in this specific case, we tried to recover

353
00:34:40,280 --> 00:34:45,380
the secret key from a device by obtaining video footage not from the Samsung Galaxy

354
00:34:45,380 --> 00:34:52,400
but from the speakers, okay, the power led of the speakers that were connected to the same

355
00:34:52,400 --> 00:34:58,900
USB hub that was used to charge the Samsung Galaxy. And in order to make it completely

356
00:34:58,900 --> 00:35:04,680
outrageous, we did it with an iPhone, tried to recover the key from the Samsung Galaxy S8.

357
00:35:06,000 --> 00:35:13,460
On the right side, you can see the video footage of the power led of the speakers. Okay,

358
00:35:13,560 --> 00:35:15,060
you can see that it is green.

359
00:35:15,380 --> 00:35:20,380
This is actually being taken from the speakers as you can see on the left side.

360
00:35:20,980 --> 00:35:26,380
Between the speakers and the smartphone, you can see a lens which was used to fill the entire

361
00:35:27,440 --> 00:35:34,740
frame with the view of the LED. I want to show to you the video. You cannot see anything,

362
00:35:34,860 --> 00:35:45,240
right? It seems like completely innocent video with green color. Moreover, I will argue that

363
00:35:45,240 --> 00:35:50,260
you cannot see even the difference between the IDLE and the PSYC operations being performed

364
00:35:50,980 --> 00:35:55,960
by the Samsung Galaxy S8. Okay? They cannot be detected by the naked eye.

365
00:35:59,540 --> 00:36:05,520
But here is something very interesting. Okay? We executed eight consecutive iterations of

366
00:36:05,520 --> 00:36:15,220
PSYC operations where each iteration consisted of 1100 of PSYC operations on the Samsung Galaxy S8.

367
00:36:15,240 --> 00:36:21,000
say while obtaining video footage from the power LED of the connected speakers.

368
00:36:22,060 --> 00:36:27,680
You can see that by averaging each frame into a single value and arranging them in a time

369
00:36:27,680 --> 00:36:34,560
series and then again zooming into the green channel, you can see that we can detect the

370
00:36:34,560 --> 00:36:41,060
beginning and the end of the eight iterations by analyzing the green channel and again using

371
00:36:41,060 --> 00:36:45,300
this by arranging the values in a time series.

372
00:36:48,340 --> 00:36:55,020
Now this actually gives you the ability to calculate the iteration time based on the

373
00:36:55,020 --> 00:36:58,580
number of values between each two peaks that you can see in here, okay?

374
00:37:01,000 --> 00:37:07,840
But then again, another question that we need to answer is how accurate is this calculation?

375
00:37:09,820 --> 00:37:16,440
So, on the left side, you can see the distribution of the execution time based only on the first

376
00:37:16,440 --> 00:37:17,260
iteration, okay?

377
00:37:17,360 --> 00:37:22,660
We apply the attack by using only the first iteration and as you can see, it's very noisy.

378
00:37:23,360 --> 00:37:34,280
The two possibilities or the two cases that whether the bit have a similar value or was

379
00:37:34,280 --> 00:37:37,320
it changed in comparison to the previous index?

380
00:37:37,320 --> 00:37:45,480
You cannot set a threshold that will give you an accurate, you will be able to use it

381
00:37:45,480 --> 00:37:48,560
in order to accurately distinguish between the two specific cases.

382
00:37:50,940 --> 00:37:58,160
However, when you use instead the distribution of the execution time based on the minimum

383
00:37:58,780 --> 00:38:04,740
execution time among these eight iterations, what you're seeing in the middle, you can

384
00:38:04,740 --> 00:38:07,300
see that you can actually set a threshold.

385
00:38:07,300 --> 00:38:13,240
threshold in the middle that will allow you to distinguish between the two possible bits

386
00:38:13,240 --> 00:38:18,680
of the key index with very high accuracy, okay, 99% accuracy.

387
00:38:19,780 --> 00:38:22,000
Now 99% accuracy is good.

388
00:38:22,320 --> 00:38:24,080
It's not excellent, okay?

389
00:38:24,200 --> 00:38:25,420
It's not error-prone.

390
00:38:25,600 --> 00:38:33,840
And as a result, we will have to use an error detection and correction mechanism throughout

391
00:38:33,840 --> 00:38:40,240
the key recovery process in order to recover the complete key.

392
00:38:41,700 --> 00:38:44,200
And as you can see, this is actually what we did.

393
00:38:44,300 --> 00:38:49,600
We recovered the complete key, the complete side key from the device using a video footage

394
00:38:49,600 --> 00:38:51,740
obtained from the connected speakers.

395
00:38:53,160 --> 00:38:58,920
Then again, we also integrated an error detecting and correcting mechanism that was suggested

396
00:38:58,920 --> 00:39:01,500
by the guys that presented the Herzbleed attack.

397
00:39:01,780 --> 00:39:02,000
Okay.

398
00:39:04,480 --> 00:39:08,980
So let's briefly discuss the limitations of video-based script analysis.

399
00:39:09,480 --> 00:39:15,180
So first of all, the first limitation is the fact that the attack mostly targets weak IoT

400
00:39:15,180 --> 00:39:15,600
devices.

401
00:39:15,820 --> 00:39:17,940
I would say up to a level of a smartphone.

402
00:39:18,420 --> 00:39:22,760
I would be very surprised if somebody will take the exact same video cameras that we

403
00:39:22,760 --> 00:39:27,640
used and will show me that he was able to recover secret keys from a power lead of servers

404
00:39:27,640 --> 00:39:29,060
or power lead of laptops.

405
00:39:30,980 --> 00:39:31,940
Now, moreover...

406
00:39:31,940 --> 00:39:33,940
We discussed about it earlier.

407
00:39:35,120 --> 00:39:40,980
Due to the fact that there is a transition time where between each two frames where the

408
00:39:40,980 --> 00:39:48,660
object or the power lead isn't being captured in any frame, the sampling, the distribution

409
00:39:48,960 --> 00:39:50,580
of the sampling is semi-uniform.

410
00:39:50,840 --> 00:39:56,140
It's not exactly uniform, which is another issue that we need to resolve when recovering

411
00:39:56,140 --> 00:39:56,920
the secret keys.

412
00:39:59,240 --> 00:40:00,640
Now, let's discuss the takeaways.

413
00:40:00,640 --> 00:40:06,040
I think that now you are convinced that power LEDs are much more informative than you initially

414
00:40:06,040 --> 00:40:06,940
imagined.

415
00:40:07,940 --> 00:40:16,060
In some cases, attackers can use the information modulated over the power LED to recover speech.

416
00:40:16,300 --> 00:40:21,400
In other cases, it can be used to recover cryptographic keys, as we showed in this talk.

417
00:40:24,360 --> 00:40:29,440
Now, moreover, the potential of the attack is actually much greater than we showed you

418
00:40:29,440 --> 00:40:30,320
in this work.

419
00:40:31,300 --> 00:40:37,340
We focused on what we consider as ubiquitous cameras, not professional cameras.

420
00:40:37,660 --> 00:40:42,640
We use security cameras and smartphones, video cameras, in order to recover the secret keys.

421
00:40:43,340 --> 00:40:50,100
Attackers in reality can use professional video cameras that will provide a higher rolling

422
00:40:50,100 --> 00:40:58,580
shutter rate, a higher bit depth, and enhance zoom capabilities, and by doing so, they probably

423
00:40:58,580 --> 00:40:59,940
will be able to recover...

424
00:41:00,320 --> 00:41:08,380
Secret keys from a wider range of devices, from probably even a greater distance.

425
00:41:10,940 --> 00:41:16,760
And this is, I think, the most interesting insight or takeaway from this talk.

426
00:41:17,580 --> 00:41:21,720
We expect that more and more devices will be exposed to video-based cryptanalysis every

427
00:41:21,720 --> 00:41:21,940
year.

428
00:41:22,220 --> 00:41:22,840
Okay?

429
00:41:23,600 --> 00:41:26,540
This is actually the result of two interesting facts.

430
00:41:26,780 --> 00:41:29,460
First of all, video cameras' specifications...

431
00:41:30,320 --> 00:41:34,500
Are continuously improving each and every year, following Moore's law.

432
00:41:34,800 --> 00:41:39,080
You can see how the sensitivity of this picture has improved significantly throughout the

433
00:41:39,080 --> 00:41:39,260
years.

434
00:41:43,040 --> 00:41:50,060
Moreover, the number of functional IoT devices with weak CPU power, and I'm referring to

435
00:41:50,060 --> 00:41:57,540
sensors and smart cards and robotic vacuum cleaners and smartphones and even video streamers,

436
00:41:58,840 --> 00:42:00,300
the number of such devices...

437
00:42:00,320 --> 00:42:04,160
Are continuously increased each and every day.

438
00:42:04,420 --> 00:42:09,380
Their deployment is expected to grow throughout the next year as well.

439
00:42:09,560 --> 00:42:17,780
And as a result, we will have much improved video cameras throughout the years that co-located

440
00:42:18,120 --> 00:42:20,980
with a greater number of weak IoT devices.

441
00:42:21,360 --> 00:42:21,520
Okay?

442
00:42:21,800 --> 00:42:27,680
And due to this fact, we believe that more and more devices will be exposed to video-based

443
00:42:27,680 --> 00:42:29,180
cryptanalysis each and every year.

444
00:42:29,740 --> 00:42:30,300
Okay?

445
00:42:30,300 --> 00:42:32,260
This is the final takeaway.

446
00:42:32,720 --> 00:42:35,760
It's mostly meant for perspective.

447
00:42:36,300 --> 00:42:42,640
It might be easier for this audience to compromise the target device with the malware and exfiltrate

448
00:42:42,640 --> 00:42:43,600
the key over the Internet.

449
00:42:43,860 --> 00:42:44,100
Okay?

450
00:42:44,120 --> 00:42:45,820
Than applying the attack that I've just...

451
00:42:45,820 --> 00:42:47,300
The attacks that I've just mentioned.

452
00:42:48,480 --> 00:42:56,120
However, bear in mind that video-based cryptanalysis is intended to extract keys from non-compromised

453
00:42:56,120 --> 00:42:56,480
devices.

454
00:42:56,640 --> 00:42:56,900
Okay?

455
00:42:57,060 --> 00:43:00,220
And the beauty of it is that it uses popular equipment.

456
00:43:00,260 --> 00:43:00,280
Okay?

457
00:43:00,280 --> 00:43:00,500
And the beauty of it is that it uses popular equipment.

458
00:43:00,760 --> 00:43:05,060
Not something that we consider as specialized equipment as the equipment that I've discussed

459
00:43:05,060 --> 00:43:05,600
at the beginning.

460
00:43:07,300 --> 00:43:11,900
Now, a few other things I would like to mention.

461
00:43:12,240 --> 00:43:18,700
This research was recently awarded with a Pony Award for the best cryptographic attack

462
00:43:18,700 --> 00:43:19,240
of 2023.

463
00:43:21,460 --> 00:43:27,680
You can find the additional details if you will look for video-based cryptanalysis online.

464
00:43:28,080 --> 00:43:28,280
Okay?

465
00:43:29,320 --> 00:43:32,080
And with that in mind, thank you very much for attending this talk.

466
00:43:32,380 --> 00:43:34,800
I will be happy to take any questions from the audience.

467
00:43:35,280 --> 00:43:35,840
Thank you.

468
00:43:37,360 --> 00:43:37,760
.