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