Joanna Rutkowska: Towards (reasonably) trustworthy x86 laptops

preroll music

Herald: I’m really glad that
you’re all here and that today

I can introduce Joanna Rutkowska to you.

She will be talking about reasonably
trustworthy x86 systems.

She’s the founder and leader
of the Invisible Things Lab

and also – that’s also something you all
probably use – the Qubes OS project.

She presented numerous attacks
on Intel based systems and also

virtualization systems. But today she
will not only speak about the problems

of those machines but will present some
solutions to make them more secure.

Give it up for Joanna Rutkowska!

applause

Joanna: Okay, so, let’s start
with stating something obvious.

Personal computers have become
really the extensions of our brains.

I think most of you will
probably agree with that.

Yet the problem is that they are insecure

and untrustworthy,

which personally bothers me al lot.

And here I want to make a quick digression

for the vocabulary I’m gonna
be using during this presentation.

When we say, well, there are
three adjectives related to trust

and people will often confuse them.
When we say something is “trusted”,

that means by definition something
can compromise the security of

the whole system, which means
we don’t like things to be trusted.

“Trusted third party”, “Trusted CA”
we don’t like that.

When we say something is...

because “trusted” doesn’t necessarily
mean that it is “secure”.

So, what is secure? Secure is
something that is resistant to attacks.

Perhaps this laptop might
be resistant to attacks.

If I open [an] email attachment and the
email attachment compromises my system

or maybe that if I plug
USB for the slide changer

I might be hoping that this
action will not compromise

my whole PC.

And yet something can be
secure but not trustworthy.

A good example of this might be e. g.

Intel Management Engine (ME), that I’m
gonna be talking about more later.

So it might be very resistant to attacks,
so it might be a backdoor.

A backdoor that is
very resistant to attacks,

yet it is not acting in
the interests of the user.

So it’s not “good”, whatever
good means in your assumed,

moral reference.

So, there’s been of course a lot of work

in the last 20 years and maybe more

to build solutions that provide

security and trustworthiness

and most of this work has focused on
the application layer and things like

GnuPG and PGP first,

TOR, all the secure communication
protocols and programs.

But of course,

it is clear that any effort
on the application level

is just meaningless if we can
not assure, if we can not trust

our operating system (OS).
Because the OS is the trusted part.

So if the OS is compromised
then everything is lost.

And there has been some efforts,
notably the project I started 5 years ago

and now this is like more than a dozen
of people working on it: Qubes OS.

It tries to address the problem of OS’s

being part of the PCB,
so what we try to do is

shrink the amount of trusted
code to an absolute minimum.

There’s been also other
efforts in this area.

But OS’s is not something I’m
gonna be discussing today.

What I’m gonna be discussing today
is the final layer, is the hardware.

Because what was OS to applications
it is hardware to the OS.

Again, most of the effort so far

to create secure and trustworthy OS,

they have always been assuming
that the hardware is trusted.

That means that... usually
that means for most OS’s that

a single malicious
peripheral on this laptop,

like a malicious Wi-Fi module
or maybe embedded controller

can compromise again my whole PC,

my whole digital life.

So what to do about it?

Before we discuss what to do about it

we should quickly

recap all the problems
with present PC platforms

and specifically I’m gonna
be focusing on x86 platform

and specifically with Intel x86
platform, which means: laptops.

This picture shows how a
typical modern laptop looks like.

You can see that it consists of

a processor in the center,
and then there is memory,

some peripherals, keyboard and monitor.

Very simple.

It can be very simple, because

if we look at present Intel processors

they really integrate everything
and the kitchen sink.

Ten years ago we used to have a processor,
a Northbridge, a Southbridge

and perhaps even more discrete
elements on the motherboard.

Today nearly all these elements have been
integrated into one processor package.

This is Broadwell

and this long element
here is the CPU and GPU

and the other one it
is said to be the PCH.

PCH is what used to be
the platform controller hub,

which is what used to be called
the Southbridge and Northbridge.

The line has somehow
blurred between these.

Of course there is only one
company making these.

It’s an American
company called INTEL.

It is a completely opaque construction.

We have absolutely no ways
to examine what’s inside.

That obviously...
The advantage is that

it makes construction of computers,
of laptops very easy now.

And lots of vendors can
produce little sexy laptops,

like the one I have here.

On this picture we see now some more
elements that are in this processor.

So, when you say processor
today, it’s no longer CPU.

Processor is now CPU, GPU,
memory controller, hub, PCIe,

root, some Southbridge,

so e.g. SATA controller and so on,
as well as something

that is called Management Engine (ME),
which we discuss in a moment.

There are few more elements
here that are important.

The most important for us
is the SPI flash element.

Because what’s interesting is that
with this whole integration

that has happened to the processor
and the other peripherals,

still the storage for the firmware,

so the storage where your BIOS as
well as other firmware is stored,

is still a discrete element.

We’ll see this element in
one of the next slides.

So let’s now consider first

the problem of boot security.

Obviously everybody understands
that boot security is something

- how to start the chain of
trust for whatever software

is gonna be running later -
is of a paramount importance.

I think I’m out of range.

Connected with boot security
is malicious peripherals,

that I mentioned shortly before.

So we’ll be now thinking: Can we assure

only good code is started

and how the peripherals
might interfere here.

Again, we will look at this SPI flash.

If we're now considering the boot
security we would like to understand

what code is loaded on the platform. And
if we now think where this code is stored,

it seems that the code is stored on
the SPI Flash and potentially also

on some of the discrete elements.

Let me state it again that this whole
integrated processor package

has everything and the kitchen
sink except for the flash,

so except for the storage of the firmware.

Here we have one of the SPI flash chips.

This is from my Laptop actually.

It’s a little microcontroller

and it typically stores the firmware for
these things, that are written here.

Now the question is, let's say I
have got this laptop from a store.

How can I actually verify what
firmware is really on this chip?

Well I can perhaps boot it into some
minimal Linux and try to ask it.

But of course if there is some malicious
something on the motherboard,

not necessarily this chip,
I will not get reliable answers.

Another question: Let’s say I somehow
know that there’s something trustworthy

on this SPI chip. Can I somehow enforce
read-only’ness of this program?

There have been some efforts to do that.

Like some projects by Peter Stuge
who just took a soldering iron

and connected one of the pins - one
of these 8 pins is called “write protect”.

If you ground it, it will be telling the
chip to discard any Write commands.

But again, remember, this chip
is still a little microcontroller,

it’s a little computer. So it might
ignore whatever you requested to do.

It’s not like you are cutting off
a signal for Write commands.

You are merely asking the
processor to ignore it.

So if you don’t trust the chip in the
first place, this doesn’t provide you

a reliable way to enforce read-only’ness.

Finally can I upload my own firmware?
Can I choose to use whatever BIOS I want?

Again, we don’t seem to have luck here.

And as I mentioned, this is just
one of the places on the platform

where the state is stored.
Embedded controller would be

a whole another microcontroller
having its own internal flash.

Or if not, using another
SPI chip to get flash from.

A disk would be another
microcontroller with a small computer,

having its own - typically -
flash for its own firmware.

And perhaps the same
with the Wi-Fi module.

Now for many years, myself and
lots of other people believed that

technologies like TPM, trusted execution
technology... like UEFI Secure Boot

I never really liked, but many people
did - they believed that they could

somehow solve the problem of secure boot.

But all of these technologies
have been shown to fail horribly

in this... on this premise.

And then we have...
So these were problems,

the tip of the iceberg of
problems of the secure boot.

The short story is: Today we can
not really assure secure boot.

Maybe before we move on to
Intel ME: e.g. Intel TXT:

Trusted Execution Technology was
introduced by Intel in the hope

to put the BIOS outside of the TCB,
trusted computing base for the platform.

So, the idea was that if you use TXT
which you can think of as

a special instruction of the processor,
that was the root of trust.

So, the promise was that
when using Intel TXT

you can start the chain of trust

without trusting the BIOS.
As well as other peripherals

like Wi-Fi card, which might
be malicious perhaps.

And that was just great.
And I really like the technology.

With my team we have done
lots of research on TXT.

But one of the first attacks that we have
presented, and that was back in like 2009,

was that we could bypass TXT
by having a malicious SMM.

SMM was loaded by the BIOS.

So apparently it turned out, that the BIOS
could not be really put outside of the TCB

so easily, because if it was really
malicious it would provide a malicious SMM

and then the SMM could bypass TXT.
So the response from Intel was: “OK,

but worry not, we have a technology
called STM - Secure Transfer Monitor.”

That is a little hypervisor to sandbox
the SMM which might be malicious.

So they wanted to boot
a special dedicated...

they built it actually... they built a
special technology to sandbox this SMM.

And then it turned out
this is not so easy.

Because as usual they
were missing the details.

And it is 6 years, 6 years has passed and

we still have not seen
any real STM in the wild.

Which just is an example how
hopeless this approach in building,

in trying to provide secure
boot is for the x86 platform.

Another problem with x86 that

has risen to prominence in the recent
years is the Intel Management Engine.

One of these things, that Intel

has put into this integrated processor
is called Management Engine (ME).

And this ME is a little microcontroller
that is inside your processor.

It has its own internal RAM,
it has its own internal peripherals.

Like DMA engine, which
has access to the host RAM.

And of course, it loads only
Intel-signed firmware.

And it has also its own private ROM inside
the processor, that nobody can inspect.

And nobody knows what it does.

And it runs a whole bunch
of proprietary programs.

And it runs even Intel’s
own proprietary OS.

And this all is happening all the time
when you have some power connected

to your processor.
Even if it’s in a sleep mode.

It’s running all the time
here on my computer.

It can be doing anything it wants.

Obviously when I say something
like that the first thought for,

at least for security people
is: “This is an ideal

backdooring or rootkitting
infrastructure.” Which is true.

However there is another
problem and it’s Zombification.

I call it Zombification of personal
computing that I will discuss in a moment.

I’m just stressing these are two somehow
independent problems with this ME.

About 10 or more years ago I used to be
a very active malware researcher or

scout malware researcher. Especially
rootkit researcher and back then when,

if I was to imagine an ideal
infrastructure for writing rootkits,

I couldn’t possibly imagine
anything better than ME.

Because ME has access to essentially
everything that is important.

As I mentioned it has
unconstrained access to DRAM,

to the actual CPU, to GPU.

It can also talk to your networking card,

especially to the Ethernet card

which controller is also in the
Southbridge in the processor.

It can also talk to the SPI
flash and asks the SPI flash.

It has its own dedicated
partition on the SPI flash,

which can be used to store
whatever ME wants to store there.

This is really problematic and
we don’t know what it runs.

But the other problem,
that is perhaps less obvious,

is what I call zombification of
the General Purpose Computing.

About a year ago there
was a book published by

one of the Intel architects, one of the
architects who designed Intel ME.

I highly recommend this book.

It’s the only somehow official source
of information about Intel ME.

And what the book has made clear is that

the model of computing that
Intel envisions in the future,

is to take the model, that we have
today, which looks like this.

The size of the boxes somehow
attempts to present

the amount of logic or involvement
of each of the layers

in processing of the user data.

Obviously we have most of this
processing done in the applications.

But we also have some involvement from the
OS and also from the hardware, of course.

For example, when we want to
generate a random number

we would usually ask an OS to

return us the random number.

Because the OS can generate it using
timings and interrupts, whatever.

But again, most of the logic, most of
the code is in the application’s layer.

And this is good, because

thanks to computing being
general purpose computing,

everyone of us can write applications.

We can argue what is the best
way to implement some crypto.

Some people can write it one way, some
other people can write it another way.

And that’s good.

Now this is the model
that Intel wants to go to.

It essentially wants to eliminate
all the logic that touches data

from apps and OS even
and move it to Intel ME.

Because, remember,
Intel ME is also an OS.

It’s a separate OS. Only that this is an
OS that nobody knows how it works.

It’s an OS, that nobody
has any possibility

to look at the source code
or even reverse engineer.

Because even we can not
really analyse the binaries.

It’s the OS that is fully controlled
by Intel. And not to mention that

any functionality it offers is
also fully controlled by Intel.

Without anybody being
able to verify what they do.

That might not even be malicious.

They may not even be
doing malicious things.

Perhaps they are just
implementing something wrong.

Bugs. Security bugs, right?

But of course Intel believes
that whatever Intel writes

must be secure.

For some reason the must have missed

a number of papers that my team and others

have published in the recent 10 years.

The questions are: Can we disable Intel ME
or can we control what code runs there?

Can we see at least what code is there?

And as far as I’m aware the
answer is unfortunately: Not.

As I mentioned, I have this cool
laptop it runs Qubes OS, of course,

but still it not only runs Qubes OS.
It also runs side by side Intel ME.

Intel ME proprietary OS.

And I can’t do anything about it.

About 6 or 7 years ago my team
has done some work on Intel AMT.

I believe this was the first and probably
the only work where we managed

to actually inject code into
ME. That was back in times

when Intel ME was not in the
processor. It was in the Northbridge.

It was in the Q35 or Q45 chipset,
if I remember correctly.

So we demonstrated how we
can inject a rootkit into ME.

Of course Intel then patched it.

Now they continue to think that whatever
they write will be always secure.

But, the problem is...

For a number of years after that
presentation I used to believe

that we could use VTD
- an INTEL IMMU technology with TXT -

perhaps to effectively sandbox ME.

Because some of the specifications I saw,

suggested that VTD should be able to

sandbox ME accesses to host memory.

And because we used VTD heavily
on Qubes, thanks to Xen using it,

I was pretty much not
that worried about ME.

Unfortunately it turned out
that ME can just bypass VTD.

And this is a feature of this ME.

Which brings us to this rather
sad conclusion that perhaps

if we look at Intel x86 platform,
then the war is lost here.

It might be lost even
if we didn’t have ME.

Even if we somehow manage to
convince Intel to get rid of ME,

or at least to offer OEMs, Laptop
vendors, an option to disable it,

by fusing something.

The problem with secure boot
that I mentioned earlier,

and that I analysed in more detail
in a paper I released 2 months ago,

is that it really is hopeless,

because of the complexity
of the architecture

where we have ring 3, ring 0, okay. Then
we have SMM, then we have virtualisation,

then we have STM to sandbox SMM,
and the interactions between these.

This all doesn’t look really like
it could be solved effectively,

which of course bothers me a lot.

At least on purely egoistic reasons,

because I spent the last 5 years
of my life on this Qubes project.

And of course with such a state of
things it makes my whole Qubes project

somehow meaningless.

If the situation is so bad,

perhaps the only way to solve the problem
is to change the rules of the game.

Because you can not really
win under the old rules.

That’s why I wanted to share
this approach with you today.

That starts with recognizing that

most of the problems here is
related to the persistent state,

that is stored pretty much
everywhere on your platform,

which usually keeps the
firmware, but not only.

So let’s imagine, that we could do a
clean separation of state from hardware.

So this is the current picture.
This is your laptop.

The reddish boxes are state,
the persistent state.

That means these are places
where malware can persist.

So you reinstall the OS, but
the malware still can re-infect.

There are also places where
malware can store secrets,

once it steals them from you.
So imagine I can have malware,

that might only be stealing
my disk encryption key.

And it can store it somewhere on
the disk or maybe on SPI flash.

Or maybe in the Wi-Fi module firmware, or
maybe in the embedded controller firmware,

somewhere. Somewhere
there in those red rectangles.

Now if the malware does it,
that is a pretty fatal situation,

because if my laptop
gets stolen or seized,

perhaps then the adversary who gets

a key to the malware can
just decrypt the blobs.

And the blobs would reveal my disk
decryption key. And then the game is over.

And also another problem with
this state is that it might be

revealing many of the user and
personally identifiable information.

How ever you read this PI shortcut.

These are for example MAC addresses.

Or maybe processor serial number.

Or maybe ME serial number. Whatever!

Or maybe the list of SSID networks,
that ME has seen recently.

How do you know it’s not being
stored somewhere on your SPI flash?

You don’t know what is stored there.
Even though I can’t take off my SPI flash

or just connect a programmer to my
SPI flash - an EEPROM programmer -

I can read the contents of the SPI
flash, but all of this will be encrypted.

Now we recognize, that the
state might be problematic.

And now imagine a picture, that
we have the laptop, which has

no persistent state storage.
Which is this blue rectangle.

Let’s call it stateless laptop.

And then we have another element,
that we’re gonna call trusted stick

for lack of any more sexy name for it.

That’s gonna be keeping all the firmware,
all the platform configuration,

all the system partitions,
like boot and root,

all the user partitions.

Now we see that... and of course the
firmware and system partitions

will be exposed in a read only manner.

So even if malware, perhaps a traditional
malware, that got into my system

through a malicious attachment,
even if it found a weakness in the BIOS,

or maybe in the chipset, allowing
it to re-flash normally, allowing it

to re-flash the BIOS - we have seen plenty of
such attacks in the recent several years.

Now it would not be able
to succeed, because

the trusted stick, which gonna be a
simple FPGA implemented device,

will just be exposing
the read-only storage.

You see that firmware injection
can be prevented this way.

Also there is no places
to store stolen secrets.

Again, the same malware running in the ME

still can steal my disk encryption
key or my PGP private key.

But it has no place to store it.

So if somebody now takes my laptop,
will not be able to find it there.

You might say, maybe it will be
able to store it on the stick.

But then, again, the stick, the firmware
and system partitions are read-only.

And the user partitions
are encrypted by the stick.

So even if ME can send something to be
stored there, nobody besides the user

can really get hands on this blob.

Also we get a reliable way to
verify what firmware we use.

Or ability to choose what
firmware we want to use.

Because we can just take this stick,
plug into our trustworthy computer,

some, I don’t know, Lenovo X60 from 15
years ago, that we have running Coreboot

and we just analysed all
the elements, whatever.

So we finally a have a way to
upload firmware in a reliable way.

Thanks to the actual laptop having no
state, we can have something like Tails

finally doing what it advertises.
I can boot Tails or something like that.

I can use it, I can shut it down and there
is no more traces of my activity there.

I can give my laptop to somebody other.
Or I can boot some other environment.

Perhaps some, I don’t know,
Windows to play games, or whatever.

So what would it take to have
such a stateless laptop?

This is the simplest version which
shows that the only modification

that has been made here was
to take the SPI flash chip

and essentially put it outside
the laptop on a trusted stick.

And just route the wiring,
just 4 wires, to the trusted stick.

And that’s pretty much it.

That’s the simplest version. Oh,
and I also got rid of the disk.

And also I had to ensure, that
whatever discrete devices,

which are in that case embedded
controller and Wi-Fi module,

they do not have flash memory
but use something like OTP memory.

We can further get rid
of the Wi-Fi, and use

an external USB connected
one if that is not possible.

And for the embedded controller that
should be possible, much more easier,

because embedded controller is always
something that the OEM chooses.

So we can just talk to whatever
OEM, who would like to implement

this stateless laptop, and ask the
OEM to use an embedded controller

with essentially ROM, instead of flash.

So that’s the simplest version,
which is really simple.

This is a more complex version
where we also fit something

that I call here SPI Multiplexer.
Which allows to share the firmware

not just to the processor, but
also to the embedded controller.

And perhaps also with the disk.

Because maybe we actually
would like to have internal disk.

Because internal disk will always
be faster and will always be bigger

than whatever disk we will
put on our trusted stick.

You might object, that, come on, disk
is actually not a stateless thing! Right?

Because disk is made especially
to store state persistently.

But it’s a special disk, that I will
mention in just a few minutes.

It’s a special disk running trusted
firmware and doing read-only

and encryption for everything.

And now for the trusted stick:

As I mentioned, the trusted
stick is envisioned to have

read-only and encrypted partitions.

And the read-only partitions are for
firmware and the system code.

So the first block is something that we
would like to export over SPI, typically,

and the system partition is
something that we make visible

to the OS using something like
pretending being USB mass storage

or actually implementing
USB mass storage protocol.

And the encrypted partition
- again, the important thing here is

that encryption should be
implemented by the stick itself.

So we have some key here,

the question is how this key should be...

What input should be taken
to derive this key from.

It could be something that
is persistent to the stick.

It could be combined with a
passphrase, that the user enters

using a traditional keyboard,
plus maybe a secret from the TPM.

And when I say TPM I think about the
firmware TPM inside the processor

that is using storage provided by

encrypted firmware partition.

The optional internal disk
that I just mentioned,

it should essentially do
the same as the stick,

and because it will be
running trusted firmware

that it will be fetching
from the trusted stick itself

the disk will not have any flash memory.

So because we will trust
the hardware of the disk

and because we will trust the
firmware, we will trust the firmware

to provide read-only and encrypted
partitions just like those ones

I mentioned on the stick, which is nice
because it reveals the stick from acting

as a mass storage device, which has

practical consequences which are nice.

So there’s a picture with the internal
trusted disk, which you see just here.

As you can see, it takes also the
firmware from the trusted stick.

And there is even an open source
project, OpenSSD. And it looks like

people have already built an open hardware
open firmware SSD, a very performant disk.

So this is not just science
fiction, even for this SSD.

Okay, so that looks all very nice,
but there is one problem.

Even though malware may not have any
place on the laptop to leak the secrets,

it still might try to do
it over networking.

And let’s differentiate now between
classic malware and sophisticated malware.

Classic malware is something you get with
an attachment or some drive-by-attack

which we’ll discuss in a moment.
Now, let’s focus on sophisticated malware.

So, a hypothetical rootkit in ME.

Before we move on, for obvious
reasons, such a sophisticated malware

would not be interested
in getting caught easily.

So, it would not be establishing a
TCP connection to NSA.gov server

or whatever, right?
That would be plain stupid.

Having that in mind, let’s
consider a few scenarios.

Scenario number 0 is
an air-gapped system.

Even though it might
be an air-gapped system,

still remember there is ME running there.

If the computer is not
inside a Faraday cage,

there is still plenty of other
networks or devices around it.

Which means that ME can theoretically
use your Wi-Fi card or even speaker

to establish a covert channel with, say,
your phone, that might be just nearby.

So, in order to make such a
system truly air-gapped,

knowing that we can not get rid of the ME,

we really need to have kill-switches
for any transmitting devices,

including the speakers, and apparently
even that might not be enough,

because some people showed
covert channels that used

things like power fluctuations

or temperature fluctuations but let’s
leave that exotic examples aside.

A more interesting scenario is a
closed network of trusted nodes.

In that scenario we assume that
all these people are trusted.

Again, by definition that means that
any of these people can compromise

the security of anybody else.
We really don’t like trusted things,

but, well, let’s start with something.

Now, even though each of these trusted
peers which run state-less laptops,

even each of these have
this malicious ME in itself

because we gonna fit a small proxy

so a modification that we are...
that we should additionally do,

that I have not shown you before,
is that rather than connecting

your Wi-Fi module directly to the
processor which is not good,

because it gives full authority of the
processor over this Wi-Fi module.

Instead we would like to
connect it to some proxy.

It would be doing some kind of tunnelling.

Something like VPN or maybe TORifying
any traffic that is generated there.

So even though ME might be willing
to be sending some traffic

maybe not explicit traffic,

maybe will be piggybacking on
some user generated traffic,

by only modifying, I don’t know, TCP
initial sequence numbers, or something.

It still all will be happening
inside the tunnel.

Again, some people might be
saying “Yeah, but still ME

might be modulating the timings
of the generated packets

and this way try to convey some
information using timing.”

We can’t truly do much about that
but on the other hand it would be

extremely difficult for ME to
do that, implementation wise.

Finally a scenario where
we want to use any...

when we want to connect with anybody
not just with a trusted computer.

So, say, with some website on the internet
that might or might not be trusted.

Again, by having this proxy which by
the way might be implemented inside

this embedded controller that
we know, if you remember,

it runs the trusted firmware because it
fetches firmware from our trusted stick.

So the proxy again is tunnelling
any potential leakage from ME

which means that a malicious ISP or
any part of the infrastructure here

still can not really retrieve the
secrets that ME tries to leak.

But of course at some point we need to
terminate the stunnel that might be

the VPN server or might be a TOR exit
node or maybe the server itself if it’s,

say, maybe an onion server, in
which case anybody here can still

presumably get the secrets
from ME in this cloud here.

Which unfortunately we
can do nothing about.

Except for hoping that at least
if we used perhaps TOR

for this first part of the equation

then at least a malicious
administrator of, say, this server

would not be able to
correlate whose decryption...

whose disk decryption key it really is.

Although this is very tricky. That would
only work if this computer was

a special purpose computer. If you
used something like Qubes here

and if you wanted to have different
partitions, one for your personal

and only one of these partitions
would be special secret partitions.

That wouldn’t work, because
ME still would be able to gather

your identification information
from whatever partitions you have.

Because again, it has unconstrained access
to all the personal, all the host memory.

But still this... using this
proxy pushes adversary,

hypothetical adversary, in the
ME, into extreme difficulty

of needing to piggy-back on
some higher-level protocols

establishing exotic cover channels.
Comparing to what they can do today

one can... they simply steal the key
and store it on SPI first partition.

Or maybe on your disk. This is like
orders of magnitude more difficult

for them to do.

We mentioned the sophisticated
malware and I mentioned

the classic malware is a different story.
The classic malware doesn’t need

to be shy against leaking something
through whatever means you can think of.

Perhaps by sending email to somebody. But
obviously to address the classic malware

problem we can address it quite
reasonably well on the OS level.

For example using compartmentalization.
But here comes the problem,

is, that a malicious BIOS...

Let me get back a little bit. Because
so far we having assuming that

we don’t really need to trust the BIOS.
Because having this stateless laptop

and trusted stick, even if the BIOS was
malicious, it still, again, would not

be able to change anything in its own
firmware partition, would not be able to

store any stolen secrets
anywhere. So it’s convenient

to figure that the BIOS
might not be trusted.

But then, again, a compromised
BIOS might instead be providing

privilege escalation backdoors for
classic malware that executes on your

compartmentalised OS.
Such as to do VM escape.

Such things are trivial to implement.

And we don’t want classic malware
which means we want to ensure

that the BIOS does not
provide such backdoors.

And to make it short, we need open-source
BIOS. Something like Coreboot.

It’s great that we have Coreboot
and we could help Coreboot

to become such a BIOS
for this stateless laptop.

Even though Coreboot is not fully open-
source - it relies on so-called Intel FSP,

the firmware support package, which
is a Intel blob that is needed to

initialize your DRAM and other silicon
- still it should be reasonably easy to

ensure that FSP does not
provide SMM backdoors.

So this is a solvable problem.

Finally there’s this question:
So let’s say half a year from now

or a year from now pure reason
or somebody will tell you

here is the stateless laptop.
You can order, just a 1000 dollars.

So you got the laptop. But how do you
know it really IS a stateless laptop?

Maybe it is full of state-caring
elements. Maybe it’s full of

radio devices that are
emanating radios everywhere.

This comes down to the problem of:
How do we compare 2 different PCBs?

Two different Printed Circuit Boards?

As far as I’m aware right now our industry
has no ways to compare two different PCBs

and to state: yes they look identical.

Because if we had that, then we could
have the vendor, the laptop vendor

which would obviously have to be
open-hardware to publish the schematics

and pictures of the boards and then
anybody who ordered this laptop

would have an opportunity to always,
say, photograph the board and

have a diff tool to compare it.
If it really looks the same.

Sure we would not be able to see inside
the chips but at least the geometry-wise

comparison would be a tremendous step
to making such malicious modifications

by vendors very difficult.

This is a vision problem, kind of, right?
You take 2 photos, have 2 photos

of 2 PCBs and you have a tool to compare
it. And I believe Jake Applebaum

has already mentioned it,
some... a year ago probably,

it’s a great research project for all
you academic people sitting here.

That’s an example of a board that...
I have no idea, I got this laptop,

I opened it, I see this board. Sure, I can
identify some IC elements

like this embedded controller here...

But, really, maybe it’s connected
somehow differently,

maybe there is some other flash
elements there, I don’t know.

I would like to have an ability now to
check this with a called-in image

that some experts will analyze
in-depth and say it’s safe to use.

Many people say that perhaps we should
all give up on Intel x86 because ME e.g.

applause

Yet this is not such a nice idea.

Or maybe this is not such a
silver bullet, I should have said.

First, we have ARM. Everybody says
“Why not ARM? Let’s go to ARM!”

First: There’s no such thing as an ARM
processor. Okay?

ARM just sells the specifications, or IP.

And then the vendors, like Samsung,
Texas Instruments etc. who take this IP

and design and make very own SOC.
This is still a proprietary processor

that they can put whatever they want
inside. E.g. we have Trust Zone

that by itself is not as closed as ME.
That there is nothing that would

prevent a vendor to actually take
Trust Zone and lock it down

and end up with something
like ME very easily.

Just a matter of the
vendor willing to do that.

Also the diversity of the processors
make it difficult for OS’s like Qubes

that would like to use advanced
technologies like IMMU for isolation

to actually support all of them because
different PSOCs might be implementing

completely different versions or
even technologies doing that.

Another alternative, a much better one
is to use open-hardware processors.

Currently that means FPGA-
implemented processors.

In the future maybe we will have 3D
printers that will allow everybody

to print it. That will be great. But
probably is not coming any time,

in the coming 10 or 20 years.

And meanwhile the performance and
lack of really any security technologies

like IOMMU or virtualization doesn’t
make this a viable solution

for the coming say 5 years at least.

And even then, even if we have
such an open-source processor

this clean separation of state
still makes lots of sense.

Right? Again, because firmware
infections can be easily prevented

because malware, if it gets there
somehow still has no places

to store stolen secrets because
it provides reliable way to verify

or upload firmware. And makes it
easy to boot multiple environments.

And share laptops with others.

I know that most of you will now say:
“Yeah, that may be cool idea but

the market will never
buy into that!” Right?

Understanding that PCs are really,
as I said, extension of our brains,

we should stop thinking about
market forces as the ultimate force

shaping how our personal
computing looks like.

Just like we didn’t desert
to market forces

to give us human rights. Right?

We should not count on the market forces
to give us trustworthy personal computers.

Because that might just not be really...

applause

That just might not be in the
interest of the market forces!

So, hopefully, some legislation
could be of help here.

Maybe EU could do something here.

Because it’s really fun, when I
often talk with other engineers,

and we all know that our world
now really runs on computers,

and yet it apparently...
Almost every engineer I talked to

says something like “Yeah but the
sales people will never do that,

the business will never agree to that.”

But if the world runs on computers
shouldn’t it be us, the engineers,

who should actually have the
final say how this should...

how the computer technology
should look like?

Yeah, I’ll just leave it here with this.
Thank you very much!

final applause

postroll music

subtitles created by
c3subtitles.de in 2016