 We went over the steps of the secure boot implementation in Asakus and Ubuntu today, Asakus and Debian, which is kind of partial support, but not enough to actually do anything useful. Yes? I'm going to create a document going to be under DEF CON 14, Bob. Really? What's it called? QEI space block. OK. So we didn't have, it's unfortunate we don't actually master representation here because of last time on as well, but we largely agree that we are basically just going to learn the same general idea, namely we use let us share with which is correct, which Matthew can probably expand more about, but whose purpose is to be signed by an SD like Microsoft, essentially, bootstraps our way into better bootloader like Grubb, which we can then bootstrap the rest of the system from. The Grubb itself needs to be signed by a Debian key, so we need to do that, I think, on an activity master in order to have remotely acceptable security. To do that, we need to sort out key management so that the point of attack so we want to protect it in more or less the same kinds of ways that we protect the key for the Debian archive. So is it going to be an FTP team number one in the room? Oh, hello. I think it was not here. That's very useful. I'm an FTP assistant, so not. Excellent. This can't be your fault. You can at least tell us whether we're confused about something about the general. I'm just going to go over. Since there's a bunch of people here, I'll quickly go over what SHIM does, what features it enables that are relative to Debian, and a few things that need to be considered based on some changing requirements. So SHIM is an EFI executable, which is in a format that is acceptable for signing by Microsoft. It performs one real function, which is to execute EFI executables that are assigned with a key that is not in the firmware key database. So UFI security systems have a database of acceptable keys, and exactly needs to be signed by bits in that database to be executed through the standard UFI mechanisms. SHIM exists to be signed by a third party who is already trusted by the platform, and then bridge that user trust to a different user trust. So the typical way of using it is for the vendor to ship SHIM signed by Microsoft or some other trusted third party, and then embed their key inside that. Any further binaries that's assigned with that key, SHIM will perform its own validation, its own relocation, and will launch them independently of the firmware, so you don't need to go through the firmware key database. In addition, SHIM also supports its own user-modifiable key database, so the end user can generate a signing key, install that in a standardized way that is consistent between different systems. It requires the user to be physically present. There's a point where it requires you to type in a confirmation phrase on a screen at the console. So it's designed to prevent it from being easy to social engineer, sending it to installing arbitrary keys. GRUB will then call into SHIM in order to verify the kernel, so you can then have a fully signed user trust up to the point where you then use whatever additional user trust you want. If you wanted to build something on top of this, where you had a verified INR MFS and a verified GRUB file system, you could do that. That's not required. As far as we're concerned, once user space starts, then the usual trust model is that user space is assumed to be trustworthy, whatever it is. There's no enforcement there. The other thing you can do with this key database is disable signature validation, which means that SHIM will launch anything you get it. Again, that requires physical presence. Under limits, you type in a password, you reboot, and then SHIM will want you to type in the same password again. And then, after that, you want to disable signature enforcement. And from then on, it will boot any GRUB or any kernel. So the user has a standardized way to disable this enforcement. Without saving security? Without saving security entirely. So that means that you don't have to jump through whichever boots you're going to do, but that full vendor has implemented just in order to do current development or correct development. Which is quite a serious problem, because at present, while there are certain requirements on firmware, particularly from things like the Windows End certification, on the box that you must make available, it says absolutely nothing about whether there's to be a remote, even slight inconvenience. Or whether you can figure out from the menu what it's called. Unless you deeply understand security, you're half the time unlikely to figure out which option relates to putting it in a setup mode. The aim of all of this was to reduce the least worst thing that still respects the user freedoms. I think we came as close as we could possibly get. The local key management stuff was implemented by SUSE, originally. Most of the rest of it was implemented by Red Hat. The future stuff, there's not a great deal of additional work being done on SHIM in interesting temple ways at the moment. There's support for ARM, has just been added. It also has support for 32-bit X86, if you have one of the tiny number of systems with secure boots and 32-bit UBFI firmware. It has support for being a fallback boot loader, where if you put it in a well-defined location, if the system loses all its boot entries, then SHIM will launch, re-enroll your boot entries, and then boot normally. One thing is that Microsoft have recently modified their sign-in policies slightly. In order to sign up to Microsoft SignService, you now require an extended validation certificate. So in HTTP lands, those are the ones where you get the big green thing in Firefox, just the level one that also gives you the name of the company you're talking to. That costs more money, because it means somebody actually has to go to real efforts to verify your existence and identity. It also means you're going to have a real existence and identity and be verified. So I think the issue is that I've seen so far is on the order of $1,000 for a three-year certificate. This is within Debian's round, but it is a little bit hostile to the individual end user. That's the shit. It also doesn't affect the most of the keys. Right, you can't sign other keys with that. You cannot get a CAB cert. But that's in itself not a problem. Microsoft's originally requires that any embedded keys also be in these certs. They can last that requirement. It's now perfectly accessible to generate your own key, but said key is supposed to be maintained in a FIFS-compliant hardware device. Now that sounds kind of terrifying, but FIFS-compliant hardware devices includes just Java smart cards. So that's not a particularly high hurdle to get over. If you're a crypto-organization, then FIFS-compliant usually means the weaker than your... Yes. So a real hardware security module is way beyond the FIFS requirements here. A smart card that plugs into a USB reader is completely acceptable. There also exist USB tokens that's defectively presented as smart cards. The thing that we're doing in Inhibitor is none the above, but we do use GFs for this. So we have three of seven requirements on reconstructing our master security key, which I don't know if it means the letter of FIFS, but it is equivalent to this variable. So the other thing is that Microsoft has no way to verify this because it's a key thing. Yes. So if that's what it is... It's always too much that you're not doing what you do. You probably should not put that in the e-mail. I don't know. You probably should also not put that in the e-mail anyway. It's a good thing that you can hear this on the screen. But that's more a case of if you do somehow screw up, then there might be problems later, but just don't screw up. So we have gotten informal, at least, approval from Microsoft for the key sharding that Colin described. We haven't actually gone through the certification process or the signing process since they did change their requirements due to some other issues regarding minimum version requirements for SHIM. We did a public too. So the other thing in terms of SHIM development is a desire to move to... SHIM's now moved to a model where the vendor certificate is stored in an additional section. It's not embedded in the code or data segment. There's a separate section within the executable that contains the certificate. This means that if we do the appropriate work to ensure reducible builds, even if you receive a binary from Debian, you'll be able to verify that the binary you build from the source code is identical to the one in Debian with the exception of the certificate. So you can verify that all the accessible codes are identical. This is for two purposes. First of all, it means that users can actually trust the Debian or whoever are building the binaries from the same source code and that if it is backdoor, it's backdoors in the tool chain. It's not backdoor by Microsoft. Secondly, you can check that in other ways by confirming the signed objects. And secondly, this is also, we hope, going to make life easier for Microsoft because they'll be able to verify that the code is identical and if a binary matches something they've already signed with the exception of the certificate, then it can go through a shortcut. This is not through some altruistic desire to make life easier for Microsoft in general. It's because the signing process can take months. Or result in rejections if they simply go on. Yeah. In terms of the long-term politics of Microsoft being the signing thing, then that's going to continue being a conversation for a long time. I can't really say anything more about that at the moment. That's not going to change in the immediate future. Nobody else has offers to take that role. Have we seen anything that was suggested that they are not acting as a part of our business? We have not seen anything to suggest that they are acting in their own interests as opposed to others. There are ways in which they have been annoying in one way or another, but none of it is. None of it appears to be malicious. None of it appears to be malicious. They're a signing authority and they're a large company. So they're expecting some different suggestions of us. So there was a mention that we're going to need to start signing grub. How would this interact with, I wanted to start having UEFI stub Linux kernels that can be directly booted rather than using grub? Right. So the way I designed this in November 2 permits both. The state of the code in Debian today is as follows. Grub has a number of patches mainly from Matthew's network pass which cause it to behave in a secure, but appropriate way when loaded and such. So for instance, when the grub core image is signed it will refuse to load any modules which are not in the core image because that would amount to executing unsigned code in the framework context which you're not allowed to do. As a result we build a rather larger core image in the case of the script that has everything we need. All that code is in Debian. Some of it I think is configured off when involved with us for any trivial. We have code to build a custom upload. So the sort of thing that a handful of packages do to put things into rather old lists in the archive for instance DI builds a raw installer custom thing which ends up being unpacked by Dac into... actually my ham script I think into installer-thing somewhere under this. We have the code to do something similar for UEFI. At that point Dac would unpack the raw boot loader images into Jesse then UEFI, something rather, and also sign those with the SP sign tool and the FUE. I laid that out in the implementation I have today to put in such a way that you can have different packages, it's not just for grubs so different packages could do the same thing. The kernel could omit, in fact probably should omit, an object for signing in a much simpler way. For that kind of thing to be sensible it has to be entirely automated really it should not be something that requires manual action by a team master otherwise it's going to take all week. To answer another question that was possibly also what you were asking, SHIM does not care whether you're looking grub the kernel or any other valid UEFI executable as long as it's signed with the trustee key you can tell SHIM to just launch the kernel directly instead of having SHIM launch. Oh sure, I was more concerned with as we work toward trying to integrate UEFI direct boot into Debian which I hope we do at some point. I would really recommend not doing that. It requires you to put the NRMFS in a unified system partition. That's just a fast idea. Don't do it. Let's talk about that later. I can imagine it being useful in specific situations under the same general purpose approach. Just to clarify the, for this purpose of getting this working in Debian you outlined at least a to-do being enabling that code for secure boot and grub but were there other things that I should note down as being we need to actually come straight with you. Right, so I asked a question on IRC to Colin and I looked and scrolled back to him. I recall that we had a to-do list that somebody said was recorded somewhere can we refer back to that earlier document? What's the URL for that so we can grab that into the copy here? Well I sent in a mail which was a summary of it was hoped again probably recently we had a link on I think it was I guess it would be a shame we spent most of the time moving forward, rehashing that and describing what the secure boot is. Just to dignite that. Can we move on by various people trying to find that? That's basically the Can you paste it into copy? Do you want a copy? I think that's fine, thanks. One thing I want to add regarding the state of the current code at present rather than preferred to to permit you to put on sign kernels this has been so-called confidential the reason for that is that the version of SHIM that has been in certainly a boot I think also to whatever extent it's indebted is it does not have mock manager enabled to be a machine only key thing that Matthew was talking about a moment ago. Without that if you acquire signed kernels then the barrier to entry testing new kernels and kernel development etc goes up so we need to mock to be in place before we can require some kernels Once we do I'll be happy to prevent that bit of growth and then we will not be in a position where there are many trivial kernel exploits that will get our key root so you're saying like the step zero is to get mock manager well we can do many other things in preparation but step zero in order to get in order to get to the sign kernels is having a mock manager so we don't need to hedge unnecessarily on user freedom we have a bunch of packaging that enables mock manager just needs to get the new option version of SHIM for signing purposes but any SHIM work will be in key so we need to be talking about making sure it is addressed to someone so I do have looking through Ben's mail I do have some duff changers to support this I can really use assistance with setting up the test environment or if it is just easier to test the production system today then I can review that I did a different one for you I would like to grab you Ben this week the other thing that is important there is that as I said earlier I think that this should run unattended I would prefer to run it unattended where possible I don't want to be in a situation where all grab uploads go through new effectively but there is it is possible that we may want to make this require some kind of basic white listing or depend on the uploader's key or something so that we are not effectively saying that any Debian developer gets to upload an object which can get signed by Debian's secure boot key because that would be quite a large exposure the compromise we have in Ubuntu today is that any binary upload that is going to go through signing bars it does require a button push sign off just check with it matches that is something that will be signed before basically in the same kind of way we know what it is we can very very easily make new queue processing we are going to be able to share what we want to think so are you saying that is something that you can work with on to make it happen the other important piece is actually having WP which we do not have today Todd I think you said you said a little earlier you wanted to have an HSM for this if you want to have that done away just for the developer is that something that you have hardware for at the moment and if not once a week I think we have the hardware to change there is also it would probably also then be on a different coast than at the HSM itself so we would need to make that protocol product basically one thing about the HSM when we looked at this in particular we found that there were basically none on the market that had to be free drivers which is why we ended up using smart cards is that your experience or is that just not I have one here which has free drivers I'm not sure it actually supports every single thing we want to so I would need to make sure it does that we basically just need an RSA 248 for this purpose even if we just have a community we can just use anything we can actual smart cards are kind of finicky and rake and stuff I use I use I use the rest of this baggy I know the upstream people quite well given I also maintain packages in one of the upstream teams are you effectively volunteering to research and make sure that the HSM is acquired? yeah I'll make sure that happens and then you said there was a second piece which was setting this up so it can be detached from the e-master yeah we don't we probably don't want that running on the e-master directly partially to limit the attack surface so the machine could be running on probably not be on the I-26 machine at all would that be something you'd also be doing? I would need to check the exact status there but yeah I can make the DSA side of that okay secure route with the main micro it's the essentially the patch set which is so I can definitely do that so this consists of the Linux CFI module which is basically straight from straight from my patch with a couple of weeks and I also added a patch to cause the linux and linux ID commands to automatically check through to that is this different than the ones that SUSE is using? I don't know what's in SUSE it's essentially the same as what's in Federo it's possible do you have the automatic chaining of Linux 2.0 sorry you've got to be sure that's not the answer should they not probably just go upstream? yeah so it's been a little bit controversial there to at least the thinking on this I think the most practical answer for the timing is a standard I can speak to some people I think the concern Grubb upstream have is not linked to assumptions about the FSF's desires on this front and I think if this can be made clear as the only way this actually does anything is to guarantee that there's user control for keys I don't think it's necessarily going to be a problem long term but there's going to be some discussion about that and to figure out what there is a way to determine the FSF policy do you want it to be policy? I don't think folks from FSF here is that something that you can pull in for that discussion? John Sullivan's are on he was just talking about it so we don't do well I'm not saying derail but if there's a plan to have a conversation let's make that a to-do so just to we have this list of to-dos we're generating here it seems like we've got a couple concrete things for dealing with getting the Debbie and Key of the HSM pieces and then someone's going to have to get the key then there you mentioned that we need to get mock manager support from the SHIM the one-two stuff that does that is there's someone who is going to take care of that I'm happy to maintain the SHIM package step to minus one and you can give me a key you guys no you can get the you can get the name of the key I can but it's not useful if you want me to upload it would you be in it? sure so this discussion you guys were just having was a meeting with the SSF to talk about freedom do you see that? emerging the growth changes would it be an objection to see it? will we have to keep walking on getting as much as you can go? no so this would just be in Debbie? it would be more convenient not to be in too much of a battle of days for everybody to have a gigantic growth set in every district that is kind of that of copying around that's not really very satisfactory but it doesn't block us immediately one useful thing that growth upstream did do in response to the in response to things like this was implementing a verification layer so you can do the best signing of growth modules and it might well be nice to integrate that so that we don't have to embed all of the modules that we care about in the core image but again not a particular locker so just in terms of an interest of making it clear to do this what is the meeting with the SSF it sounded like you didn't need to do that it's not blockable at all to try to try to make sure that Debbie and the SSF are vaguely aligned on what we're doing and not doing with a hardware-enablement level support for UF and security and by the way are there any considerations for answering this sort of step to not recompile all of the shared parts of the room on CDs for recovery packages you're going to either have to ship the same car to the stadium or you're going to have to also rebuilds growth and ship and finally how does that work I don't know you know but how does that work like someone else is like a signed shim that's signed by Microsoft as long as the shim itself is not GPLed so there's no problem there but because it's used in computation with shim it's always possible for user to replace it with one they build themselves so again there's no problem that's it but would so like if I wanted to use Microsoft signed shim in my distribution yeah I'd give you that one yeah you'll also have to use their caravan and their caravan or if they're signing you'll have to use theirs on packages well I would like the booties now and the one you released a while ago yeah you could do whatever you want if you mod it mod without any user involvement if you want it to be turnkey if you don't want the user to have to set up their own machine overking in order to boot your distribution then you need to I'm booting it's either yours or the bootie one that I'm booting a 32 bit kernel that I can tell myself the bootie thing only works because today we boot unsigned kernels after after the exit services call okay yes that's Holtz I told you that that's why it's hard to hard to break is it possible that kernel still be signed just like kernel yeah are we talking about shipping a Microsoft signed shim with the bootie that's what we're doing that's what we're doing it's it's not exactly pretty obviously you're dependent on an external and not always friendly entity it means that in order to upgrade a particular piece of software we basically need a sign off from Microsoft which should be very comfortable with on the other hand the alternative is low and protracted processor trying to set up a CA and getting that into enough actual hardware that real users will be using so that they can boot our systems we have we did explore the possibility of signing with two keys with Microsoft's key and with one that we operated ourselves that falls and runs in file of various firmware not actually supporting that we're not should we ship a Microsoft signed shim we have to have one other option I mean to encourage people to use soft sign keys but the important how you're going to put the installer you need to bootstrap it if you buy a I bought the shelf it only will trust the Microsoft key so you have to talk people into figuring out the obscure UI that's different on each hardware or you can do a lot of them so the point for me is not does it suck that we have to rely on Microsoft for this yes it does suck but I think it's more important that we not make the process of installing a free operating system on modern firmware the process that involves typing in a long string of hex digits into your firmware setup screen before you need to start the effect of that is going to be turning off lots of people from free software and I don't see that as what meets our long term goals I'm not comfortable with all of the ways we have to get there but as long as we're still building the actual software ourselves and the only involvement from Microsoft is a signature that we can verify refers to the same code then I think it's basically acceptable this is actually really good for my in this case which is we release a live live distribution which would be great to have with Microsoft so from what I understand from our to-do list here the uploading of the shim mock manager the updating of the grub package to be signed by the Model 1.55 and the kernel team changes that will be the uploading kernel images that are signed depending on the stack changes and all of those are relatively easy things to do just simple package changes so maybe we need to and there isn't anything else really that needs to be done that has been identified as additional tasks since the last time we talked about this is that correct do you already have a process to acquire the key who doesn't know who's going to do that it's going to be do you say it's going to acquire the key well somebody actually had a discussion is what is about whether the is locking down things do you want to turn that up so the brief summary is that in the European world for meaningful security you need to distinguish between the root and the kernel in terms of all privileges in the past it was straightforward for root to modify the kernel in various ways and there's no particularly strong reason to prevent that because at worst they could always edit the kernel on disk and reboot into a new modified kernel Secureboot prevents that and so as a result there is an incentive to lock kernel down such that it's not possible to modify the running kernel in the root which means checking for signatures on modules it means not allowing root to modify the kernel through any debug interfaces or through DEF-MEM or for the or for roots to be able to control PCI devices directly through their resource regions so various things also KXX it's really easy to use KXX to modify the running kernel you can jump back into the first kernel from the second kernel it's not like you actually have to kill users things to do this it's there's a set of patches which may eventually get upstream I spent a while doing that and then Linus said something that we contravened because we fucked up here we're right to repeat it and now case cook has taken over trying to get that upstream but right now it's an external patch set that Debian would probably want state responsibility for we in any way actually obligated it isn't any real state of need but for Microsoft to do that no but if your kernel can be used to subvert security counter-operating systems then you will probably be blacklisted there is not actually anything other than a bunch of typing stopping some of these KXX cultural jokes yeah I know I know that but I mean right now do the words say this the words assume that you're not stupid right but what I mean is Ubuntu is currently just really binary that would allow that you know you would have to speak to two of them to spoilers I can't speak on that behalf I would say this is a really bad idea okay so the is there a question about including this patch set in Debian that you want to discuss or is there something that needs to be done the details well including the patch that seems relatively uncontroversial I think the question is are we going to turn it on by default when booted via secure boot and what will be the point otherwise I mean it's optional then it has no effect I mean it would obviously not be optional in signed kernels question is what do we do with it in other cases I think that's a detail that can be sorted on right so it sounds like this is definitely not this is definitely not blocking anything else we have one minute left the the blocker for everything is getting a key or at most is that something that a single person from DSA can do is require getting several people together so the process is basically we generate the key and then submit a significant request do you mark or something the process is that we generate a key all the equipment form which is then embedded in the ship package which is then forced on you by yourself so we generate the key we decide where you store the key we generate the key you create your own self-signed certificate check package check package hang on how do you do the signing request is that a person that requires you to be the search from a CEO and then you upload the binary through a web form that is recalculated yes using that sitting around for that purpose every other possibility so these types form where does it come in? it's an eV it's an eV it's available for two vendors right now you use that to sign the uploads you use that for anything else you use that to sign the you sign a cabinet which then rotates your file so the question does the existing setup allow for being signed with multiple keys not just for Microsoft so the setup in theory of it being binary back from Microsoft so you add your keys in addition to the Microsoft key and then about 10 to 15 percent of the key to refuse to boot right because it was not in the initial stack it was not usually in the initial stack isn't that what this is doing is it able to use a key on the HP machines that's for to do preloaded slowly not for any other situation obviously if you're pre-loading it on a particular vendor's firmware then you can make sure that it works then so the thing is to purchase an eV generate the key in the self sign pieces that then would be fast on to receive to jam into the shim package that would then be loaded via Windows what stage in this does the shim get packed into a signed package we upload the shim source to Debian get that through Nu well I guess we're not doing source multiple we go out either we upload the binary maybe we want to use that to this package so the binaries are always built on the build deal we get through binary Nu and we have the shim binary package we extract well whoever controls the certificate whoever controls the key that has the eV served the executable puts it in a cab signs the cab and all those steps can be done on Linux then you submit it to Microsoft through the website which has to be done on Windows does anyone tested to see when that site works with the silver light compatible thing built on like I don't think works with any current excessive life resembling chips I kind of figured it's a shot I'd ask it also in our experience can't even be run in a virtualized instance of windows oh you kidding me what so far as we've been able to determine RIS team is not available that particular silver light in application doesn't because silver light in general seems to be for the purposes of submission it does not work so so we can use that could be ineptitude with Windows on the part of RIS team it's not exactly a skill we select so the DSA obtains an eV served and generates the key in the self-signed is that clear that DSA is going to do that or should that be a key manager role or is that in dispute DSA would in fact be in control of the key to manage the hardware connected to make sense for people so then someone from DSA would also be doing the extraction and say is there any value to the two-level setup that we have in the room to so we use the at the moment we have a two-level setup so that we have something which is kept compliant but not approximately kept compliant anyway but not online and an operational key which will retain DSA so I mean the reason my understanding of the motivation for that but I remember it being that we were interested in being able to revoke particular signatures we've done without having to go through microsoft the actual implementation of that is somewhat questionable due to the fact that we don't have the same process for propagation by microsoft has bugs in theory at least we should properly do the same thing I don't know we haven't used it it hasn't been useful to date part of that is the fact that we cannot write to dvx means that we cannot that the way you get around this is by simply grabbing an older version of shim or whatever so we can certainly provide you with the procedure that we use to generate the old market I don't know of anything so let's it's time for this one but I mean when you already have it it's good to just talk about it it was sadly not especially straightforward in both ways so we won't get that to talk I don't mean to forget this but we are very keen to make sure that we do this in a certain piece in my other case yeah great put your name down so it's not that we haven't understand what's needed and we've got names next to our tasks yes yeah are there deadlines for anything are we expecting this all to get in or it will be nice but of course it's going to depend on what you're talking about it would be nice quiet things need to start moving if we actually think we're going to get it done for Jesse which means that the BSE piece will be done in the month oh yeah not the big one within aim but just about so by how do they feel about some pieces can go through new and all that even before then it may not be useful but at least maybe if we're not running the label or anything else okay very shortly after that we should then be able to sort of like work in I will be using sort of sort of so once that filters very shortly after it starts like a signed CD image or signed boot from CD images and that kind of thing clearly I commit to making sure that way you've already done this any way before so we can work through that there are TDS so yes so the way that we do this right now you need it in a you need it in a dev in order to be able to spot upgrades so this means that that we have to to set up those so we need to we have to go up to that signed by DAC machinery later on we upload go up to signed which downloads the signed thing from the archive verifies it against the the keys it expects and it stuffs that into a dev and uploads it and the same will happen for SHIM SHIM works differently because you're waiting for it to come back from Microsoft because we need to verify that Microsoft actually signed the thing we do that but yes, it functions it's not basically a signed SHIM it's really being done in the office it sounds like the DAC that you work with in testing the environment can probably happen in parallel you don't get blocked out unfortunately the SHIM why we use software that particular piece of it is inspired by DAC alright thanks everybody jesse