 So I'm going to be talking about today. I'm going to be talking about securing TPM secrets with TXD and kernel signatures. Rolls right off the tongue. But first, I've got a disclaimer like some other people. The mind's not legal. It's a little more technical in nature. I'm not talking about secure boot today, but I will be talking a lot about some of the secure boot technologies. A lot of what I'm trying to do is not necessarily prevent you from booting a kernel or a different command line or a different NITRD on your system. I just want to make sure that if you're going to access secrets that are stored or rooted in the TPM, I want to make sure that you're running a kernel that I've authorized with a NITRD and a kernel command line that I've approved. And so I use a lot of the secure boot technologies to do that, but I'm not trying to implement secure boot in the traditional sense of locking out invalid or unauthorized OSes from booting on your system. Also, I'm focusing on Intel's TXT solution. Although, in principle, you can take the same approaches that I've talked about today and use it with AMD's mechanisms as well. It's just the system testing and developing on happens to be an Intel system, so that's what I'm using. So first of all, what is the problem? What am I actually trying to do here? Well, I've got a bunch of secrets that I want to store in my TPM. For the sake of arguments, let's just say these are storage encryption keys, but really, they could be anything that you want to store in the TPM. As I kind of alluded to on the last slide, I want to restrict access to those secrets to just kernels that I've authorized, kernels that I've signed. Now, I'm saying that I've signed, but really, this could be anyone that you trust. So if you happen to trust your distribution vendor, that's fine. Doesn't really matter from this particular case. And here's the kicker. I need a solution that works both on the latest and greatest UEFI systems, but I also need this to work on older UEFI systems that maybe don't support UEFI's secure boot, as well as older systems that are still booting a legacy BIOS, or newer systems that are still using legacy BIOS for that matter. And finally, because I like making things difficult, I want to make this as easy to manage as I can. I need it to be able to handle updates gracefully. These might be systems that are stashed away in a data center somewhere, and I need to just be able to do a system update on it and not have anybody go out and touch the system, because that's difficult, that's hard, it's error-prone. Something will go wrong. So that's kind of what I'm trying to solve here. So first, we know we've got secrets in the TPM, so a quick little refresher slide on how you actually protect things that are stored in the TPM. Hopefully, this is not new to anyone, but common way of securing secrets that are in the TPM are to seal them against a set of PCR values. Once again, common approach. The TPM protects these PCRs from tampering. It works really well. We've heard plenty of talks so far at this conference and in previous conference about this, so I don't want to go into too much more detail. But if you have any questions, feel free to interrupt me. So OK, great. So we have the TPM with our secrets in it. We've got them sealed to a specific set of PCRs. How do we actually go about setting the PCRs, especially in early boot? Because some of these TPM secrets that we have, we might need to access before we've got a full user space up. For example, if this is a storage encryption key, this might be the encryption key that we use to protect the root file system. So we need to be able to unlock this as soon as possible. Or at least I want to be able to unlock this as soon as possible for this example. So the easy way to go about setting these TPM PCRs is through secure boot. Once again, it's not a secure boot talk, but I'm going to be talking a lot about secure boot. Secure boot measures the system states into these PCRs. I think once again, this is something that we're all aware of, not necessarily new. This could be the firmware itself. This could be the firmware configuration, boot loader, kernel, et cetera, et cetera. And the basic idea is we heard this even in the last talk. When these components of the system change, the PCR values change so that you can detect when something has gone on. So pretty good way to do this. And now we're going to detour even further off into secure boot, and I'm going to give you a quick little overview of a couple of the main secure boot mechanisms. There's obviously more approaches to secure boot, but at least in the generic X86 world, these are the two big ones. First one, I think we all know about this UEFI secure boot. It's a static root of trust model that builds up a root of trust by verifying the signature of each firmware blob that it executes. This includes the main system firmware, as well as the firmware of any PCI add-on cards you might have, such as RAID controllers, network cards that might be doing Pixie or iSCSI or who knows whatever else you might have. The public key is embedded in the firmware. I think we all know that Microsoft controls the primary keys, and that's important because even though you can add your own key into there, you're still probably going to be relying on that Microsoft key if you're using any of those PCI add-on cards because odds are you're not gonna be able to get the company that ships you your RAID controller card to use your individual key to sign their firmware. If you do manage to do that, just shoot me an email, let me know how you did that because I'd be curious. Anyway, UEFI secure boot works pretty well for what we're doing. PCR7, if you're not familiar with UEFI secure boot, PCR7 is a hash of the kernel signing authority. So this is basically the certificate that's used to perform the kernel signature. So this is great. This would effectively get me what I need. This gives me a nice, stable PCR in the TPM that I can use to seal to, and it's gonna reflect the signing authority of the kernel. So I could sign my kernel and I could see a nice consistent PCR value in PCR7, and as long as I didn't change my signing key, it's gonna be the same no matter what kernel I run. So if I only had to worry about modern UEFI systems, this would probably be a great solution, but unfortunately I'm not quite that lucky. Which kind of brings us around to the other secure boot technology that we're gonna kind of focus on today. And I'm gonna go through this slide kind of quickly because I've got some more diagrams towards the end of this talk where I'm gonna go into how this works in detail. But basically the big difference is, whereas UEFI secure boot is a static root of trust, TXT is a dynamic root of trust. And what I mean by this is TXT doesn't necessarily have that iterative approach where it's going to verify the signature on every firmware blob that it loads and executes. It's going to be triggered by the processor when it executes a specific instruction. It's going to load something called the SNIT ACM, our authenticated code module, which lives in the firmware. It's shipped on most systems that support TXT now. It used to be you had to go out and get it separately, but I think those days are mostly passed. And this firmware works in conjunction with some special magic in the processor and in the chip set and other parts of the firmware to basically kind of throw up a hard boundary so that anything that happened on the system previously can't influence what you're about to do next in this DRT, this dynamic root of trust kind of measurement phase. So it's unfortunately it's closed source, so you can't look at the ACM. So that's why I kind of say it's a little bit of a magic here. But it is kind of a neat bit of functionality. So once you're in this little bit of magic code, you're in this DRTM environment, this is where the measured launch environment kicks in. And this, if you're familiar with Tboot, which is the boot loader that handles TXT for Linux, this is where Tboot comes in. This is where you can go ahead. You can measure the kernel, your NITRD, your command line, basically do any other sorts of measurements that you want to do. And you don't have to worry about, like I said, a malicious firmware or something that was there previously coming in tampering with you. You've got a clean state. There's only one core that's executing on the system. All the memory mappings have been locked down. So it's a safe space for you to do your measurements. The one unfortunate drawback is Tboot, as it works right now, just does hashes of the kernel, the NITRD, and the command line. So every time you load a new kernel, every time you change the command line, every time you have a different NITRD, those PCRs are going to change on you, which makes it difficult. Whenever you need to apply an update, those PCRs are going to change. It's not a stable base for you to seal your secrets to. So now we've got a little understanding of secure boot. We know what the problem is. How do we actually go about solving it? Well, as I said before, we need to use secure boot because this is really the only way we can set those TPM PCRs before the kernel and the user space are up. And of our two options, we've got UEFI secure boot, which gives us a stable PCR. It's great. It only works on modern UEFI systems. So that's a deal breaker for me, maybe not for you. Intel TXT works on all the systems, pretty much made from quite some time from Intel. But it doesn't have that PCR stability that I need so that I can seal secrets to. So lessons to kind of take away from this. Signature-based PCRs are stable. That's good. TXT works regardless of the firmware type. So that's also good. I'm going to say there's a little bit of fine print here. If you're looking at most modern distributions, which support UEFI secure boot, specifically Fedora or REL, if you're using Grub, they disable the multi-boot 2 capability, which is what you need to boot Tboot. It's a chain loader. So if you're going to try to duplicate any of this on Fedora, you do need to rebuild your Grub so that you can do this or use some other boot loader. If you're interested in doing that, come talk to me. I'm here all day. I'm more than happy to explain how to get that working. But it's kind of a little more involved than we can do in 40 minutes today. But yeah, sorry. And the one last little lesson to take note here is that when you're using TXT, the verification of the kernel, the command line, the init-rd, that all happens in Tboot, which is a piece of software. So it's not this magical piece of firmware. It's not hardware. It's not a piece of software that needs to get signed by Microsoft or some other identity. This is a piece of software that you can modify and do whatever you want with. So this kind of starts opening up the proposed solution. This gives us a path forward. What we're going to do is I'm going to extend Tboot to support signature verification using the PECoff format. First of all, if you're a TPM nerd, did you catch the little joke? Extend, yeah, yeah, yeah. OK, second time I tried this. Didn't work the first time either. But anyway, so the PECoff format, if you're familiar with UEFI Secure Boot, this is the format they use for their signed kernels, both Windows and for Linux. So if we can leverage that same format, this means that you can have a build system which just churns out signed kernels, and it'll work UEFI Secure Boot as well as this proposed solution. So you don't have to do anything special. In fact, the prototype I've got working right now, I can just take a stock Fedora kernel, and it just works. I don't need to rebuild it. I don't need to re-sign it if I want to use the Fedora signing keys, and it works just fine. The other thing we'll need to do, in addition to teaching T-boot and giving it the smarts to handle this format and do all the signature verifications, we also need to extend the T-boots policies to have support not just for the hashes, but we want to give it support for the certificates that are used to sign the kernels. So that's it. There's no changes to that SN8 ACM, so you don't have to worry about loading a new firmware blob or anything. These are all changes that you can do. You can look at the source code, build your own binaries. It just works. So here's where my horrible diagrams come in. This is actually the TXT boot process, and I know the T-boot maintainers here. My apologies if I screwed this up a little bit, but this is how I understand it to work, and I'll try to make note of how it works currently and the changes that are going to happen as part of this proposed solution. So the first thing is your system comes up. You've got your boot loader, grub, whatnot, and you need to chain boot into T-boot. T-boot is effectively its own boot loader, so if you're using grub, you use the chain loader mechanism, and you fire up T-boot. And the first thing a T-boot does is it basically performs the usual number of Sandy checks. It makes sure that you've got the right hardware and firmware so that you can actually do TXT, and that's pretty much it before it starts the DRTM process. And then T-boot goes ahead and executes that special CPU instruction, which then jump starts this whole TXT process. This fires up the ACM code, which goes off, does its magic, locks down all the other cores, protects the memory, does all these wonderful things. And some of the important parts that it does is it actually verifies the, I might be getting ahead of myself. This is where I should have paid more attention when I was doing these slides. Yeah, so OK, so it sets up the system, and it gives you this nice, safe DRTM environment. And then you've got the TXT launch control policy, which is rooted in the TPM. And when I say rooted in the TPM, it's not actually stored inside the TPM because the TPM has a limited amount of storage space, but it's a signed blob. And it's verified by secrets that are stored in the TPM. So you don't have to worry about that. And this launch control policy, this goes out. It's configurable by you. And you get to tell it what you care about on your system. So you can have it go off and measure the BIOS on the system, the firmware configuration, and most importantly, the T-boot binary itself because you want to ensure that you're running the T-boot that you think you're running. Because obviously, you could go ahead and load in a malicious T-boot, which would do all sorts of things and bypass all your wonderful protections. So at this point, once the launch control policy has been executed and it's signed off on everything, you know that the system has booted up the T-boot that you expect it to be running, all the firmware checks that you've told it to enforce have been validated in the systems in an OK state. And at this point, it hands control back over to T-boot itself. And this is where some of the stuff starts to come into play that we were talking about with the kernel signature verification and whatnot. And this is in the TXC terms, this is the measured launch environment or T-boot. And from here, we have another policy. It's called the verified launch policy. It's actually kind of contained inside the launch control policy, but conceptually, it's easier to think of it as a separate policy, I think. And here on the current TXT, this is what has the hashes of the kernel, the NETRD, and the command line that you want to, that you're basically going to authorize to start up. I'll be extending that so that we can optionally insert certificates as well. And you can use those so that as long as the kernel and NETRD whatnot has been signed by that certificate or something in that certificate chain, it'll get authorized. And once again, rooted in the TPM, so you've got a nice way of verifying that this is the policy that you've set up. And T-boot just basically goes through and performs either the hash checks if you're using hashing, or it goes ahead and does all the signature verification if that's what you're doing. And then finally, when it's done, one of the last things is it updates the PCRs. Right now, there's a handful of PCRs that does, and it updates those with basically the signature of the policies that it's been using for verification, as well as the hash measurements of the kernel that are being whatnot. Moving forward, and this is still kind of TBD, this is a work in process. But we're also going to include somewhere. We'll have the hash of the signature authority which is used to sign the kernel. So that will be much like we had PCR7 with UEFI secureboot. This will be a similar concept, and that will have a nice stable PCR that we can use for sealing data that will stay constant as long as the kernel signing authority stays constant. And then, once all that is done, then Tboot, like any other boot loader, goes ahead, bootstraps, and it starts up the kernel, using the kernel and the NETRD that it's verified. That's pretty much it. So current status. Prototype is still a work in progress. The kernel verification is working. I'm not actually enforcing anything, but the Tboot code does actually go out and check the kernel, make sure the signature checks out and all that. Just recently, just before I came here, I got it working with certificate chains, which is nice because most people aren't necessarily going to have just one self-signed certificate that they use. They're going to have a chain of things. The policy, the extensions to the Tboot policy to support signature verification, as well as updating the PCR, those are both works in progress. That's what I'm moving on to next. But that, in theory, should be much easier than doing the signature verification. At least, hopefully, there'll be a lot less ASN-1. So anyway, prototype code. There's a link to it up there. Make sure you check out the working TXT SIG branch. The master branch is basically as an import, a fork of the core Tboot code. The TXT SIG branch has all the changes. Now, I will caution you, this is prototype quality code, so please don't judge me by this code. It's kind of ugly still, but it's getting better. So anyway, if you're interested, feel free to check it out. On the off chance, this is something you'd like to contribute to. Definitely check it out and send me some email. I'd be more than happy to have some help. Open issues that we still have to resolve. We've been focusing a lot on the signature verification of the kernel itself. Haven't necessarily looked at the initRD or the command line just yet. However, this is a problem for UEFI secure boot as well. And there are a few workarounds for UEFI secure boot. They're actually kind of cool. You can bundle the initRD and the kernel command line into one big blob that gets executed. It's kind of cool. So that theoretically should work with this approach as well. So that would probably be the easiest thing to do. But obviously, if there's another approach, we can adopt that too. Like I said, this is really kind of still a undefined to be determined thing. Yeah, and in the meantime, even if we don't necessarily solve this the way tboot works, you can still use the digest hash verification for the command line and the initRD. That would still work. It would somewhat go somewhat against what we're trying to accomplish, but that is a fallback of nothing else. And lastly, upstream acceptance is still a bit to be determined. My apologies if I'm putting words in your mouth, but I think so far the prototype has been well accepted. And we'll be having some talks with the maintainer later today. So hopefully we'll nail that out. But anyway, that's it. If you have any questions, that's my email, that's my Twitter. You can feel free to get in touch with me. And like I said, I'll be here for the rest of the day as well. And I think we've done pretty good on time. So I think we've got questions. Questions? See, I wasn't kidding. It was a lot more confusing, wasn't it? Oh, there's one. Saved by the tboot maintainer. Great speech, thank you. My question is, how is your idea to store a certificate for verification? Because storing them in TPM, in my opinion, isn't a good idea. So you have to manage some other way to pass it to tboot in some secure way. Excellent question. And I'll just preface it by saying this is still a work in progress. So I just got certificate chains working before I came out here. I think the initial goal is they'll obviously need to reside as part of the policy, the verified launch policy, which is currently, as I understand it, stored inside the launch control policy which exists outside the TPM with the signature being verified by a key that's stored inside the TPM. So I think by storing it in the policy and not inside the TPM, that should alleviate the problems of limited TPM storage. Or so I envision it. If you see any problems there, please let me know. All questions? Great talk, thank you. I wasn't clear on the order of the components during the load. I mean, is there a secure boot loader? It's Linux, sham, grub and tboot and what order do these? Sure. Yeah, no, and it is a bit confusing. That's a good question. So if you look at this slide, so the boot loader at the top, I've been using grub for my testing. So feel free to substitute grub for boot loader at the very top of this slide. Other boot loaders are available. But anyway, so grub would go ahead and chain load into tboot and that's basically what we're seeing here. And then tboot, ignore all the magic that tboot does. tboot then once it's actually verified everything and signed off and systems working as expected, then tboot effectively acts as a boot loader and it loads the kernel that it's measured and signed off. So it's really, you can think of it, it's not a whole lot different if you remember dual booting windows back when that was kind of popular. You'd have grub that would go off and do a chain loader into your windows boot loader and it would go from there. Very similar concept here. We're using grub, at least in my testing, I've been using grub to chain load into tboot which then goes and loads the Linux kernel. Is there a Linux shim just before grub? No, there's no shim. This is one of the things that I kind of like this. In some ways, not that I have any reason to distrust the UEFI secure boot shim or whatnot but you do have this binary blob that you can't really build and modify and in some sense this is a little more appealing to me because you can go out and you can build tboot and you can run tboot and I can know that the tboot that I'm running is the tboot that I built. Now you still have to rely and trust that the system firmware is correct, that that ACM blob isn't doing anything malicious but realistically you already have to trust your system firmware anyway. So I don't see that as really any additional trust that I'm not already placing in my system. But no, tboot, there's nothing magic to it. You can go grab the sources and rebuild it yourself. Okay, thank you so much. I have questions. If not, let's thank Paul.