All right, good morning and welcome to the second edition of the E-match based Linux and
boot integrity devroom. On the first edition, we were down in the basement, the underground
and now we've been promoted up and we're in a window which is great, yes, you cannot hear me
that is fine. There's no speakers, this is for the livestream, but thank you, this is just
for the livestream. Now we're not important enough to have speakers or other microphones,
so if you have questions, please raise your hand, we welcome questions and discussions,
but then I'm going to have the speakers and to please repeat the question or the comment
before answering because we want people on the livestream or watching the recording to hear
the question. Otherwise, it looks like the speaker is talking to himself like a crazy person.
A bit of logistics and then we will start, so all the talks of the same format,
speakers have 20 minutes for content, plus 5 minutes for Q&A at the end, so speakers like
12 questions during the talks, my clarinet, so please do that if they allow it, and then we
have a 5 minutes buffer at the end for spillover and for changing the speaker. If you need to leave
the room or reinvent it, please it's possible wait for this 5 minutes buffer at the end because
it's a small room, sits on noisy, doesn't noisy, it stops the procedure, if 20 people start
leaving the room or the talk, so we'll defame here for the end, please leave it at the time,
it's possible. Then on top of that, we have a great set of talks today, we have an even greater set
of speakers, and none of them are controversial tech billionaires, you know, it's not a given,
these days are for them, so I think that's good. And finally, we are also organizing not just these
devil, but another conference, all systems go, is going to happen in Berlin on the 31st of September
and 1st of October, we are going to open the CFP in a month already looking for sponsors,
though, so if you work for a company in the sitting on a big pile of cash and don't know what to do
with it, please go on the office and go website, and this sponsors link is open. And with that,
let me introduce the first speaker, my colleague Leonard, and he's going to tell us everything you
are wanting to know, and then some about the PMs. Thank you, let's work on Leonard.
Okay, can you? Yeah, this thing seems to work. I don't know a lot of slides, I have no
reasons, I'm not going to be able to go through all of them, because it's just too much stuff.
Also, it's going to be fairly technical, I really hope that at least some of you have a basic understanding
of what a TPM is. I did this in one talk, in past years, it passed conferences, so I kind of hope
that one of the other already has a rough idea what we actually do with TPMs in system development.
But yeah, to live in this, what are actually the goals with a TPM work that I personally and
others have been doing in the system, like the big goal that I have is that we catch up with
other OSIS, because right now, it's like all the big OSIS that are not classic learning
system, you tend to have some form of TPM hookup that just works. And if it's not TPM,
and at least some other kind of security and cliff, a thing that works like a TPM. So if you look
at Android, if you look at Windows, if you look at all these things, they all have this. So for me,
it's kind of the pointing that we don't have the same level of support on generic learning
distributions. My goal is that we can, in particular, default to measured boot. So yeah,
to catch it up in that regard, and not just have secondary but also measured boot.
So that we can body fault like Windows does it with a bit locker, do this encryption lock
to TPM, so it's not just about that, but also about service credentials so that we can do more
than just a description of locked to TPM, and actually pass secrets or how we call them
a little bit more generically. So it's credentials to services in a relatively secure way and can
authenticate them and equip them in a way that locked to TPM. That we have a method to do second
parameterization of the boot, because there's always this problem that if you have a further
locked down boot, that typically means that you run stuff that is signed or you lock
your description to stuff that is what you think it should be, but that makes parameterization
a little bit harder, because it basically parameters are usually something locals, something,
but not the vendors controls, but the local and the local user controls. So doing the
securely in a way that everything's authenticated and they crypt it if needed, it's not trivial.
One of it goes also to make confidential computing a thing, like confidential computing
you need to basically make sure that any input to your system is in some way authenticated
and encrypted and TPM's play, or at least TPM like things, play at major role in that.
And then also provided PIS that others can start making use of TPM and a more reasonable way.
I mean, TPM stacks have existed for a long time, but the problem is that if you actually
want to write a application that uses TPM and has a sensible policy that locks to the system state,
that's very hard for the simple reason, but there are no big-time measurements or traditionally
the wind. So, and the definite goal of all of this is to make the TPM stuff something that can be
turned on by default on generic Linux. The same way, when it's just TPM, TPM is available,
we should do the same, because right now none of the distributions generally do that.
This, the work on that has been progressing quite substantially, so these are a bunch of
the components of the system that already have been hooked up.
Yes, the given explanation, brief of what all these is, clips and up is like the thing that
unlocks a disk and can do this against the TPM, crypt and roll is the other side that you enroll,
but you can encrypt a disk against TPM. PCR extends about the measurements so that we can
measure the boot status, so that the TPM has an idea how far has a system progressed booting.
I guess it still has a left in it already and things like that. It's kind of relevant so that you can
bind secrets to these systems states. So, for example, that you can say,
if you can build from a secret shell, it'll be accessible to the OS during early boot, during the
inner-ready phase, but not later, so that anyone who can explore its system later has no chance
to actually get access to the disk encryption volume key, at least not from the TPM directly.
PCR machines and PCRFS are kind of like they're actually just a multi-culting for PCRFase,
they measure identity of the system in a way, so that you can write policies that are generic,
but also unlock only and specific systems. PCR machine measures the at-see machine ID,
and system PCRFS, and measures the UID of the filesystems that you booted from.
This is when you stop is this UFI stuff that runs during, like from UFI,
like before the kernel initialized, it does the measurements of the kernel itself.
It's like, I didn't have another talk about UKI's, it's kind of related to that.
This is an imagine or something that can predict the measurements that are going to happen
if you build a certain kernel up at UKI, but it here. UKI files this little Python tool that allows
us to build UKI's, so they glue together a kernel inner-ready and so on, and then do invoke system
the measure to get the measurements and then get that kind of blah, blah, blah.
This is a BPCR lock, it's a major component of all of this, more recent addition,
it's about management of PCRFase policies for TPM that cover all the stuff that is inherently
local to the system, right? Like because if you want to bind disk encryption to TPMs,
what do you actually do is like, like parts of it, the measurements cover stuff that the
YSVANA controls, right? You have deviant distribution, you have a door distribution,
but then there's all the other stuff that covers stuff that is inherently local to a system,
right? Like that the YSVANA cannot predict, right? Like because you have a different graphics card,
different CPU, different firmware version, and so on. So actually the parts of the vena controls
are actually small, but it's really nice, really predictable, that's where systemy measure is about,
and then all the massive other stuff, which is really chaotic because there are so many different
stakeholders, right? Like there are firmware developers and Intel is always in there and there's
so a system piece of Alex of us to help you manage that. Systemy required is this thing,
I mean it's a dynamic repetition, but one of the nice things it does is that on first build you can
create petitions for you and actually lock them to TPM, so it cannot just grow in petitions,
but you can also set them up and do that in really smart and cryptographic enhanced way if you
so well. Since it requires this, like this too, I mentioned this earlier about system credentials,
how we can securely monitor our services and systems, in a way that is locked to TPM.
Import credentials kind of the other side, it's systemy credit tools that you generalize these,
encrypted authenticated credentials, things and import credentials, it's like how you then
consume them in a service, so it's very easy for for systemy services to just have secrets,
like, I don't know, key material, but also configuration that is locked to TPM.
Systemy as B sign is a recent addition to systemy, it's just a second good signing,
does pretty much the same thing that the PE sign do or SP sign do? Well, I don't have much time left.
Systemy key you does, yeah, also something, let's not go into that. One of the point is,
it goes to the hypothesis that we put more focus on magic, we're not seconded, you know,
seconded is the thing where everybody signs their stuff with ultimately some key that is
controlled by Microsoft. Imagine if it is these other things where you just let do everything
and then however you bind your description to that over this kind of software has one.
I find there's a lot more democratic, right? Like because it doesn't make any restrictions
about your boot, it just says, yeah, if you do not boot what I chose earlier when I
encrypt in my disk, you will not get access to the disk. So it makes, like it should actually
something that opensource people should really love because it's democratic, it's free,
it makes no restriction on controlling anything prohibiting anything, all the, all
it says is that, yeah, this doesn't need to be in this specific state where the disk could be
accessible. And that's a good thing. And for this model, like a tofu model, like instead of having
the central database of certificates where everything's side, it does it the other way around,
basically, yeah, when you install your system, you lock everything down at that moment,
you trust your system and from that point on, you know, it's going to only be unlockable of
system still in relatively similar state. So to me, yeah, I mentioned it was way more interesting.
Secondly, it's kind of add on, you can also do this reasons to do this, but I find
measured through just like, yeah, it's, it's a lot more focused because it actually allows you to
control what you want instead of what some big organization, big distribution, it wants to do,
and it's, it's more democratic. This is my taken things, look at for example, love,
second, yeah. So, I can actually, in the last five minutes, to really interesting stuff,
something that we recently added is actually that we can combine the system, EPCR lock. I
mentioned earlier, already, it's like a thing for managing all the local things of the system,
like the local measurements that are specific to the local device, and combine the
same PCR policies, which are these policies that cover all the measurements of the last window
controls. It was really hard to combine these two things, but to me, this was always a holy grail,
because the basically means yes, the last one that can lock down things, that the last
window controls, and you can lock down the stuff that your local system is, and then you can
combine them both and have a security policy where you basically can say, yeah, my laptop can only be
unlocked if the system is still in that state where I installed it plus anything from federal
runs on it. This is actually impossible to implement on TPMs, because the policy language that
TPMs support then allows us, I talked to a lot of TPM people and nobody could come up with an
ized version. Ultimately, the way I found this by sharding, so basically, we have a risk of encryption
that's done with a large key, and one half is protected by the PCR lock stuff, and the other stuff
is protected by the CIS, CIS, CIS policies, so the TPM doesn't actually know that there are two policies
involved. It's a nice hack. I think it delivers pretty nicely what we want. It's not as good as if
the TPM would support this natively, because yeah, these things can be authenticated out of
some, basically, and would be better if the TPM could do the same thing, but it's still
kind of nice. There's very tough not to crack to figure out how this works. But I'm kind of happy with
this. Other things that we've recently added to TPM2 to target, it's like this, we finally
have a synchronization point. One, the TPMs actually have shown up during good, because we are
like, normally on my laptop, for example, TPMs are just there, what was that? TPMs are just there,
right, because they are discreet hardware that is probably doing all the boot, and it's just
there. But the thing is, in real life, it's not always that way, like a political and arm,
TPM is kind of planet and wire software, thingies and enclaves, and the needs to first
run some software in user space, so that the TPM devices can actually show up, and it's because
they don't have storage, and then this OS component needs to provide storage to the
enclave. So long story short, this actually, yeah, doing other boot attacks a while until
TPM shows up. And now the reasons why TPMs show up right, because I don't know, the drivers
that compile those modules are loaded only on demand, because generic distribution tends to
want to support a lot of systems and not just one. So this was actually kind of weird, like
figuring out that, oh my god, we cannot assume that a TPM is there all the time, because that
means doing all the boot TPMs are there, doing right boot at TPMs are there, but in the middle
there isn't simply because, yeah, what the firmware found, and what user space found,
and rather gap in the middle until we actually manage to set up things as the same way as the
firmware already added. Yeah, one other thing, probably the last thing I'm going to talk about
is, before we switch to questions, the system credentials are available on privilege, or service
credentials. I mentioned what these credentials are, right? We extended this a little bit
so that it's not only something that you can parameterize the whole system and system services
was, but also user stuff. And it's actually quite nicely implemented, because it actually
involves the user ID of the user and has to set it into the policy, like basically into the
key that we actually use for the encryption authentication. So that basically means even though
the concept of users and operating system concept, like the TPM has no concept of users or anything
like this, you can nicely lock your system credentials to that and then also to the TPM. So yeah,
the actual encryption authentication basically takes a key that is ultimately released by the TPM,
but it also contains material from that we acquire from the current self in a secure way.
And that basically means, yeah, if I walk in as user Lennon, I can ask the system to unlock the
secrets for me, but any other user couldn't do the same thing. Yeah, that's kind of nice.
There's so much other stuff that we recently had. I'd like multi-profile you guys. I talked about
all kind of small things. I make it really nice to work with this, so that you actually can
build stuff much nicer. And it goes on and goes on and, like, confidential computing support,
we now support natively in during food loading. We can measure which is something that is not
TPM. We have this offline modes as distributions can actually build all that stuff in the build system
and then have this signature logic in some other system that is very much secured and then you
can get the signature back and then merge it again. Yeah, we have modeling IPC, IPC, IPI's nowadays,
one of the last things is really hard actually to do right like the PCI works that, you know,
we need a lot of meta information to implement these kind of policies and the meta information
needs to be somewhere for the root file system, but we can't put it on root file system because
it's supposed to unlock the root file system so we need to put it in the ESP, but then you also need
to figure out how to authenticate that and things like that. Yeah, we figured out all of this out
more. There's so much more, so much more, so much more. As I mentioned right in the beginning,
we aren't going to call ourselves up. So let's talk about questions.
So the question once regarding if I buy in five years or laptop and I want to transfer my data
from the old one because the new one that is actually worked, you know, the TPM stuff is just
one way to unlock your disk in the same way as the other operating systems usually give you
a recovery key or something like this. We do too, right like you should not lock your disk exclusive
to the TPM if you want to be able to get access to without the TPM. So TPM is one way to get it in
the same way as photo keys, the pass keys are another way to get it the same way as your password
might be another one and the recovery key. I would assume that in future the same way as photo
other pushes you to using TPM by default and then combine it with a recovery key we would kind of do
the same thing. And incessantly we added this for this the high level concept of a recovery key
to disk encryption and it's actually the exact same thing as a password. The only difference is that
we generated from the computer so it has high guaranteed high entropy instead of letting the user pick
it which generally is usually not at that high entropy. Okay, my question.
So the question was regarding what do we do with like for microcode and for my stuff I presume
that I was doing early boot and the changes that have and how like the effect the PCR management
and then the policies we generate. This is precisely the system you picture all across about.
It's like this management tool to deal with this kind of stuff. So yes, firmware updates,
microcode update, blah blah blah blah blah, this will all affect the PCRs. So what system do you
picture all across the list to help you is that we have a clear way how in a good case is in the best
cases we will know how the PCRs are going to be influenced. I mean we don't know right now
generally because the state is simply not available from the firmware lens but my hope is that
eventually after we update the carry some of this information related to the PCRs zero result.
They kind of hope that these kind of information will soon or later be available for them.
They would be the idea case but of course it's going to be at least initially the absolute exception.
The common case will be we just have no. How are what we do know is that there's going to be a
firmware update going to take place. So it comes out with all the infrastructure to actually
relax the policies when in a firmware update is expected and then you reboot and then we'll
need to lock it down. So this is kind of what one of those two except we do in much nicer because we
can do it's more fine grain and we don't drop all the protections. We just drop the protections
of the stuff where we just look at what the new measurements are and look against that.
If you put it measured or secure and you have a con-laptate or something other that influences
of the week how do you get the new measurement into your food chain,
food ones whether we cover a key? No, like if you update like so the questions regarding what
if you update a kernel or something like this how does that reflect in the PCR policies.
So we don't do this like we don't have to that's a good thing because the other thing that I
talked about like the sign PCR policies, this is about like kernels if they build the way we think
like as UKI they can come with a signed gold measurement JSON thing built in right and this is
signed and we can pass a signature to the TPM and then anything was with the public keep behind
the signature will be accepted for unlocking the disk right so that basically means we never have
to re-enroll as long as it changes to the PCR's are controlled by the Westlander because
the Westlander really just predict what's the changed measurement is going to be sign of risk
their own key and that's the signature key is going to be accepted by the TPM and hence we are good right
so this is fundamental difference on how Windows does it because in Windows they don't have
this support because they designed for TPM one or two instead of TPM two right and TPM two there's
this concept of sign PCR policies and TPM one or two it wasn't so when those doesn't this case
that turn off all the protections you boot and then lock again right so that basically we enroll
we don't have to do this because we have the luxury of coming late and just being able to rely on
TPM two so I'm sorry for the Windows people that they're kind of stuck with this city model
so that's this also means the system will help us get the initial provisioning of the TPM
often running because personally I still find TPM to not something I would like to order
the reels they're deal with so the way we're getting TPM provisioning like setting up the
original TPM on on first put like we all have to do this like as called TPM to set up or something
it's like a service that we ship but once we're going to set up an S.R.K. like a storage
would keep the thing that you have to do if there's none so I'm pretty sure we can polish this
like a little bit more that we can I don't know give you nice ways to reset the TPM via Chrome
come online think like that there are a couple of things to do this good about this but we're doing
enough already to get this like make this invisible to users there was some
design about this yeah yeah I'm I'm a war like the sort of the the what was said there
is that the T.C.G group like the people behind TPM are preparing a spec regarding the gold
measurements I'm a war of this but talking to some people from the TPM like from the T.C.G
they are not entirely sure this is actually going to happen like in real life so
you know I find out a way of a design we need something much simpler like for like the
stuff that we need like it's so trivial that I don't know yeah I think when that appears it's
going to be trivial to consumers too right that let's bet until actually appears otherwise
there's no point in supporting it
so yeah yeah so yeah yeah so I'm very good with he mentioned that like the T.C.G people are
like some people try to get the firmware wonders to provide these gold measurements
of the book and so far they're never succeeded and in particular he claimed that the PCR
zero stuff that I mentioned was not actually provided by anybody to FW update the things
so mine knowledge like they're talking to to which it used like the guy behind FW update the
or L what's called LV anyway the the call the thing they said and one of the one that does
the PCR is the one stuff
yeah so yeah I'm not going to repeat that but they think what I'm I let we still
say that yeah the I think the data that they have about PCR zero is it's kind of uninteresting
ultimately it's not what I want because what they carry what the one field that they have
covers the system state and then tells you the final PCR value what I want to know
is the measurements that got into that value to be able to replicate that