So, welcome again.
The next speaker is Leonard Pettering, known for SystemD, PostAudio, and other fundamental
projects.
And, yeah, he will talk about his journey and learnings of fusing TPMs and, yeah, how
that is working with four image-based Linux operating systems, measuring boots, and so
on.
Hi.
Yeah.
What he said.
So, I'm going to talk about image-based Linux and TPMs.
We don't have much time.
I think it's just 20 minutes, and it's a complex topic.
I already know right now that I'm not going to be able to finish, but, yeah, that's not
too bad.
I hope the slides should be online sooner or later, so, if we don't finish, it's not
too bad.
So, let's jump right in.
What's an image-based Linux?
I don't think I have to say too much about that, because Luca already gave an introduction
about this.
But, yeah, it's really about having a core file system images instead of fine-grained
images.
Many benefits.
I'm not going to go into detail.
Here, we'll focus simply on the relevance for building trusted systems.
These images, we now call DDIs.
Luca had that on the slides as well, which is like this coverable disk image.
It just means that there's a GPT partition table which describes what's on it and usually
has a variety and things like that.
The other thing in the title of my talk was a TPM.
Yeah, I hope some of you have a rough idea what a TPM is.
It's a security chip.
Traditionally, it's a discrete one, but nowadays, it can also be in firmware or even in software.
It's a cryptographic scope processor in a way, and usually, people then think, oh, it
must be something fast, but it's usually not.
It's just, it's actually terribly slow, usually, but it's not what it's supposed to
be.
It's standardized, widely available, all your laptops, and particularly, like, the business
laptops usually have it as a discrete chip, the cheaper ones nowadays have it in firmware.
It's pretty universal.
Conceptually, similar to smart cards and fighter keys, right, like it's a storage for keys,
but it's also very different.
Supposedly, temp-approved, it can store at least one key securely, actually, more than
this, but yes, the primary purpose is like, there's a seed key stored on it, and then
everything else can be derived from this.
That key cannot be extracted, that's the fun part about it, so ideally, you have to have
that specific chip, or if you don't have that chip, then, yeah, you can't retrieve the keys.
You can do lots of things with these things.
Most interesting, I think, is one that you can ask the TPM to encrypt and decrypt data.
Ultimately, it was that seed key that stored on it.
That basically means, while you don't have that much storage on the TPM, you can see
me store as many keys as you want with the TPM simply by wrapping that key, as they say,
by taking any secret key you have, passing it to the TPM so that it encrypts it with
its own built-in seed key, or some key derived of that, and then you get it back and stored
on disk, and so you basically have infinite ways how to bind keys to the TPM.
What's fun about this part is that this encryption can involve policy.
Policy basically means that you can make restrictions about how the key can be decrypted.
For example, you can require that also a pin is provided, like a human-typed pin.
Pin just means password, by the way, it doesn't mean it has to be a number.
It can also imply that system has to be in a specific state for the key to be decrypted.
State means, for example, that specific software firmware bootloader runs, that the system
is in a specific boot phase, that the specific disk encryption volume key has been used
and things like that.
That's why a concept called PCR is more about that.
It's probably mostly we're going to actually talk about that part.
It can also mean you can bind policy to time, like so that it can specify time when a key
can be decrypted and prohibited otherwise.
It's actually a useful feature.
It sounds crazy, but it's actually pretty useful, and hopefully we can quickly talk
about that later.
The prior slide, that's just the TPM stuff that I find interesting that we're going
to touch in this talk, but there's a lot more about it.
It has an RNG, you can actually do store stuff there, dictionary, tag protection, like millions
of things you cannot just encrypt, you can sign, I don't know.
I'm not going to go into detail with that, only 20 minutes.
These PCR policies, I want to go into detail.
It's the most interesting type of access policy, and most people who deal with TPMs,
I think, have encrypted their hard disk and linked it to the TPM, usually just played
around with the PCR policies.
That's something.
PCR is short for platform configuration registers.
They're basically just registers, like little data variables on the chip.
Usually you have 24 of those.
Initially they boot up as zero.
You cannot set them to anything you like.
The only thing you can do is you can pass some data to the PCR, and then it's going to execute
this.
You can update the PCR with the number N, like you have 24, like that's zero to 23, and we'll
calculate a hash value of the old value plus concatenate it with the new data.
I said that it's chart 256 because it's effectively what people use these days, but it actually
can't be anything.
But that's the only operation it does.
That basically means if you pass data and later data and later data, it's going to come
up with a value, and this value is derived from all the data you pass to it.
This is a way of how we can implement a chain of trust.
This operation where you send the data to the PCR is called extension of the PCR, or
you can also say the measurement of the data, depending which way you look.
How are these PCRs used on most of the laptops that you have?
The firm will already start writing data to it.
What data does it actually write to it?
Basically all the code it executes right before it executes it, and also all the configuration
for that code right before it makes use of this.
Afterwards, the PCRs have a specific value, and this value you can then use to prove that
the system went through certain stages, because every part of the system always measures the
next thing so that if every element in the chain originally was trusted, then it will
pass on the trust and so on and so on, and nobody can change the past, but only the future,
and that's how you implement a chain of trust for the formatted boot.
The other good thing is that if you know the elements of that chain that you're going to
measure in advance, you can pre-calculate PCR values.
You can basically say offline, okay I'm using this firmware, this boot loader and this kernel.
I can tell you what the PCR is going to look like ahead of time, because I can actually
calculate this hash operation myself in a very, very trivial way.
You can pre-calculate PCR values.
This is awesome, because if you can pre-calculate the PCR values, and these PCR values can be
used in policy and secrets on keys that you encrypt with CTPM, then you basically can
say with that that keys can only be decrypted if the system booted up with software that
I actually trust, and that's what is kind of useful about PCRs.
You can do even other stuff with that, but this is like the key takeaway.
If we can bind the decryption of secrets by the TPM to the state of these PCR values,
we can protect the secrets so that only on very specific systems running specific software,
running specific configuration, these secrets can be recovered.
This is, yeah, for disk encryption that's a primary use case.
Image-based OSes have this benefit that they can be measured as a whole.
If you have the entire OS in an image, it's very easy to calculate the hash value of it,
and then it's very easy if you take that hash value and pass it to the TPM to know in advance
what the PCR is going to be at the end when the system is fully booted up.
This is systematically different if you have a package-based OS, right, and package-based
OS where locally you create a file system, locally you unpack all these packages, and
sometimes you update them at this time, and sometimes you update them in another time.
Image-based OSes, you would end up as a file system that is going to be widely different
from everybody else who installs the same OS, right?
Image-based OSes don't have this vulnerability because their cores, their updates as a whole,
you can do these precalculations, and they're going to have the same hash values in every
single system, and hence the same PCR values in every single system.
Yeah, what's also great is it's not just about hash values in the PCRs that eventually
will show up because that sucks a little bit because it basically means that if you have
a secret that you bind to a specific hash value and then you update the image that you
ultimately calculated this from, then all these hash values will change.
That sucks because it basically means that you can't update your software anymore because
if you do, you lose access to all your secrets.
Nonetheless, this is what Windows actually does, but we can do better and actually assign
these things because if we can precalculate them, right, we know that this OS version
is going to end up with these PCR values, then we can actually sign them on like the
vendor can do this and provide the user both with the OS itself, plus information about
what's the expected PCR is, plus the signature for it, then you can actually use a TPM and
link secrets instead to the hash values can link them to the public key that belongs to
the signature that you will get.
This is awesome because it basically means that you can update as many as you want, you
will not lose access to your secrets.
Now I'm going to talk about system D because I'm the system D guy.
Quick overview about all the TPM stuff we now have in the most current system D version,
like it actually covers the unreleased version that's coming up 253.
But yeah, system D stuff, it's a stuff that, like a UFI stuff that you can glue in front
of a kernel and it does measurements of the kernel that's about the boot, it does lots
of other things, but this is, yeah, for this context about TPMs, this is what I find interesting
about it.
It still runs in UFI mode before Linux is invoked and then passes control to Linux.
There's a service system called system D PCR phase, what that does, it measures certain
strings at specific times of the boot into a specific PCR.
What's the purpose of this?
Sometimes, or I guess always, it's kind of useful that, for example, the encryption key
for the root volume can only be an unlock in the iterative, but not after.
And that's an awesome property because it basically means that when somebody exploits
your system after the root file system is actually activated, then they can't talk to
the TPM to get the password back because basically these phases stuff can destroy the PCRs and
because the PCRs that are used for the policy, yeah, the key is inaccessible until a reboot
is done and we end up in an iterative again.
The system D PCR FS, what that measures is like FS identity, like file system identity,
that's UUIDs of a file system, things like that, the thinking about that is that there
should be PCR where you can basically say, okay, that identifies a specific installation
that I have, do we use PCR-15 for this?
So basically, that you can guarantee, yeah, my laptop is going to have that value there,
another laptop is definitely going to have a different one.
So it's about being able to bind policy to specific installations.
There's a system PCR machine that measures etsy-machinity, etsy-machinity is just a explicit
system ID that we introduced a while back.
System re-crypt setup is now something that can consume all this stuff that I was talking
about there.
These things measure, this one then actually is able to unlock disk secrets based on these
PCR policies.
There's something, yeah, the crypt setup is actually not just about making use of the
PCR policies, it also measures a hash derived from the volume key of the root file system,
for example, or actually you can measure any volume key with that.
So the idea is basically that the secret is also measured to DPM and that this gives a
much stronger protection of the PCR-15 stuff that I was talking about.
In future we probably also add something similar to system de-varity so that basically, yeah,
you can very protect file systems and have the top level hash measured.
Crypt setup can consume this, then there's also system de-crets in the service manager,
that's the concept we recently learned, system de-crets is basically how you can pass secrets
into services and they can be encrypted via TPM stuff and things like that.
So it's kind of useful that you basically can say, I want my X509 secret key encrypted
in a way that it can only be unlocked on my specific server running my specific OS during
the inner dirty boot phase but not later or something like this.
We measure as a tool that can pre-calculate expected PCR values for UKIs, UKIs, unified
kernel images, we had talked about that before, so I'm not going to explain that, can also
sign them so that you can basically have a UKI that carries both like the signature
along with it so that then later people can just make use of this to unlock their volumes.
There's recently added tool, UKi-fi, UKi-fi, I don't know how we're supposed to pronounce
that yet, but anyway, it builds on system measuring a couple of other tools and you
give it just a component that builds the UKI stuff, signs it with secure boot, signs it
with the system you measure and then you have this one blob that you can ultimately deploy.
The net result of this is three relevant PCRs, in 11 we're going to measure the kernel and
the root file system into, in PCR 12 there's going to be basically the configuration you
pass to the kernel, that's primarily kernel parameters and things like that, but it's
also more is like, we have this credentials concept that I mentioned is going to measure
it into that if they are passed into the system and we'll have soon something called
SysCVG, which is like a secure way how you can manage Etsy stuff, it's also going to
be measured into that.
And then PCR 15 I mentioned is kind of the identity of the local system.
So yeah, and then you can consume this, and I mentioned this already with system decryptin
roll, where you can basically say, now this disk can only be unlocked on a system that
has physical access to this very TPM, so to hardware, that can only be locked if it's
booted with properly signed OS UKIs and DDIs by a specific random, so I can say, I install
Fedora here and this secret key shell, only be unlocked ever if it's actually Fedora that
is booted, but not if Hacker OS or something is booted.
I can say, it will link it to the configuration, I can say that secrets can only be available
during a specific boot phase, for example in the NRAD but not later, so that you know
that if you leave your booted up laptop somewhere in your hotel room or something like that,
and you're not supervising it, that at least they'll not be able to get your root volume
encryption key via directly talking to TPM.
You can also add a PIN, you can do rate limiting and things like that, so that like this is
dictionary attack protection, so that people cannot just go and hammer the TPM trying a
couple of things, trying a couple of PINs or something like that, because the TPM eventually
says no, you have to wait or something, or you have to provide an unlocked PIN.
I'm good at time actually, so far so good, PCRs are really useful stuff and you're probably
going to extend users them all across the system before other things.
They have other uses like remote attestation, like you can use them to basically remotely
say, like verify that a system in a specific state.
People usually use that for servers and stuff, so that if you have a cloud and you have lots
of notes, that before you give a workload to a specific survey, you can verify that
it's still running exactly the software that it should be and nobody hacked with it and
booted something else and things like that.
It's also useful actually, yeah, back to the hotel situation, I leave my hotel, in my laptop
in the hotel, I come back and I can use the remote attestation so that this device can
prove to me that it's actually my device, running my software as I intended and not something
else.
So, yeah, configuration and images I already mentioned, credentials I already mentioned
briefly.
Yeah.
Last thing, second boot and measured boot, people shouldn't confuse, measured boot is
what I was just talking about with all the measurement, like this chain of PCRs and things
like that.
There's also second boot in UFI, usually you do both, but they have different purposes,
right?
Like one is ahead of time stuff where it doesn't even allow software to boot that isn't signed
properly.
The measured boot is different, like the software can all run, but it will not get access to
secrets if it's the wrong software.
Anyway, we don't have much time anymore.
I would like to take at least some questions, so let's do that.
Hello.
So, all these measurements, are they going to be in TPM event log for SIMD2 where I can
debug that stuff?
Yeah, that's a good question.
So, yeah, the, like, we currently mention this in the login framework, like the regular,
like syslog and third journal.
We do not write a TPM event log.
I know that there's a specification for actually writing a TPM event log.
We totally should.
But I didn't want to implement this TCG spec for that yet, and I didn't find a good library
doing this that I wanted to use.
But ultimately, like for the remote attestation case, we absolutely need this.
Eventually, I want to get to this world where we can, like before we run any service, any
container or any VM or something, we can measure ahead of time what we do and we write
that result to that event log and then people can consume the event log.
So, I think system we should write that.
Yeah.
I mean, I'm not a direct fan of the former two, but if you implement that stuff, we have
now three event logs.
We have the UFO one, we have the IMA one, and then now we have the system D1, so it's kind
of, it's a kernel thing that actually the kernel should provide, I think, at least.
Well, I mean, it can grow indefinitely, and I'm not sure you want the kernel to write
stuff indefinitely.
I don't know.
I'm amazed that.
If you care about these things, like, I don't think we should come up with our own standard
for this, so I kind of, if we write anything, it probably should be the TCG one, but I
don't know.
I didn't look into details like rotation or whatever else.
Anyway.
Okay.
Thanks.
So, right at the moment, system D krypton roll has a least privilege problem in that
whenever you're handling cryptographic materials, you should always expose them to the least
number of subsystems.
And the problem is that system D krypton roll is unwrapping the TPM key and then passing
the unwrapped key down into the kernel.
But the kernel itself has a system for handling the unwrapping of TPM keys, so what we should
be doing is passing the TPM key straight into the kernel and allowing the kernel to unwrap
it.
Are there any plans to actually implement that?
I didn't know this existed.
So I don't know, is it documented anywhere?
Yeah, it's called the trusted key subsystem.
Yeah, I mean, yeah, so far we don't really make much use of the key rings thing because
of complex beast, but if it exists, I see no reason why we wouldn't use it.
Okay, thanks.
I have a talk on that tomorrow on trusted keys if you are interested.
My question is about something else, do you know about systems where the TPM2 communication
is encrypted and authenticated to avoid someone desoldering the TPM and messing with it?
We do parameter encryption, and originally it was just bound to the PIN and in the recent
versions there's some salting going on, but I think we are like, you know, the good thing
is that nowadays even the TPM2S maintainers themselves send us all the patches to fix
these things.
So I think we're pretty, like, at least we're way better than what Windows currently does
and we keep on improving.
Hi, how to integrate this into a grub boot process?
So you always need, so as far as I know, see, you always need an initial run file system
to set up or to process all these TPM functionality and then initializing a looks key store and
then switch root into the root file system.
So is there a better way?
You're asking me if grub is a better way for anything?
You're asking the wrong guy, I think grub, yeah, I'm not going to say bad things, but
you know, we have this other bootloader like a system, I mean it's not a bootloader, it's
just a boot menu, but SD boot, and I'm not a fan of grub in these things, and I systematically
think it's really, really stupid to do disk encryption in grub because it's not what you
want there, you want authentication, not encryption, and so, I don't know, it's, like, to build
a trusted boot chain, I'm not convinced that grub should be part of the solution, it should
just like, you know, an EFI systems at least if you sac your boot and things like that,
you have all the buildings block that you need, you don't need another way of protecting
things.
I know that many distributions, if they want to, like, because they use unencrypted, like,
they want to use encrypted slash boot, which I think is stupid, but if they do this, then
yeah, of course, you need to add a disk encryption support to grub, but I think the problem is
you shouldn't have an encrypted boot, you should use UKIs and things like that, and
then have your secrets come in once the, and it already initializes and tells a system
what to do.
So, if you ask me, is there a better way?
No, what you're proposing is the worst way, this is the better way, so yeah.
Thank you for your quick question, you didn't talk a lot about recovery, and I'm more interested
into, through your test, have you encountered TPM2 wearing and TPM2 dying, and what can
happen in those situations regarding field recovery, disaster recovery, and so on.
So, you know, in all the stuff we're doing, like, the TPM stuff is just one option among
many, right, like, we have multiple key slots and locked stuff, and so we added actually
to system decryption role high-level support for concept like recovery keys, which are
just regular passwords, the only difference is they're generated by the system instead
of selected by users, so they have high entropy and should be good quality.
But I would say, yeah, if, like, it's what everybody else does too, right, like on MacOs
you can have a recovery key, on Windows you can have a recovery key, and this is what
we should do here as well, right, like use TPMs absolutely, and then hide entropy recovery
keys that things are fucked up, things are fucked up, but yeah, it's a matter ultimately
for the distributions to have a nice UI for this, right.
With all of this, I kind of want to push into the direction that the TPM stuff is a default,
and then if you want something else, like FIDO or whatever else you enroll in addition
to that, and that's, yeah, anyway, here, thank you very much.