1
00:00:00,390 --> 00:00:12,019
preroll music
2
00:00:12,019 --> 00:00:15,290
Herald: I’m really glad that
you’re all here and that today
3
00:00:15,290 --> 00:00:19,350
I can introduce Joanna Rutkowska to you.
4
00:00:19,350 --> 00:00:25,000
She will be talking about reasonably
trustworthy x86 systems.
5
00:00:25,000 --> 00:00:30,150
She’s the founder and leader
of the Invisible Things Lab
6
00:00:30,150 --> 00:00:37,149
and also – that’s also something you all
probably use – the Qubes OS project.
7
00:00:37,149 --> 00:00:41,600
She presented numerous attacks
on Intel based systems and also
8
00:00:41,600 --> 00:00:46,829
virtualization systems. But today she
will not only speak about the problems
9
00:00:46,829 --> 00:00:52,329
of those machines but will present some
solutions to make them more secure.
10
00:00:52,329 --> 00:00:54,550
Give it up for Joanna Rutkowska!
11
00:00:54,550 --> 00:01:03,329
applause
12
00:01:03,329 --> 00:01:09,300
Joanna: Okay, so, let’s start
with stating something obvious.
13
00:01:09,300 --> 00:01:14,210
Personal computers have become
really the extensions of our brains.
14
00:01:14,210 --> 00:01:18,000
I think most of you will
probably agree with that.
15
00:01:18,000 --> 00:01:21,159
Yet the problem is that they are insecure
16
00:01:21,159 --> 00:01:25,869
and untrustworthy,
17
00:01:25,869 --> 00:01:29,299
which personally bothers me al lot.
18
00:01:29,299 --> 00:01:32,250
And here I want to make a quick digression
19
00:01:32,250 --> 00:01:38,149
for the vocabulary I’m gonna
be using during this presentation.
20
00:01:38,149 --> 00:01:41,170
When we say, well, there are
three adjectives related to trust
21
00:01:41,170 --> 00:01:45,140
and people will often confuse them.
When we say something is “trusted”,
22
00:01:45,140 --> 00:01:49,740
that means by definition something
can compromise the security of
23
00:01:49,740 --> 00:01:54,770
the whole system, which means
we don’t like things to be trusted.
24
00:01:54,770 --> 00:02:00,329
“Trusted third party”, “Trusted CA”
we don’t like that.
25
00:02:00,329 --> 00:02:02,320
When we say something is...
26
00:02:02,320 --> 00:02:06,500
because “trusted” doesn’t necessarily
mean that it is “secure”.
27
00:02:06,500 --> 00:02:12,730
So, what is secure? Secure is
something that is resistant to attacks.
28
00:02:12,730 --> 00:02:18,829
Perhaps this laptop might
be resistant to attacks.
29
00:02:18,829 --> 00:02:22,610
If I open [an] email attachment and the
email attachment compromises my system
30
00:02:22,610 --> 00:02:28,540
or maybe that if I plug
USB for the slide changer
31
00:02:28,540 --> 00:02:33,700
I might be hoping that this
action will not compromise
32
00:02:33,700 --> 00:02:37,159
my whole PC.
33
00:02:37,159 --> 00:02:40,999
And yet something can be
secure but not trustworthy.
34
00:02:40,999 --> 00:02:45,360
A good example of this might be e. g.
35
00:02:45,360 --> 00:02:49,750
Intel Management Engine (ME), that I’m
gonna be talking about more later.
36
00:02:49,750 --> 00:02:54,180
So it might be very resistant to attacks,
so it might be a backdoor.
37
00:02:54,180 --> 00:02:57,180
A backdoor that is
very resistant to attacks,
38
00:02:57,180 --> 00:03:02,480
yet it is not acting in
the interests of the user.
39
00:03:02,480 --> 00:03:09,170
So it’s not “good”, whatever
good means in your assumed,
40
00:03:09,170 --> 00:03:12,969
moral reference.
41
00:03:12,969 --> 00:03:18,750
So, there’s been of course a lot of work
42
00:03:18,750 --> 00:03:24,110
in the last 20 years and maybe more
43
00:03:24,110 --> 00:03:27,540
to build solutions that provide
44
00:03:27,540 --> 00:03:30,750
security and trustworthiness
45
00:03:30,750 --> 00:03:35,640
and most of this work has focused on
the application layer and things like
46
00:03:35,640 --> 00:03:38,709
GnuPG and PGP first,
47
00:03:38,709 --> 00:03:45,490
TOR, all the secure communication
protocols and programs.
48
00:03:45,490 --> 00:03:49,720
But of course,
49
00:03:49,720 --> 00:03:55,750
it is clear that any effort
on the application level
50
00:03:55,750 --> 00:04:00,810
is just meaningless if we can
not assure, if we can not trust
51
00:04:00,810 --> 00:04:06,579
our operating system (OS).
Because the OS is the trusted part.
52
00:04:06,579 --> 00:04:12,680
So if the OS is compromised
then everything is lost.
53
00:04:12,680 --> 00:04:18,260
And there has been some efforts,
notably the project I started 5 years ago
54
00:04:18,260 --> 00:04:24,130
and now this is like more than a dozen
of people working on it: Qubes OS.
55
00:04:24,130 --> 00:04:28,360
It tries to address the problem of OS’s
56
00:04:28,360 --> 00:04:32,230
being part of the PCB,
so what we try to do is
57
00:04:32,230 --> 00:04:37,750
shrink the amount of trusted
code to an absolute minimum.
58
00:04:37,750 --> 00:04:41,510
There’s been also other
efforts in this area.
59
00:04:41,510 --> 00:04:46,730
But OS’s is not something I’m
gonna be discussing today.
60
00:04:46,730 --> 00:04:54,250
What I’m gonna be discussing today
is the final layer, is the hardware.
61
00:04:54,250 --> 00:05:00,700
Because what was OS to applications
it is hardware to the OS.
62
00:05:00,700 --> 00:05:05,380
Again, most of the effort so far
63
00:05:05,380 --> 00:05:07,720
to create secure and trustworthy OS,
64
00:05:07,720 --> 00:05:14,000
they have always been assuming
that the hardware is trusted.
65
00:05:14,000 --> 00:05:18,850
That means that... usually
that means for most OS’s that
66
00:05:18,850 --> 00:05:24,100
a single malicious
peripheral on this laptop,
67
00:05:24,100 --> 00:05:30,530
like a malicious Wi-Fi module
or maybe embedded controller
68
00:05:30,530 --> 00:05:34,810
can compromise again my whole PC,
69
00:05:34,810 --> 00:05:39,340
my whole digital life.
70
00:05:39,340 --> 00:05:42,760
So what to do about it?
71
00:05:42,760 --> 00:05:46,500
Before we discuss what to do about it
72
00:05:46,500 --> 00:05:52,550
we should quickly
73
00:05:52,550 --> 00:05:59,050
recap all the problems
with present PC platforms
74
00:05:59,050 --> 00:06:03,180
and specifically I’m gonna
be focusing on x86 platform
75
00:06:03,180 --> 00:06:09,850
and specifically with Intel x86
platform, which means: laptops.
76
00:06:09,850 --> 00:06:17,340
This picture shows how a
typical modern laptop looks like.
77
00:06:17,340 --> 00:06:23,160
You can see that it consists of
78
00:06:23,160 --> 00:06:28,260
a processor in the center,
and then there is memory,
79
00:06:28,260 --> 00:06:32,120
some peripherals, keyboard and monitor.
80
00:06:32,120 --> 00:06:36,210
Very simple.
81
00:06:36,210 --> 00:06:41,060
It can be very simple, because
82
00:06:41,060 --> 00:06:47,250
if we look at present Intel processors
83
00:06:47,250 --> 00:06:53,130
they really integrate everything
and the kitchen sink.
84
00:06:53,130 --> 00:07:00,300
Ten years ago we used to have a processor,
a Northbridge, a Southbridge
85
00:07:00,300 --> 00:07:03,640
and perhaps even more discrete
elements on the motherboard.
86
00:07:03,640 --> 00:07:11,830
Today nearly all these elements have been
integrated into one processor package.
87
00:07:11,830 --> 00:07:13,780
This is Broadwell
88
00:07:13,780 --> 00:07:19,710
and this long element
here is the CPU and GPU
89
00:07:19,710 --> 00:07:26,490
and the other one it
is said to be the PCH.
90
00:07:26,490 --> 00:07:30,960
PCH is what used to be
the platform controller hub,
91
00:07:30,960 --> 00:07:34,930
which is what used to be called
the Southbridge and Northbridge.
92
00:07:34,930 --> 00:07:39,850
The line has somehow
blurred between these.
93
00:07:39,850 --> 00:07:42,060
Of course there is only one
company making these.
94
00:07:42,060 --> 00:07:46,050
It’s an American
company called INTEL.
95
00:07:46,050 --> 00:07:51,410
It is a completely opaque construction.
96
00:07:51,410 --> 00:08:00,080
We have absolutely no ways
to examine what’s inside.
97
00:08:00,080 --> 00:08:04,520
That obviously...
The advantage is that
98
00:08:04,520 --> 00:08:09,030
it makes construction of computers,
of laptops very easy now.
99
00:08:09,030 --> 00:08:13,410
And lots of vendors can
produce little sexy laptops,
100
00:08:13,410 --> 00:08:17,510
like the one I have here.
101
00:08:17,510 --> 00:08:23,820
On this picture we see now some more
elements that are in this processor.
102
00:08:23,820 --> 00:08:28,620
So, when you say processor
today, it’s no longer CPU.
103
00:08:28,620 --> 00:08:34,470
Processor is now CPU, GPU,
memory controller, hub, PCIe,
104
00:08:34,470 --> 00:08:38,800
root, some Southbridge,
105
00:08:38,800 --> 00:08:46,110
so e.g. SATA controller and so on,
as well as something
106
00:08:46,110 --> 00:08:52,900
that is called Management Engine (ME),
which we discuss in a moment.
107
00:08:52,900 --> 00:08:56,920
There are few more elements
here that are important.
108
00:08:56,920 --> 00:09:02,270
The most important for us
is the SPI flash element.
109
00:09:02,270 --> 00:09:07,780
Because what’s interesting is that
with this whole integration
110
00:09:07,780 --> 00:09:11,960
that has happened to the processor
and the other peripherals,
111
00:09:11,960 --> 00:09:15,640
still the storage for the firmware,
112
00:09:15,640 --> 00:09:21,550
so the storage where your BIOS as
well as other firmware is stored,
113
00:09:21,550 --> 00:09:29,980
is still a discrete element.
114
00:09:29,980 --> 00:09:34,460
We’ll see this element in
one of the next slides.
115
00:09:34,460 --> 00:09:39,280
So let’s now consider first
116
00:09:39,280 --> 00:09:46,080
the problem of boot security.
117
00:09:46,080 --> 00:09:49,960
Obviously everybody understands
that boot security is something
118
00:09:49,960 --> 00:09:54,330
- how to start the chain of
trust for whatever software
119
00:09:54,330 --> 00:10:03,370
is gonna be running later -
is of a paramount importance.
120
00:10:03,370 --> 00:10:15,510
I think I’m out of range.
121
00:10:15,510 --> 00:10:18,520
Connected with boot security
is malicious peripherals,
122
00:10:18,520 --> 00:10:22,760
that I mentioned shortly before.
123
00:10:22,760 --> 00:10:27,520
So we’ll be now thinking: Can we assure
124
00:10:27,520 --> 00:10:30,890
only good code is started
125
00:10:30,890 --> 00:10:38,000
and how the peripherals
might interfere here.
126
00:10:38,000 --> 00:10:41,920
Again, we will look at this SPI flash.
127
00:10:41,920 --> 00:10:47,530
If we're now considering the boot
security we would like to understand
128
00:10:47,530 --> 00:10:54,150
what code is loaded on the platform. And
if we now think where this code is stored,
129
00:10:54,150 --> 00:10:57,880
it seems that the code is stored on
the SPI Flash and potentially also
130
00:10:57,880 --> 00:11:03,310
on some of the discrete elements.
131
00:11:03,310 --> 00:11:08,330
Let me state it again that this whole
integrated processor package
132
00:11:08,330 --> 00:11:13,110
has everything and the kitchen
sink except for the flash,
133
00:11:13,110 --> 00:11:21,560
so except for the storage of the firmware.
134
00:11:21,560 --> 00:11:25,650
Here we have one of the SPI flash chips.
135
00:11:25,650 --> 00:11:28,460
This is from my Laptop actually.
136
00:11:28,460 --> 00:11:32,110
It’s a little microcontroller
137
00:11:32,110 --> 00:11:38,900
and it typically stores the firmware for
these things, that are written here.
138
00:11:38,900 --> 00:11:47,340
Now the question is, let's say I
have got this laptop from a store.
139
00:11:47,340 --> 00:11:55,720
How can I actually verify what
firmware is really on this chip?
140
00:11:55,720 --> 00:12:00,940
Well I can perhaps boot it into some
minimal Linux and try to ask it.
141
00:12:00,940 --> 00:12:05,120
But of course if there is some malicious
something on the motherboard,
142
00:12:05,120 --> 00:12:12,950
not necessarily this chip,
I will not get reliable answers.
143
00:12:12,950 --> 00:12:20,900
Another question: Let’s say I somehow
know that there’s something trustworthy
144
00:12:20,900 --> 00:12:27,020
on this SPI chip. Can I somehow enforce
read-only’ness of this program?
145
00:12:27,020 --> 00:12:30,020
There have been some efforts to do that.
146
00:12:30,020 --> 00:12:36,630
Like some projects by Peter Stuge
who just took a soldering iron
147
00:12:36,630 --> 00:12:43,680
and connected one of the pins - one
of these 8 pins is called “write protect”.
148
00:12:43,680 --> 00:12:50,430
If you ground it, it will be telling the
chip to discard any Write commands.
149
00:12:50,430 --> 00:12:54,710
But again, remember, this chip
is still a little microcontroller,
150
00:12:54,710 --> 00:12:59,440
it’s a little computer. So it might
ignore whatever you requested to do.
151
00:12:59,440 --> 00:13:05,320
It’s not like you are cutting off
a signal for Write commands.
152
00:13:05,320 --> 00:13:09,630
You are merely asking the
processor to ignore it.
153
00:13:09,630 --> 00:13:16,330
So if you don’t trust the chip in the
first place, this doesn’t provide you
154
00:13:16,330 --> 00:13:19,810
a reliable way to enforce read-only’ness.
155
00:13:19,810 --> 00:13:26,010
Finally can I upload my own firmware?
Can I choose to use whatever BIOS I want?
156
00:13:26,010 --> 00:13:30,570
Again, we don’t seem to have luck here.
157
00:13:34,530 --> 00:13:38,110
And as I mentioned, this is just
one of the places on the platform
158
00:13:38,110 --> 00:13:42,200
where the state is stored.
Embedded controller would be
159
00:13:42,200 --> 00:13:49,020
a whole another microcontroller
having its own internal flash.
160
00:13:49,020 --> 00:13:54,040
Or if not, using another
SPI chip to get flash from.
161
00:13:54,040 --> 00:13:59,270
A disk would be another
microcontroller with a small computer,
162
00:13:59,270 --> 00:14:05,190
having its own - typically -
flash for its own firmware.
163
00:14:05,190 --> 00:14:11,190
And perhaps the same
with the Wi-Fi module.
164
00:14:11,190 --> 00:14:18,150
Now for many years, myself and
lots of other people believed that
165
00:14:18,150 --> 00:14:25,080
technologies like TPM, trusted execution
technology... like UEFI Secure Boot
166
00:14:25,080 --> 00:14:29,300
I never really liked, but many people
did - they believed that they could
167
00:14:29,300 --> 00:14:32,410
somehow solve the problem of secure boot.
168
00:14:32,410 --> 00:14:38,370
But all of these technologies
have been shown to fail horribly
169
00:14:38,370 --> 00:14:44,440
in this... on this premise.
170
00:14:44,440 --> 00:14:47,090
And then we have...
So these were problems,
171
00:14:47,090 --> 00:14:52,590
the tip of the iceberg of
problems of the secure boot.
172
00:14:52,590 --> 00:15:01,640
The short story is: Today we can
not really assure secure boot.
173
00:15:01,640 --> 00:15:08,050
Maybe before we move on to
Intel ME: e.g. Intel TXT:
174
00:15:08,050 --> 00:15:12,160
Trusted Execution Technology was
introduced by Intel in the hope
175
00:15:12,160 --> 00:15:19,029
to put the BIOS outside of the TCB,
trusted computing base for the platform.
176
00:15:19,029 --> 00:15:26,440
So, the idea was that if you use TXT
which you can think of as
177
00:15:26,440 --> 00:15:32,710
a special instruction of the processor,
that was the root of trust.
178
00:15:32,710 --> 00:15:37,220
So, the promise was that
when using Intel TXT
179
00:15:37,220 --> 00:15:45,089
you can start the chain of trust
180
00:15:45,089 --> 00:15:50,370
without trusting the BIOS.
As well as other peripherals
181
00:15:50,370 --> 00:15:54,320
like Wi-Fi card, which might
be malicious perhaps.
182
00:15:54,320 --> 00:16:01,210
And that was just great.
And I really like the technology.
183
00:16:01,210 --> 00:16:04,940
With my team we have done
lots of research on TXT.
184
00:16:04,940 --> 00:16:10,940
But one of the first attacks that we have
presented, and that was back in like 2009,
185
00:16:10,940 --> 00:16:16,500
was that we could bypass TXT
by having a malicious SMM.
186
00:16:16,500 --> 00:16:20,190
SMM was loaded by the BIOS.
187
00:16:20,190 --> 00:16:26,640
So apparently it turned out, that the BIOS
could not be really put outside of the TCB
188
00:16:26,640 --> 00:16:32,080
so easily, because if it was really
malicious it would provide a malicious SMM
189
00:16:32,080 --> 00:16:38,440
and then the SMM could bypass TXT.
So the response from Intel was: “OK,
190
00:16:38,440 --> 00:16:46,190
but worry not, we have a technology
called STM - Secure Transfer Monitor.”
191
00:16:46,190 --> 00:16:54,589
That is a little hypervisor to sandbox
the SMM which might be malicious.
192
00:16:54,589 --> 00:17:02,480
So they wanted to boot
a special dedicated...
193
00:17:02,480 --> 00:17:09,209
they built it actually... they built a
special technology to sandbox this SMM.
194
00:17:09,209 --> 00:17:14,420
And then it turned out
this is not so easy.
195
00:17:14,420 --> 00:17:17,050
Because as usual they
were missing the details.
196
00:17:17,050 --> 00:17:22,050
And it is 6 years, 6 years has passed and
197
00:17:22,050 --> 00:17:28,369
we still have not seen
any real STM in the wild.
198
00:17:28,369 --> 00:17:35,880
Which just is an example how
hopeless this approach in building,
199
00:17:35,880 --> 00:17:44,079
in trying to provide secure
boot is for the x86 platform.
200
00:17:44,079 --> 00:17:47,330
Another problem with x86 that
201
00:17:47,330 --> 00:17:52,210
has risen to prominence in the recent
years is the Intel Management Engine.
202
00:17:52,210 --> 00:17:58,530
One of these things, that Intel
203
00:17:58,530 --> 00:18:04,800
has put into this integrated processor
is called Management Engine (ME).
204
00:18:04,800 --> 00:18:12,140
And this ME is a little microcontroller
that is inside your processor.
205
00:18:12,140 --> 00:18:18,900
It has its own internal RAM,
it has its own internal peripherals.
206
00:18:18,900 --> 00:18:26,850
Like DMA engine, which
has access to the host RAM.
207
00:18:26,850 --> 00:18:34,120
And of course, it loads only
Intel-signed firmware.
208
00:18:34,120 --> 00:18:40,610
And it has also its own private ROM inside
the processor, that nobody can inspect.
209
00:18:40,610 --> 00:18:45,230
And nobody knows what it does.
210
00:18:45,230 --> 00:18:51,200
And it runs a whole bunch
of proprietary programs.
211
00:18:51,200 --> 00:18:58,500
And it runs even Intel’s
own proprietary OS.
212
00:18:58,500 --> 00:19:03,630
And this all is happening all the time
when you have some power connected
213
00:19:03,630 --> 00:19:07,460
to your processor.
Even if it’s in a sleep mode.
214
00:19:07,460 --> 00:19:10,970
It’s running all the time
here on my computer.
215
00:19:10,970 --> 00:19:17,830
It can be doing anything it wants.
216
00:19:17,830 --> 00:19:21,520
Obviously when I say something
like that the first thought for,
217
00:19:21,520 --> 00:19:25,220
at least for security people
is: “This is an ideal
218
00:19:25,220 --> 00:19:30,660
backdooring or rootkitting
infrastructure.” Which is true.
219
00:19:30,660 --> 00:19:33,860
However there is another
problem and it’s Zombification.
220
00:19:33,860 --> 00:19:38,330
I call it Zombification of personal
computing that I will discuss in a moment.
221
00:19:38,330 --> 00:19:50,390
I’m just stressing these are two somehow
independent problems with this ME.
222
00:19:50,390 --> 00:19:57,120
About 10 or more years ago I used to be
a very active malware researcher or
223
00:19:57,120 --> 00:20:03,010
scout malware researcher. Especially
rootkit researcher and back then when,
224
00:20:03,010 --> 00:20:09,040
if I was to imagine an ideal
infrastructure for writing rootkits,
225
00:20:09,040 --> 00:20:16,600
I couldn’t possibly imagine
anything better than ME.
226
00:20:16,600 --> 00:20:22,830
Because ME has access to essentially
everything that is important.
227
00:20:22,830 --> 00:20:27,160
As I mentioned it has
unconstrained access to DRAM,
228
00:20:27,160 --> 00:20:31,130
to the actual CPU, to GPU.
229
00:20:31,130 --> 00:20:36,180
It can also talk to your networking card,
230
00:20:36,180 --> 00:20:39,930
especially to the Ethernet card
231
00:20:39,930 --> 00:20:45,900
which controller is also in the
Southbridge in the processor.
232
00:20:45,900 --> 00:20:50,610
It can also talk to the SPI
flash and asks the SPI flash.
233
00:20:50,610 --> 00:20:54,670
It has its own dedicated
partition on the SPI flash,
234
00:20:54,670 --> 00:21:02,260
which can be used to store
whatever ME wants to store there.
235
00:21:02,260 --> 00:21:07,830
This is really problematic and
we don’t know what it runs.
236
00:21:11,080 --> 00:21:15,470
But the other problem,
that is perhaps less obvious,
237
00:21:15,470 --> 00:21:27,360
is what I call zombification of
the General Purpose Computing.
238
00:21:27,360 --> 00:21:32,830
About a year ago there
was a book published by
239
00:21:32,830 --> 00:21:39,120
one of the Intel architects, one of the
architects who designed Intel ME.
240
00:21:39,120 --> 00:21:41,790
I highly recommend this book.
241
00:21:41,790 --> 00:21:51,570
It’s the only somehow official source
of information about Intel ME.
242
00:21:51,570 --> 00:21:58,240
And what the book has made clear is that
243
00:21:58,240 --> 00:22:03,740
the model of computing that
Intel envisions in the future,
244
00:22:03,740 --> 00:22:08,840
is to take the model, that we have
today, which looks like this.
245
00:22:08,840 --> 00:22:13,990
The size of the boxes somehow
attempts to present
246
00:22:13,990 --> 00:22:21,330
the amount of logic or involvement
of each of the layers
247
00:22:21,330 --> 00:22:25,290
in processing of the user data.
248
00:22:25,290 --> 00:22:29,610
Obviously we have most of this
processing done in the applications.
249
00:22:29,610 --> 00:22:37,050
But we also have some involvement from the
OS and also from the hardware, of course.
250
00:22:37,050 --> 00:22:42,150
For example, when we want to
generate a random number
251
00:22:42,150 --> 00:22:56,820
we would usually ask an OS to
252
00:22:56,820 --> 00:22:59,200
return us the random number.
253
00:22:59,200 --> 00:23:05,490
Because the OS can generate it using
timings and interrupts, whatever.
254
00:23:05,490 --> 00:23:10,890
But again, most of the logic, most of
the code is in the application’s layer.
255
00:23:10,890 --> 00:23:14,240
And this is good, because
256
00:23:14,240 --> 00:23:19,549
thanks to computing being
general purpose computing,
257
00:23:19,549 --> 00:23:22,620
everyone of us can write applications.
258
00:23:22,620 --> 00:23:28,890
We can argue what is the best
way to implement some crypto.
259
00:23:28,890 --> 00:23:33,910
Some people can write it one way, some
other people can write it another way.
260
00:23:33,910 --> 00:23:36,500
And that’s good.
261
00:23:36,500 --> 00:23:42,000
Now this is the model
that Intel wants to go to.
262
00:23:42,000 --> 00:23:48,250
It essentially wants to eliminate
all the logic that touches data
263
00:23:48,250 --> 00:23:54,950
from apps and OS even
and move it to Intel ME.
264
00:23:54,950 --> 00:24:03,830
Because, remember,
Intel ME is also an OS.
265
00:24:03,830 --> 00:24:10,710
It’s a separate OS. Only that this is an
OS that nobody knows how it works.
266
00:24:10,710 --> 00:24:13,730
It’s an OS, that nobody
has any possibility
267
00:24:13,730 --> 00:24:18,040
to look at the source code
or even reverse engineer.
268
00:24:18,040 --> 00:24:21,590
Because even we can not
really analyse the binaries.
269
00:24:21,590 --> 00:24:29,590
It’s the OS that is fully controlled
by Intel. And not to mention that
270
00:24:29,590 --> 00:24:34,240
any functionality it offers is
also fully controlled by Intel.
271
00:24:34,240 --> 00:24:42,880
Without anybody being
able to verify what they do.
272
00:24:42,880 --> 00:24:45,360
That might not even be malicious.
273
00:24:45,360 --> 00:24:48,179
They may not even be
doing malicious things.
274
00:24:48,179 --> 00:24:51,730
Perhaps they are just
implementing something wrong.
275
00:24:51,730 --> 00:24:57,230
Bugs. Security bugs, right?
276
00:24:57,230 --> 00:25:00,820
But of course Intel believes
that whatever Intel writes
277
00:25:00,820 --> 00:25:06,520
must be secure.
278
00:25:06,520 --> 00:25:12,220
For some reason the must have missed
279
00:25:12,220 --> 00:25:17,040
a number of papers that my team and others
280
00:25:17,040 --> 00:25:25,450
have published in the recent 10 years.
281
00:25:25,450 --> 00:25:30,730
The questions are: Can we disable Intel ME
or can we control what code runs there?
282
00:25:30,730 --> 00:25:34,470
Can we see at least what code is there?
283
00:25:34,470 --> 00:25:39,799
And as far as I’m aware the
answer is unfortunately: Not.
284
00:25:39,799 --> 00:25:44,350
As I mentioned, I have this cool
laptop it runs Qubes OS, of course,
285
00:25:44,350 --> 00:25:51,970
but still it not only runs Qubes OS.
It also runs side by side Intel ME.
286
00:25:51,970 --> 00:25:54,919
Intel ME proprietary OS.
287
00:25:54,919 --> 00:26:06,000
And I can’t do anything about it.
288
00:26:06,000 --> 00:26:14,330
About 6 or 7 years ago my team
has done some work on Intel AMT.
289
00:26:14,330 --> 00:26:17,850
I believe this was the first and probably
the only work where we managed
290
00:26:17,850 --> 00:26:23,570
to actually inject code into
ME. That was back in times
291
00:26:23,570 --> 00:26:29,270
when Intel ME was not in the
processor. It was in the Northbridge.
292
00:26:29,270 --> 00:26:35,740
It was in the Q35 or Q45 chipset,
if I remember correctly.
293
00:26:35,740 --> 00:26:42,320
So we demonstrated how we
can inject a rootkit into ME.
294
00:26:42,320 --> 00:26:46,470
Of course Intel then patched it.
295
00:26:46,470 --> 00:26:51,049
Now they continue to think that whatever
they write will be always secure.
296
00:26:51,049 --> 00:26:55,270
But, the problem is...
297
00:26:55,270 --> 00:27:00,590
For a number of years after that
presentation I used to believe
298
00:27:00,590 --> 00:27:09,220
that we could use VTD
- an INTEL IMMU technology with TXT -
299
00:27:09,220 --> 00:27:11,900
perhaps to effectively sandbox ME.
300
00:27:11,900 --> 00:27:15,360
Because some of the specifications I saw,
301
00:27:15,360 --> 00:27:21,059
suggested that VTD should be able to
302
00:27:21,059 --> 00:27:25,830
sandbox ME accesses to host memory.
303
00:27:25,830 --> 00:27:32,580
And because we used VTD heavily
on Qubes, thanks to Xen using it,
304
00:27:32,580 --> 00:27:42,730
I was pretty much not
that worried about ME.
305
00:27:42,730 --> 00:27:51,000
Unfortunately it turned out
that ME can just bypass VTD.
306
00:27:51,000 --> 00:27:58,940
And this is a feature of this ME.
307
00:27:58,940 --> 00:28:04,570
Which brings us to this rather
sad conclusion that perhaps
308
00:28:04,570 --> 00:28:14,760
if we look at Intel x86 platform,
then the war is lost here.
309
00:28:14,760 --> 00:28:18,260
It might be lost even
if we didn’t have ME.
310
00:28:18,260 --> 00:28:24,460
Even if we somehow manage to
convince Intel to get rid of ME,
311
00:28:24,460 --> 00:28:31,279
or at least to offer OEMs, Laptop
vendors, an option to disable it,
312
00:28:31,279 --> 00:28:35,100
by fusing something.
313
00:28:39,190 --> 00:28:44,630
The problem with secure boot
that I mentioned earlier,
314
00:28:44,630 --> 00:28:49,840
and that I analysed in more detail
in a paper I released 2 months ago,
315
00:28:49,840 --> 00:28:53,120
is that it really is hopeless,
316
00:28:53,120 --> 00:28:58,289
because of the complexity
of the architecture
317
00:28:58,289 --> 00:29:03,900
where we have ring 3, ring 0, okay. Then
we have SMM, then we have virtualisation,
318
00:29:03,900 --> 00:29:09,640
then we have STM to sandbox SMM,
and the interactions between these.
319
00:29:09,640 --> 00:29:20,030
This all doesn’t look really like
it could be solved effectively,
320
00:29:20,030 --> 00:29:26,809
which of course bothers me a lot.
321
00:29:26,809 --> 00:29:29,020
At least on purely egoistic reasons,
322
00:29:29,020 --> 00:29:34,910
because I spent the last 5 years
of my life on this Qubes project.
323
00:29:34,910 --> 00:29:41,940
And of course with such a state of
things it makes my whole Qubes project
324
00:29:41,940 --> 00:29:47,090
somehow meaningless.
325
00:29:47,090 --> 00:29:52,360
If the situation is so bad,
326
00:29:52,360 --> 00:29:58,250
perhaps the only way to solve the problem
is to change the rules of the game.
327
00:29:58,250 --> 00:30:06,070
Because you can not really
win under the old rules.
328
00:30:06,070 --> 00:30:14,390
That’s why I wanted to share
this approach with you today.
329
00:30:14,390 --> 00:30:21,610
That starts with recognizing that
330
00:30:21,610 --> 00:30:27,610
most of the problems here is
related to the persistent state,
331
00:30:27,610 --> 00:30:32,630
that is stored pretty much
everywhere on your platform,
332
00:30:32,630 --> 00:30:42,280
which usually keeps the
firmware, but not only.
333
00:30:42,280 --> 00:30:50,549
So let’s imagine, that we could do a
clean separation of state from hardware.
334
00:30:50,549 --> 00:30:59,079
So this is the current picture.
This is your laptop.
335
00:30:59,079 --> 00:31:05,870
The reddish boxes are state,
the persistent state.
336
00:31:05,870 --> 00:31:11,659
That means these are places
where malware can persist.
337
00:31:11,659 --> 00:31:17,510
So you reinstall the OS, but
the malware still can re-infect.
338
00:31:17,510 --> 00:31:23,280
There are also places where
malware can store secrets,
339
00:31:23,280 --> 00:31:29,539
once it steals them from you.
So imagine I can have malware,
340
00:31:29,539 --> 00:31:36,210
that might only be stealing
my disk encryption key.
341
00:31:36,210 --> 00:31:42,530
And it can store it somewhere on
the disk or maybe on SPI flash.
342
00:31:42,530 --> 00:31:48,979
Or maybe in the Wi-Fi module firmware, or
maybe in the embedded controller firmware,
343
00:31:48,979 --> 00:31:56,860
somewhere. Somewhere
there in those red rectangles.
344
00:31:56,860 --> 00:32:00,100
Now if the malware does it,
that is a pretty fatal situation,
345
00:32:00,100 --> 00:32:03,960
because if my laptop
gets stolen or seized,
346
00:32:03,960 --> 00:32:10,390
perhaps then the adversary who gets
347
00:32:10,390 --> 00:32:13,850
a key to the malware can
just decrypt the blobs.
348
00:32:13,850 --> 00:32:21,809
And the blobs would reveal my disk
decryption key. And then the game is over.
349
00:32:21,809 --> 00:32:25,960
And also another problem with
this state is that it might be
350
00:32:25,960 --> 00:32:34,200
revealing many of the user and
personally identifiable information.
351
00:32:34,200 --> 00:32:39,580
How ever you read this PI shortcut.
352
00:32:39,580 --> 00:32:43,720
These are for example MAC addresses.
353
00:32:43,720 --> 00:32:48,179
Or maybe processor serial number.
354
00:32:48,179 --> 00:32:51,340
Or maybe ME serial number. Whatever!
355
00:32:51,340 --> 00:32:57,850
Or maybe the list of SSID networks,
that ME has seen recently.
356
00:32:57,850 --> 00:33:01,850
How do you know it’s not being
stored somewhere on your SPI flash?
357
00:33:01,850 --> 00:33:07,069
You don’t know what is stored there.
Even though I can’t take off my SPI flash
358
00:33:07,069 --> 00:33:14,419
or just connect a programmer to my
SPI flash - an EEPROM programmer -
359
00:33:14,419 --> 00:33:27,010
I can read the contents of the SPI
flash, but all of this will be encrypted.
360
00:33:27,010 --> 00:33:31,460
Now we recognize, that the
state might be problematic.
361
00:33:31,460 --> 00:33:36,700
And now imagine a picture, that
we have the laptop, which has
362
00:33:36,700 --> 00:33:44,340
no persistent state storage.
Which is this blue rectangle.
363
00:33:44,340 --> 00:33:47,669
Let’s call it stateless laptop.
364
00:33:47,669 --> 00:33:53,659
And then we have another element,
that we’re gonna call trusted stick
365
00:33:53,659 --> 00:33:57,850
for lack of any more sexy name for it.
366
00:33:57,850 --> 00:34:04,749
That’s gonna be keeping all the firmware,
all the platform configuration,
367
00:34:04,749 --> 00:34:09,719
all the system partitions,
like boot and root,
368
00:34:09,719 --> 00:34:14,789
all the user partitions.
369
00:34:14,789 --> 00:34:18,889
Now we see that... and of course the
firmware and system partitions
370
00:34:18,889 --> 00:34:22,549
will be exposed in a read only manner.
371
00:34:22,549 --> 00:34:28,009
So even if malware, perhaps a traditional
malware, that got into my system
372
00:34:28,009 --> 00:34:35,339
through a malicious attachment,
even if it found a weakness in the BIOS,
373
00:34:35,339 --> 00:34:40,359
or maybe in the chipset, allowing
it to re-flash normally, allowing it
374
00:34:40,359 --> 00:34:51,228
to re-flash the BIOS - we have seen plenty of
such attacks in the recent several years.
375
00:34:51,228 --> 00:34:54,698
Now it would not be able
to succeed, because
376
00:34:54,698 --> 00:34:59,940
the trusted stick, which gonna be a
simple FPGA implemented device,
377
00:34:59,940 --> 00:35:07,599
will just be exposing
the read-only storage.
378
00:35:07,599 --> 00:35:13,390
You see that firmware injection
can be prevented this way.
379
00:35:13,390 --> 00:35:17,109
Also there is no places
to store stolen secrets.
380
00:35:17,109 --> 00:35:21,869
Again, the same malware running in the ME
381
00:35:21,869 --> 00:35:27,640
still can steal my disk encryption
key or my PGP private key.
382
00:35:27,640 --> 00:35:31,099
But it has no place to store it.
383
00:35:31,099 --> 00:35:35,880
So if somebody now takes my laptop,
will not be able to find it there.
384
00:35:35,880 --> 00:35:39,719
You might say, maybe it will be
able to store it on the stick.
385
00:35:39,719 --> 00:35:45,219
But then, again, the stick, the firmware
and system partitions are read-only.
386
00:35:45,219 --> 00:35:49,359
And the user partitions
are encrypted by the stick.
387
00:35:49,359 --> 00:35:56,769
So even if ME can send something to be
stored there, nobody besides the user
388
00:35:56,769 --> 00:36:02,910
can really get hands on this blob.
389
00:36:02,910 --> 00:36:06,900
Also we get a reliable way to
verify what firmware we use.
390
00:36:06,900 --> 00:36:11,219
Or ability to choose what
firmware we want to use.
391
00:36:11,219 --> 00:36:17,650
Because we can just take this stick,
plug into our trustworthy computer,
392
00:36:17,650 --> 00:36:26,009
some, I don’t know, Lenovo X60 from 15
years ago, that we have running Coreboot
393
00:36:26,009 --> 00:36:30,249
and we just analysed all
the elements, whatever.
394
00:36:30,249 --> 00:36:39,080
So we finally a have a way to
upload firmware in a reliable way.
395
00:36:39,080 --> 00:36:45,580
Thanks to the actual laptop having no
state, we can have something like Tails
396
00:36:45,580 --> 00:36:54,680
finally doing what it advertises.
I can boot Tails or something like that.
397
00:36:54,680 --> 00:37:02,660
I can use it, I can shut it down and there
is no more traces of my activity there.
398
00:37:02,660 --> 00:37:08,329
I can give my laptop to somebody other.
Or I can boot some other environment.
399
00:37:08,329 --> 00:37:19,900
Perhaps some, I don’t know,
Windows to play games, or whatever.
400
00:37:19,900 --> 00:37:27,499
So what would it take to have
such a stateless laptop?
401
00:37:27,499 --> 00:37:32,910
This is the simplest version which
shows that the only modification
402
00:37:32,910 --> 00:37:37,920
that has been made here was
to take the SPI flash chip
403
00:37:37,920 --> 00:37:42,710
and essentially put it outside
the laptop on a trusted stick.
404
00:37:42,710 --> 00:37:49,509
And just route the wiring,
just 4 wires, to the trusted stick.
405
00:37:49,509 --> 00:37:50,749
And that’s pretty much it.
406
00:37:50,749 --> 00:37:55,989
That’s the simplest version. Oh,
and I also got rid of the disk.
407
00:37:55,989 --> 00:38:02,779
And also I had to ensure, that
whatever discrete devices,
408
00:38:02,779 --> 00:38:06,260
which are in that case embedded
controller and Wi-Fi module,
409
00:38:06,260 --> 00:38:10,819
they do not have flash memory
but use something like OTP memory.
410
00:38:10,819 --> 00:38:14,420
We can further get rid
of the Wi-Fi, and use
411
00:38:14,420 --> 00:38:18,400
an external USB connected
one if that is not possible.
412
00:38:18,400 --> 00:38:22,559
And for the embedded controller that
should be possible, much more easier,
413
00:38:22,559 --> 00:38:27,289
because embedded controller is always
something that the OEM chooses.
414
00:38:27,289 --> 00:38:33,779
So we can just talk to whatever
OEM, who would like to implement
415
00:38:33,779 --> 00:38:39,069
this stateless laptop, and ask the
OEM to use an embedded controller
416
00:38:39,069 --> 00:38:45,259
with essentially ROM, instead of flash.
417
00:38:45,259 --> 00:38:51,680
So that’s the simplest version,
which is really simple.
418
00:38:51,680 --> 00:38:57,269
This is a more complex version
where we also fit something
419
00:38:57,269 --> 00:39:04,669
that I call here SPI Multiplexer.
Which allows to share the firmware
420
00:39:04,669 --> 00:39:09,130
not just to the processor, but
also to the embedded controller.
421
00:39:09,130 --> 00:39:12,329
And perhaps also with the disk.
422
00:39:12,329 --> 00:39:16,329
Because maybe we actually
would like to have internal disk.
423
00:39:16,329 --> 00:39:22,989
Because internal disk will always
be faster and will always be bigger
424
00:39:22,989 --> 00:39:29,400
than whatever disk we will
put on our trusted stick.
425
00:39:29,400 --> 00:39:36,489
You might object, that, come on, disk
is actually not a stateless thing! Right?
426
00:39:36,489 --> 00:39:44,480
Because disk is made especially
to store state persistently.
427
00:39:44,480 --> 00:39:50,099
But it’s a special disk, that I will
mention in just a few minutes.
428
00:39:50,099 --> 00:39:54,530
It’s a special disk running trusted
firmware and doing read-only
429
00:39:54,530 --> 00:39:59,319
and encryption for everything.
430
00:39:59,319 --> 00:40:05,059
And now for the trusted stick:
431
00:40:05,059 --> 00:40:10,900
As I mentioned, the trusted
stick is envisioned to have
432
00:40:10,900 --> 00:40:14,160
read-only and encrypted partitions.
433
00:40:14,160 --> 00:40:22,739
And the read-only partitions are for
firmware and the system code.
434
00:40:22,739 --> 00:40:29,289
So the first block is something that we
would like to export over SPI, typically,
435
00:40:29,289 --> 00:40:34,479
and the system partition is
something that we make visible
436
00:40:34,479 --> 00:40:42,969
to the OS using something like
pretending being USB mass storage
437
00:40:42,969 --> 00:40:52,559
or actually implementing
USB mass storage protocol.
438
00:40:52,559 --> 00:40:57,680
And the encrypted partition
- again, the important thing here is
439
00:40:57,680 --> 00:41:06,309
that encryption should be
implemented by the stick itself.
440
00:41:06,309 --> 00:41:10,589
So we have some key here,
441
00:41:10,589 --> 00:41:14,319
the question is how this key should be...
442
00:41:14,319 --> 00:41:22,150
What input should be taken
to derive this key from.
443
00:41:22,150 --> 00:41:27,849
It could be something that
is persistent to the stick.
444
00:41:27,849 --> 00:41:31,239
It could be combined with a
passphrase, that the user enters
445
00:41:31,239 --> 00:41:37,819
using a traditional keyboard,
plus maybe a secret from the TPM.
446
00:41:37,819 --> 00:41:44,079
And when I say TPM I think about the
firmware TPM inside the processor
447
00:41:44,079 --> 00:41:47,190
that is using storage provided by
448
00:41:47,190 --> 00:41:57,050
encrypted firmware partition.
449
00:41:57,050 --> 00:42:01,829
The optional internal disk
that I just mentioned,
450
00:42:01,829 --> 00:42:07,279
it should essentially do
the same as the stick,
451
00:42:07,279 --> 00:42:11,209
and because it will be
running trusted firmware
452
00:42:11,209 --> 00:42:15,739
that it will be fetching
from the trusted stick itself
453
00:42:15,739 --> 00:42:19,640
the disk will not have any flash memory.
454
00:42:19,640 --> 00:42:24,109
So because we will trust
the hardware of the disk
455
00:42:24,109 --> 00:42:28,160
and because we will trust the
firmware, we will trust the firmware
456
00:42:28,160 --> 00:42:32,789
to provide read-only and encrypted
partitions just like those ones
457
00:42:32,789 --> 00:42:39,119
I mentioned on the stick, which is nice
because it reveals the stick from acting
458
00:42:39,119 --> 00:42:44,140
as a mass storage device, which has
459
00:42:44,140 --> 00:42:50,630
practical consequences which are nice.
460
00:42:50,630 --> 00:42:59,209
So there’s a picture with the internal
trusted disk, which you see just here.
461
00:42:59,209 --> 00:43:04,009
As you can see, it takes also the
firmware from the trusted stick.
462
00:43:04,009 --> 00:43:09,509
And there is even an open source
project, OpenSSD. And it looks like
463
00:43:09,509 --> 00:43:18,200
people have already built an open hardware
open firmware SSD, a very performant disk.
464
00:43:18,200 --> 00:43:28,520
So this is not just science
fiction, even for this SSD.
465
00:43:28,520 --> 00:43:34,909
Okay, so that looks all very nice,
but there is one problem.
466
00:43:34,909 --> 00:43:42,700
Even though malware may not have any
place on the laptop to leak the secrets,
467
00:43:42,700 --> 00:43:46,549
it still might try to do
it over networking.
468
00:43:46,549 --> 00:43:52,660
And let’s differentiate now between
classic malware and sophisticated malware.
469
00:43:52,660 --> 00:43:59,499
Classic malware is something you get with
an attachment or some drive-by-attack
470
00:43:59,499 --> 00:44:04,070
which we’ll discuss in a moment.
Now, let’s focus on sophisticated malware.
471
00:44:04,070 --> 00:44:17,399
So, a hypothetical rootkit in ME.
472
00:44:17,399 --> 00:44:23,999
Before we move on, for obvious
reasons, such a sophisticated malware
473
00:44:23,999 --> 00:44:30,130
would not be interested
in getting caught easily.
474
00:44:30,130 --> 00:44:37,580
So, it would not be establishing a
TCP connection to NSA.gov server
475
00:44:37,580 --> 00:44:44,849
or whatever, right?
That would be plain stupid.
476
00:44:44,849 --> 00:44:49,619
Having that in mind, let’s
consider a few scenarios.
477
00:44:49,619 --> 00:44:54,739
Scenario number 0 is
an air-gapped system.
478
00:44:54,739 --> 00:44:58,079
Even though it might
be an air-gapped system,
479
00:44:58,079 --> 00:45:01,519
still remember there is ME running there.
480
00:45:01,519 --> 00:45:11,619
If the computer is not
inside a Faraday cage,
481
00:45:11,619 --> 00:45:18,559
there is still plenty of other
networks or devices around it.
482
00:45:18,559 --> 00:45:25,539
Which means that ME can theoretically
use your Wi-Fi card or even speaker
483
00:45:25,539 --> 00:45:33,019
to establish a covert channel with, say,
your phone, that might be just nearby.
484
00:45:33,019 --> 00:45:39,450
So, in order to make such a
system truly air-gapped,
485
00:45:39,450 --> 00:45:42,880
knowing that we can not get rid of the ME,
486
00:45:42,880 --> 00:45:48,299
we really need to have kill-switches
for any transmitting devices,
487
00:45:48,299 --> 00:45:53,569
including the speakers, and apparently
even that might not be enough,
488
00:45:53,569 --> 00:45:58,200
because some people showed
covert channels that used
489
00:45:58,200 --> 00:46:04,420
things like power fluctuations
490
00:46:04,420 --> 00:46:11,670
or temperature fluctuations but let’s
leave that exotic examples aside.
491
00:46:11,670 --> 00:46:18,609
A more interesting scenario is a
closed network of trusted nodes.
492
00:46:18,609 --> 00:46:24,019
In that scenario we assume that
all these people are trusted.
493
00:46:24,019 --> 00:46:27,660
Again, by definition that means that
any of these people can compromise
494
00:46:27,660 --> 00:46:33,180
the security of anybody else.
We really don’t like trusted things,
495
00:46:33,180 --> 00:46:38,229
but, well, let’s start with something.
496
00:46:38,229 --> 00:46:46,420
Now, even though each of these trusted
peers which run state-less laptops,
497
00:46:46,420 --> 00:46:52,869
even each of these have
this malicious ME in itself
498
00:46:52,869 --> 00:46:58,079
because we gonna fit a small proxy
499
00:46:58,079 --> 00:47:02,920
so a modification that we are...
that we should additionally do,
500
00:47:02,920 --> 00:47:08,259
that I have not shown you before,
is that rather than connecting
501
00:47:08,259 --> 00:47:13,599
your Wi-Fi module directly to the
processor which is not good,
502
00:47:13,599 --> 00:47:19,009
because it gives full authority of the
processor over this Wi-Fi module.
503
00:47:19,009 --> 00:47:23,670
Instead we would like to
connect it to some proxy.
504
00:47:23,670 --> 00:47:27,709
It would be doing some kind of tunnelling.
505
00:47:27,709 --> 00:47:34,199
Something like VPN or maybe TORifying
any traffic that is generated there.
506
00:47:34,199 --> 00:47:40,309
So even though ME might be willing
to be sending some traffic
507
00:47:40,309 --> 00:47:42,630
maybe not explicit traffic,
508
00:47:42,630 --> 00:47:48,390
maybe will be piggybacking on
some user generated traffic,
509
00:47:48,390 --> 00:47:56,239
by only modifying, I don’t know, TCP
initial sequence numbers, or something.
510
00:47:56,239 --> 00:48:00,530
It still all will be happening
inside the tunnel.
511
00:48:00,530 --> 00:48:05,589
Again, some people might be
saying “Yeah, but still ME
512
00:48:05,589 --> 00:48:09,869
might be modulating the timings
of the generated packets
513
00:48:09,869 --> 00:48:18,629
and this way try to convey some
information using timing.”
514
00:48:18,629 --> 00:48:21,650
We can’t truly do much about that
but on the other hand it would be
515
00:48:21,650 --> 00:48:27,870
extremely difficult for ME to
do that, implementation wise.
516
00:48:27,870 --> 00:48:32,769
Finally a scenario where
we want to use any...
517
00:48:32,769 --> 00:48:38,140
when we want to connect with anybody
not just with a trusted computer.
518
00:48:38,140 --> 00:48:44,469
So, say, with some website on the internet
that might or might not be trusted.
519
00:48:44,469 --> 00:48:52,119
Again, by having this proxy which by
the way might be implemented inside
520
00:48:52,119 --> 00:48:57,089
this embedded controller that
we know, if you remember,
521
00:48:57,089 --> 00:49:05,569
it runs the trusted firmware because it
fetches firmware from our trusted stick.
522
00:49:05,569 --> 00:49:11,759
So the proxy again is tunnelling
any potential leakage from ME
523
00:49:11,759 --> 00:49:18,130
which means that a malicious ISP or
any part of the infrastructure here
524
00:49:18,130 --> 00:49:23,529
still can not really retrieve the
secrets that ME tries to leak.
525
00:49:23,529 --> 00:49:28,239
But of course at some point we need to
terminate the stunnel that might be
526
00:49:28,239 --> 00:49:36,069
the VPN server or might be a TOR exit
node or maybe the server itself if it’s,
527
00:49:36,069 --> 00:49:45,709
say, maybe an onion server, in
which case anybody here can still
528
00:49:45,709 --> 00:49:55,129
presumably get the secrets
from ME in this cloud here.
529
00:49:55,129 --> 00:49:58,489
Which unfortunately we
can do nothing about.
530
00:49:58,489 --> 00:50:05,180
Except for hoping that at least
if we used perhaps TOR
531
00:50:05,180 --> 00:50:09,219
for this first part of the equation
532
00:50:09,219 --> 00:50:13,690
then at least a malicious
administrator of, say, this server
533
00:50:13,690 --> 00:50:17,029
would not be able to
correlate whose decryption...
534
00:50:17,029 --> 00:50:19,880
whose disk decryption key it really is.
535
00:50:19,880 --> 00:50:24,039
Although this is very tricky. That would
only work if this computer was
536
00:50:24,039 --> 00:50:27,739
a special purpose computer. If you
used something like Qubes here
537
00:50:27,739 --> 00:50:32,150
and if you wanted to have different
partitions, one for your personal
538
00:50:32,150 --> 00:50:37,580
and only one of these partitions
would be special secret partitions.
539
00:50:37,580 --> 00:50:41,859
That wouldn’t work, because
ME still would be able to gather
540
00:50:41,859 --> 00:50:47,259
your identification information
from whatever partitions you have.
541
00:50:47,259 --> 00:50:53,259
Because again, it has unconstrained access
to all the personal, all the host memory.
542
00:50:53,259 --> 00:51:01,199
But still this... using this
proxy pushes adversary,
543
00:51:01,199 --> 00:51:05,869
hypothetical adversary, in the
ME, into extreme difficulty
544
00:51:05,869 --> 00:51:11,579
of needing to piggy-back on
some higher-level protocols
545
00:51:11,579 --> 00:51:18,119
establishing exotic cover channels.
Comparing to what they can do today
546
00:51:18,119 --> 00:51:23,039
one can... they simply steal the key
and store it on SPI first partition.
547
00:51:23,039 --> 00:51:28,910
Or maybe on your disk. This is like
orders of magnitude more difficult
548
00:51:28,910 --> 00:51:34,589
for them to do.
549
00:51:34,589 --> 00:51:37,569
We mentioned the sophisticated
malware and I mentioned
550
00:51:37,569 --> 00:51:44,319
the classic malware is a different story.
The classic malware doesn’t need
551
00:51:44,319 --> 00:51:51,549
to be shy against leaking something
through whatever means you can think of.
552
00:51:51,549 --> 00:51:59,380
Perhaps by sending email to somebody. But
obviously to address the classic malware
553
00:51:59,380 --> 00:52:07,229
problem we can address it quite
reasonably well on the OS level.
554
00:52:07,229 --> 00:52:14,209
For example using compartmentalization.
But here comes the problem,
555
00:52:14,209 --> 00:52:20,680
is, that a malicious BIOS...
556
00:52:20,680 --> 00:52:24,609
Let me get back a little bit. Because
so far we having assuming that
557
00:52:24,609 --> 00:52:28,959
we don’t really need to trust the BIOS.
Because having this stateless laptop
558
00:52:28,959 --> 00:52:34,420
and trusted stick, even if the BIOS was
malicious, it still, again, would not
559
00:52:34,420 --> 00:52:40,199
be able to change anything in its own
firmware partition, would not be able to
560
00:52:40,199 --> 00:52:45,180
store any stolen secrets
anywhere. So it’s convenient
561
00:52:45,180 --> 00:52:51,260
to figure that the BIOS
might not be trusted.
562
00:52:51,260 --> 00:52:59,320
But then, again, a compromised
BIOS might instead be providing
563
00:52:59,320 --> 00:53:07,979
privilege escalation backdoors for
classic malware that executes on your
564
00:53:07,979 --> 00:53:12,900
compartmentalised OS.
Such as to do VM escape.
565
00:53:12,900 --> 00:53:16,229
Such things are trivial to implement.
566
00:53:16,229 --> 00:53:21,199
And we don’t want classic malware
which means we want to ensure
567
00:53:21,199 --> 00:53:27,559
that the BIOS does not
provide such backdoors.
568
00:53:27,559 --> 00:53:35,239
And to make it short, we need open-source
BIOS. Something like Coreboot.
569
00:53:35,239 --> 00:53:40,199
It’s great that we have Coreboot
and we could help Coreboot
570
00:53:40,199 --> 00:53:43,789
to become such a BIOS
for this stateless laptop.
571
00:53:43,789 --> 00:53:50,200
Even though Coreboot is not fully open-
source - it relies on so-called Intel FSP,
572
00:53:50,200 --> 00:53:56,279
the firmware support package, which
is a Intel blob that is needed to
573
00:53:56,279 --> 00:54:04,519
initialize your DRAM and other silicon
- still it should be reasonably easy to
574
00:54:04,519 --> 00:54:10,650
ensure that FSP does not
provide SMM backdoors.
575
00:54:10,650 --> 00:54:16,460
So this is a solvable problem.
576
00:54:16,460 --> 00:54:25,139
Finally there’s this question:
So let’s say half a year from now
577
00:54:25,139 --> 00:54:30,239
or a year from now pure reason
or somebody will tell you
578
00:54:30,239 --> 00:54:37,549
here is the stateless laptop.
You can order, just a 1000 dollars.
579
00:54:37,549 --> 00:54:43,619
So you got the laptop. But how do you
know it really IS a stateless laptop?
580
00:54:43,619 --> 00:54:50,309
Maybe it is full of state-caring
elements. Maybe it’s full of
581
00:54:50,309 --> 00:54:56,239
radio devices that are
emanating radios everywhere.
582
00:54:56,239 --> 00:55:04,009
This comes down to the problem of:
How do we compare 2 different PCBs?
583
00:55:04,009 --> 00:55:06,499
Two different Printed Circuit Boards?
584
00:55:06,499 --> 00:55:13,900
As far as I’m aware right now our industry
has no ways to compare two different PCBs
585
00:55:13,900 --> 00:55:17,859
and to state: yes they look identical.
586
00:55:17,859 --> 00:55:26,249
Because if we had that, then we could
have the vendor, the laptop vendor
587
00:55:26,249 --> 00:55:33,079
which would obviously have to be
open-hardware to publish the schematics
588
00:55:33,079 --> 00:55:37,979
and pictures of the boards and then
anybody who ordered this laptop
589
00:55:37,979 --> 00:55:43,699
would have an opportunity to always,
say, photograph the board and
590
00:55:43,699 --> 00:55:51,170
have a diff tool to compare it.
If it really looks the same.
591
00:55:51,170 --> 00:55:56,859
Sure we would not be able to see inside
the chips but at least the geometry-wise
592
00:55:56,859 --> 00:56:06,269
comparison would be a tremendous step
to making such malicious modifications
593
00:56:06,269 --> 00:56:09,579
by vendors very difficult.
594
00:56:09,579 --> 00:56:13,900
This is a vision problem, kind of, right?
You take 2 photos, have 2 photos
595
00:56:13,900 --> 00:56:20,910
of 2 PCBs and you have a tool to compare
it. And I believe Jake Applebaum
596
00:56:20,910 --> 00:56:26,989
has already mentioned it,
some... a year ago probably,
597
00:56:26,989 --> 00:56:37,999
it’s a great research project for all
you academic people sitting here.
598
00:56:37,999 --> 00:56:43,809
That’s an example of a board that...
I have no idea, I got this laptop,
599
00:56:43,809 --> 00:56:52,660
I opened it, I see this board. Sure, I can
identify some IC elements
600
00:56:52,660 --> 00:56:55,980
like this embedded controller here...
601
00:56:55,980 --> 00:56:59,729
But, really, maybe it’s connected
somehow differently,
602
00:56:59,729 --> 00:57:02,819
maybe there is some other flash
elements there, I don’t know.
603
00:57:02,819 --> 00:57:09,009
I would like to have an ability now to
check this with a called-in image
604
00:57:09,009 --> 00:57:18,419
that some experts will analyze
in-depth and say it’s safe to use.
605
00:57:18,419 --> 00:57:26,469
Many people say that perhaps we should
all give up on Intel x86 because ME e.g.
606
00:57:26,469 --> 00:57:34,039
applause
607
00:57:34,039 --> 00:57:39,309
Yet this is not such a nice idea.
608
00:57:39,309 --> 00:57:47,809
Or maybe this is not such a
silver bullet, I should have said.
609
00:57:47,809 --> 00:57:53,459
First, we have ARM. Everybody says
“Why not ARM? Let’s go to ARM!”
610
00:57:53,459 --> 00:57:57,910
First: There’s no such thing as an ARM
processor. Okay?
611
00:57:57,910 --> 00:58:04,199
ARM just sells the specifications, or IP.
612
00:58:04,199 --> 00:58:12,319
And then the vendors, like Samsung,
Texas Instruments etc. who take this IP
613
00:58:12,319 --> 00:58:18,199
and design and make very own SOC.
This is still a proprietary processor
614
00:58:18,199 --> 00:58:24,789
that they can put whatever they want
inside. E.g. we have Trust Zone
615
00:58:24,789 --> 00:58:30,869
that by itself is not as closed as ME.
That there is nothing that would
616
00:58:30,869 --> 00:58:36,390
prevent a vendor to actually take
Trust Zone and lock it down
617
00:58:36,390 --> 00:58:41,200
and end up with something
like ME very easily.
618
00:58:41,200 --> 00:58:45,620
Just a matter of the
vendor willing to do that.
619
00:58:45,620 --> 00:58:53,059
Also the diversity of the processors
make it difficult for OS’s like Qubes
620
00:58:53,059 --> 00:58:58,599
that would like to use advanced
technologies like IMMU for isolation
621
00:58:58,599 --> 00:59:04,019
to actually support all of them because
different PSOCs might be implementing
622
00:59:04,019 --> 00:59:11,739
completely different versions or
even technologies doing that.
623
00:59:11,739 --> 00:59:17,240
Another alternative, a much better one
is to use open-hardware processors.
624
00:59:17,240 --> 00:59:24,809
Currently that means FPGA-
implemented processors.
625
00:59:24,809 --> 00:59:29,199
In the future maybe we will have 3D
printers that will allow everybody
626
00:59:29,199 --> 00:59:33,709
to print it. That will be great. But
probably is not coming any time,
627
00:59:33,709 --> 00:59:37,170
in the coming 10 or 20 years.
628
00:59:37,170 --> 00:59:44,609
And meanwhile the performance and
lack of really any security technologies
629
00:59:44,609 --> 00:59:51,089
like IOMMU or virtualization doesn’t
make this a viable solution
630
00:59:51,089 --> 00:59:56,410
for the coming say 5 years at least.
631
00:59:56,410 --> 00:59:59,259
And even then, even if we have
such an open-source processor
632
00:59:59,259 --> 01:00:06,490
this clean separation of state
still makes lots of sense.
633
01:00:06,490 --> 01:00:11,789
Right? Again, because firmware
infections can be easily prevented
634
01:00:11,789 --> 01:00:16,630
because malware, if it gets there
somehow still has no places
635
01:00:16,630 --> 01:00:22,920
to store stolen secrets because
it provides reliable way to verify
636
01:00:22,920 --> 01:00:29,229
or upload firmware. And makes it
easy to boot multiple environments.
637
01:00:29,229 --> 01:00:31,789
And share laptops with others.
638
01:00:31,789 --> 01:00:38,420
I know that most of you will now say:
“Yeah, that may be cool idea but
639
01:00:38,420 --> 01:00:48,489
the market will never
buy into that!” Right?
640
01:00:48,489 --> 01:00:55,159
Understanding that PCs are really,
as I said, extension of our brains,
641
01:00:55,159 --> 01:01:02,900
we should stop thinking about
market forces as the ultimate force
642
01:01:02,900 --> 01:01:08,289
shaping how our personal
computing looks like.
643
01:01:08,289 --> 01:01:13,900
Just like we didn’t desert
to market forces
644
01:01:13,900 --> 01:01:19,599
to give us human rights. Right?
645
01:01:19,599 --> 01:01:26,280
We should not count on the market forces
to give us trustworthy personal computers.
646
01:01:26,280 --> 01:01:28,689
Because that might just not be really...
647
01:01:28,689 --> 01:01:34,569
applause
648
01:01:34,569 --> 01:01:40,299
That just might not be in the
interest of the market forces!
649
01:01:40,299 --> 01:01:44,459
So, hopefully, some legislation
could be of help here.
650
01:01:44,459 --> 01:01:48,969
Maybe EU could do something here.
651
01:01:48,969 --> 01:01:56,289
Because it’s really fun, when I
often talk with other engineers,
652
01:01:56,289 --> 01:02:03,019
and we all know that our world
now really runs on computers,
653
01:02:03,019 --> 01:02:06,999
and yet it apparently...
Almost every engineer I talked to
654
01:02:06,999 --> 01:02:12,619
says something like “Yeah but the
sales people will never do that,
655
01:02:12,619 --> 01:02:15,809
the business will never agree to that.”
656
01:02:15,809 --> 01:02:23,579
But if the world runs on computers
shouldn’t it be us, the engineers,
657
01:02:23,579 --> 01:02:28,809
who should actually have the
final say how this should...
658
01:02:28,809 --> 01:02:33,030
how the computer technology
should look like?
659
01:02:33,030 --> 01:02:37,509
Yeah, I’ll just leave it here with this.
Thank you very much!
660
01:02:37,509 --> 01:02:40,499
final applause
661
01:02:40,499 --> 01:02:44,569
postroll music
662
01:02:44,569 --> 01:02:50,799
subtitles created by
c3subtitles.de in 2016