1
00:00:10,220 --> 00:00:15,320
good afternoon and thank you for being

2
00:00:12,139 --> 00:00:17,240
here so today I'll be presenting our

3
00:00:15,320 --> 00:00:20,509
insights and results from our

4
00:00:17,240 --> 00:00:22,400
investigation of low-level hardware bugs

5
00:00:20,509 --> 00:00:24,710
this is joint work between Technical

6
00:00:22,400 --> 00:00:26,390
University of Darmstadt and our

7
00:00:24,710 --> 00:00:32,418
collaborators at Texas A&M University

8
00:00:26,390 --> 00:00:34,160
and Intel in actively pursuing the holy

9
00:00:32,418 --> 00:00:36,349
grail of trusted computing and its

10
00:00:34,160 --> 00:00:38,150
promises for security for our vulnerable

11
00:00:36,350 --> 00:00:40,640
software many solutions and

12
00:00:38,150 --> 00:00:42,790
architectures have been continuously

13
00:00:40,640 --> 00:00:45,440
proposed in the landscape over the years

14
00:00:42,790 --> 00:00:47,960
some of these are on the list here this

15
00:00:45,440 --> 00:00:50,870
is of course not an exhaustive list

16
00:00:47,960 --> 00:00:53,750
it started with dedicated security trips

17
00:00:50,870 --> 00:00:55,730
such as TPMS and now we are we have the

18
00:00:53,750 --> 00:00:59,480
more popular trusted or isolated

19
00:00:55,730 --> 00:01:01,038
execution environments we have dedicated

20
00:00:59,480 --> 00:01:03,410
Hardware extensions for runtime

21
00:01:01,039 --> 00:01:07,190
enforcement and yet a station of

22
00:01:03,410 --> 00:01:09,679
software while it's executing we have

23
00:01:07,190 --> 00:01:11,060
dedicated trust anchors and trusted

24
00:01:09,680 --> 00:01:13,610
execution environments for embedded

25
00:01:11,060 --> 00:01:16,640
systems we even have capability based

26
00:01:13,610 --> 00:01:20,270
systems and processors with OEM

27
00:01:16,640 --> 00:01:22,099
constructions in them some of these

28
00:01:20,270 --> 00:01:26,959
solutions come from academia that's the

29
00:01:22,099 --> 00:01:29,360
big some solutions are proposed from

30
00:01:26,959 --> 00:01:31,700
academia that's the big Greenway well

31
00:01:29,360 --> 00:01:35,660
there some are from industries such as

32
00:01:31,700 --> 00:01:37,190
Intel SGX and armed trust zone and we

33
00:01:35,660 --> 00:01:40,009
also have an emerging open-source

34
00:01:37,190 --> 00:01:42,080
architecture risk 5 that is recently

35
00:01:40,009 --> 00:01:43,970
enabling a lot more work in this space

36
00:01:42,080 --> 00:01:46,160
and changing the game for system

37
00:01:43,970 --> 00:01:48,560
security by setting us free from

38
00:01:46,160 --> 00:01:50,810
proprietary architectures and closed

39
00:01:48,560 --> 00:01:52,640
source legacy hardware but anyway

40
00:01:50,810 --> 00:01:56,649
regardless where the solution is coming

41
00:01:52,640 --> 00:01:59,720
from the a lot all of these solutions

42
00:01:56,649 --> 00:02:01,429
suffer from they they all have one

43
00:01:59,720 --> 00:02:03,920
problem and that is the fundamental

44
00:02:01,429 --> 00:02:05,840
trust assumptions of these solutions the

45
00:02:03,920 --> 00:02:07,819
traditional threat model was always a

46
00:02:05,840 --> 00:02:10,520
software-only anniversary and software

47
00:02:07,819 --> 00:02:13,790
only vulnerabilities and the focus was

48
00:02:10,520 --> 00:02:15,620
on software that executes on top of a

49
00:02:13,790 --> 00:02:17,660
processor architecture it took us a

50
00:02:15,620 --> 00:02:19,760
while to realize that there's actually a

51
00:02:17,660 --> 00:02:21,410
more complicated microarchitecture

52
00:02:19,760 --> 00:02:23,929
underneath all of this and hardware

53
00:02:21,410 --> 00:02:27,079
implementation that we were always as

54
00:02:23,930 --> 00:02:29,870
was trusted and secure now of course we

55
00:02:27,079 --> 00:02:32,540
know otherwise right the recent outbreak

56
00:02:29,870 --> 00:02:33,500
of attack such as Spectre and meltdown

57
00:02:32,540 --> 00:02:36,048
to name a few

58
00:02:33,500 --> 00:02:38,629
was representing a disruptive paradigm

59
00:02:36,049 --> 00:02:40,670
shift in in the attacks but in the

60
00:02:38,629 --> 00:02:42,349
attack space from software

61
00:02:40,670 --> 00:02:45,349
vulnerabilities these cross layer

62
00:02:42,349 --> 00:02:47,089
attacks exploit issues which originated

63
00:02:45,349 --> 00:02:48,649
in your microarchitecture and in the

64
00:02:47,090 --> 00:02:50,750
hardware of our systems by means of

65
00:02:48,650 --> 00:02:53,569
software which is a major change from

66
00:02:50,750 --> 00:02:55,340
our traditional threat model and these

67
00:02:53,569 --> 00:02:57,920
are either patched by software or

68
00:02:55,340 --> 00:03:00,319
microcode because you cannot actually

69
00:02:57,920 --> 00:03:01,879
patch the hardware even the even though

70
00:03:00,319 --> 00:03:03,470
the issues originate in the hardware I

71
00:03:01,879 --> 00:03:08,149
cannot patch the hardware after the

72
00:03:03,470 --> 00:03:10,549
hardware is fabricated and this compels

73
00:03:08,150 --> 00:03:11,989
us to take a step back and start

74
00:03:10,549 --> 00:03:14,659
questioning the security of our

75
00:03:11,989 --> 00:03:16,400
underlying hardware in general take a

76
00:03:14,659 --> 00:03:17,900
closer look at the design process of the

77
00:03:16,400 --> 00:03:19,489
hardware the security assurance

78
00:03:17,900 --> 00:03:22,250
techniques that are being used

79
00:03:19,489 --> 00:03:23,959
especially when I am assuming that my

80
00:03:22,250 --> 00:03:25,549
hardware is the root of trust of my

81
00:03:23,959 --> 00:03:29,269
systems so we need to actually take a

82
00:03:25,549 --> 00:03:31,519
better look into that and so in our work

83
00:03:29,269 --> 00:03:34,010
and in this talk we go one level beneath

84
00:03:31,519 --> 00:03:36,739
the micro architectural design decisions

85
00:03:34,010 --> 00:03:39,290
and we take a deeper look and hardware

86
00:03:36,739 --> 00:03:41,180
implementation itself and whether the

87
00:03:39,290 --> 00:03:43,879
hardware how the hardware is secure

88
00:03:41,180 --> 00:03:46,790
design and what are the techniques that

89
00:03:43,879 --> 00:03:48,649
are used to verify the security of the

90
00:03:46,790 --> 00:03:50,298
RT of the hardware implementations

91
00:03:48,650 --> 00:03:54,919
before the hardware is actually

92
00:03:50,299 --> 00:03:56,780
fabricated and so how how the hardware

93
00:03:54,919 --> 00:03:59,180
designed hardware is typically

94
00:03:56,780 --> 00:04:02,209
implemented by using light by being

95
00:03:59,180 --> 00:04:04,310
described at a register transfer level

96
00:04:02,209 --> 00:04:05,959
using a hardware description language

97
00:04:04,310 --> 00:04:08,090
such as very long I'm huge DL at least

98
00:04:05,959 --> 00:04:10,159
these are the most popular ones and then

99
00:04:08,090 --> 00:04:12,889
this description that models how the

100
00:04:10,159 --> 00:04:15,198
data signals flow through registers at

101
00:04:12,889 --> 00:04:18,349
clock cycles then it is usually that's

102
00:04:15,199 --> 00:04:20,630
thousands of RTL code lines which are

103
00:04:18,349 --> 00:04:23,750
then synthesized into registers wired

104
00:04:20,630 --> 00:04:25,310
and other logic and then layout and then

105
00:04:23,750 --> 00:04:26,539
fabricated into the chip that you

106
00:04:25,310 --> 00:04:28,909
actually hold in your hand

107
00:04:26,539 --> 00:04:31,250
now the question is how do I know this

108
00:04:28,909 --> 00:04:34,210
RTL description is secure what are the

109
00:04:31,250 --> 00:04:34,210
techniques that are being used

110
00:04:37,070 --> 00:04:41,810
so in concurrence to the convinced oh

111
00:04:39,350 --> 00:04:43,640
this there is a conventional hardware at

112
00:04:41,810 --> 00:04:45,680
hardware development lifecycle in place

113
00:04:43,640 --> 00:04:47,539
for years and in current to that there

114
00:04:45,680 --> 00:04:50,090
is a security development lifecycle that

115
00:04:47,540 --> 00:04:52,880
is being adapted by semiconductor

116
00:04:50,090 --> 00:04:54,830
companies recently the hardware design

117
00:04:52,880 --> 00:04:56,480
lifecycle traditionally begins at the

118
00:04:54,830 --> 00:04:58,190
architecture specifications

119
00:04:56,480 --> 00:05:00,440
through the microarchitecture and then

120
00:04:58,190 --> 00:05:03,110
the actual RTL implementation using a

121
00:05:00,440 --> 00:05:05,120
hardware description language and then

122
00:05:03,110 --> 00:05:07,850
functional verification until it makes

123
00:05:05,120 --> 00:05:11,720
it to until the chip has signed off for

124
00:05:07,850 --> 00:05:14,330
tape out and fabrication so security

125
00:05:11,720 --> 00:05:16,340
relevant issues would be introduced or

126
00:05:14,330 --> 00:05:18,080
bugs would be unintentionally introduced

127
00:05:16,340 --> 00:05:19,700
at either the architecture stage or the

128
00:05:18,080 --> 00:05:23,060
microarchitecture or at the RTL

129
00:05:19,700 --> 00:05:25,039
implementation but at the

130
00:05:23,060 --> 00:05:26,480
microarchitecture stage most of these

131
00:05:25,040 --> 00:05:28,760
decisions have to do with micro

132
00:05:26,480 --> 00:05:31,250
architectural design decisions or flaws

133
00:05:28,760 --> 00:05:34,460
in the design decisions as for example

134
00:05:31,250 --> 00:05:37,669
whether to do cache isolation or not but

135
00:05:34,460 --> 00:05:40,159
at the RTL implementation the bugs are

136
00:05:37,669 --> 00:05:42,349
mostly about how you implement it and

137
00:05:40,160 --> 00:05:43,970
hardware so if you have cache isolation

138
00:05:42,350 --> 00:05:46,580
do you actually implement it correctly

139
00:05:43,970 --> 00:05:48,290
in your hardware or not and these are

140
00:05:46,580 --> 00:05:52,159
the level of bugs or the classes of bugs

141
00:05:48,290 --> 00:05:53,900
that were focused on in this work and so

142
00:05:52,160 --> 00:05:55,550
in concurrence to the this hardware

143
00:05:53,900 --> 00:05:57,229
development lifecycle there's a security

144
00:05:55,550 --> 00:05:59,780
development lifecycle in place which

145
00:05:57,229 --> 00:06:01,580
starts by setting out the security

146
00:05:59,780 --> 00:06:03,770
specifications that I want out of my

147
00:06:01,580 --> 00:06:05,620
product the threat model the assets that

148
00:06:03,770 --> 00:06:07,849
I want to protect in my SOC the

149
00:06:05,620 --> 00:06:11,140
adversarial capability is everything

150
00:06:07,850 --> 00:06:13,940
that I want out of my chip and then

151
00:06:11,140 --> 00:06:15,620
security testing is done or verification

152
00:06:13,940 --> 00:06:19,370
to check that the product meets these

153
00:06:15,620 --> 00:06:21,050
security specifications and in order to

154
00:06:19,370 --> 00:06:23,169
do that there is a spectrum of different

155
00:06:21,050 --> 00:06:26,229
techniques that are deployed by industry

156
00:06:23,169 --> 00:06:28,669
manyou such as manual code inspection

157
00:06:26,229 --> 00:06:31,789
simulation based techniques and formal

158
00:06:28,669 --> 00:06:33,409
verification so the entire process and

159
00:06:31,790 --> 00:06:36,020
challenge eneral is challenging on

160
00:06:33,410 --> 00:06:38,150
multiple fronts but most interesting to

161
00:06:36,020 --> 00:06:40,070
us was the spectrum of techniques used

162
00:06:38,150 --> 00:06:42,799
and their effectiveness in detecting

163
00:06:40,070 --> 00:06:47,210
these bugs before I actually manufacture

164
00:06:42,800 --> 00:06:49,850
the chip so there is a spectrum

165
00:06:47,210 --> 00:06:52,609
different approaches in for pre silicon

166
00:06:49,850 --> 00:06:57,020
verification there's proof carrying code

167
00:06:52,610 --> 00:06:58,819
where you basically translate or model

168
00:06:57,020 --> 00:07:00,409
your system mathematically and the

169
00:06:58,819 --> 00:07:02,599
properties that you want improve the

170
00:07:00,410 --> 00:07:05,569
properties for that system and give out

171
00:07:02,599 --> 00:07:07,009
code that carries the proof these are

172
00:07:05,569 --> 00:07:10,130
not very scalable and there are a lot

173
00:07:07,009 --> 00:07:11,990
more complex to use there's also a class

174
00:07:10,130 --> 00:07:15,110
of approaches that are based on model

175
00:07:11,990 --> 00:07:16,940
checking and and again there are

176
00:07:15,110 --> 00:07:19,729
scalability issues with these but

177
00:07:16,940 --> 00:07:22,940
bounding using bounded model checking or

178
00:07:19,729 --> 00:07:24,500
constraint state spaces helps alleviate

179
00:07:22,940 --> 00:07:26,509
the problem most of the

180
00:07:24,500 --> 00:07:28,039
industry-standard tools out there for

181
00:07:26,509 --> 00:07:30,039
functional verification for Hardware

182
00:07:28,039 --> 00:07:32,270
rely on some form of model checking

183
00:07:30,039 --> 00:07:33,830
there's also a class of approaches that

184
00:07:32,270 --> 00:07:35,750
relies on information flow analysis

185
00:07:33,830 --> 00:07:38,090
where you check that you do not have

186
00:07:35,750 --> 00:07:41,330
unauthorized information flows from your

187
00:07:38,090 --> 00:07:43,190
source to your destination signals and

188
00:07:41,330 --> 00:07:45,800
this is done at different levels of

189
00:07:43,190 --> 00:07:48,139
abstraction and there's there's little

190
00:07:45,800 --> 00:07:49,880
support out there for verifying the

191
00:07:48,139 --> 00:07:51,380
hardware with the firmware running on

192
00:07:49,880 --> 00:07:54,530
top of the hardware although there is

193
00:07:51,380 --> 00:07:56,659
work underway at Intel and a smaller

194
00:07:54,530 --> 00:07:59,869
company Tortuga logic where they try to

195
00:07:56,659 --> 00:08:02,840
approach this problem but scalability

196
00:07:59,870 --> 00:08:04,190
also remains an issue so just like I

197
00:08:02,840 --> 00:08:06,500
mentioned there are fundamental

198
00:08:04,190 --> 00:08:07,969
limitations with these techniques most

199
00:08:06,500 --> 00:08:10,460
importantly is the cost modular

200
00:08:07,969 --> 00:08:13,310
complexity of your SOC designs most of

201
00:08:10,460 --> 00:08:15,020
these techniques fail to scale with much

202
00:08:13,310 --> 00:08:18,259
larger system on chips real-world

203
00:08:15,020 --> 00:08:20,120
system-on-chip designs especially when

204
00:08:18,259 --> 00:08:23,469
you need to detect or verify properties

205
00:08:20,120 --> 00:08:26,229
that span many large modules of hardware

206
00:08:23,469 --> 00:08:29,240
these techniques cannot capture

207
00:08:26,229 --> 00:08:31,758
non-registered state so what happens

208
00:08:29,240 --> 00:08:33,799
with your caches it's mostly focused on

209
00:08:31,759 --> 00:08:36,320
registers days or the architecture of

210
00:08:33,799 --> 00:08:38,270
your of your designs you also cannot

211
00:08:36,320 --> 00:08:39,800
capture timing timing flow so there

212
00:08:38,270 --> 00:08:41,659
focus on functional information flows

213
00:08:39,799 --> 00:08:43,669
from one signal to the other but

214
00:08:41,659 --> 00:08:46,600
capturing timing channels is not

215
00:08:43,669 --> 00:08:48,829
directly supported in these techniques

216
00:08:46,600 --> 00:08:50,690
hardware software interactions are also

217
00:08:48,829 --> 00:08:52,640
completely missing in these tools they

218
00:08:50,690 --> 00:08:55,550
either verify Hardware loan or software

219
00:08:52,640 --> 00:08:58,400
alone and they're not actually very

220
00:08:55,550 --> 00:09:00,199
automated so you need to

221
00:08:58,400 --> 00:09:02,030
anticipate the security properties you

222
00:09:00,200 --> 00:09:03,590
want to test for you need to express

223
00:09:02,030 --> 00:09:05,959
them you need to give them to the tools

224
00:09:03,590 --> 00:09:13,190
and then there's a lot of human

225
00:09:05,960 --> 00:09:15,080
intervention involved in the process and

226
00:09:13,190 --> 00:09:16,940
so knowing all of this we wanted to test

227
00:09:15,080 --> 00:09:21,350
the effectiveness of these techniques

228
00:09:16,940 --> 00:09:23,120
and we and so we co-organized one

229
00:09:21,350 --> 00:09:24,590
real-world hardware box so we wanted to

230
00:09:23,120 --> 00:09:26,510
actually have real-world bugs where we

231
00:09:24,590 --> 00:09:28,880
try to detect them and we co-organized

232
00:09:26,510 --> 00:09:31,160
what our collaborators at Texas A&M

233
00:09:28,880 --> 00:09:32,540
University and Intel the first

234
00:09:31,160 --> 00:09:35,000
international hardware security

235
00:09:32,540 --> 00:09:37,520
competition hack attack which was

236
00:09:35,000 --> 00:09:40,790
co-located with the systems and hardware

237
00:09:37,520 --> 00:09:42,949
design conference TAC both in 2018 and

238
00:09:40,790 --> 00:09:48,829
in 2019 but in this talk I'll be

239
00:09:42,950 --> 00:09:50,690
focusing on our findings from 2018 so we

240
00:09:48,830 --> 00:09:51,860
took a deep dive into the bugs that get

241
00:09:50,690 --> 00:09:55,880
committed at the hardware implementation

242
00:09:51,860 --> 00:09:58,820
level which is a non-trivial task

243
00:09:55,880 --> 00:10:00,890
because real-world Hardware bugs happen

244
00:09:58,820 --> 00:10:03,830
to be in real-world hardware which is

245
00:10:00,890 --> 00:10:08,449
closed source and proprietary and so we

246
00:10:03,830 --> 00:10:10,460
decided to go for risk 5 SOC a risk 5

247
00:10:08,450 --> 00:10:12,830
system on chips testbed where we

248
00:10:10,460 --> 00:10:14,570
constructed and injected these bugs in

249
00:10:12,830 --> 00:10:16,700
close collaboration with our

250
00:10:14,570 --> 00:10:19,280
collaborators at Intel who are hardware

251
00:10:16,700 --> 00:10:22,040
security professionals and we injected

252
00:10:19,280 --> 00:10:24,380
these into the SOC s and we put them out

253
00:10:22,040 --> 00:10:27,199
for the teams to try and see how many of

254
00:10:24,380 --> 00:10:30,500
these bugs could these teams detects in

255
00:10:27,200 --> 00:10:32,600
both mm 18 and 19 over 100 teams from

256
00:10:30,500 --> 00:10:34,490
academia and industry participated in

257
00:10:32,600 --> 00:10:39,620
the competition which was pretty good

258
00:10:34,490 --> 00:10:41,200
turnover and after the 2018 after we did

259
00:10:39,620 --> 00:10:42,920
this investigation we did our own

260
00:10:41,200 --> 00:10:49,490
investigation using formal verification

261
00:10:42,920 --> 00:10:51,650
techniques one challenge here was how to

262
00:10:49,490 --> 00:10:52,550
systematically construct these bugs for

263
00:10:51,650 --> 00:10:54,110
our associates

264
00:10:52,550 --> 00:10:56,569
such that they're also as real-world as

265
00:10:54,110 --> 00:10:58,520
possible and so we based the bug

266
00:10:56,570 --> 00:11:01,430
selection and construction on real-world

267
00:10:58,520 --> 00:11:03,199
CVEs and processor errata that involve

268
00:11:01,430 --> 00:11:06,800
software exploitable hardware and

269
00:11:03,200 --> 00:11:09,350
firmware bugs and other other books were

270
00:11:06,800 --> 00:11:11,660
inspired by the insights and experience

271
00:11:09,350 --> 00:11:13,310
of our collaborators at Intel

272
00:11:11,660 --> 00:11:15,230
with issues that they themselves have

273
00:11:13,310 --> 00:11:17,660
encountered internally during the design

274
00:11:15,230 --> 00:11:24,080
process of during the hardware design

275
00:11:17,660 --> 00:11:26,199
process themself and we basically did

276
00:11:24,080 --> 00:11:28,580
this for risk five associates and

277
00:11:26,200 --> 00:11:30,589
reproduced these bugs and inserts them

278
00:11:28,580 --> 00:11:34,370
as well as additional security features

279
00:11:30,589 --> 00:11:35,990
to augment to these associates we

280
00:11:34,370 --> 00:11:38,480
attempted to achieve as much coverage as

281
00:11:35,990 --> 00:11:40,550
possible of security critical modules of

282
00:11:38,480 --> 00:11:43,370
our associate rai to inject the bugs

283
00:11:40,550 --> 00:11:46,609
into the interconnects the cryptographic

284
00:11:43,370 --> 00:11:47,959
engines debug interfaces and so on we

285
00:11:46,610 --> 00:11:49,370
also try to achieve coverage of the

286
00:11:47,959 --> 00:11:51,319
different effects these vulnerabilities

287
00:11:49,370 --> 00:11:53,480
or at least these bugs would have in

288
00:11:51,320 --> 00:11:56,450
terms of denial of service information

289
00:11:53,480 --> 00:11:57,860
leakage privilege escalation and such

290
00:11:56,450 --> 00:12:02,149
that they're also software exploitable

291
00:11:57,860 --> 00:12:04,160
at least most of them and in doing that

292
00:12:02,149 --> 00:12:06,470
we managed to construct a testbed of

293
00:12:04,160 --> 00:12:08,810
over 30 representative RTL bugs in

294
00:12:06,470 --> 00:12:11,230
hardware in a risk 5 SOC so you can

295
00:12:08,810 --> 00:12:13,670
check the full list in our paper and

296
00:12:11,230 --> 00:12:17,480
also please check our repository since

297
00:12:13,670 --> 00:12:19,370
we've just open sourced our testbed so I

298
00:12:17,480 --> 00:12:21,680
just want to quickly dive in into this

299
00:12:19,370 --> 00:12:25,459
SOC and showcase one or two examples of

300
00:12:21,680 --> 00:12:27,560
the bugs we've put in there so this is

301
00:12:25,459 --> 00:12:29,029
the risk 5 SOC that we've used for the

302
00:12:27,560 --> 00:12:30,680
back construction so as you can see it's

303
00:12:29,029 --> 00:12:33,860
not a toy example it's a real-world

304
00:12:30,680 --> 00:12:36,439
design it's a fully fledged SOC with an

305
00:12:33,860 --> 00:12:38,180
ax I interconnect a peripheral bus lots

306
00:12:36,440 --> 00:12:40,700
of other peripherals and a DMA engine

307
00:12:38,180 --> 00:12:42,589
and so on and we try to inject our bugs

308
00:12:40,700 --> 00:12:44,990
throughout different security critical

309
00:12:42,589 --> 00:12:49,360
components to spandy as much as possible

310
00:12:44,990 --> 00:12:55,279
of the SOC yeah

311
00:12:49,360 --> 00:12:57,890
and one example for these bugs was a

312
00:12:55,279 --> 00:13:00,140
memory access violation bug where there

313
00:12:57,890 --> 00:13:02,720
was a slight miss configuration in the

314
00:13:00,140 --> 00:13:06,260
memory about the configuration of the

315
00:13:02,720 --> 00:13:09,140
memory addresses that an SPI peripheral

316
00:13:06,260 --> 00:13:12,529
or serial processor peripheral and the

317
00:13:09,140 --> 00:13:14,810
SOC controller module map - and this is

318
00:13:12,529 --> 00:13:17,350
a very simple RTL bug but it's actually

319
00:13:14,810 --> 00:13:19,819
but it has actually very critical

320
00:13:17,350 --> 00:13:22,550
privilege escalation consequences from a

321
00:13:19,820 --> 00:13:23,690
security standpoint and although it's

322
00:13:22,550 --> 00:13:25,640
actually pretty

323
00:13:23,690 --> 00:13:26,720
it's very difficult to detect that kind

324
00:13:25,640 --> 00:13:29,830
of bug using formal verification

325
00:13:26,720 --> 00:13:32,510
techniques because it would require

326
00:13:29,830 --> 00:13:34,400
verifying very complex bus protocols and

327
00:13:32,510 --> 00:13:37,010
their implementation which was which

328
00:13:34,400 --> 00:13:39,110
spanned many many modules of hardware

329
00:13:37,010 --> 00:13:41,420
implementation that kind of bug is

330
00:13:39,110 --> 00:13:43,040
actually easier to detect or was easier

331
00:13:41,420 --> 00:13:45,709
to detect by the teams by manual

332
00:13:43,040 --> 00:13:48,500
inspection because the team sort of had

333
00:13:45,710 --> 00:13:50,450
an intuition of which where would we

334
00:13:48,500 --> 00:13:52,190
which what are the high risk areas or

335
00:13:50,450 --> 00:13:57,200
the areas where we would inject bugs and

336
00:13:52,190 --> 00:13:59,240
they chose where to focus on another

337
00:13:57,200 --> 00:14:02,360
example of a bug that was actually

338
00:13:59,240 --> 00:14:04,190
software exploitable it was a bug that

339
00:14:02,360 --> 00:14:07,460
was in the finite state machine of the

340
00:14:04,190 --> 00:14:10,640
ax I bus address decoder the bug

341
00:14:07,460 --> 00:14:12,440
basically the ax at the finite state

342
00:14:10,640 --> 00:14:14,030
machine has to keep state in the sense

343
00:14:12,440 --> 00:14:16,010
that it keeps track of every memory

344
00:14:14,030 --> 00:14:18,290
access that's coming in and whether it's

345
00:14:16,010 --> 00:14:19,819
allowed or not and it was a small bug in

346
00:14:18,290 --> 00:14:23,959
the finite state machine that basically

347
00:14:19,820 --> 00:14:27,830
meant the the if a faulty transaction

348
00:14:23,960 --> 00:14:29,960
comes in a subsequent transaction that

349
00:14:27,830 --> 00:14:31,940
is not if it's if it's also faulty it

350
00:14:29,960 --> 00:14:33,320
still slips through the check it should

351
00:14:31,940 --> 00:14:34,790
check every time whether a transaction

352
00:14:33,320 --> 00:14:36,710
was allowed or not but this bug

353
00:14:34,790 --> 00:14:38,630
basically lets one faulty transaction

354
00:14:36,710 --> 00:14:41,930
gets in and then a subsequent one to

355
00:14:38,630 --> 00:14:43,970
also slip through unconditionally and so

356
00:14:41,930 --> 00:14:46,430
we show how we could exploit and it had

357
00:14:43,970 --> 00:14:49,400
a simple bug like that with a software

358
00:14:46,430 --> 00:14:51,469
the software attack where we could

359
00:14:49,400 --> 00:14:53,150
trigger malicious memory accesses and do

360
00:14:51,470 --> 00:14:54,740
privilege escalation but you know due to

361
00:14:53,150 --> 00:15:01,640
time constraints you will have to check

362
00:14:54,740 --> 00:15:07,640
out the attack in the paper so one

363
00:15:01,640 --> 00:15:12,170
example of a native okay another example

364
00:15:07,640 --> 00:15:14,720
so that the competition itself was okay

365
00:15:12,170 --> 00:15:17,000
there was also and some the teams that

366
00:15:14,720 --> 00:15:18,980
could also detect bugs that we did not

367
00:15:17,000 --> 00:15:21,290
inject ourselves but already existed in

368
00:15:18,980 --> 00:15:22,820
the open source implementations such as

369
00:15:21,290 --> 00:15:25,630
with the real time this was an example

370
00:15:22,820 --> 00:15:28,310
of a bug but I won't go through that

371
00:15:25,630 --> 00:15:30,740
like I said we had one competition hack

372
00:15:28,310 --> 00:15:34,069
attack for the teams to detect these

373
00:15:30,740 --> 00:15:35,450
bugs which consisted of phase one and

374
00:15:34,070 --> 00:15:38,870
phase two

375
00:15:35,450 --> 00:15:41,990
and the teams used a different types of

376
00:15:38,870 --> 00:15:44,090
techniques mostly manual inspection and

377
00:15:41,990 --> 00:15:48,110
also dynamic verification simulation

378
00:15:44,090 --> 00:15:50,660
based techniques as well as formal

379
00:15:48,110 --> 00:15:52,730
verification however most of the teams

380
00:15:50,660 --> 00:15:54,560
eventually relied on manual inspection

381
00:15:52,730 --> 00:15:56,690
because it was the most intuitive and

382
00:15:54,560 --> 00:15:58,430
accessible to them some teams did use

383
00:15:56,690 --> 00:16:00,200
formal verification but they complained

384
00:15:58,430 --> 00:16:02,930
that the tools tools would not scale

385
00:16:00,200 --> 00:16:04,910
well in our study we focused on formal

386
00:16:02,930 --> 00:16:07,880
verification techniques we used the two

387
00:16:04,910 --> 00:16:09,589
of cadence Jasper Gold's techniques

388
00:16:07,880 --> 00:16:13,010
formal property verification and

389
00:16:09,590 --> 00:16:14,810
security path verification and the two

390
00:16:13,010 --> 00:16:16,460
main challenges that we encountered when

391
00:16:14,810 --> 00:16:18,229
using these tools which were formal

392
00:16:16,460 --> 00:16:21,280
verification tools dedicated for

393
00:16:18,230 --> 00:16:23,420
security analysis was state exposure and

394
00:16:21,280 --> 00:16:25,550
identifying and expressing the security

395
00:16:23,420 --> 00:16:30,079
properties that you actually want to

396
00:16:25,550 --> 00:16:33,170
detect so I won't go through our

397
00:16:30,080 --> 00:16:34,400
detection results in detail but I just

398
00:16:33,170 --> 00:16:36,800
want to know that want you to know that

399
00:16:34,400 --> 00:16:38,810
out of 31 bugs we investigated we could

400
00:16:36,800 --> 00:16:40,910
actually only detect 15 using formal

401
00:16:38,810 --> 00:16:42,979
verification techniques and we could

402
00:16:40,910 --> 00:16:47,329
only formulate security properties for

403
00:16:42,980 --> 00:16:49,220
only 17 of them and through our findings

404
00:16:47,330 --> 00:16:51,260
basically we see that there are certain

405
00:16:49,220 --> 00:16:53,960
classes of bugs that are fundamentally

406
00:16:51,260 --> 00:16:54,650
very challenging to detect using state

407
00:16:53,960 --> 00:16:58,520
of the art form of verification

408
00:16:54,650 --> 00:16:59,990
techniques because of because of the

409
00:16:58,520 --> 00:17:01,760
because they cannot capture timing

410
00:16:59,990 --> 00:17:04,339
channels because they require

411
00:17:01,760 --> 00:17:05,839
verification of the software and the

412
00:17:04,339 --> 00:17:08,929
firmware at the firmware and the

413
00:17:05,839 --> 00:17:11,480
hardware together there are bugs that

414
00:17:08,930 --> 00:17:13,100
span multiple modules and books for

415
00:17:11,480 --> 00:17:15,620
which security properties cannot be

416
00:17:13,099 --> 00:17:17,899
expressed for and so what we need now is

417
00:17:15,619 --> 00:17:19,459
basically this is a call for action we

418
00:17:17,900 --> 00:17:21,050
need to investigate and research more

419
00:17:19,460 --> 00:17:23,510
scalable Hardware assurance techniques

420
00:17:21,050 --> 00:17:25,579
and exploit open source hardware to

421
00:17:23,510 --> 00:17:29,150
actually do that better the risks and

422
00:17:25,579 --> 00:17:30,620
the gains and our ongoing work now is to

423
00:17:29,150 --> 00:17:32,390
try and have future editions of hack

424
00:17:30,620 --> 00:17:34,330
attack expanding to systems design

425
00:17:32,390 --> 00:17:36,800
system security conferences and

426
00:17:34,330 --> 00:17:39,020
developing hybrids hardware security

427
00:17:36,800 --> 00:17:40,610
assurance approaches which basically

428
00:17:39,020 --> 00:17:42,940
combine fuzzing with formal verification

429
00:17:40,610 --> 00:17:45,229
techniques to try and achieve better

430
00:17:42,940 --> 00:17:46,520
scalability with larger system on chip

431
00:17:45,230 --> 00:17:50,330
designs

432
00:17:46,520 --> 00:17:56,570
that would be it thank you very much

433
00:17:50,330 --> 00:18:02,428
[Applause]

434
00:17:56,570 --> 00:18:04,500
questions hi this is Raju from I'm a

435
00:18:02,429 --> 00:18:06,210
security researcher at intel line thanks

436
00:18:04,500 --> 00:18:11,390
for a very nice presentation and the pre

437
00:18:06,210 --> 00:18:11,390
silicon I can't I can't hear you sorry

438
00:18:15,080 --> 00:18:20,428
hi thanks for the nice presentation I'm

439
00:18:17,700 --> 00:18:22,590
from Nintendo so one general question on

440
00:18:20,429 --> 00:18:25,770
the pre silicon security evaluation work

441
00:18:22,590 --> 00:18:28,530
you have done had you considered any

442
00:18:25,770 --> 00:18:31,280
assessment of the impact of the process

443
00:18:28,530 --> 00:18:34,440
technology underneath on the hardware

444
00:18:31,280 --> 00:18:37,200
the manufacturing process like 40

445
00:18:34,440 --> 00:18:40,350
nanometer nanometer I see your point

446
00:18:37,200 --> 00:18:42,360
thank you so know in this in this study

447
00:18:40,350 --> 00:18:44,610
we focused on logical implementation

448
00:18:42,360 --> 00:18:45,840
bugs at the RTL level I understand that

449
00:18:44,610 --> 00:18:48,090
you're referring to physical effects

450
00:18:45,840 --> 00:18:49,500
that might come up for physical faults

451
00:18:48,090 --> 00:18:50,970
that occur due to the manufacturing

452
00:18:49,500 --> 00:18:53,790
technology this this would actually be

453
00:18:50,970 --> 00:18:57,150
an an interesting thing to explore for

454
00:18:53,790 --> 00:19:00,299
another hack attack but yes in this one

455
00:18:57,150 --> 00:19:02,610
we focus on functional on unlogical bugs

456
00:19:00,299 --> 00:19:07,559
in the RTL implementation per se thanks

457
00:19:02,610 --> 00:19:09,570
thank you all right John Criswell

458
00:19:07,559 --> 00:19:12,149
University of Rochester it's nice work

459
00:19:09,570 --> 00:19:14,428
one question I have is your call to

460
00:19:12,150 --> 00:19:17,880
action calls for more verification that

461
00:19:14,429 --> 00:19:19,350
bugs have not entered into the system if

462
00:19:17,880 --> 00:19:21,030
I understand it correctly right it's a

463
00:19:19,350 --> 00:19:23,668
formal verification that sort of thing

464
00:19:21,030 --> 00:19:25,860
I'm wondering if the hardware community

465
00:19:23,669 --> 00:19:27,630
is also considering correct by

466
00:19:25,860 --> 00:19:29,159
construction techniques on the software

467
00:19:27,630 --> 00:19:30,960
world for example we have programming

468
00:19:29,160 --> 00:19:33,210
types of programming languages with type

469
00:19:30,960 --> 00:19:35,250
systems that prevent us from creating

470
00:19:33,210 --> 00:19:37,890
buggy software to begin with at least

471
00:19:35,250 --> 00:19:39,450
for certain classes of bugs so are there

472
00:19:37,890 --> 00:19:41,040
similar considerations being taken by

473
00:19:39,450 --> 00:19:43,440
the hardware community yes there's a

474
00:19:41,040 --> 00:19:45,750
hidden side on that so there is work

475
00:19:43,440 --> 00:19:47,100
going on in proposing hardware

476
00:19:45,750 --> 00:19:48,929
description languages new ones and

477
00:19:47,100 --> 00:19:51,750
extending existing ones where there is

478
00:19:48,929 --> 00:19:54,000
security typing or some sort where you

479
00:19:51,750 --> 00:19:56,159
would then identify okay these are my

480
00:19:54,000 --> 00:19:58,080
signals this is the security label of

481
00:19:56,159 --> 00:19:59,760
each one of my signals and this is what

482
00:19:58,080 --> 00:20:01,949
I expect out of each one of them the

483
00:19:59,760 --> 00:20:04,470
this is like asking software programmers

484
00:20:01,950 --> 00:20:06,210
to use rust and to change their to

485
00:20:04,470 --> 00:20:08,130
change their mindset most hardware

486
00:20:06,210 --> 00:20:09,570
designers don't want to migrate to newer

487
00:20:08,130 --> 00:20:12,000
hardware description languages

488
00:20:09,570 --> 00:20:14,399
it also affects your IP reuse the

489
00:20:12,000 --> 00:20:16,890
community is based on reusing IP cores

490
00:20:14,400 --> 00:20:18,240
or that's already that's already

491
00:20:16,890 --> 00:20:19,350
designed you would need to migrate

492
00:20:18,240 --> 00:20:22,470
everything to numerous descriptions

493
00:20:19,350 --> 00:20:26,820
languages but yes there is ongoing work

494
00:20:22,470 --> 00:20:28,360
in that direction okay thank you let's

495
00:20:26,820 --> 00:20:34,159
think you speak here again

496
00:20:28,360 --> 00:20:34,159
[Applause]