Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/564 Thanks!
And now our first talk here today
will be about an evil made at
us. We'll find out how to actually
make sure that the piece of software
that you type in, for example, your hard
drive password every morning, is actually
a piece of software that you think it is.
So please welcome Matthew.
Good morning. So first of all, I'd like
to say that it's wonderful that so many
of you have been able to make it to this
completely unreasonable time in the
morning.
I appreciate this quick
introduction. My name's Matthew Garita,
I'm a security developer at Choros,
but I'm also on the board of
directors of the Free Software
Foundation.
So while I'm very interested in
security, especially very
low level security, securing the
platform before we even get to the point
of running applications, I focus
as far as possible on ensuring
that any security work
I do still
permits the owner of the computer
to be the person who makes the ultimate
decision about what they want their
security policy to be, what software they
want to be able to run.
Because it's unfortunate when
we make security choices that make it
impossible for people to have
free control of their own systems.
So the quick just
so the quick
corporate sponsorship thing, we just
opened an office in Berlin.
Chat to me if you are interested in
working on this kind of stuff.
Well, as we talked about today is the
problem of how you
can fundamentally know that your
computer is trustworthy.
In this case, when I say trustworthy,
what I mean is the computer will not
betray you. The computer is
operating in your best interest.
The computer is not choosing
to circumvent your decisions
and make life easier for
people who are not you.
And so we've seen cases where, for
instance, in DRM computers are
untrustworthy because they refuse to let
you do what you want to do.
But from a security perspective, we also
want to be sure that a computer
is taking your secrets
and holding them and treating them
in a trustworthy manner.
It's not releasing those secrets to
anybody else.
It's not holding
onto them and then using them
to leak data about you.
So part of that positive thinking
about how we define the trustworthiness
of the computer is knowing when we trust
a computer.
And up until the point where you
start putting secrets into
a computer, it doesn't matter whether
it's trustworthy or not, it doesn't have
any way to harm you.
Now, secrets are obviously things
like passwords, past freezes.
Secrets are also things like your
browsing history.
Secrets are anything
that is not information
that you would necessarily wish to
publish entirely.
I'm only going to be talking about the
former stuff, but in terms
of building a fully trustworthy platform,
you need to have trustworthiness
from the very beginning of the book
process before you enter
any secrets. Your computer must
be in a trustworthy state.
You need to be able to look at your
computer and say, I trust this
computer.
Because if that's not true,
how do you know that the software that
you're typing your password into
is operating in your best interests
and the free software world?
We can examine the source codes.
We can have a lot of people independently
reviewing it. And that means that there
is perhaps a higher probability
of us being able to look at this software
and say, yes, this software is
trustworthy.
But once that's been compiled, once
that's on disk, if someone is able to
modify that software
on your hard drive, then it's may
transition from being trusted
to untrusted.
So if someone is able to get access to
your system and then modify the contents
of that, then you're in an unfortunate
position.
But it's worse than that because
that software is running on top of
an operating system, Colonel.
And how do you know that the colonel
itself has not modified
that software?
A sufficiently modified
currently back Col is
able to arbitrarily modify
the behavior of any userspace
applications, even if you had
some way to verify that your userspace
application was trustworthy, that the
passphrase had the program
taking your description, passphrase had
not been modified. If the kernels be
modified, it doesn't matter.
The kernel can still subvert that.
But say you have some mechanism to verify
that the kernel is good when it's right
off disk.
How do you know that the bootloader
that ripped the kernel off disk and then
verified kernel states didn't then modify
the kernel, which could then
modify the application and
then stoya passphrase or send it off
to somewhere and pleasant?
The bootloader, OK, say we have a means
of verifying the bootloader, how do we
ensure that the firmware that launched
the bootloader didn't tamper with the
bootloader that launches the kernel that
can then be tampered with to tamper with
the software that reads your passphrase?
And fine, OK, we solve all of that
and then, well, fundamentally, at some
point, the CPU itself is obviously
executing this code is capable of doing
whatever it wants.
And if the CPU is not trustworthy, then
there is no way to trust the firmware in
the way. Trust the bootloader that we
trust the kernel. No way to trust the
password prompt.
Figuring out how to trust the CPU is a
hard problem.
I'm going to ignore it.
But figuring out the trustworthiness of
the rest of the system is more
practical, not necessarily to the extent
that everybody would like, but
to a reasonable extent,
trusted computing was a phrase
that started appearing a little
over 10 years ago in the early 2000s, and
at that point, trusted computing.
It was clear it was going to be used as
a mechanism to ensure
that our computers, the computers
we owned, could be trusted
by media companies,
could be trusted by proprietary
software developers.
We felt that the way that trusted
computing was inevitably going to be used
was for
our computers to be
out of our control, that people
would use this technology to restrict
what we could do with our computers.
Thankfully, none of that's happened.
And there's various technological and
political reasons for that, which I'm not
going to go into today.
At the heart of trusted computing is
a component called a trusted platform
module.
Most of the time, a trusted platform
module is a small,
discrete.
I see. That's on your system
motherboards. It's typically on the LPC
bus. The TPM
does not have any ability
to access system memory directly.
The TPM can only do what
is asked to do. The TPM cannot
independently modify system state.
The TPM has no way
of reaching out and looking at the
contents of RAM and figuring out what
you're running.
The TPM can only do
what it's told to do.
It can only know what it's explicitly
told about.
If you never run
any code that touches the TPM, the TPM
can do nothing to TPM, cannot phone home
on its own, the TPM cannot
interfere with your ability to run
software.
For the most part, on free software
platforms, we have completely ignored
the TPM because
most things we can think of to do with it
were not particularly beneficial to us.
At the TPM has one
fascinating feature, which is inherent
to the trusted computing goal, the
idea that we can define whether a
computer is in a trusted state, and
that's something called measurement.
Insecure about
each component verifies a
cryptographic signature on the following
components and refuses to run it
if that signature doesn't match
in trusted computing,
your ability to run arbitrary
software is in no way restricted.
There is no validation of signatures.
There are no keys involved in this at
this stage.
Instead, every
component measure is the next component.
And stores that in the TPM.
And measurements in this case is just
a sha one hash and.
Just as a brief clarification here,
TPM version of the TPIMs version,
one point two is what I'm most going to
be talking about. TPM 2.0
is now available and devices
are beginning to appear.
But pretty much every single TPM
that's currently available in the wild is
a one point two device and they
uninfluential one more.
TPM to devices have support
for basically arbitrary hash algorithms,
including some that are actually good.
So in a measured Bhoot.
The first component looks
at the next component to be executed
and before executing, it
takes a shower, one of that.
And then it's right that
sha one value into a
platform configuration register
or a PCR.
When we say it's written,
extend is a meaningful words hit
when a value is written, it does not
replace the existing value.
It's not possible to arbitrarily
overwrite the existing contents of
a PCR instead.
The existing content of the PCR.
Is prepend it to the new value,
so you had 20 points in the picture,
you wrote a 20 Blanka one,
and now you have a 40
byte value.
And that 40 point value is
then again hashed
again with Shahd one and the
PCR is set
to that value.
So this means that the new
value of the PCR depends on
the previous value,
which means that there is basically three
ways to get a specific
PCR value.
And those are.
Bring shall one.
So if you are able to figure out
a way to add 20
bytes of arbitrary data to the existing
PCR value such that you control
the new shall one value, then you
can completely break trusted boot.
If any of you know how to break SHA one.
I'm going to be a little bit unhappy.
And various other people are going to be
very, very unhappy.
And we're all going to have bad
days.
So, again, I'm going
to ignore this possibility because
it's far too terrifying and we can't do
anything about it anyway.
Another is to trigger execution of
arbitrary code through unmeasured data.
Measurements typically only measures
the code
at a few exceptions, but basically it
measures the code.
That code has to operate on data.
As a species, we're pretty
bad at writing code.
We're even worse at writing code
that deals with data
and we're astonishingly bad at writing
code that deals with arbitrary use of
provider data.
A break
in trusted computing process
was demonstrated by the Invisible Things
labs through the simple
expedient of noticing that.
The firmware allows you to
provide a boots picture
in the firmware.
And this meant the people buying the
boards from Intel could
replace the boots with something,
including their company brands, rather
than just having a generic Intel logo.
The problem was the format's was
BNP, the Microsoft
bitmap format, and
that includes run length encoding
support, i.e., you can say
the next value represents
256 of these values.
So it's a lossless compression mechanism.
There was nothing in the code
to check that the
coding did not result in you overrunning
the buffer that the
bitmap was being decompressed into,
which let you overwrite arbitrary code
in the firmware.
And then since
the bitmap was on measures, you then
had arbitrary codes execution, which
meant that you could then modify
the following stage, but right
the correct one value into the PCR
so everything would look good.
If your phone was not trustworthy, if
your firm was not competent,
then your firm where cannot be
trustworthy.
So the fact that the majority of us
are running proprietary firmware
with no available source code and we
can't verify this, any of it is any use
whatsoever is a minor problem
here.
And finally, you can perform exactly the
same sequence of rights to the picture,
and this is what happens in the normal
boot, if nothing's been modified,
then the one of every components will
match.
You perform the same
sequence of PCR
updates and you end up with the same PCR
values.
So that's great.
If the system Boutte's correctly,
then the PCR values
will always be the same.
As long as no systems have been, as
long as not components of being
interfered with.
But there's a minor problem here.
Has we read those values
and the straightforward answer
is very simple, we
just.
Ask the hospital what the
PCR values are.
There's a command you send to it and then
it gives you that.
So that seems like a straightforward
answer.
But the TPM is hardware
if we talk to hardware through the
kernel.
The colonel can just lie to
us.
The colonel could give back whatever PCR
values the colonel wanted to.
And this, again, is kind
of a problem, the entire point of this is
to determine whether we can trust the
colonel and if the colonel's
untrustworthy, we have no means
of determining whether the answer is
accurate or not.
If we get back incorrect values, we know
something's wrong, but getting back
correct values does not mean that
everything's OK.
It's the standard way of dealing with
this. Well, something called remote
station, and this was
the thing that we were most concerned
about in terms of trusted computing
back in the early 2000s.
Remote as a station is a protocol
where the TPM
has a cryptographic conversation
with a remote server.
Every TPM has what's called an
endorsement key built in and the
endorsement key has a certificate.
It's the change back to the TPM
manufacturer so you can
ask the TPM to sign something with its
endorsement key. You can ask the TPM for
the endorsement certificates.
You can verify that the endorsement
certificate changed back to the TPM
vendor. You can verify that the
TPM is able to sign something
with that key, and that means that
the TPM has control of
that specific endorsement key.
You know that you're talking to a real
TPM at that point.
So there are a reasonably complicated
chain of events. You can then create
a secure cryptographic communication
channel between the TPM and a remote
system, I might say, between the TPM, the
remote system. This is all mediated by
your operating system.
If you're operating system doesn't want
this to happen, it won't happen.
This can't be done against your will if
you're running an operating system you
control.
The local operating system has no means
of interfering with remote
at the station if the remote
system gets a set of values from
your team.
It knows that those are the values that
the TPM hangs over.
All the operating system can do is
basically perform a denial of service.
It can prevent this from happening at
all.
The remote the remote system can
then look at the PCR values and
can decide whether the system is in a
trustworthy state and that could be based
on any kind of arbitrary policy.
Different components are measured into
different pieces. So you can look at the
system and say, OK, I recognize this
firmware version because the PCR that
contains the firmware measurement is
disvalue.
And I recognize this bootloader.
And I don't care what Col's being booted,
you can do something like that.
From there is you need to trust
the remote's machine and
you don't have any particular
reason to trust the eight remote's
machine has not been subverted
and is now operating outside.
Your decisions
about trust.
If someone compromises this machine, then
you could have a setup where your
computer access to the remote machine
and then a remote machine might send you
an SMS back saying your computer is
good or your computer is bad.
If someone can interfere with the
machine, then it can always just
say your computer is good.
And obviously, you also need network
access, so this means that if you're
using remote station, there's no way for
you as a local user to figure
out whether your system is trustworthy.
If you're on a plane without Wi-Fi, if
you're in the middle of the countryside
or if you just don't feel like connecting
to the network, you can't do remote
isolation.
So it's not ideal.
And then how's the remote machine
communicate back to you?
Esme's maybe, but then someone
could just interfere with
that and send you a fix this mess.
We know that the phone networks are
not as secure as we would like them to
be, especially if your
adversary is a government.
And over
some sort of secure connection, well,
if you're running on your local system,
then fine, you open
the browser, the browser says,
yes, everything's fine because your
browser is being compromised by the
car and also your points.
And so you can't trust what it's telling
you about. Everything looks OK here as
well.
So remote isolation is a problem because
it relies on you having to trust a
large number of systems that aren't in
your control.
And that's not the kind of situation
we want.
We're asserting that the CPM is
trustworthy. Everything I'm talking about
is completely pointless if the team isn't
trustworthy. So if you'd like to treat
this as an academic exercise, that's
completely fine. I understand your point
of view.
But if the TPM is trustworthy, then we
can take advantage of any other
features that the TPM offers to
control secrets.
And this is good because one thing that
TPIMs can do is control data
release based on the state of the
pickle's.
As well as measurements, teams are able
to encrypt small quantities of data,
you can ask a TPM to generate
Banaszak and
you can then ask the TPM to encrypt
something with that.
And the cool thing here is you can
ask the TPM to encrypt that
data along with information
about the PCR values.
Now, the key to decrypt this data
is kept on the TPM,
the decrypt, the private key is never
in system ran, it's never on
your hard drive.
This data is encrypted with
a key that is in the TPM.
So.
There's no straightforward way for
someone to get hold of the private
key that they need to decrypt this.
If you have the PCR value sets,
then when you put the data into the TPM,
the TPM decrypts it and then looks
at the PCR values and compares those
to the values that it has recorded.
And if they match, it
will return the encrypted data
to decrypt the data.
And if they don't match, it
will return an error.
So this means that it's possible to have
a secret that will only be released
if the TPM is in a
if the measurements are good,
which then should indicate that your
system is trustworthy.
So you could use this, for instance,
as a way of storing
your desk decryption key,
and that means that someone who if
your boot process is interfered with, if
the measurements no longer match,
the TPM will not release
the decryption key.
And as a result, your bootloader will
not be able to decrypt your hard
drive and your system will not boot.
Now, this doesn't protect against the
case where someone just steals your
laptop, if that's all you're doing, then
all they need to do is turn your laptop
on.
And it'll boot the 2pm
is not verifying that you
are the person using the system, all the
TPM is doing in this case is verifying
that the boot state
has not been tampered with.
So, OK, we can deal
with this.
You enter a passphrase as well,
so the system Boutte's.
The 2pm decrypts the key,
if the 2pm successfully decrypts the
key, that's half of the process.
We still need you to type in a
passphrase in order to
decrypt the key through a second
stage and actually allow you to
access your hard drive.
So this seems safe because
if someone steals your machine and turns
it on, then they still can't
get access to your system without your
passphrase. And if the boot process
is tampered with, then the first
step of this will fail and the
system will not prompt you for the
passphrase.
There's a problem with this line of
thinking, which is fine.
You boot your system and you get the
password prompt and you think, OK,
the system is in a secure state.
I can trust the system, I can type in
my password and you type in
your password and you hit enter and it
looks like the system is missing.
And then. Oh, no.
Linux's bad.
This happens, I'll try turning
it off and turning it on again.
And you turn this off and you turn this
on again and you get your passport prompt
again and you type in your passport again
and the system boots.
And so everything is fine.
Software is bad with writing
software. This is unsurprising.
This happens. How many of you have never
seen a Colonel Panicker Boot?
Awesome, nobody put their hands up so
great, this seems
like something that might just happen
right now.
The problem is
how do you know what's actually printing
that?
You have no way at this point
of knowing that this passport is
legitimate.
Now, you do know.
That if the boot process has been
Ifti boot process has been tampered with,
that the TPM
will not release the secret, so the
passphrase on its own is useless.
But you still don't know that that's a
real possibility, that someone could
have infected your system
with some code that modified your boot
process and then put up a fake
passport print.
Waited for you to type in a password,
saved that password
somewhere.
Printed a fake kernel panic
and then uninstalled itself,
you reboot and now everything works
correctly because your boot process is
not trustworthy.
The problem is there's now a copy of your
passphrase somewhere on your system
that's an attacker can get hold of.
And now they walk in, steal your laptop.
They have your secret and they have
your passphrase.
So this is not
ideal.
The problem here is that you're still
typing in a secret before you
know that the system is trustworthy.
Now, the idea here is the evil major
tank is one where, say, your
laptop is in a hotel room and
an adversary enters your hotel room while
you're out, tampers with your system and
then leaves your system has now
transitioned from being trustworthy to
not being trustworthy.
And the evil made was a
technology developed by you and the
Rakowski, the invisible things
that was intended to make
it.
Less practical for this, rather
than just blindly typing in a secret,
you would instead have a mechanism
by which the system would prove to you
that it was trustworthy in advance.
And this time, rather than just
encrypting a disk encryption
secret, you encrypt a
phrase that's only known to the user.
So when you install and even
made you type in a secret
phrase that nobody should be able to
guess.
That's then encrypted with the TPM and
again sealed with the specific set of
PCR values.
So.
System, Boutte's.
And then if
the system's in a trustworthy state.
That secret can be decrypted
and then printed.
And if you see that phrase, then you know
that your systems in a trustworthy state,
if you don't see that phrase, then
you should not consider the system
trustworthy and you should not type
anything into it as
a couple of problems with this.
And the first is that if it's always
Princip's, if you have this as part of
your normal boot process, then someone
can just walk up, reboot your
system, read the freeze off the screen,
and then install some malware
that prints the same phrase, even if your
system's not in a trustworthy state.
So there's a way around that, which is
that rather than having the secret stored
on the system.
You stole the secrets on a USB stick,
and then when you boot the system with
the USB stick, then the secret can be
decrypted and printed, but that
relies on the user.
Carrying around a USB stick, it relies
on the user having the discipline
to always boot with the USB stick if
there's a risk that that system's been
tampered with.
And so you could potentially end up in
a situation where a user forgets to do
this and
then that system has been compromised.
So exposing a static
secret is a little bit
suboptimal.
Ideally, we would not have a static
secrets, we would think of some sort of
dynamic exposure, something
that.
Changes over time, something
where nearly having possession
of a single instance of the
secret being presented does not allow
you to present the correct secrets in
future once a shared secret
with some sort of dynamic component
and.
I would really hope that all of you
are already using something along
these lines, if you're not,
you should feel bad and then you should
go into Nieblas immediately, because
this is basically the design
goal of top
the protocol
that's used for the majority of
Two-Factor authentication.
You have a secret when you're looking
into a website.
When you are unable to hefe, the website
generates the secrets and stores it, and
the website typically prints
a QR code and
you enroll that QR codes on your phone
and now your phone also has a copy of The
Secret.
But the authentication that you present
is based not just on that secret, but
also on the current time.
So
there's a algorithm
by which you take the secret at the time
and then you generate a six digit number.
You present that six digit number to the
website.
The website then verifies
that that's the great number
because the website also knows the
secrets. And with luck, the website
also knows the time of day.
That's pretty much a problem.
And this is nice because it's very easily
available, you can get lots of Two-Factor
authentication that you can get free
software, Two-Factor authentication apps,
you can run free software authentication
apps on free software operating systems.
You can even run them on free software
operating systems that run on top of
basically free firmware.
So that's nice.
Users have been trained to understand
this kind of thing fairly well.
Lots of people use Two-Factor
authentication and somehow the world
hasn't ended.
So we can probably assume that users are
reasonably familiar with the idea that
you have this magic six digit number,
even if they don't understand the
technology behind it.
So what we can do is.
SEAL the top secrets
to the TPM.
Print a QR code that then allows
the user to share the secrets between
their laptop and, say, their phone
and then on Bhoot.
We print a six digit number.
And then the user checks their phone
and checks, whether it's the same six
digit number and if
the two numbers match, then
the system is trustworthy.
Or, you know, there's a one in a million
chance that the system was compromised
and you just happen to get the right
secrets if you use longer numbers, if you
want to give a
quick demo of this.
As you can see, I have a
wonderful source
control.
So simply run
the application,
this case, I'm running this route because
this version of it talked to the TPM
directly through the external interface
rather than using the TPM daemon.
And then, well, escargots
isn't Nancy wonderful?
So if I make that a bit smaller, anybody
with a phone in the audience can now
steal a copy of The Secret to anybody
watching it on.
So I'm then going to,
you know, not actually use
this secret for anything important.
Because I'm not an idiot.
And then if I run.
OK, I guess a six digit number.
And if I had enrolled that QR
codes on my phone and looked at it
now, it would show the same six digit
number.
I'll leave it up to the audience to
verify whether this is the case
afterwards, I just
as a reminder, if you're attempting
to do this while watching the video
later, it won't work because
time has passed.
And that's kind of the point.
So back to this, so
a couple of problems with this, and the
first is that the secret
exists in RAM.
The TPM itself cannot do the top
generation. And so we have to allow
the TPM to decrypt the secrets
and then release the secret into RAM.
And that means that anybody who's able
to access the contents of RAM
is able to access the secret.
Now, if they've compromised the boot
process, this isn't a problem because the
TPM will refuse to release the secrets,
but they're a memory based attacks that
you can perform even if
the system's in a trusted state,
like if you have any externally
accessible DMA capable busses
like Express Cards or Thunderbolt,
you can just DMA the secret
out of RAM.
So you really want the economy
to be enabled. Unfortunately, many free
operating systems still disable the
Ioannina by default, even if the hardware
supports it because we're bad
at software.
Also, intel bad at
GPU design, but that's another story.
So we can think about alternatives,
and one option is that TPM
keys themselves when we generate a TPM
key, we can ask the TPM
to restrict that key to specific
PCR state.
That is, the TPM will not
be able.
Well, sorry, will refuse to perform
any encryption, decryption
or signing operations with that key
unless the PCR state matches
so we could generate a key.
We can see all that to the 2pm
and then we can ask the 2pm to
sign the current time of day.
And the team can then
provide that signed object to us
in some way, like maybe printing another
QR code and then you can verify that
the signature matches.
So we may, for instance, enroll, have an
application where we enroll the public
key on your phone,
have the TPM
sign the time, print
QR code.
You scan that QR code with this
application. The application then
verifies that the QR code is.
Signs correctly remains that requires
us to write new software.
I really dislike writing software, so
it's unfortunate that I have to do that
for a living.
It's less familiar to users.
And one of the big problems with
security is making things as easy
for the users as possible, asking them to
do something new and different and
exciting every time they boot.
That system is not ideal.
So is there anything else we can do?
And we could generate a key
outside the TPM.
We could then impulses into the TPM.
So it's now under control.
Rather than signing the final day, week
is encrypt the time of day, hash it and
then extract six digits and print them.
Now this is very like Togepi,
but it's incompatible.
You could then, so you'd still need a
different application on the phone.
But in this case the behavior would be
very similar.
It would be probably easier to train
users. The downside to this is that
the in order to verify this, because
we're doing encryption, the phone
also needs a copy of the same private
key, which is why we have to generate the
key outside the TPM rather than in the
TPM.
And the problem with encrypt
generating key outside TPM and then
imposing it into the TPM is that
due to some unfortunate design decisions,
any key that's been imported into a TPM
can then be exposed from the TPM.
So.
Anybody could then ask the
TPM to just release a copy
of this key.
So if anybody is able to get hold of your
system and excuse electrico, they could
then just extract that private key
from the TPM and then they'd be able
to fake things at a later point.
And maybe where overcomplicating things
little, maybe there's benefits in
additional simplicity, because
apparently simplicity is a virtue.
Something that is repeatedly stated
by operating system authors and
apparently they don't understand either
the word simplicity or virtue.
Times have a bunch of weapons.
This is nice, you can attach interesting
bits of hardware to your TPM.
Now, it's not immediately obvious why
you want to do that, because you can't
use arbitrary code on the CPM, but
access to the pins can be
restricted based on the PC
state.
You can set things up such
that you can only write to the
GPO if.
The PCR state is correct.
So you, for instance, attach
a small led to the pin
and then at boot, the operating system
attempts to rights to that led, if
the PCR values are correct, it can do so.
The lead turns on and your systems in a
good state.
So. Right.
This seems pretty awesome.
We can just and this is a very easy
modifications. Make the laptops.
We just need an extra led that's tied
to line on.
The mother was so cool.
Turns out that is quite easy to just
attach things to LEDs to
make them turn on.
So the hardware that you would require
in order to attack this is not
particularly complicated.
Yes. So it's kind of a nice idea,
but it's not ideal.
Nothing is.
We've been thinking about.
Using the screen or using an
LED for communication.
We could instead
use some other interface and
example of that is NFC,
so you could, for instance.
Basically perform remotes, attestation
over NFC, your
system boots to a certain point, and
then some sort of prompt appears,
you walk along, you tap
a physical object you have in your
possession against the machine
and then.
Communications performed, the TPM
produces some sorts of
signs, material passes that
to the device, the device verifies that
this is correct.
Some of the nice things about this is
that.
You can now also move away from things
like having a passphrase, you can have a
secret that's embedded in the physical
device, and if you don't
tap the physical device against the
system, that secret is not provided.
And so the system refuses to boot.
Another nice features about this approach
is that you can't
just ignore the prompt.
If I get a six digit number on the
screen, then I can still
just skip verification and go ahead
and type in my secret.
In this case, if I if
I always have to tap my phone
or something else against the laptop,
and if that does not automatically
result in the system, then booting
completely.
There's no
way for me to forget to do this if I
don't do this. The system doesn't boot
and this means that you can engrain.
Appropriate behavior into your uses?
It's much easier to train users if
there's no way they can get it wrong.
I have previously worked as a sysadmin,
so this is, unfortunately,
personal experience.
And.
Problem here is, well,
you're still.
Limited in terms of hardware, supports
the majority of laptops, don't have
any NFC capability.
And even the majority of phones don't
have any NFC capability,
but where you do have this hardware, this
is a potentially interesting avenue to
explore. And when I say it's an
interesting avenue to explore, I mean, it
would be very nice if someone else would
write the code to support this.
It's my usual approach to trying to get
new software.
However, even with all of these things,
we're still vulnerable to certain kinds
of attack.
Now, previously, I mentioned DNA
capable devices and.
If you have no Ayumu,
if you have no way to
prevent DMA based attacks,
just give up.
That's not going to work out well for
you.
Unfortunately, there is one device that
is always on your system and is always
capable of performing DNA, and that's the
management engine that's built into
all recent intel systems,
AMD will be shipping something
equivalent at some point, I'm sure.
So, you know,
in the 86 world, we're basically stuck
with this idea that there is a device
that can do arbitrary DNA.
And if it can do arbitrary DNA,
then even if your system
appears trustworthy until that point,
someone because of injected arbitrary
codes into the management engine at some
point. And that person
who injected those into the management
engine may work
for a three letter organization,
for instance.
And that's going to have the ability
to steal your secrets, or even
if it doesn't steal your secrets, it can
just compromise your operating system
after it's booted off.
You thought you were in a completely
trustworthy state.
There's no good answer
to this at the moment.
This is a problem in a variety of ways.
It's a problem in terms of us having a
trustworthy firm, where it's a problem in
terms of us having a trustworthy
operating system.
We do not know.
For sure how tightly controlled
access to the management engine is,
we do not know how
secure it the management engine is, how
competent the developers were,
all we have is Intel's assertion
that the management engine is written by
top men.
Having seen.
Various bits of code that Intel have
reduced over the years, I would not want
to state that Intel
are always good at writing software.
And obviously, you can attack the TPM
itself.
CPMs are not intended
to be tamper resistance, the
specification explicitly leaves
any kind of Tempah stuff up to either
the platform specification or
for individual vendors to compete
over.
And yeah,
this is not ideal.
A lot of them define
tamper evidence and
8pm is tamper evident.
If if someone tampers with it, you can
see that.
And a lot of vendors interpret this as
well. Look at the motherboard.
Is the TPM still there?
If so, it hasn't been tampered with.
Which is not ideal, TVs
are not intended to be particularly
resistant to attacks, it's almost
certainly the case that if someone
did capture 2pm, they're going to be able
to read the data
out of it.
This is something that governments would
certainly be able to do.
It's something that a sufficiently
skilled amateur would probably be able to
do for not that much money or time.
So that's not really
ideal.
It's OK, though. We have a good solution
to this intel have come up with the idea
that rather than having a physical 2pm on
the motherboard, you can have a software
team that runs on the management
engine.
Awesome and obviously
all of this also relies on you having a
2pm.
As of July
this year, all systems
with Windows 10 certification will be
required, all new systems keep windows
and certification will be required to
ship the TPM.
So that's nice.
Thanks, Microsoft, if
you've got an Apple.
Well, that's unfortunate.
If any of you are actually doing
any kind of confidential work on Apple's
Stop for the love of God, please,
please stop.
The absence of any kind of
plausible security on
Apple's is a disaster.
There's no secure boot.
There's no way to do a measured boot.
So you can't verify the trustworthiness
of the system later.
Even if you're using full disk
encryption, the password prompt could
be written by anything
it can then man in the middle, you store
your description, freeze, and then allow
anybody to have access to your system
later. Don't use Apple laptops
if you have anything.
You want to keep secrets in any way
whatsoever.
But obviously, if hardware isn't
trustworthy, we have no mechanism to
build trust of the sea if you can't be
trusted.
There's no way we can build a trustworthy
laptop if your hardware has been
designed by the manufacturer to be
untrustworthy, you can't do anything
about that afterwards. The only real
improvement you can make there is
eventually to have more control over the
entire process.
And that's still going to be cases where
even if we have fully.
Opensource CPU's, if
we have the ability to verify the status
of every transistor in the design and
ensure that the system is completely
trustworthy, when it was Fab's,
it could still have has a back door
introduced. Solving this is a very,
very difficult problem.
And I'm going to say that
I have no idea how to solve it.
But incremental improvements in security
are still improvements in security.
We can't just sit there
and say we can't solve the really hard
problems, so therefore we should ignore
every other problem.
We still need to do what
we can to make it easier for people
to verify that to the maximum
extent possible, that system is
trustworthy.
So.
There is some code available
for this to work for you to be able
to do trusted, but
you need a bootloader that does full TPM
measurements. I have a
set of patches to the shim first
Loeser that supports doing measurements.
I have some patches for grub that
also support doing measurements.
The combination of these means that you
can then have a completely measured
process up to the point where
the kernel starts.
So the energy is measured.
The Cardinals measured, grub's measured,
Chim's measured. Any module grubbed loads
are measured. I'm even measuring
the commands that you type into grubbed,
which is maybe overkill.
And then the code, as I demonstrated for
generating and encrypting the
top secrets and then decrypting
those, is available there as well.
Ideally, we would integrate these
into systems such that it's
very straightforward for users to
just enable this functionality.
There are some additional complexities
around this, which I'm happy to talk to
people about if they're interested, but
it's sufficiently subtle that it's
probably not worth it right now.
Anyway, we have about ten
minutes left, so if
we could go to some questions.
As always, if you have questions, please
line up at the mikes, there are three
mikes on each side and two
mikes on the top.
And also if you're on the stream, of
course, as always, go to the ISC
general, go on Twitter and people
will read out. Your questions for you
will actually start from the Internet,
please.
Thank you.
We had some discussion on the IOC
whether it would be possible to
use the NFC approach, but instead
replace it with, for
example, a QR code so
that the TPM presents some signed
material and a QR code.
The phone verifies the signatures produce
a six digit number.
You have to enter in your computer to
proceed with a secure about.
Yeah, I don't see any reason that that
wouldn't work.
Sure.
Yes, so you would need to ensure
that the application didn't just provide
a six digit number, but the application
also, Princesa, an indication as to
whether the cert verified
just. But, yeah, I don't see any reason
that that wouldn't work.
Microphone number eight, please.
Yes, thanks for the great talk.
I would like to know how, you know,
if you like, see the TPM stuff
to the configuration registers, like
with your bootloader signature and stuff.
How does this or does this even handle
updates?
That was the subtlety that I was
hoping to just conveniently allied.
Right now there
are a few ways of doing this.
So, for instance, you could pass
when you perform an update, when you know
that the measurement is going to change,
you could have a mechanism for passing
that information back to the bootloader.
The bootloader could then rather than
loading the kernel, and anybody
could instead just extend
the perform the same measurements.
But rather than booting the kernel, it
can then unseal the secret
reseal. It's the new values and then
reboot. And then that was
work. That means that you need to have a
secure communication channel between the
operating system and bootloader.
I think there's a couple of ways you
could potentially do that with EFI
authenticated variables.
But this is a thing where
the way that most existing
implementations get around this is that
when you do an update, the
secret is unsealed
and then say to the hard drive, you then
boot without verification
and then you receive it.
And that's not entirely ideal.
I think that maybe ends up encouraging
users to behave in a
reckless manner.
But, yeah, the
state of the arts here is mixed,
even proprietary operating systems
don't do a great job of it.
I think that that's something where we
could come up with something better, but
it's going to be some work figuring out
exactly how to integrate this with update
mechanisms. It's possible, but it's not
convenient.
Microphone number one, please.
I'm sorry if
you already answered this, I was late
to the talk, but have you ever looked at
the crummiest security design
and their use of TPIMs and secure
but I mean, they control the hardware
platform as well, so.
Right. So cheap.
And Chrome OS is.
Based in the states that the TPM is the
abuse of trust, and you then have
secrets for things like hard drive
encryption since the TPM, this is still.
This does ensure that if the system
is no longer trustworthy, that you do not
have access to your secrets, but it's
still vulnerable to the state where you
have a compromised system that then
presents a fake prompt
for you to type in your passphrase
or something and then reboots itself.
So.
Cruz gets a lot of the way there, but
it's still vulnerable to certain classes
of attack, the laptop
doesn't do a good job of proving to you
that it's in a trustworthy state.
It merely asserts that it is
OK. I'm not entirely sure if that will
work, but I'll think about it.
Microphone number two, please.
OK. I have two small questions.
The first one would be, why is the TPM
on the one, the water, not just
integrating the C.P.U to prevent
a while to just remove
it or something?
And the second,
wouldn't it be a very
simple
solution to just restart
a computer of the TPM
decides that isn't trustworthy and start
off well, doing a quick
code and or a
LED light or something.
So the first question.
The short answer is international
geopolitics, the
long answer is TPIMs
fall into the kinds of categories
of hardware that it's difficult to export
in certain countries.
If Intel integrated
teams into their hardware, Intel would
not be able to sell those CPU's in
certain countries.
Also.
Various people relying on teams do not
necessarily trust U.S.
manufacturers, teams are
pretty much all Penkin possible.
You can just swap them out.
If you look at the tables
for a Lenovo, you can actually see
that Lenovo supports on the same
system CPMs from four different
manufacturers.
And some of that's just for convenience
in terms of
choosing whoever is cheapest for a
particular production run.
But some of that is because certain
customers will want teams
from a certain manufacturer because
they trust that country.
Some of them will want
teams from a certain country because
they're legally required to.
In China, you're probably going to want
a Chinese TPM.
So things are a little more complicated
than you might imagine.
The upside of this is that if your CPU's
untrustworthy.
Someone would still need to compromise
your TPM as well, and if your
TPM comes from, say, Infineon,
if it's a German KPM and if you're CPU's
from Intel, you're going to
either need someone with compromised both
manufacturing in Germany and the U.S.
or you're going to have needed to have
screws up badly enough that both the NSA
and Germany are really upset that
you.
The second question, why can't people
just reboot the system?
The TPM has no mechanism to
operate on its own. The TPM just does not
have that ability.
It's impossible to do that with existing
hardware.
Signal angel, please.
Thank you.
Are there any operating system project
that would be happy to implement this
as their standard?
I don't see any reason why
any free software operating system
couldn't have this functionality added to
it. It's really just a matter of
people putting in the work.
I keep meaning to get round to it, but
I'm also incredibly lazy.
No one plays a
a tool, a tool
called the Evil Abigael was released
recently, that model that automates
modifying the unit to insert a back
door. I was wondering if you had
looked at that tool or had any comment on
it.
So that is basically
the kind of attack that this is intended
to protect against if the NSA is
modifieds than the measurements of the
NSA will change.
And so the secret won't be released.
So evil Abigael will just not work.
Thank you.
Number two, please.
Thanks to the
implementation of the idea, you mentioned
that one of the problems was you had to
pull the secret out of the TPM in order
to actually perform the operation.
But the algorithms,
it's like H.R. one or something like
that. Is the TPM capable of doing it
directly? No more
upsetting, but yeah, there's been a lot
easier in that case.
And to again, please, hello,
what prevents the following attack,
an attacker steals your laptop, creates
an identical copy where your laptop was,
and then when the laptop when
you put the fake laptop, it shows you
a secret and the attacker is
booting your legitimate laptop at the
same time communicating with the fake
laptop and showing that same secret.
OK, so basically the
system is compromised such that rather
than talking to the TPM
locally, it's talking to a remote TPM,
correct?
Oh
yeah, that sounds upsetting.
I make sure you put your laptop in the
Faraday cage.
Thank you.
I use lots of stickers on your laptop,
maybe microphone number
eight, please.
Are there any remote attestation
or hardware boot measurement features
available on NYNEX 86 systems?
CPMs are not fundamentally ties to
Eighty-six, there are certainly
systems in existence that have TPN base
functionality, in some cases a hardware
TPN, in some cases a software
team that's running in trust.
Truslow, which is again utterly
terrifying.
But
in that case, you can do exactly the same
operations in terms of whether
there are other implementations
based on completely different
technology, but basically solving the
same problem. None that I know of.
I'd say this if this is a problem you're
trying to solve, the easiest way to do
it is just to drop a among the system.
There is nothing specific about
them. You could quite happily have
a TPM attached to a MIPS if you wanted.
Thanks.
Internet, please.
Thank you. What is the difference between
your coat compared to secure gear up
to Miko's and
secure grub to so security?
Is that the one from the government
that the French organization?
OK, anyway,
that's
my recollection, is that other
implementations only support
TPIMs on Biosystems,
my implementation also adds support for
EFI.
So you can combine this with vesicular
boots and you can have verification
of the status of the nice things about
these your boots.
If plantation's this is that your
key database is hashed into
a PCR as well.
So you can verify in the same way that
nobody's tampered with the key database.
And if you're really.
This allows for some interesting
policies, like you can only
seal against the firmware
and the key database,
and then you can just assert that
secure boot resulted in everything
else being trustworthy.
All that makes updates simpler because
sign stuff just boots magically without
you having to interfere with this.
Anyway, yeah, I think that's the main
difference, and that's
it, please, once again, thank Matthew.