Okay, we're going to sign it.
Our next talk is by James Bottomley about Secure Boot, which is apparently
now famous topic.
Ready?
It's green.
Okay, near me now.
Okay, so for once and a while, I'm actually not going to be talking about the TPN,
which was sort of what I've been talking about most of the time,
largely because everybody else now wants to talk about the TPN, so my job is done.
Instead I'm going to be talking about a much older topic called Secure Boot.
Sorry, let's see if we can actually get this to work.
Okay, so I think I don't need much introduction.
They didn't give me much introduction, but this is me.
I've been a cone developer for about 30 years now.
I've worked on a variety of systems.
I've done a lot of community stuff.
I've done a lot of business stuff with converting business to open source.
I was one of the people who led the effort to found the technical advisory board of
the Linux Foundation, but I'm also still technically a kernel developer.
I don't do much kernel development anymore.
Apart from battling with TPNs and arguing of the subsystems,
but I'm still technically Scusie Maintainer and Pyrrist Architecture Maintainer.
I also wrote the first Secure Boot loader called Preloader N.
In the kernel in 2011.
This is when Microsoft was first starting out with the Secure Boot.
Pieces of it are actually in Shirm, which is the now what you all use to execute Secure Boot
and Linux.
I still actually maintain FI tools and SB sign tools, which are Secure Boot tool kits.
FI tools are wrote myself in 2011, and it's where preloading their sits.
SB sign tools is something I inherited from a guy in, sorry, trying to get my phone to shut up.
I inherited it from a guy called Jeremy Kerr, who used to work from Auslabs.
I still actually am active on the FI Security sub team, which is the team that discusses all technology
that goes into the FI stand and relates to Secure Boot.
If you go back to a little history, Microsoft started mandating Secure Boot in 2011,
which is where I got interested in it.
At the time, the concern was since Microsoft had not done its cloud pivot, it was still the enemy of Linux,
but this would actually be used to exclude Linux from desktop and even server PCs once it went in.
My job as tab chair at that time was to formulate a strategy that would mean that we could actually get around this or work with Microsoft.
One of the good things was the power of Linux was growing.
Microsoft did not have the ability to execute.
If it's policy had been exclusion, it did not have the ability to execute on it.
If it knew the Microsoft engine is doing this, they had to come to an accommodation with Linux to get Secure Boot to work.
So my job was to negotiate some of that.
Part of this job, this is why I got into writing FI tools, was that I did write this little thing called preloader,
which was actually capable of booting, basically preloader was a tiny little interface
that Microsoft would approve a Secure that would then go on to load grub.
And in order that Microsoft would demonstrate its faith in us, I made this little open source thing.
They refused to sign anything, it was GPL, so I put it under LGPL, which we agreed was a compromise,
and then I got them to sign it to prove that we in the Linux ecosystem could actually get our tools signed by Microsoft to run a Secure Boot.
The reason for this was in the early days of Secure Boot, the UFI consortium, didn't want to run what's called the CA,
the Master Key for signing all binaries.
So Microsoft happened to be in charge of the Master Key.
Every time you wanted something signed for Secure Boot, you had to go and ask Microsoft.
And so my job was to prove that if a Linux person came along and asked Microsoft to sign something, they would.
And indeed they did, so preloader all got signed.
Shirm following the same principles came along in 2011.
Microsoft had already accepted they had to sign Linux tools.
We expected and they did sign Shirm, so that's why we use Shirm now.
And the MOK, the machine owner key subsystem came along in 2013.
I'll explain a bit what that is later.
But Shirm and Mark is now basically the standard Secure Boot mechanism for Linux.
Okay, so what is Secure Boot?
Hopefully everybody in the audience pretty much has heard of this.
But let me just explain briefly how it works.
When it's activated, the system won't execute anything from the EFI partition unless it signed.
And the EFI partition is where you bootloader sits.
Or at least where the first stage of your bootloader sits in the case of Grub.
And it can be deactivated by a disabling Secure Boot in the BIOS memory menus.
You don't have to have it.
But pretty much every PC comes configured out of the box when it shipped to you with Secure Boot activated.
And we knew way back then because Microsoft's first response to, we have to have Linux sign was,
oh you can just deactivate it and where how many people do you know and know how to go into a BIOS menu and deactivate Secure Boot in their PC.
It would basically act as a massive drag on the Linux market.
So this wasn't an option for us.
But if anything ever goes wrong with Secure Boot, this is an option for you.
I mean, as a developer of Secure Boot, I screw up all the time and get an unbeatable system because I've missing something or done something wrong.
We didn't have the Escape button, which is I go in and turn off Secure Boot.
My PC will be lost to me forever.
So understanding how to turn off Secure Boot is also very useful.
Secure Boot is actually implemented in an EFI variable called an authenticated variable.
EFI has loads of variables that it stores.
They're usually stored either as volatile, which means you can set them, but then they disappear when you turn the machine off,
or non-volatile, which means they're stored in the envy RAM of EFI itself.
And authenticated variables are just one class of EFI variables.
Pretty much we only ever use authenticated variables for Secure Boot variables.
But if a variable is authenticated, it comes with a key or set of keys that an update to that variable will not be accepted unless the update is signed by one of these keys.
So we have this database of the loud keys sitting in the UFI BIOS, but you can only update that database if you also possess a separate key, which is actually in something called the key exchange key database as a hierarchy.
Revocation in EFI Secure Boot is done by something called DBX.
The database of excluded stuff.
Usually DBX is populated by hashes of binaries.
So whenever EFI executes, you get any.
10 minutes left. I thought it was a 30 minute talk.
Okay, go and sit down.
Okay, so the vacation is accomplished by enrolling either the hash of the binary or one of its signing certificates in DBX.
And so if you put that hash in there that binary is blacklist forever, it will never be able to execute.
And updates to these two variables can be accomplished if you have an update that is signed by something that is in what's called the key exchange variable, the K-E-K.
It's another authenticated variable.
This is the list of keys allow to sign updates.
It sounds very logical.
And then updates to K-E-K can only be done if they're signed by something called the platform key.
The platform key is a variable that only stores one key and it's supposed to store the owner of the system.
So there is actually a bios mechanism supposedly in every system for when you get the system you're supposed to take ownership of the system by putting it on platform key in there,
which basically means you, the owner of the machine control of these hierarchies.
Because you owning the platform key control updates to the key exchange key and the key exchange key controls updates to DB.
And practice no one in the world ever really does this.
So I mean, how many people have actually taken ownership of their laptop?
It's not bad.
I know if I'd done this and I say open source summit, there would be zero response.
This is pretty good.
But the point is that you can take ownership of your platform by swapping out the P.K.
But pretty much nobody ever ever does this.
And so the shim mock mechanism is designed for people who don't want to do this,
and they still actually get the same benefits of owning their own machine.
So what a shim and mock.
The point about shim is that it actually pivots trust away from the EFI keys.
I'm going to try and do a demo assuming that I have time to do it.
Well, I actually show you what is in these databases,
but they're fully populated usually by OEM keys and Microsoft keys.
No personal keys at all, sit in any of these EFI variables.
So the shim variables are where we actually deposit trust for Linux.
So shim is signed by for Microsoft key, now called the EFI CAK.
But when shim executes, it pivots trust to a set of Linux keys that are usually installed by the Linux distribution you're booting.
And these keys are stored in actual, they're not authenticated variables,
because it's very difficult to update or authenticated variables,
unless you have the private key and we don't want to do that.
So they're actually just stored in what are called boot time variables in UEFI.
So boot time variables are variables that are visible only at boot time,
as soon as you transition to runtime in UEFI, they disappear.
Which means that once the operating system boots, as in Linux boots,
it can't get access to these variables anymore.
So the only way of updating these values of variables is to reboot the system and go through shim again.
And so that means that the protection of the EFI envelope is what actually protects these variables instead of signing.
So it's an alternative way of doing it.
But the point is the operating system would never actually see what keys were used to boot.
Unless shim does this trick where every shim variable has a mirror variable in the runtime,
which is allowed to be visible at runtime, and you're actually allowed to alter it,
but it's volatile, so it will disappear on reboot.
So every reboot shim just copies over the boot services variable that it sees to this runtime variable,
the kernel can see, and so we can actually see the list of all the certificates that are in there.
And the variable that shim uses called MOK list, it's that variable there.
This is a boot service is only variable, but shim mirrors it to something called MOK list with a just an RT on the end.
And if you go into your Linux system and look at the EFI variable through the EFI file system,
it's slash slash firmware slash EFI vars, you'll find all of these RT variable sitting there,
and you can actually see what value shim used to boot.
We actually have an excluded list as well, because we need to blacklist some Linux binaries,
because distributions are forever screwing up, didn't say that, but they do.
And so we have a MOK list X, which is our list of excluded binaries.
And on the on boot, the kernel actually populates what's called the platform keyring with these EFI DB keys.
So these are all the keys in EFI DB, remember they're mostly Microsoft keys and keys by OEMs,
so their keys were not that interested in.
And it also populates something called the machine keyring with the keys that win the MOK list.
In fact, it populates them with MOK list RT, because it can't see MOK list,
just trusts that shim copied it over to the RT variable correctly.
And so if you actually do, as root key control show on these keys,
it will give you a list of the certificates in each.
But here's the point about the MOK list.
How do you actually enroll keys in MOK?
If you can't see the variables, if you can't update the variables.
And the point of doing this means that you have to signal, you want an update to shim,
and shim will confirm this is a correct update by asking you as the machine owner
to confirm it before it actually updates the variables.
So the way you actually add a key to the MOK list is that you run this thing called
mock-util install and just give it a certificate.
It will ask you for a password, but when it reboots, shim will find this new key
plus the password in the hash in this MOK list variable.
And it will ask the person who's at, it will stop the boot and it will ask you,
do you want to enroll this password this new key?
If yes, type the password that you did, so you have to retipe the password.
This is supposed to be the security measure we use to ensure that,
because obviously MOK new is just a runtime variable.
Anybody who has access to the UEFI variables at runtime could alter this.
But if they don't know what password you created it with, they can't alter it to have your password.
So if it's altered and they've used the wrong password, when you type your password on reboot,
it will mismatch, shim will refuse the enroll.
Alternatively, if you type your password and everything goes through, you have absolute
confirmation that no one intercepted this in this sort of reboot process.
So this is the secure way that we try and actually do the enrolling in the MOK database.
So it's how you can actually enroll your own keys.
And if I'm lucky I'll give you a demo of that as well.
And it's done using this MOK util import file command.
Okay, so the kernel entrusted key rings.
By default, the kernel will only trust, and this is a mouthful.
I don't know why we have this name.
There is actually a built-in trusted key ring with this sort of three words in the name,
which is usually where the certificate that was created that kernel compile time is stored.
This is if you just clean out an entire kernel compile, do a MakeMR proper,
and then do a rebuild.
The kernel will regenerate the certificate, and it will actually insert it into the kernel.
But usually if you're using sine modules, it will sign every module with the certificate.
And there is a lot of benefit to actually having this key, this key being completely
ephemeral.
If you trash it on every build of the kernel, it will mean that you never have access to the
certificate of sine modules, and your module system is completely secure.
The problem is that if you on a laptop have say an Nvidia graphics module that is
partly binary and you need to insert it, you can't insert it unless it's signed.
And if you threw the certificate away, you can't sign it.
So how do you get out of this problem?
Well, the key's the kernel trust is not just this built-in certificate,
but now we also configure it to trust the keys that we're in the MOK list,
which is the machine key ring.
And so if you actually look at this thing called the secondary trusted key ring,
I don't know why it's called this, because this is actually the primary key ring
that kernel trusts.
I don't know why it's called secondary, but whatever reason it's called secondary trusted keys.
And it's key ring that consists of two other key rings, usually.
And it's usually the built-in key ring plus the machine key ring,
which means that you'd for boot trust both the built-in certificate
and all the certificates in the MOK list.
And then the MOK list is usually certificates from your distribution,
which means that your distribution, if Nvidia, if they like Nvidia,
can go off and sign the Nvidia binary module with their certificate.
And because their certificate is in the MOK list,
that module will actually insert into your kernel.
That's how it works.
For reasons I'm not wholly clear on this,
secondly, the secondary trusted key ring configures to include the machine key,
is actually a kernel configuration parameter.
You could turn it off if you want, if you are super paranoid,
but if you turn it off, most binary modules just won't work,
and nobody has any way of signing them.
So every distribution on the planet usually configures this to yes.
So the secondary trusted key ring consists of both the built-in and the MOK keys,
but it does not trust the platform keys.
So Microsoft certificate, which is in the platform key ring,
does not go into the secondary trusted list.
Not that is unless you happen to be running Fedora.
Fedora actually has a patch that and this is an out-of-tree binary patch,
because kernel maintainers when not so when it's been suggested,
which it has now four times, keeps getting rejected.
It's because the basic idea of sharing a certificate trust
is a way from the Microsoft keys, a way from the UFIDB keys.
So we're not going to put them back into the most trusted keys of the Linux key ring,
which are the ones we trust to sign modules.
And so if you have Fedora and you do a,
what's in the secondary trusted keys, you'll find all three key rings,
but on most distributions you only find two,
and it's only the platform keys and the machine owner keys.
And obviously they can be used to sign modules.
And there is a third problem, which for the life of me,
I've had this argument.
So there's always something that people disagree with you in kernel development.
I think it's nuts that if you turn off secure boot, boot up a machine,
you'll find the machine key ring as empty.
Right, because you didn't boot securely,
we don't populate the machine key ring.
Which means that if you were relying on certificates in the machine key ring
that binary modules like your Nvidia one,
if you turn off secure boot, your Nvidia module won't insert.
Because certificates actually not in the machine key ring,
because it was not secure booted,
we didn't trust shame to have correctly populated the machine key ring.
I think that's wrong, because turning off secure boot,
it's supposed to put you into a less secure configuration.
That means that what is it matter if there's certificate in there or not,
but Mimi Zohar is the person who's blocking this.
She's adamant that we shouldn't add certificates in this case.
So that's why when you turn off secure boot,
if you haven't Nvidia video card, it doesn't work.
Okay, revocation and S-Bat.
The revocation story of your FI is absolutely abysmal.
Remember I said it was DB, and you populate DB with Hashes.
But the problem with Hashes is that there's one per binary,
and it doesn't scale.
Even in Linux, we have about eight different distributions.
They turn over shame at a rate of about once every quarterly release.
Four times a year, eight distributions, four times a year,
24 versions of shame every year.
It's been going for about 10 years, so we've got 250 versions of shame,
something like that out there.
If we suddenly discover the CV floor and shame that goes all the way back to prehistory,
we've got about 250 different versions of shame.
Somebody has to track down, work out, what is the hash for every version?
And then try and get the hash for every version into this DBX variable.
And the problem there is that DBX is sitting in NV RAM in UEFI,
which is very expensive, and you've got about 64 kilobytes of it,
if you're really lucky, it just does not scale in the way that actually works.
So in Linux, we came up with this thing called S-Bat,
which is a secure boot, I think it's authentication,
something I can't remember.
But each EFI binary has what's called an S-Bat section.
EFI binaries are actually P-Coff binaries, they're not L-F binaries,
but P-Coff has this idea of name sections in the same way that L-F does.
So we put into this P-Coff section called dot L-Bat, dot L-F dot S-Bat,
and it consists of a tag and a level.
It can have several of these, because there's a global tag called just S-Bat,
and that has level 1.
And that means that, and then you can actually have an upstream specific tag.
So if you're a grub, grub actually has a grub tag that is also,
it's actually currently sitting at around level 4,
because we've revoked three versions of grub before this.
And then you actually have a distribution specific tag as well.
So if I am the Debian compilation of grub,
I actually also have a third tag that says grub dot Debian,
and then that also has a level.
So that we can do revocation in three ways.
If I change the S-Bat version itself,
I revoked every binary that was ever compiled under the S-Bat system.
Every single one will go, they would no longer be allowed to boot.
If I just rev the grub level, I've revoked every version of grub for every distribution,
and if I just rev the grub dot Debian thing,
I've revoked only the Debian distribution version of grub.
So if we find a CVE, we look at where is the CVE.
If it's only in Debian, they'll rev version.
If it's in the entirety of grub, they'll rev theirs.
And let's say we discover the CVE and open SSL that everything we've ever put in the secure boot chain used,
going all the way back, we could even rev the S-Bat level.
But we've actually never done that.
And shim itself sets a variable again.
It's one of these boot service only variables inside called S-Bat level.
And obviously on your PC, it's reflected to S-Bat level RT.
So shim will do that so you can go and have a look at it.
But this actually contains the minimum acceptable levels for at least S-Bat.
It's usually got one for grub and it's usually got one for the grub distribution.
The rules of S-Bat are that if you have a leveling in your S-Bat section with a tag,
and that tag is not present in the S-Bat level variable, then you're authorized.
It treats it as though the level is actually zero,
which means that this variable doesn't need to start growing until we actually start meeting revocations for it.
And obviously as I said, we can simply revoke every class of binary by raising the S-Bat level
and shimmers in charge of that.
And so if you're booting your version of shirm, you will agree on when you need to rev the S-Bat level,
C-V-E's and you do it.
And we can therefore revoke all classes of Linux binaries at several granularities
without actually ever adding an entry to DBX, which is very useful for saving non-volatile memory.
The only thing we have a non-volatile memory is this S-Bat level variable.
So let's see, I've got two minutes for demo.
Okay, I'm not going to get to the demo.
Let's give up on that.
I was just going to show you all the keys and the key rings.
You can go through on your own and do that.
We'll get round to the conclusions, which is that secure boot is basically now an indispensable part of our modern security tools.
I mean, we require it to boot.
M-K variables are used to populate the trusted keys of the kernel.
And this is very useful.
I was going to show you in the demo how to enroll your own certificate.
But it's with the M-K Utils Import command.
So you can go and practice that on your own.
And you should be aware of misbehavior when secure boot is disabled.
Right, if you disable the machine key ring will fall out of the trusted keys.
And all the certificates you relied on being enrolled in there are not enrolled.
And obviously, revocation story is now way way nicer than Microsoft's in UEFI's.
So with that, this is just the usual stuff.
You can get the presentation online and I'll put it up there.
And I'll say thank you.
And I think I've got two minutes for questions.
Hello, so if I was making my own OS and my own machine.
And I wanted to know other OS other than my OS to be installed on that machine.
How could I stop secure booting up the Ubuntu or Windows machine?
Would it be with an aspect and would they play with everything?
So if you actually only want your own operating system to boot,
you don't use shin.
You can actually go to the DB variables, extract all the Microsoft and LEM certificates in there
and just put your own key in it.
It's what I used to do to my own laptops when I was actually early days of secure boot.
So there are still mechanisms to allow use the owner of the machine to fully accept all the variables in DB and make sure they're yours.
If you do this, you still have a problem with certificate enrollment.
The kernel still won't trust your certificates in DB.
But it will actually allow you to, I mean, you probably have to have some sort of boot loader that will install the MOT certificates as well.
So the kernel will trust them, but that's about it. You should be able to do it yourself.
Okay, that is questions.
Thank you.