0:00:00.390,0:00:12.019
preroll music
0:00:12.019,0:00:15.290
Herald: I’m really glad that[br]you’re all here and that today
0:00:15.290,0:00:19.350
I can introduce Joanna Rutkowska to you.
0:00:19.350,0:00:25.000
She will be talking about reasonably[br]trustworthy x86 systems.
0:00:25.000,0:00:30.150
She’s the founder and leader[br]of the Invisible Things Lab
0:00:30.150,0:00:37.149
and also – that’s also something you all[br]probably use – the Qubes OS project.
0:00:37.149,0:00:41.600
She presented numerous attacks[br]on Intel based systems and also
0:00:41.600,0:00:46.829
virtualization systems. But today she[br]will not only speak about the problems
0:00:46.829,0:00:52.329
of those machines but will present some[br]solutions to make them more secure.
0:00:52.329,0:00:54.550
Give it up for Joanna Rutkowska!
0:00:54.550,0:01:03.329
applause
0:01:03.329,0:01:09.300
Joanna: Okay, so, let’s start[br]with stating something obvious.
0:01:09.300,0:01:14.210
Personal computers have become[br]really the extensions of our brains.
0:01:14.210,0:01:18.000
I think most of you will[br]probably agree with that.
0:01:18.000,0:01:21.159
Yet the problem is that they are insecure
0:01:21.159,0:01:25.869
and untrustworthy,
0:01:25.869,0:01:29.299
which personally bothers me al lot.
0:01:29.299,0:01:32.250
And here I want to make a quick digression
0:01:32.250,0:01:38.149
for the vocabulary I’m gonna[br]be using during this presentation.
0:01:38.149,0:01:41.170
When we say, well, there are[br]three adjectives related to trust
0:01:41.170,0:01:45.140
and people will often confuse them.[br]When we say something is “trusted”,
0:01:45.140,0:01:49.740
that means by definition something[br]can compromise the security of
0:01:49.740,0:01:54.770
the whole system, which means[br]we don’t like things to be trusted.
0:01:54.770,0:02:00.329
“Trusted third party”, “Trusted CA”[br]we don’t like that.
0:02:00.329,0:02:02.320
When we say something is...
0:02:02.320,0:02:06.500
because “trusted” doesn’t necessarily[br]mean that it is “secure”.
0:02:06.500,0:02:12.730
So, what is secure? Secure is[br]something that is resistant to attacks.
0:02:12.730,0:02:18.829
Perhaps this laptop might[br]be resistant to attacks.
0:02:18.829,0:02:22.610
If I open [an] email attachment and the[br]email attachment compromises my system
0:02:22.610,0:02:28.540
or maybe that if I plug[br]USB for the slide changer
0:02:28.540,0:02:33.700
I might be hoping that this[br]action will not compromise
0:02:33.700,0:02:37.159
my whole PC.
0:02:37.159,0:02:40.999
And yet something can be[br]secure but not trustworthy.
0:02:40.999,0:02:45.360
A good example of this might be e. g.
0:02:45.360,0:02:49.750
Intel Management Engine (ME), that I’m[br]gonna be talking about more later.
0:02:49.750,0:02:54.180
So it might be very resistant to attacks,[br]so it might be a backdoor.
0:02:54.180,0:02:57.180
A backdoor that is[br]very resistant to attacks,
0:02:57.180,0:03:02.480
yet it is not acting in[br]the interests of the user.
0:03:02.480,0:03:09.170
So it’s not “good”, whatever[br]good means in your assumed,
0:03:09.170,0:03:12.969
moral reference.
0:03:12.969,0:03:18.750
So, there’s been of course a lot of work
0:03:18.750,0:03:24.110
in the last 20 years and maybe more
0:03:24.110,0:03:27.540
to build solutions that provide
0:03:27.540,0:03:30.750
security and trustworthiness
0:03:30.750,0:03:35.640
and most of this work has focused on[br]the application layer and things like
0:03:35.640,0:03:38.709
GnuPG and PGP first,
0:03:38.709,0:03:45.490
TOR, all the secure communication[br]protocols and programs.
0:03:45.490,0:03:49.720
But of course,
0:03:49.720,0:03:55.750
it is clear that any effort[br]on the application level
0:03:55.750,0:04:00.810
is just meaningless if we can[br]not assure, if we can not trust
0:04:00.810,0:04:06.579
our operating system (OS).[br]Because the OS is the trusted part.
0:04:06.579,0:04:12.680
So if the OS is compromised[br]then everything is lost.
0:04:12.680,0:04:18.260
And there has been some efforts,[br]notably the project I started 5 years ago
0:04:18.260,0:04:24.130
and now this is like more than a dozen[br]of people working on it: Qubes OS.
0:04:24.130,0:04:28.360
It tries to address the problem of OS’s
0:04:28.360,0:04:32.230
being part of the PCB,[br]so what we try to do is
0:04:32.230,0:04:37.750
shrink the amount of trusted[br]code to an absolute minimum.
0:04:37.750,0:04:41.510
There’s been also other[br]efforts in this area.
0:04:41.510,0:04:46.730
But OS’s is not something I’m[br]gonna be discussing today.
0:04:46.730,0:04:54.250
What I’m gonna be discussing today[br]is the final layer, is the hardware.
0:04:54.250,0:05:00.700
Because what was OS to applications[br]it is hardware to the OS.
0:05:00.700,0:05:05.380
Again, most of the effort so far
0:05:05.380,0:05:07.720
to create secure and trustworthy OS,
0:05:07.720,0:05:14.000
they have always been assuming[br]that the hardware is trusted.
0:05:14.000,0:05:18.850
That means that... usually[br]that means for most OS’s that
0:05:18.850,0:05:24.100
a single malicious[br]peripheral on this laptop,
0:05:24.100,0:05:30.530
like a malicious Wi-Fi module[br]or maybe embedded controller
0:05:30.530,0:05:34.810
can compromise again my whole PC,
0:05:34.810,0:05:39.340
my whole digital life.
0:05:39.340,0:05:42.760
So what to do about it?
0:05:42.760,0:05:46.500
Before we discuss what to do about it
0:05:46.500,0:05:52.550
we should quickly
0:05:52.550,0:05:59.050
recap all the problems[br]with present PC platforms
0:05:59.050,0:06:03.180
and specifically I’m gonna[br]be focusing on x86 platform
0:06:03.180,0:06:09.850
and specifically with Intel x86[br]platform, which means: laptops.
0:06:09.850,0:06:17.340
This picture shows how a[br]typical modern laptop looks like.
0:06:17.340,0:06:23.160
You can see that it consists of
0:06:23.160,0:06:28.260
a processor in the center,[br]and then there is memory,
0:06:28.260,0:06:32.120
some peripherals, keyboard and monitor.
0:06:32.120,0:06:36.210
Very simple.
0:06:36.210,0:06:41.060
It can be very simple, because
0:06:41.060,0:06:47.250
if we look at present Intel processors
0:06:47.250,0:06:53.130
they really integrate everything[br]and the kitchen sink.
0:06:53.130,0:07:00.300
Ten years ago we used to have a processor,[br]a Northbridge, a Southbridge
0:07:00.300,0:07:03.640
and perhaps even more discrete[br]elements on the motherboard.
0:07:03.640,0:07:11.830
Today nearly all these elements have been[br]integrated into one processor package.
0:07:11.830,0:07:13.780
This is Broadwell
0:07:13.780,0:07:19.710
and this long element[br]here is the CPU and GPU
0:07:19.710,0:07:26.490
and the other one it[br]is said to be the PCH.
0:07:26.490,0:07:30.960
PCH is what used to be[br]the platform controller hub,
0:07:30.960,0:07:34.930
which is what used to be called[br]the Southbridge and Northbridge.
0:07:34.930,0:07:39.850
The line has somehow[br]blurred between these.
0:07:39.850,0:07:42.060
Of course there is only one[br]company making these.
0:07:42.060,0:07:46.050
It’s an American[br]company called INTEL.
0:07:46.050,0:07:51.410
It is a completely opaque construction.
0:07:51.410,0:08:00.080
We have absolutely no ways[br]to examine what’s inside.
0:08:00.080,0:08:04.520
That obviously...[br]The advantage is that
0:08:04.520,0:08:09.030
it makes construction of computers,[br]of laptops very easy now.
0:08:09.030,0:08:13.410
And lots of vendors can[br]produce little sexy laptops,
0:08:13.410,0:08:17.510
like the one I have here.
0:08:17.510,0:08:23.820
On this picture we see now some more[br]elements that are in this processor.
0:08:23.820,0:08:28.620
So, when you say processor[br]today, it’s no longer CPU.
0:08:28.620,0:08:34.470
Processor is now CPU, GPU,[br]memory controller, hub, PCIe,
0:08:34.470,0:08:38.800
root, some Southbridge,
0:08:38.800,0:08:46.110
so e.g. SATA controller and so on,[br]as well as something
0:08:46.110,0:08:52.900
that is called Management Engine (ME),[br]which we discuss in a moment.
0:08:52.900,0:08:56.920
There are few more elements[br]here that are important.
0:08:56.920,0:09:02.270
The most important for us[br]is the SPI flash element.
0:09:02.270,0:09:07.780
Because what’s interesting is that[br]with this whole integration
0:09:07.780,0:09:11.960
that has happened to the processor[br]and the other peripherals,
0:09:11.960,0:09:15.640
still the storage for the firmware,
0:09:15.640,0:09:21.550
so the storage where your BIOS as[br]well as other firmware is stored,
0:09:21.550,0:09:29.980
is still a discrete element.
0:09:29.980,0:09:34.460
We’ll see this element in[br]one of the next slides.
0:09:34.460,0:09:39.280
So let’s now consider first
0:09:39.280,0:09:46.080
the problem of boot security.
0:09:46.080,0:09:49.960
Obviously everybody understands[br]that boot security is something
0:09:49.960,0:09:54.330
- how to start the chain of[br]trust for whatever software
0:09:54.330,0:10:03.370
is gonna be running later -[br]is of a paramount importance.
0:10:03.370,0:10:15.510
I think I’m out of range.
0:10:15.510,0:10:18.520
Connected with boot security[br]is malicious peripherals,
0:10:18.520,0:10:22.760
that I mentioned shortly before.
0:10:22.760,0:10:27.520
So we’ll be now thinking: Can we assure
0:10:27.520,0:10:30.890
only good code is started
0:10:30.890,0:10:38.000
and how the peripherals[br]might interfere here.
0:10:38.000,0:10:41.920
Again, we will look at this SPI flash.
0:10:41.920,0:10:47.530
If we're now considering the boot[br]security we would like to understand
0:10:47.530,0:10:54.150
what code is loaded on the platform. And[br]if we now think where this code is stored,
0:10:54.150,0:10:57.880
it seems that the code is stored on[br]the SPI Flash and potentially also
0:10:57.880,0:11:03.310
on some of the discrete elements.
0:11:03.310,0:11:08.330
Let me state it again that this whole[br]integrated processor package
0:11:08.330,0:11:13.110
has everything and the kitchen[br]sink except for the flash,
0:11:13.110,0:11:21.560
so except for the storage of the firmware.
0:11:21.560,0:11:25.650
Here we have one of the SPI flash chips.
0:11:25.650,0:11:28.460
This is from my Laptop actually.
0:11:28.460,0:11:32.110
It’s a little microcontroller
0:11:32.110,0:11:38.900
and it typically stores the firmware for[br]these things, that are written here.
0:11:38.900,0:11:47.340
Now the question is, let's say I[br]have got this laptop from a store.
0:11:47.340,0:11:55.720
How can I actually verify what[br]firmware is really on this chip?
0:11:55.720,0:12:00.940
Well I can perhaps boot it into some[br]minimal Linux and try to ask it.
0:12:00.940,0:12:05.120
But of course if there is some malicious[br]something on the motherboard,
0:12:05.120,0:12:12.950
not necessarily this chip,[br]I will not get reliable answers.
0:12:12.950,0:12:20.900
Another question: Let’s say I somehow[br]know that there’s something trustworthy
0:12:20.900,0:12:27.020
on this SPI chip. Can I somehow enforce[br]read-only’ness of this program?
0:12:27.020,0:12:30.020
There have been some efforts to do that.
0:12:30.020,0:12:36.630
Like some projects by Peter Stuge[br]who just took a soldering iron
0:12:36.630,0:12:43.680
and connected one of the pins - one[br]of these 8 pins is called “write protect”.
0:12:43.680,0:12:50.430
If you ground it, it will be telling the[br]chip to discard any Write commands.
0:12:50.430,0:12:54.710
But again, remember, this chip[br]is still a little microcontroller,
0:12:54.710,0:12:59.440
it’s a little computer. So it might[br]ignore whatever you requested to do.
0:12:59.440,0:13:05.320
It’s not like you are cutting off[br]a signal for Write commands.
0:13:05.320,0:13:09.630
You are merely asking the[br]processor to ignore it.
0:13:09.630,0:13:16.330
So if you don’t trust the chip in the[br]first place, this doesn’t provide you
0:13:16.330,0:13:19.810
a reliable way to enforce read-only’ness.
0:13:19.810,0:13:26.010
Finally can I upload my own firmware?[br]Can I choose to use whatever BIOS I want?
0:13:26.010,0:13:30.570
Again, we don’t seem to have luck here.
0:13:34.530,0:13:38.110
And as I mentioned, this is just[br]one of the places on the platform
0:13:38.110,0:13:42.200
where the state is stored.[br]Embedded controller would be
0:13:42.200,0:13:49.020
a whole another microcontroller[br]having its own internal flash.
0:13:49.020,0:13:54.040
Or if not, using another[br]SPI chip to get flash from.
0:13:54.040,0:13:59.270
A disk would be another[br]microcontroller with a small computer,
0:13:59.270,0:14:05.190
having its own - typically -[br]flash for its own firmware.
0:14:05.190,0:14:11.190
And perhaps the same[br]with the Wi-Fi module.
0:14:11.190,0:14:18.150
Now for many years, myself and[br]lots of other people believed that
0:14:18.150,0:14:25.080
technologies like TPM, trusted execution[br]technology... like UEFI Secure Boot
0:14:25.080,0:14:29.300
I never really liked, but many people[br]did - they believed that they could
0:14:29.300,0:14:32.410
somehow solve the problem of secure boot.
0:14:32.410,0:14:38.370
But all of these technologies[br]have been shown to fail horribly
0:14:38.370,0:14:44.440
in this... on this premise.
0:14:44.440,0:14:47.090
And then we have...[br]So these were problems,
0:14:47.090,0:14:52.590
the tip of the iceberg of[br]problems of the secure boot.
0:14:52.590,0:15:01.640
The short story is: Today we can[br]not really assure secure boot.
0:15:01.640,0:15:08.050
Maybe before we move on to[br]Intel ME: e.g. Intel TXT:
0:15:08.050,0:15:12.160
Trusted Execution Technology was[br]introduced by Intel in the hope
0:15:12.160,0:15:19.029
to put the BIOS outside of the TCB,[br]trusted computing base for the platform.
0:15:19.029,0:15:26.440
So, the idea was that if you use TXT[br]which you can think of as
0:15:26.440,0:15:32.710
a special instruction of the processor,[br]that was the root of trust.
0:15:32.710,0:15:37.220
So, the promise was that[br]when using Intel TXT
0:15:37.220,0:15:45.089
you can start the chain of trust
0:15:45.089,0:15:50.370
without trusting the BIOS.[br]As well as other peripherals
0:15:50.370,0:15:54.320
like Wi-Fi card, which might[br]be malicious perhaps.
0:15:54.320,0:16:01.210
And that was just great.[br]And I really like the technology.
0:16:01.210,0:16:04.940
With my team we have done[br]lots of research on TXT.
0:16:04.940,0:16:10.940
But one of the first attacks that we have[br]presented, and that was back in like 2009,
0:16:10.940,0:16:16.500
was that we could bypass TXT[br]by having a malicious SMM.
0:16:16.500,0:16:20.190
SMM was loaded by the BIOS.
0:16:20.190,0:16:26.640
So apparently it turned out, that the BIOS[br]could not be really put outside of the TCB
0:16:26.640,0:16:32.080
so easily, because if it was really[br]malicious it would provide a malicious SMM
0:16:32.080,0:16:38.440
and then the SMM could bypass TXT.[br]So the response from Intel was: “OK,
0:16:38.440,0:16:46.190
but worry not, we have a technology[br]called STM - Secure Transfer Monitor.”
0:16:46.190,0:16:54.589
That is a little hypervisor to sandbox[br]the SMM which might be malicious.
0:16:54.589,0:17:02.480
So they wanted to boot[br]a special dedicated...
0:17:02.480,0:17:09.209
they built it actually... they built a[br]special technology to sandbox this SMM.
0:17:09.209,0:17:14.420
And then it turned out[br]this is not so easy.
0:17:14.420,0:17:17.050
Because as usual they[br]were missing the details.
0:17:17.050,0:17:22.050
And it is 6 years, 6 years has passed and
0:17:22.050,0:17:28.369
we still have not seen[br]any real STM in the wild.
0:17:28.369,0:17:35.880
Which just is an example how[br]hopeless this approach in building,
0:17:35.880,0:17:44.079
in trying to provide secure[br]boot is for the x86 platform.
0:17:44.079,0:17:47.330
Another problem with x86 that
0:17:47.330,0:17:52.210
has risen to prominence in the recent[br]years is the Intel Management Engine.
0:17:52.210,0:17:58.530
One of these things, that Intel
0:17:58.530,0:18:04.800
has put into this integrated processor[br]is called Management Engine (ME).
0:18:04.800,0:18:12.140
And this ME is a little microcontroller[br]that is inside your processor.
0:18:12.140,0:18:18.900
It has its own internal RAM,[br]it has its own internal peripherals.
0:18:18.900,0:18:26.850
Like DMA engine, which[br]has access to the host RAM.
0:18:26.850,0:18:34.120
And of course, it loads only[br]Intel-signed firmware.
0:18:34.120,0:18:40.610
And it has also its own private ROM inside[br]the processor, that nobody can inspect.
0:18:40.610,0:18:45.230
And nobody knows what it does.
0:18:45.230,0:18:51.200
And it runs a whole bunch[br]of proprietary programs.
0:18:51.200,0:18:58.500
And it runs even Intel’s[br]own proprietary OS.
0:18:58.500,0:19:03.630
And this all is happening all the time[br]when you have some power connected
0:19:03.630,0:19:07.460
to your processor.[br]Even if it’s in a sleep mode.
0:19:07.460,0:19:10.970
It’s running all the time[br]here on my computer.
0:19:10.970,0:19:17.830
It can be doing anything it wants.
0:19:17.830,0:19:21.520
Obviously when I say something[br]like that the first thought for,
0:19:21.520,0:19:25.220
at least for security people[br]is: “This is an ideal
0:19:25.220,0:19:30.660
backdooring or rootkitting[br]infrastructure.” Which is true.
0:19:30.660,0:19:33.860
However there is another[br]problem and it’s Zombification.
0:19:33.860,0:19:38.330
I call it Zombification of personal[br]computing that I will discuss in a moment.
0:19:38.330,0:19:50.390
I’m just stressing these are two somehow[br]independent problems with this ME.
0:19:50.390,0:19:57.120
About 10 or more years ago I used to be[br]a very active malware researcher or
0:19:57.120,0:20:03.010
scout malware researcher. Especially[br]rootkit researcher and back then when,
0:20:03.010,0:20:09.040
if I was to imagine an ideal[br]infrastructure for writing rootkits,
0:20:09.040,0:20:16.600
I couldn’t possibly imagine[br]anything better than ME.
0:20:16.600,0:20:22.830
Because ME has access to essentially[br]everything that is important.
0:20:22.830,0:20:27.160
As I mentioned it has[br]unconstrained access to DRAM,
0:20:27.160,0:20:31.130
to the actual CPU, to GPU.
0:20:31.130,0:20:36.180
It can also talk to your networking card,
0:20:36.180,0:20:39.930
especially to the Ethernet card
0:20:39.930,0:20:45.900
which controller is also in the[br]Southbridge in the processor.
0:20:45.900,0:20:50.610
It can also talk to the SPI[br]flash and asks the SPI flash.
0:20:50.610,0:20:54.670
It has its own dedicated[br]partition on the SPI flash,
0:20:54.670,0:21:02.260
which can be used to store[br]whatever ME wants to store there.
0:21:02.260,0:21:07.830
This is really problematic and[br]we don’t know what it runs.
0:21:11.080,0:21:15.470
But the other problem,[br]that is perhaps less obvious,
0:21:15.470,0:21:27.360
is what I call zombification of[br]the General Purpose Computing.
0:21:27.360,0:21:32.830
About a year ago there[br]was a book published by
0:21:32.830,0:21:39.120
one of the Intel architects, one of the[br]architects who designed Intel ME.
0:21:39.120,0:21:41.790
I highly recommend this book.
0:21:41.790,0:21:51.570
It’s the only somehow official source[br]of information about Intel ME.
0:21:51.570,0:21:58.240
And what the book has made clear is that
0:21:58.240,0:22:03.740
the model of computing that[br]Intel envisions in the future,
0:22:03.740,0:22:08.840
is to take the model, that we have[br]today, which looks like this.
0:22:08.840,0:22:13.990
The size of the boxes somehow[br]attempts to present
0:22:13.990,0:22:21.330
the amount of logic or involvement[br]of each of the layers
0:22:21.330,0:22:25.290
in processing of the user data.
0:22:25.290,0:22:29.610
Obviously we have most of this[br]processing done in the applications.
0:22:29.610,0:22:37.050
But we also have some involvement from the[br]OS and also from the hardware, of course.
0:22:37.050,0:22:42.150
For example, when we want to[br]generate a random number
0:22:42.150,0:22:56.820
we would usually ask an OS to
0:22:56.820,0:22:59.200
return us the random number.
0:22:59.200,0:23:05.490
Because the OS can generate it using[br]timings and interrupts, whatever.
0:23:05.490,0:23:10.890
But again, most of the logic, most of[br]the code is in the application’s layer.
0:23:10.890,0:23:14.240
And this is good, because
0:23:14.240,0:23:19.549
thanks to computing being[br]general purpose computing,
0:23:19.549,0:23:22.620
everyone of us can write applications.
0:23:22.620,0:23:28.890
We can argue what is the best[br]way to implement some crypto.
0:23:28.890,0:23:33.910
Some people can write it one way, some[br]other people can write it another way.
0:23:33.910,0:23:36.500
And that’s good.
0:23:36.500,0:23:42.000
Now this is the model[br]that Intel wants to go to.
0:23:42.000,0:23:48.250
It essentially wants to eliminate[br]all the logic that touches data
0:23:48.250,0:23:54.950
from apps and OS even[br]and move it to Intel ME.
0:23:54.950,0:24:03.830
Because, remember,[br]Intel ME is also an OS.
0:24:03.830,0:24:10.710
It’s a separate OS. Only that this is an[br]OS that nobody knows how it works.
0:24:10.710,0:24:13.730
It’s an OS, that nobody[br]has any possibility
0:24:13.730,0:24:18.040
to look at the source code[br]or even reverse engineer.
0:24:18.040,0:24:21.590
Because even we can not[br]really analyse the binaries.
0:24:21.590,0:24:29.590
It’s the OS that is fully controlled[br]by Intel. And not to mention that
0:24:29.590,0:24:34.240
any functionality it offers is[br]also fully controlled by Intel.
0:24:34.240,0:24:42.880
Without anybody being[br]able to verify what they do.
0:24:42.880,0:24:45.360
That might not even be malicious.
0:24:45.360,0:24:48.179
They may not even be[br]doing malicious things.
0:24:48.179,0:24:51.730
Perhaps they are just[br]implementing something wrong.
0:24:51.730,0:24:57.230
Bugs. Security bugs, right?
0:24:57.230,0:25:00.820
But of course Intel believes[br]that whatever Intel writes
0:25:00.820,0:25:06.520
must be secure.
0:25:06.520,0:25:12.220
For some reason the must have missed
0:25:12.220,0:25:17.040
a number of papers that my team and others
0:25:17.040,0:25:25.450
have published in the recent 10 years.
0:25:25.450,0:25:30.730
The questions are: Can we disable Intel ME[br]or can we control what code runs there?
0:25:30.730,0:25:34.470
Can we see at least what code is there?
0:25:34.470,0:25:39.799
And as far as I’m aware the[br]answer is unfortunately: Not.
0:25:39.799,0:25:44.350
As I mentioned, I have this cool[br]laptop it runs Qubes OS, of course,
0:25:44.350,0:25:51.970
but still it not only runs Qubes OS.[br]It also runs side by side Intel ME.
0:25:51.970,0:25:54.919
Intel ME proprietary OS.
0:25:54.919,0:26:06.000
And I can’t do anything about it.
0:26:06.000,0:26:14.330
About 6 or 7 years ago my team[br]has done some work on Intel AMT.
0:26:14.330,0:26:17.850
I believe this was the first and probably[br]the only work where we managed
0:26:17.850,0:26:23.570
to actually inject code into[br]ME. That was back in times
0:26:23.570,0:26:29.270
when Intel ME was not in the[br]processor. It was in the Northbridge.
0:26:29.270,0:26:35.740
It was in the Q35 or Q45 chipset,[br]if I remember correctly.
0:26:35.740,0:26:42.320
So we demonstrated how we[br]can inject a rootkit into ME.
0:26:42.320,0:26:46.470
Of course Intel then patched it.
0:26:46.470,0:26:51.049
Now they continue to think that whatever[br]they write will be always secure.
0:26:51.049,0:26:55.270
But, the problem is...
0:26:55.270,0:27:00.590
For a number of years after that[br]presentation I used to believe
0:27:00.590,0:27:09.220
that we could use VTD[br]- an INTEL IMMU technology with TXT -
0:27:09.220,0:27:11.900
perhaps to effectively sandbox ME.
0:27:11.900,0:27:15.360
Because some of the specifications I saw,
0:27:15.360,0:27:21.059
suggested that VTD should be able to
0:27:21.059,0:27:25.830
sandbox ME accesses to host memory.
0:27:25.830,0:27:32.580
And because we used VTD heavily[br]on Qubes, thanks to Xen using it,
0:27:32.580,0:27:42.730
I was pretty much not[br]that worried about ME.
0:27:42.730,0:27:51.000
Unfortunately it turned out[br]that ME can just bypass VTD.
0:27:51.000,0:27:58.940
And this is a feature of this ME.
0:27:58.940,0:28:04.570
Which brings us to this rather[br]sad conclusion that perhaps
0:28:04.570,0:28:14.760
if we look at Intel x86 platform,[br]then the war is lost here.
0:28:14.760,0:28:18.260
It might be lost even[br]if we didn’t have ME.
0:28:18.260,0:28:24.460
Even if we somehow manage to[br]convince Intel to get rid of ME,
0:28:24.460,0:28:31.279
or at least to offer OEMs, Laptop[br]vendors, an option to disable it,
0:28:31.279,0:28:35.100
by fusing something.
0:28:39.190,0:28:44.630
The problem with secure boot[br]that I mentioned earlier,
0:28:44.630,0:28:49.840
and that I analysed in more detail[br]in a paper I released 2 months ago,
0:28:49.840,0:28:53.120
is that it really is hopeless,
0:28:53.120,0:28:58.289
because of the complexity[br]of the architecture
0:28:58.289,0:29:03.900
where we have ring 3, ring 0, okay. Then[br]we have SMM, then we have virtualisation,
0:29:03.900,0:29:09.640
then we have STM to sandbox SMM,[br]and the interactions between these.
0:29:09.640,0:29:20.030
This all doesn’t look really like[br]it could be solved effectively,
0:29:20.030,0:29:26.809
which of course bothers me a lot.
0:29:26.809,0:29:29.020
At least on purely egoistic reasons,
0:29:29.020,0:29:34.910
because I spent the last 5 years[br]of my life on this Qubes project.
0:29:34.910,0:29:41.940
And of course with such a state of[br]things it makes my whole Qubes project
0:29:41.940,0:29:47.090
somehow meaningless.
0:29:47.090,0:29:52.360
If the situation is so bad,
0:29:52.360,0:29:58.250
perhaps the only way to solve the problem[br]is to change the rules of the game.
0:29:58.250,0:30:06.070
Because you can not really[br]win under the old rules.
0:30:06.070,0:30:14.390
That’s why I wanted to share[br]this approach with you today.
0:30:14.390,0:30:21.610
That starts with recognizing that
0:30:21.610,0:30:27.610
most of the problems here is[br]related to the persistent state,
0:30:27.610,0:30:32.630
that is stored pretty much[br]everywhere on your platform,
0:30:32.630,0:30:42.280
which usually keeps the[br]firmware, but not only.
0:30:42.280,0:30:50.549
So let’s imagine, that we could do a[br]clean separation of state from hardware.
0:30:50.549,0:30:59.079
So this is the current picture.[br]This is your laptop.
0:30:59.079,0:31:05.870
The reddish boxes are state,[br]the persistent state.
0:31:05.870,0:31:11.659
That means these are places[br]where malware can persist.
0:31:11.659,0:31:17.510
So you reinstall the OS, but[br]the malware still can re-infect.
0:31:17.510,0:31:23.280
There are also places where[br]malware can store secrets,
0:31:23.280,0:31:29.539
once it steals them from you.[br]So imagine I can have malware,
0:31:29.539,0:31:36.210
that might only be stealing[br]my disk encryption key.
0:31:36.210,0:31:42.530
And it can store it somewhere on[br]the disk or maybe on SPI flash.
0:31:42.530,0:31:48.979
Or maybe in the Wi-Fi module firmware, or[br]maybe in the embedded controller firmware,
0:31:48.979,0:31:56.860
somewhere. Somewhere[br]there in those red rectangles.
0:31:56.860,0:32:00.100
Now if the malware does it,[br]that is a pretty fatal situation,
0:32:00.100,0:32:03.960
because if my laptop[br]gets stolen or seized,
0:32:03.960,0:32:10.390
perhaps then the adversary who gets
0:32:10.390,0:32:13.850
a key to the malware can[br]just decrypt the blobs.
0:32:13.850,0:32:21.809
And the blobs would reveal my disk[br]decryption key. And then the game is over.
0:32:21.809,0:32:25.960
And also another problem with[br]this state is that it might be
0:32:25.960,0:32:34.200
revealing many of the user and[br]personally identifiable information.
0:32:34.200,0:32:39.580
How ever you read this PI shortcut.
0:32:39.580,0:32:43.720
These are for example MAC addresses.
0:32:43.720,0:32:48.179
Or maybe processor serial number.
0:32:48.179,0:32:51.340
Or maybe ME serial number. Whatever!
0:32:51.340,0:32:57.850
Or maybe the list of SSID networks,[br]that ME has seen recently.
0:32:57.850,0:33:01.850
How do you know it’s not being[br]stored somewhere on your SPI flash?
0:33:01.850,0:33:07.069
You don’t know what is stored there.[br]Even though I can’t take off my SPI flash
0:33:07.069,0:33:14.419
or just connect a programmer to my[br]SPI flash - an EEPROM programmer -
0:33:14.419,0:33:27.010
I can read the contents of the SPI[br]flash, but all of this will be encrypted.
0:33:27.010,0:33:31.460
Now we recognize, that the[br]state might be problematic.
0:33:31.460,0:33:36.700
And now imagine a picture, that[br]we have the laptop, which has
0:33:36.700,0:33:44.340
no persistent state storage.[br]Which is this blue rectangle.
0:33:44.340,0:33:47.669
Let’s call it stateless laptop.
0:33:47.669,0:33:53.659
And then we have another element,[br]that we’re gonna call trusted stick
0:33:53.659,0:33:57.850
for lack of any more sexy name for it.
0:33:57.850,0:34:04.749
That’s gonna be keeping all the firmware,[br]all the platform configuration,
0:34:04.749,0:34:09.719
all the system partitions,[br]like boot and root,
0:34:09.719,0:34:14.789
all the user partitions.
0:34:14.789,0:34:18.889
Now we see that... and of course the[br]firmware and system partitions
0:34:18.889,0:34:22.549
will be exposed in a read only manner.
0:34:22.549,0:34:28.009
So even if malware, perhaps a traditional[br]malware, that got into my system
0:34:28.009,0:34:35.339
through a malicious attachment,[br]even if it found a weakness in the BIOS,
0:34:35.339,0:34:40.359
or maybe in the chipset, allowing[br]it to re-flash normally, allowing it
0:34:40.359,0:34:51.228
to re-flash the BIOS - we have seen plenty of[br]such attacks in the recent several years.
0:34:51.228,0:34:54.698
Now it would not be able[br]to succeed, because
0:34:54.698,0:34:59.940
the trusted stick, which gonna be a[br]simple FPGA implemented device,
0:34:59.940,0:35:07.599
will just be exposing[br]the read-only storage.
0:35:07.599,0:35:13.390
You see that firmware injection[br]can be prevented this way.
0:35:13.390,0:35:17.109
Also there is no places[br]to store stolen secrets.
0:35:17.109,0:35:21.869
Again, the same malware running in the ME
0:35:21.869,0:35:27.640
still can steal my disk encryption[br]key or my PGP private key.
0:35:27.640,0:35:31.099
But it has no place to store it.
0:35:31.099,0:35:35.880
So if somebody now takes my laptop,[br]will not be able to find it there.
0:35:35.880,0:35:39.719
You might say, maybe it will be[br]able to store it on the stick.
0:35:39.719,0:35:45.219
But then, again, the stick, the firmware[br]and system partitions are read-only.
0:35:45.219,0:35:49.359
And the user partitions[br]are encrypted by the stick.
0:35:49.359,0:35:56.769
So even if ME can send something to be[br]stored there, nobody besides the user
0:35:56.769,0:36:02.910
can really get hands on this blob.
0:36:02.910,0:36:06.900
Also we get a reliable way to[br]verify what firmware we use.
0:36:06.900,0:36:11.219
Or ability to choose what[br]firmware we want to use.
0:36:11.219,0:36:17.650
Because we can just take this stick,[br]plug into our trustworthy computer,
0:36:17.650,0:36:26.009
some, I don’t know, Lenovo X60 from 15[br]years ago, that we have running Coreboot
0:36:26.009,0:36:30.249
and we just analysed all[br]the elements, whatever.
0:36:30.249,0:36:39.080
So we finally a have a way to[br]upload firmware in a reliable way.
0:36:39.080,0:36:45.580
Thanks to the actual laptop having no[br]state, we can have something like Tails
0:36:45.580,0:36:54.680
finally doing what it advertises.[br]I can boot Tails or something like that.
0:36:54.680,0:37:02.660
I can use it, I can shut it down and there[br]is no more traces of my activity there.
0:37:02.660,0:37:08.329
I can give my laptop to somebody other.[br]Or I can boot some other environment.
0:37:08.329,0:37:19.900
Perhaps some, I don’t know,[br]Windows to play games, or whatever.
0:37:19.900,0:37:27.499
So what would it take to have[br]such a stateless laptop?
0:37:27.499,0:37:32.910
This is the simplest version which[br]shows that the only modification
0:37:32.910,0:37:37.920
that has been made here was[br]to take the SPI flash chip
0:37:37.920,0:37:42.710
and essentially put it outside[br]the laptop on a trusted stick.
0:37:42.710,0:37:49.509
And just route the wiring,[br]just 4 wires, to the trusted stick.
0:37:49.509,0:37:50.749
And that’s pretty much it.
0:37:50.749,0:37:55.989
That’s the simplest version. Oh,[br]and I also got rid of the disk.
0:37:55.989,0:38:02.779
And also I had to ensure, that[br]whatever discrete devices,
0:38:02.779,0:38:06.260
which are in that case embedded[br]controller and Wi-Fi module,
0:38:06.260,0:38:10.819
they do not have flash memory[br]but use something like OTP memory.
0:38:10.819,0:38:14.420
We can further get rid[br]of the Wi-Fi, and use
0:38:14.420,0:38:18.400
an external USB connected[br]one if that is not possible.
0:38:18.400,0:38:22.559
And for the embedded controller that[br]should be possible, much more easier,
0:38:22.559,0:38:27.289
because embedded controller is always[br]something that the OEM chooses.
0:38:27.289,0:38:33.779
So we can just talk to whatever[br]OEM, who would like to implement
0:38:33.779,0:38:39.069
this stateless laptop, and ask the[br]OEM to use an embedded controller
0:38:39.069,0:38:45.259
with essentially ROM, instead of flash.
0:38:45.259,0:38:51.680
So that’s the simplest version,[br]which is really simple.
0:38:51.680,0:38:57.269
This is a more complex version[br]where we also fit something
0:38:57.269,0:39:04.669
that I call here SPI Multiplexer.[br]Which allows to share the firmware
0:39:04.669,0:39:09.130
not just to the processor, but[br]also to the embedded controller.
0:39:09.130,0:39:12.329
And perhaps also with the disk.
0:39:12.329,0:39:16.329
Because maybe we actually[br]would like to have internal disk.
0:39:16.329,0:39:22.989
Because internal disk will always[br]be faster and will always be bigger
0:39:22.989,0:39:29.400
than whatever disk we will[br]put on our trusted stick.
0:39:29.400,0:39:36.489
You might object, that, come on, disk[br]is actually not a stateless thing! Right?
0:39:36.489,0:39:44.480
Because disk is made especially[br]to store state persistently.
0:39:44.480,0:39:50.099
But it’s a special disk, that I will[br]mention in just a few minutes.
0:39:50.099,0:39:54.530
It’s a special disk running trusted[br]firmware and doing read-only
0:39:54.530,0:39:59.319
and encryption for everything.
0:39:59.319,0:40:05.059
And now for the trusted stick:
0:40:05.059,0:40:10.900
As I mentioned, the trusted[br]stick is envisioned to have
0:40:10.900,0:40:14.160
read-only and encrypted partitions.
0:40:14.160,0:40:22.739
And the read-only partitions are for[br]firmware and the system code.
0:40:22.739,0:40:29.289
So the first block is something that we[br]would like to export over SPI, typically,
0:40:29.289,0:40:34.479
and the system partition is[br]something that we make visible
0:40:34.479,0:40:42.969
to the OS using something like[br]pretending being USB mass storage
0:40:42.969,0:40:52.559
or actually implementing[br]USB mass storage protocol.
0:40:52.559,0:40:57.680
And the encrypted partition[br]- again, the important thing here is
0:40:57.680,0:41:06.309
that encryption should be[br]implemented by the stick itself.
0:41:06.309,0:41:10.589
So we have some key here,
0:41:10.589,0:41:14.319
the question is how this key should be...
0:41:14.319,0:41:22.150
What input should be taken[br]to derive this key from.
0:41:22.150,0:41:27.849
It could be something that[br]is persistent to the stick.
0:41:27.849,0:41:31.239
It could be combined with a[br]passphrase, that the user enters
0:41:31.239,0:41:37.819
using a traditional keyboard,[br]plus maybe a secret from the TPM.
0:41:37.819,0:41:44.079
And when I say TPM I think about the[br]firmware TPM inside the processor
0:41:44.079,0:41:47.190
that is using storage provided by
0:41:47.190,0:41:57.050
encrypted firmware partition.
0:41:57.050,0:42:01.829
The optional internal disk[br]that I just mentioned,
0:42:01.829,0:42:07.279
it should essentially do[br]the same as the stick,
0:42:07.279,0:42:11.209
and because it will be[br]running trusted firmware
0:42:11.209,0:42:15.739
that it will be fetching[br]from the trusted stick itself
0:42:15.739,0:42:19.640
the disk will not have any flash memory.
0:42:19.640,0:42:24.109
So because we will trust[br]the hardware of the disk
0:42:24.109,0:42:28.160
and because we will trust the[br]firmware, we will trust the firmware
0:42:28.160,0:42:32.789
to provide read-only and encrypted[br]partitions just like those ones
0:42:32.789,0:42:39.119
I mentioned on the stick, which is nice[br]because it reveals the stick from acting
0:42:39.119,0:42:44.140
as a mass storage device, which has
0:42:44.140,0:42:50.630
practical consequences which are nice.
0:42:50.630,0:42:59.209
So there’s a picture with the internal[br]trusted disk, which you see just here.
0:42:59.209,0:43:04.009
As you can see, it takes also the[br]firmware from the trusted stick.
0:43:04.009,0:43:09.509
And there is even an open source[br]project, OpenSSD. And it looks like
0:43:09.509,0:43:18.200
people have already built an open hardware[br]open firmware SSD, a very performant disk.
0:43:18.200,0:43:28.520
So this is not just science[br]fiction, even for this SSD.
0:43:28.520,0:43:34.909
Okay, so that looks all very nice,[br]but there is one problem.
0:43:34.909,0:43:42.700
Even though malware may not have any[br]place on the laptop to leak the secrets,
0:43:42.700,0:43:46.549
it still might try to do[br]it over networking.
0:43:46.549,0:43:52.660
And let’s differentiate now between[br]classic malware and sophisticated malware.
0:43:52.660,0:43:59.499
Classic malware is something you get with[br]an attachment or some drive-by-attack
0:43:59.499,0:44:04.070
which we’ll discuss in a moment.[br]Now, let’s focus on sophisticated malware.
0:44:04.070,0:44:17.399
So, a hypothetical rootkit in ME.
0:44:17.399,0:44:23.999
Before we move on, for obvious[br]reasons, such a sophisticated malware
0:44:23.999,0:44:30.130
would not be interested[br]in getting caught easily.
0:44:30.130,0:44:37.580
So, it would not be establishing a[br]TCP connection to NSA.gov server
0:44:37.580,0:44:44.849
or whatever, right?[br]That would be plain stupid.
0:44:44.849,0:44:49.619
Having that in mind, let’s[br]consider a few scenarios.
0:44:49.619,0:44:54.739
Scenario number 0 is[br]an air-gapped system.
0:44:54.739,0:44:58.079
Even though it might[br]be an air-gapped system,
0:44:58.079,0:45:01.519
still remember there is ME running there.
0:45:01.519,0:45:11.619
If the computer is not[br]inside a Faraday cage,
0:45:11.619,0:45:18.559
there is still plenty of other[br]networks or devices around it.
0:45:18.559,0:45:25.539
Which means that ME can theoretically[br]use your Wi-Fi card or even speaker
0:45:25.539,0:45:33.019
to establish a covert channel with, say,[br]your phone, that might be just nearby.
0:45:33.019,0:45:39.450
So, in order to make such a[br]system truly air-gapped,
0:45:39.450,0:45:42.880
knowing that we can not get rid of the ME,
0:45:42.880,0:45:48.299
we really need to have kill-switches[br]for any transmitting devices,
0:45:48.299,0:45:53.569
including the speakers, and apparently[br]even that might not be enough,
0:45:53.569,0:45:58.200
because some people showed[br]covert channels that used
0:45:58.200,0:46:04.420
things like power fluctuations
0:46:04.420,0:46:11.670
or temperature fluctuations but let’s[br]leave that exotic examples aside.
0:46:11.670,0:46:18.609
A more interesting scenario is a[br]closed network of trusted nodes.
0:46:18.609,0:46:24.019
In that scenario we assume that[br]all these people are trusted.
0:46:24.019,0:46:27.660
Again, by definition that means that[br]any of these people can compromise
0:46:27.660,0:46:33.180
the security of anybody else.[br]We really don’t like trusted things,
0:46:33.180,0:46:38.229
but, well, let’s start with something.
0:46:38.229,0:46:46.420
Now, even though each of these trusted[br]peers which run state-less laptops,
0:46:46.420,0:46:52.869
even each of these have[br]this malicious ME in itself
0:46:52.869,0:46:58.079
because we gonna fit a small proxy
0:46:58.079,0:47:02.920
so a modification that we are...[br]that we should additionally do,
0:47:02.920,0:47:08.259
that I have not shown you before,[br]is that rather than connecting
0:47:08.259,0:47:13.599
your Wi-Fi module directly to the[br]processor which is not good,
0:47:13.599,0:47:19.009
because it gives full authority of the[br]processor over this Wi-Fi module.
0:47:19.009,0:47:23.670
Instead we would like to[br]connect it to some proxy.
0:47:23.670,0:47:27.709
It would be doing some kind of tunnelling.
0:47:27.709,0:47:34.199
Something like VPN or maybe TORifying[br]any traffic that is generated there.
0:47:34.199,0:47:40.309
So even though ME might be willing[br]to be sending some traffic
0:47:40.309,0:47:42.630
maybe not explicit traffic,
0:47:42.630,0:47:48.390
maybe will be piggybacking on[br]some user generated traffic,
0:47:48.390,0:47:56.239
by only modifying, I don’t know, TCP[br]initial sequence numbers, or something.
0:47:56.239,0:48:00.530
It still all will be happening[br]inside the tunnel.
0:48:00.530,0:48:05.589
Again, some people might be[br]saying “Yeah, but still ME
0:48:05.589,0:48:09.869
might be modulating the timings[br]of the generated packets
0:48:09.869,0:48:18.629
and this way try to convey some[br]information using timing.”
0:48:18.629,0:48:21.650
We can’t truly do much about that[br]but on the other hand it would be
0:48:21.650,0:48:27.870
extremely difficult for ME to[br]do that, implementation wise.
0:48:27.870,0:48:32.769
Finally a scenario where[br]we want to use any...
0:48:32.769,0:48:38.140
when we want to connect with anybody[br]not just with a trusted computer.
0:48:38.140,0:48:44.469
So, say, with some website on the internet[br]that might or might not be trusted.
0:48:44.469,0:48:52.119
Again, by having this proxy which by[br]the way might be implemented inside
0:48:52.119,0:48:57.089
this embedded controller that[br]we know, if you remember,
0:48:57.089,0:49:05.569
it runs the trusted firmware because it[br]fetches firmware from our trusted stick.
0:49:05.569,0:49:11.759
So the proxy again is tunnelling[br]any potential leakage from ME
0:49:11.759,0:49:18.130
which means that a malicious ISP or[br]any part of the infrastructure here
0:49:18.130,0:49:23.529
still can not really retrieve the[br]secrets that ME tries to leak.
0:49:23.529,0:49:28.239
But of course at some point we need to[br]terminate the stunnel that might be
0:49:28.239,0:49:36.069
the VPN server or might be a TOR exit[br]node or maybe the server itself if it’s,
0:49:36.069,0:49:45.709
say, maybe an onion server, in[br]which case anybody here can still
0:49:45.709,0:49:55.129
presumably get the secrets[br]from ME in this cloud here.
0:49:55.129,0:49:58.489
Which unfortunately we[br]can do nothing about.
0:49:58.489,0:50:05.180
Except for hoping that at least[br]if we used perhaps TOR
0:50:05.180,0:50:09.219
for this first part of the equation
0:50:09.219,0:50:13.690
then at least a malicious[br]administrator of, say, this server
0:50:13.690,0:50:17.029
would not be able to[br]correlate whose decryption...
0:50:17.029,0:50:19.880
whose disk decryption key it really is.
0:50:19.880,0:50:24.039
Although this is very tricky. That would[br]only work if this computer was
0:50:24.039,0:50:27.739
a special purpose computer. If you[br]used something like Qubes here
0:50:27.739,0:50:32.150
and if you wanted to have different[br]partitions, one for your personal
0:50:32.150,0:50:37.580
and only one of these partitions[br]would be special secret partitions.
0:50:37.580,0:50:41.859
That wouldn’t work, because[br]ME still would be able to gather
0:50:41.859,0:50:47.259
your identification information[br]from whatever partitions you have.
0:50:47.259,0:50:53.259
Because again, it has unconstrained access[br]to all the personal, all the host memory.
0:50:53.259,0:51:01.199
But still this... using this[br]proxy pushes adversary,
0:51:01.199,0:51:05.869
hypothetical adversary, in the[br]ME, into extreme difficulty
0:51:05.869,0:51:11.579
of needing to piggy-back on[br]some higher-level protocols
0:51:11.579,0:51:18.119
establishing exotic cover channels.[br]Comparing to what they can do today
0:51:18.119,0:51:23.039
one can... they simply steal the key[br]and store it on SPI first partition.
0:51:23.039,0:51:28.910
Or maybe on your disk. This is like[br]orders of magnitude more difficult
0:51:28.910,0:51:34.589
for them to do.
0:51:34.589,0:51:37.569
We mentioned the sophisticated[br]malware and I mentioned
0:51:37.569,0:51:44.319
the classic malware is a different story.[br]The classic malware doesn’t need
0:51:44.319,0:51:51.549
to be shy against leaking something[br]through whatever means you can think of.
0:51:51.549,0:51:59.380
Perhaps by sending email to somebody. But[br]obviously to address the classic malware
0:51:59.380,0:52:07.229
problem we can address it quite[br]reasonably well on the OS level.
0:52:07.229,0:52:14.209
For example using compartmentalization.[br]But here comes the problem,
0:52:14.209,0:52:20.680
is, that a malicious BIOS...
0:52:20.680,0:52:24.609
Let me get back a little bit. Because[br]so far we having assuming that
0:52:24.609,0:52:28.959
we don’t really need to trust the BIOS.[br]Because having this stateless laptop
0:52:28.959,0:52:34.420
and trusted stick, even if the BIOS was[br]malicious, it still, again, would not
0:52:34.420,0:52:40.199
be able to change anything in its own[br]firmware partition, would not be able to
0:52:40.199,0:52:45.180
store any stolen secrets[br]anywhere. So it’s convenient
0:52:45.180,0:52:51.260
to figure that the BIOS[br]might not be trusted.
0:52:51.260,0:52:59.320
But then, again, a compromised[br]BIOS might instead be providing
0:52:59.320,0:53:07.979
privilege escalation backdoors for[br]classic malware that executes on your
0:53:07.979,0:53:12.900
compartmentalised OS.[br]Such as to do VM escape.
0:53:12.900,0:53:16.229
Such things are trivial to implement.
0:53:16.229,0:53:21.199
And we don’t want classic malware[br]which means we want to ensure
0:53:21.199,0:53:27.559
that the BIOS does not[br]provide such backdoors.
0:53:27.559,0:53:35.239
And to make it short, we need open-source[br]BIOS. Something like Coreboot.
0:53:35.239,0:53:40.199
It’s great that we have Coreboot[br]and we could help Coreboot
0:53:40.199,0:53:43.789
to become such a BIOS[br]for this stateless laptop.
0:53:43.789,0:53:50.200
Even though Coreboot is not fully open-[br]source - it relies on so-called Intel FSP,
0:53:50.200,0:53:56.279
the firmware support package, which[br]is a Intel blob that is needed to
0:53:56.279,0:54:04.519
initialize your DRAM and other silicon[br]- still it should be reasonably easy to
0:54:04.519,0:54:10.650
ensure that FSP does not[br]provide SMM backdoors.
0:54:10.650,0:54:16.460
So this is a solvable problem.
0:54:16.460,0:54:25.139
Finally there’s this question:[br]So let’s say half a year from now
0:54:25.139,0:54:30.239
or a year from now pure reason[br]or somebody will tell you
0:54:30.239,0:54:37.549
here is the stateless laptop.[br]You can order, just a 1000 dollars.
0:54:37.549,0:54:43.619
So you got the laptop. But how do you[br]know it really IS a stateless laptop?
0:54:43.619,0:54:50.309
Maybe it is full of state-caring[br]elements. Maybe it’s full of
0:54:50.309,0:54:56.239
radio devices that are[br]emanating radios everywhere.
0:54:56.239,0:55:04.009
This comes down to the problem of:[br]How do we compare 2 different PCBs?
0:55:04.009,0:55:06.499
Two different Printed Circuit Boards?
0:55:06.499,0:55:13.900
As far as I’m aware right now our industry[br]has no ways to compare two different PCBs
0:55:13.900,0:55:17.859
and to state: yes they look identical.
0:55:17.859,0:55:26.249
Because if we had that, then we could[br]have the vendor, the laptop vendor
0:55:26.249,0:55:33.079
which would obviously have to be[br]open-hardware to publish the schematics
0:55:33.079,0:55:37.979
and pictures of the boards and then[br]anybody who ordered this laptop
0:55:37.979,0:55:43.699
would have an opportunity to always,[br]say, photograph the board and
0:55:43.699,0:55:51.170
have a diff tool to compare it.[br]If it really looks the same.
0:55:51.170,0:55:56.859
Sure we would not be able to see inside[br]the chips but at least the geometry-wise
0:55:56.859,0:56:06.269
comparison would be a tremendous step[br]to making such malicious modifications
0:56:06.269,0:56:09.579
by vendors very difficult.
0:56:09.579,0:56:13.900
This is a vision problem, kind of, right?[br]You take 2 photos, have 2 photos
0:56:13.900,0:56:20.910
of 2 PCBs and you have a tool to compare[br]it. And I believe Jake Applebaum
0:56:20.910,0:56:26.989
has already mentioned it,[br]some... a year ago probably,
0:56:26.989,0:56:37.999
it’s a great research project for all[br]you academic people sitting here.
0:56:37.999,0:56:43.809
That’s an example of a board that...[br]I have no idea, I got this laptop,
0:56:43.809,0:56:52.660
I opened it, I see this board. Sure, I can[br]identify some IC elements
0:56:52.660,0:56:55.980
like this embedded controller here...
0:56:55.980,0:56:59.729
But, really, maybe it’s connected[br]somehow differently,
0:56:59.729,0:57:02.819
maybe there is some other flash[br]elements there, I don’t know.
0:57:02.819,0:57:09.009
I would like to have an ability now to[br]check this with a called-in image
0:57:09.009,0:57:18.419
that some experts will analyze[br]in-depth and say it’s safe to use.
0:57:18.419,0:57:26.469
Many people say that perhaps we should[br]all give up on Intel x86 because ME e.g.
0:57:26.469,0:57:34.039
applause
0:57:34.039,0:57:39.309
Yet this is not such a nice idea.
0:57:39.309,0:57:47.809
Or maybe this is not such a[br]silver bullet, I should have said.
0:57:47.809,0:57:53.459
First, we have ARM. Everybody says[br]“Why not ARM? Let’s go to ARM!”
0:57:53.459,0:57:57.910
First: There’s no such thing as an ARM[br]processor. Okay?
0:57:57.910,0:58:04.199
ARM just sells the specifications, or IP.
0:58:04.199,0:58:12.319
And then the vendors, like Samsung,[br]Texas Instruments etc. who take this IP
0:58:12.319,0:58:18.199
and design and make very own SOC.[br]This is still a proprietary processor
0:58:18.199,0:58:24.789
that they can put whatever they want[br]inside. E.g. we have Trust Zone
0:58:24.789,0:58:30.869
that by itself is not as closed as ME.[br]That there is nothing that would
0:58:30.869,0:58:36.390
prevent a vendor to actually take[br]Trust Zone and lock it down
0:58:36.390,0:58:41.200
and end up with something[br]like ME very easily.
0:58:41.200,0:58:45.620
Just a matter of the[br]vendor willing to do that.
0:58:45.620,0:58:53.059
Also the diversity of the processors[br]make it difficult for OS’s like Qubes
0:58:53.059,0:58:58.599
that would like to use advanced[br]technologies like IMMU for isolation
0:58:58.599,0:59:04.019
to actually support all of them because[br]different PSOCs might be implementing
0:59:04.019,0:59:11.739
completely different versions or[br]even technologies doing that.
0:59:11.739,0:59:17.240
Another alternative, a much better one[br]is to use open-hardware processors.
0:59:17.240,0:59:24.809
Currently that means FPGA-[br]implemented processors.
0:59:24.809,0:59:29.199
In the future maybe we will have 3D[br]printers that will allow everybody
0:59:29.199,0:59:33.709
to print it. That will be great. But[br]probably is not coming any time,
0:59:33.709,0:59:37.170
in the coming 10 or 20 years.
0:59:37.170,0:59:44.609
And meanwhile the performance and[br]lack of really any security technologies
0:59:44.609,0:59:51.089
like IOMMU or virtualization doesn’t[br]make this a viable solution
0:59:51.089,0:59:56.410
for the coming say 5 years at least.
0:59:56.410,0:59:59.259
And even then, even if we have[br]such an open-source processor
0:59:59.259,1:00:06.490
this clean separation of state[br]still makes lots of sense.
1:00:06.490,1:00:11.789
Right? Again, because firmware[br]infections can be easily prevented
1:00:11.789,1:00:16.630
because malware, if it gets there[br]somehow still has no places
1:00:16.630,1:00:22.920
to store stolen secrets because[br]it provides reliable way to verify
1:00:22.920,1:00:29.229
or upload firmware. And makes it[br]easy to boot multiple environments.
1:00:29.229,1:00:31.789
And share laptops with others.
1:00:31.789,1:00:38.420
I know that most of you will now say:[br]“Yeah, that may be cool idea but
1:00:38.420,1:00:48.489
the market will never[br]buy into that!” Right?
1:00:48.489,1:00:55.159
Understanding that PCs are really,[br]as I said, extension of our brains,
1:00:55.159,1:01:02.900
we should stop thinking about[br]market forces as the ultimate force
1:01:02.900,1:01:08.289
shaping how our personal[br]computing looks like.
1:01:08.289,1:01:13.900
Just like we didn’t desert[br]to market forces
1:01:13.900,1:01:19.599
to give us human rights. Right?
1:01:19.599,1:01:26.280
We should not count on the market forces[br]to give us trustworthy personal computers.
1:01:26.280,1:01:28.689
Because that might just not be really...
1:01:28.689,1:01:34.569
applause
1:01:34.569,1:01:40.299
That just might not be in the[br]interest of the market forces!
1:01:40.299,1:01:44.459
So, hopefully, some legislation[br]could be of help here.
1:01:44.459,1:01:48.969
Maybe EU could do something here.
1:01:48.969,1:01:56.289
Because it’s really fun, when I[br]often talk with other engineers,
1:01:56.289,1:02:03.019
and we all know that our world[br]now really runs on computers,
1:02:03.019,1:02:06.999
and yet it apparently...[br]Almost every engineer I talked to
1:02:06.999,1:02:12.619
says something like “Yeah but the[br]sales people will never do that,
1:02:12.619,1:02:15.809
the business will never agree to that.”
1:02:15.809,1:02:23.579
But if the world runs on computers[br]shouldn’t it be us, the engineers,
1:02:23.579,1:02:28.809
who should actually have the[br]final say how this should...
1:02:28.809,1:02:33.030
how the computer technology[br]should look like?
1:02:33.030,1:02:37.509
Yeah, I’ll just leave it here with this.[br]Thank you very much!
1:02:37.509,1:02:40.499
final applause
1:02:40.499,1:02:44.569
postroll music
1:02:44.569,1:02:50.799
subtitles created by[br]c3subtitles.de in 2016