Thank you very much indeed.
So as you said, my name is James Bottenley.
I've been a long-time criminal developer.
It's because he subsists the maintainer, peer-risk architecture,
maintainer, done containers.
And now I'm doing whatliness calls my midlife provision,
which is TPMs.
And I also have done a lot of open source advocacy,
but I won't be talking to you anything about that,
because I did my main track talk yesterday about it.
This talk also is a talk I gave in Japan
and a slightly longer time frame.
So I'm going to try and whip through it.
If there's anything you don't understand,
I may leave time for questions,
but if you want to see me screw up with a live demo,
don't ask too many questions otherwise
we won't get to the demo.
So history and background is that TPMs,
you probably all heard of them by now,
because Microsoft is mandating them.
They're a discrete chip,
often, sometimes they can be in firmware,
but they sit on a system bus
and usually a laptop can be a server somewhere else.
They look a bit like that.
This is a TPM20,
you can actually see it's SLB9665,
which is an affinity on TPM.
So this is what little things look like.
As I said,
they can also be firmware based.
For my means,
they technically run on either your main CPU
or an adjacent processor to your CPU.
The way most AMD and Intel firmware TPMs
work is they actually run on a separate CPU
that runs the management engine.
So Intel firmware TPMs run on the management engines,
AMD firmware TPMs run on what's called
the security processor,
which is also an adjacent arm chip
that's built into the AMD core.
Threats of the TPM include things like
Man in the Middle or Interposer Attack.
So when we first started doing TPMs in Linux,
we were completely oblivious to all of this.
The standard assumption is the Linux kernel runs
on top of the hardware.
It can communicate directly over a hardware bus
to the TPM,
and because it's communicating directly over hardware bus,
just like a PCI card,
there's no need for any security,
so we didn't build any into the kernel.
And then if you fast forward several years,
a guy from Canada,
the Canadian Security Research Institute
came along and said,
you know,
with a very simple piece of hardware,
I can just plug into the bus that your TPM is on.
I can snoot all of the transactions
and worse than that,
I can actually modify those transactions.
And therefore,
if you route your security view laptop
in your TPM,
I can pretty much break any form of security you have.
And if you look at what's been happening for
security nowadays,
Microsoft really routes the TPM,
the security in the TPM,
and the system day in line up
are forcing us to route the security in the TPM as well,
with this system DTPM2 krypton role,
and so on.
So, the intoposer,
he built,
is of two types.
There's something called a passive intoposer,
which just sits on the bus
and it's the transaction.
So, if you're passing things like passwords
or disc keys in the clear,
it just quietly snoops them
off to your local foreign enforcement agency.
And then there's these things called active intoposer.
So, passive intoposer only listens,
but an active intoposer can actually
alter the transactions on the bus as well.
And this gives it the scope
to see what you're doing
for, say, you request the information,
take it off,
and substitute something of its own desire.
This allows it to do things like
intercept,
do do man in the middle of deception,
even of security PN transactions.
And I'll actually explain how that happens in a while.
So, TPM security depends on
something called sessions.
This is a fairly abstract concept,
but it's based on a shared session key
between the TPM and the user.
This is almost identical to the way things
like TLS work over the network.
You have a mechanism for generating a shared key
that's only known between the two parties
and then you communicate over
and encrypt a channel using that key.
The TPM is actually tries to be very clever about this.
It derives a rolling key
from what a call the H Mac keys
that were initially exchanged.
And then every transaction,
the TPM,
exchanges and norms,
and the keys for the next transaction
are based on those nonsense.
So, basically you use a different
symmetric key for every transaction.
This is somewhat similar.
Again, TLS does something like this,
but usually it has a time period
for rolling your security keys
of the encrypted channel.
So, TLS tends to roll the key every two minutes.
The TPM rolls them on every transaction.
And this is what makes it think it's really secure.
The problem, of course,
is that you need an initial shared secret
to actually start this encrypted channel.
So, the initial shared secret is called
the session key,
and in a TPM it's either bound,
which is a shared secret.
It means that, and nobody in the internet
works like this anymore.
If party A knows a secret,
party B knows a secret.
They can use that secret
to the driver shared key to communicate.
But usually,
party A and party B don't know a shared secret.
So, they have to actually come up
with a way of getting on.
So, the TPM also has a mechanism called
salted sessions,
which are basically where you manage
to encrypt a secret
and send it from one party to the other.
So, when we add a TPM security to Linux
in the face of all these interpersonal attacks,
we actually included support for salted sessions
because there's no way
that a newly booted kernel
has a shared secret
that it shares with the TPM and nobody else knows.
So, the only way of communicating
securely with the TPM
was for the kernel to make up a secret
encrypted to a key in the TPM
and then send it in,
which is how salted session work.
But there are significance,
and I have to say that the kernel
isn't unique in doing this.
Pretty much everybody who uses a TPM
in a kernel-like system
or a boot-like system.
So, Microsoft BitLocker
works exactly like this as well.
So, it wasn't just us.
So, the first question with salted sessions
is, where do you get the public key to encrypt the salty?
Well, it turns out,
the TPM has a load of public keys
and it derives several in hierarchies,
which I'll talk about later,
and you can simply ask the TPM,
and it tells you what its public key is,
you encrypt the salt for the public key
and send it to TPM, you're done.
All TSSs, which are trusted secure stacks
that run TPMs, currently do this.
What's the problem with this
in an active and deposit situation?
You have asked the TPM for a public key,
it's given you one back,
and you encrypt it your salt for that public key.
An active and deposit can say,
hey, he's just asked for a key.
Take the transaction off the bus
and go, here's a duplicate key.
I've just substituted that is,
one, I have the private key to
and that can therefore decrypt,
and that means that the active and deposit
can actually work as a man and the middle
for all of these transactions.
And therefore, it supplies its own public key.
It can now decrypt the encrypted secret
that you are using to protect all of your sessions.
And this means it can decrypt the salt,
decrypt every session, all it has to do
is keep track of the rolling nonsense.
The fact that you use a different key for every session
doesn't matter because it has the master secret
that allows it to deduce what the next key will be.
So pretty much, in this situation,
all security is gone.
This is a bit of a disaster,
especially as most trusted secure stacks
don't ever make clear to any program
that is written to use a TPM
that they've actually done something
as stupid as just asking the TPM for public key.
And none of the trusted secure stacks
that are currently sitting in the world today
and there are several of them.
The windows one, there's the Intel one,
there's the IBM one.
None of them actually provides you
with an easy method of verifying the key
that you've got.
So we also have other problems
when we begin to pose that.
Because it sits often
on the same bus as the TPM,
it has access to a lot of other bus lines
as well as just the data lines.
So it's snooping the data by looking at the data lines.
But it has access to the bus reset lines as well.
And part of the problem is that TPM policies,
you've probably, if you've gone to one
of Linux talks about how you use TPM's
of system D, you'll have heard them
talk about these things called PCRs,
platform control registers,
which are effectively registers
that can be wound forwards,
but never backwards.
So you're building up an immutable
list of transactions that goes on in these PCRs.
And the key assumption of these PCRs
is they can never be reset.
They can never go back to zero,
and you can never rebuild them again.
So you can extend them by building on top of them.
It's a cryptographic extension,
but you can't reset them and start building again
unless you reset the entire machine.
This is the fundamental assumption of how PCRs work.
Unfortunately, if you've got access to the reset line
on the bus and you toggle the TPM's reset,
all of these PCRs will go back to zero.
And unfortunately, that means that if your security
and system D security does,
depend on the fact that you can't reset the PCRs,
a clever intaposer working in concert
with an adversary at the keyboard of this machine
can actually do that.
And therefore, they can rebuild the PCRs
to any state that you've locked any piece of information
in the system too, which means that
often when you set up system D,
crypt and roll, you actually enroll certain PCRs
that tell you it's secure booted
and it boots exactly this kernel,
and therefore, you just unlock the disk
without asking for a password.
And therefore, that means that I can reset your PCRs
rebuild them to exactly the same state
this unlock will occur,
and I will get access to your password
because I now have the PCRs in the correct state.
So, how do you actually establish trust
in any old key that the TPM has?
The fundamental problem that trusted secure stacks
don't solve for you.
A long time ago, and currently today,
TPM ship with a manufacturer
a science certificate that actually validates
something called the endorsement key.
But the key it actually certifies
can't be used to certify any other TPM objects.
This is really annoying.
TPMs actually generate what are called primary keys
in these things called seats.
This is TPM 202 has something called agile cryptography,
which means that any old TPM can do RSA,
can do elliptic curve for several curves and so on.
There's talk of actually adding
some of the cyber algorithms to make them post quantum.
But the point is that in order to have agile cryptography,
it doesn't quite, a TPM never knows
what key you're going to be requesting,
what algorithm you're going to be requesting.
So instead of having key stored in the TPM,
it has these things called seats,
and then it runs a key derivation function
on the seat based on the algorithm
to derive the actual key.
So usually TPMs don't actually come
pre-programmed with keys.
They come pre-programmed with a set of numbers
and they derive those keys from the number.
Now this sounds like it's all standard cryptography.
It's very easy.
There is a problem here,
and that TPMs are very,
very non-powerful systems.
They're tiny little microchips.
If you're asking for RSA keys,
part of the KDF,
the key derivation function,
involves finding prime numbers.
So it can actually take a TPM
enormously long time to find a prime number.
So if you're asking a TPM for an RSA
in 1948 key,
it can actually take it up to 60 seconds to generate that key.
And this sort of goes up exponentially
with the size of the keys that you're asking for.
Yep, question.
Yeah, the key derivation functions
are deterministic.
It will always generate the same key,
but the problem is the generate RSA keys.
You do need to guarantee a primeality,
which is why it has to do a prime number search.
It always finds the same prime number
but it still has to do the search.
So the point about that is always
use a lip to curve keys with TPMs
because they're much faster.
RSA keys are pretty terrible.
One of the properties that stored with these keys
is whether they're signing or encryption keys.
So all primary keys in a TPM
there are actually come in two different types
and there was mutually exclusive.
They can either be a signing key or they can be an encryption key
but they can't be both.
And the TPMs can only certify objects with signing keys.
And if you remember,
the TPM certificate is certifying an encryption key
or the signing key.
That's why the TPM certificate
can't be used certifying any other objects in the TPM.
The EK certificate,
like I said, was certifying an encryption key.
There is a, I mean, the industry is observed
that this is a bit of a problem
and why don't EK certificates just certify a signing key
and then everything would just work.
And this is history
because the trusted computing group
got badly burned by a backlash against TPMs,
led by none other than the Free Software Foundation,
who called it treacherous computing,
designed to track you, designed to do everything else.
And they got criticized the TPM as an agent
in your PC acting on behalf of another party.
And they claimed that all of these certificates
could be used to track you because if it's just a sign
certificate certifies a signing key,
the signing key is used certify all operations of the TPM.
All anybody who's tracking you has to do
is look at what he was used to sign
whatever attestation I wanted out of this laptop
and that uniquely identifies the laptop and the person.
So to counter this,
because of what the FSF has said,
the TCG tried to introduce privacy-preserving features
and TPM to O that would prevent all of these nasty people
in the world tracking you.
And not allowing manufacturers to ship
signing certificates was one of these measures.
If you only ship an encryption certificate,
there's no way that anybody can use that
to certify anything else, they have to use other means.
And then the TCG went on to elaborately come up with other means.
The other means is that what you need to do in your TPM
is create an ephemeral, what is called an attestation key.
Then each attestation key can be sent to a privacy-CA,
which is a party trusted by both you and the person
who's relying on whatever certification you're doing.
And the privacy-CA would then certify your attestation key.
It would give you back a little certificate that says,
either privacy-CA certify this attestation key
belongs to a genuine TPM.
And then the point is you can use this signing attestation key
to do the certification of pretty much anything
with TPM's supposed to be telling a relying party.
You send along the attestation certificate,
the relying party looks at it and says,
okay, I trust the privacy-CA, this must be a genuine TPM,
I believe you.
And the point about privacy-preserving is,
these attestation keys are ephemeral.
I can generate as many of them as I want.
I could generate one per transaction if I really wanted to.
So if I certify a couple of different things to the same CA,
it doesn't necessarily know I'm even the same laptop doing it.
That was supposed to be their solution.
And the, oh, let's skip the mechanisms,
because I'm running out of time.
There are several problems, so I was going to explain how it all works,
but you don't really need to know that.
The explanation I gave is sufficient.
First problem, although the privacy-CA is an ice idea,
none exists in nature today, so they can't be used physically.
We have no means of actually doing.
It means we have currently, if you look at anything that uses a TPM as a relying party,
is it acts as its own privacy-CA.
So that's just basically bust the veil of secrecy,
because anything you attest to and rely on also certifies the attestation keys.
It still does this attestation key thing,
but because the relying party and the privacy-CA are exactly the same body,
it always knows who you are and how many keys you've generated.
This is a bit of an oopsie, but it's because,
for us, no actual independent privacy-CA has ever been set up,
and the TPM needs these attestation keys for certifications.
Even if privacy-CA is did exist,
early boot can't use them,
because they exist on the internet, and we can't talk to the internet.
Oopsie, because most of the TPM problems are then to pose as a currently boot.
Oh dear.
Early boot also can't validate E.K. certificates,
because E.K. certificates don't have a central certificate authority.
Every manufacturer has a self-scient certificate that certifies their own E.K.
And, I mean, this is somewhat not true,
because there aren't an infinite number of TPM manufacturers in the world.
There are only about a handful.
I believe there are less than 10.
It's not impossible to embed less than 10 certificates into the kernel,
but it does mean that if another manufacturer arises in an old kernel,
it just wouldn't work, because we'd embedded the wrong set of certificates.
So, although we could theoretically use this,
it's just a dangerous thing to do.
And the other problem is that a lot of you in the room
will have firmware TPMs,
firmware TPMs don't come shipped with E.K. certificates anyway,
so you can't use this.
So, given all the issues,
we needed a new scheme to come to actually make TPM's work
securely with the kernel.
It's not enough just to secure the transactions,
which is the patch I got up into 6.10.
We also have to ensure that the key that I used to secure these transactions
is actually trustworthy and hasn't been intercepted by an entrepreneur.
So, the first thing I'd chose to do is to use the null primary session of solting.
So, here's some more TPM trivia.
The TPM has actually four separate hierarchies.
The endorsement hierarchy, or let's start with the platform hierarchy,
which is only accessible from BIOS, so you can forget about it.
The endorsement hierarchy, which is where the endorsement key lives.
This is the permanent identity hierarchy of the TPM.
The owner hierarchy, which can theoretically change
when you change the owner of your laptop.
So, if you sold your laptop on, what you should do is
wipe the owner hierarchy and it would generate a new key
and owner keys would do that.
And then the null hierarchy, which is normally not used.
The reason it's normally not used is because the null seed changes on every boot.
So, the master key of this hierarchy is different on every boot.
And usually if you're storing keys in a TPM,
they're all encrypted to the master key of the hierarchy under some algorithm.
And that means that any key you're encrypted to the null hierarchy
can only be used for the lifetime of the machine.
Once the machine reboots, the null hierarchy seed changes,
the key you derived can't be decoded anymore and it's shredded effectively.
But this is actually a useful property.
If you only want to key the last of the lifetime of the boot.
That's why we use the null seed in secure,
for securing transactions.
And an even more interesting property is because it changes on every reset.
The null hierarchy would be invalidated on a reset.
That means if I'm using it to secure transactions encrypted to the TPM,
and some interposables of reset, all of those transactions start failing
because I'm communicating on the wrong key because the null seed has changed.
This means we can actually detect whether we can detect a reset
and we can also protect all transactions against the reset as well.
You're shaking your head. What wasn't clear about that?
So what I'm assuming is that I've somehow certified the null key in whatever way
to make sure it's genuinely attached to the TPM.
So the thing I'm trying to protect against is somebody pulls the reset line.
I don't know about it, my PCRs in the real TPM or reset,
and they rebuild the values to what they want.
And the point about using the null seed, I've certified it,
so I know it belongs to the TPM, but once that TPM is reset,
it gets a different null key and I can send the communication to the TPM,
but it won't understand it.
So I will get an error back when I try and communicate on this null key.
That's the point.
So what we do is we save this null key once on boot,
and then we use it for solving every session.
Now, we still have the problem that the kernel can't certify this null key.
But if there's ever a reset, we'll know it immediately,
or at least not quite immediately.
We know it the next time we communicate with the TPM.
This is a somewhat of a problem because there is a gap between us,
the kernel communicating with the TPM,
and therefore finding out the TPM's been reset,
and somebody in user space who isn't the security conscious,
doesn't use the null seed and didn't notice.
But once we detect a reset attack,
we can immediately disable the TPM.
And what we do for trying to certify the TPM is,
we export the null primary name in a surface file.
And so if you have a way of certifying TPM keys,
you can certify this null key using that surface file.
This is what the kernel tells you it's using,
to impose a kernel defect this.
You can actually genuinely certify that.
Like I said, we export the name.
The name is simply the hash and public key,
so it gives a shortest, but unique ID for that public key.
And we verify this by more sophisticated means after boot,
meaning the kernel doesn't know it's safe when it booted.
But if you verify the key after boot,
and it verifies correctly,
that the kernel was not intercepted or trapped.
So every communication the kernel has done up to that point
with secure.
And you know this because you certify the key after the fact,
but the certification was valid for when the kernel first started.
Okay, so I developed a set of tools to try and make this easy,
and what I'll actually do is try and demo that.
So the main, it comes from something called the OpenSL TPM engine.
These links in my presentation are actually clickable.
It actually sits on get.kunnel.org if you want to actually download it.
But the tool you need is a test TPM2 primary.
What it can do is EK sign, which is export the name of the signing EK.
This is what, so in order to do signatures,
we're not going to bother with the privacy CA crap,
because it's your laptop, you know who you are.
You don't need to hide yourself from yourself.
We don't need privacy CA, so we'll just use the signing EK,
the thing that nobody was supposed to use for privacy reasons,
because the person that certifying to in the end of the laptop of the same person.
EK sign will derive the signing key and give you the name of it.
A test is a command you can use easily to verify that EK signing key directly
against the EK certificate.
What it actually does under the covers, it takes quite a while,
as it runs the full privacy CA protocol, verifies that that key is actually correct.
Once it's given you the anticipation that the EK signing key is correct,
you can actually then use that EK signing key forever,
because that key is derived from the EK seed, which never changes in the TPM.
And then there's a certify which allows you to use the signing EK that you've already deduced
to certify any other key in the system.
So let's see if we can actually do a demo.
I have six minutes, this is going to be tight.
Let's see.
So I'm going to start a software TPM.
There's a software TPM.
I am going to start my intaposer.
This is also available on get.com.org.
All it's doing is actually sitting listening.
I've got the TPM is communicating over the network.
The intaposer is listening at one network port and
snapping the transactions passing it to the other network port.
And then the virtual machine startup file is told to connect to the intaposer port.
So theoretically I know there's an intaposer there, but this is just the purpose of demonstration.
Then I'm going to start a virtual machine.
And this is actually a fully secure TPM.
It's actually system D using the TPM.
Actually, can I reduce the size of that a bit?
So you can see it's booted up.
Come on, I didn't hear.
It gives me a console and I can log into it.
So this is my system.
I'm actually using system D scripts and roll.
You notice that it didn't ask me for a password on bootup and that's because I've used the TPM key.
So the intaposer itself actually is activated.
It's been snooping.
It hasn't activated.
This is the problem of doing live demos, isn't it?
Yes.
I told it's contact the TPM directly.
So now we'll boot and the intaposer will stand between us and the booting system.
There it goes.
So the intaposer is actually seeing all the TPM transactions here.
It's not doing anything.
It's just quietly watching them.
The system still booted up still released the key.
So I can log in.
This software TPM has actually been programmed with a real TPM certificate.
All TPM certificates.
This is an RSS certificate.
So it sits in this NV index zero one C, zero zero zero zero two.
And I can just pull it out and I can show it to you.
So this is what it looks like.
The TPM I'm using is an IBM software TPM.
So actually my TPM certificate is self sign by IBM because they provide a nice little service for doing this.
But I would verify the certificate usually through the usual X509 means back to its route.
To verify that this is a proper TPM.
We'll see my done that.
I can extract that TPM.
To the EK certificate.
This is actually reading all the bytes in the index and then just putting them in.
I could actually if I read that back it's just a standard certificate.
It says exactly the same one that it told me it was.
And now I can use this to certify the key.
So the first thing I do is I get the EK.
And I'll put it into a little file called EKSign.name.
So all that file is it's hash of the first four digits actually identify the hash.
So HXB is actually shartif6 hash.
And then this is a shartif6 hash of the EK signing key.
And now I can use this to attest.
So what I'm going to do is I'm going to attest TPM2 primary using the EKS certificate and the EKS signing name.
And this should verify using the EKS certificate and that little privacy-ca thing that this is actually correct.
You can see it took, there was a slight pause there.
Even though I've got a software TPM which should be as fast as lightning.
It does take a while to do all of the transactions that are acquired by the privacy-ca.
But what this proves to me now is that the EKSigning name that I've got hold of is genuine and belongs to the TPM.
I think it does that is certified by the certificate.
I can identify the null name.
And this tells me now that the system is booted correctly and I don't have an intaposa that's actually intercepted any of these transactions.
So the TPM booted system booted securely without intaposa actually intercepting any of my transactions.
The reason it didn't even know I do have an intaposa is because the intaposa is told cleverly do not intercept any of these transactions otherwise it will be detected.
So the own transaction it can actually detect is system-descript and roll transactions.
So out of time.
Okay, so let's just do this quickly, sorry.
Give the key for the passphrase.
And I'll stop the demonstration here.
That is system-desview of the private key that was stored in the TPM.
And I've just extracted that.
If you want proof of this, do I have time for you one more?
Well, let's do it anyway, because it's fun.
That's the key I just got from the TPM.
This is, so that's where it tries to use this as a password for the TPM.
And it says I've successfully unlocked key slot one.
So I've correctly intercepted system-desviewed boot key.
And with that, I'll say thank you very much and I have no time for question here.
Thank you.