 So, hi everybody. My name is Paul Moore. If you have any questions and you can't find me this week, that's my email address. But I'll be here Monday, Tuesday, Wednesday. I'm always happy to talk to you guys. So if somebody's got any questions or if you think this is the worst idea you've ever heard of and you are glad to tell me the 37 points, why? I'd love to hear it. Really, you know, if I'm going down the wrong path, please let me know. So, anyway, with that, let's go ahead and get started. So I'm going to start off with a bunch of disclaimers. I usually don't do this, but I feel like Secure Boot, especially when we start talking about TXT, people come in with a lot of misconceptions about what I'm trying to talk about here. So I just wanted to kind of set the stage a little bit. This is not a talk about Secure Boot, okay? Even though I'm going to spend a lot of time talking about Secure Boot, that's not actually what I'm trying to solve here. So please keep that in mind. I mean, one of the things that if this work continues on, it'll obviously be how do we integrate this with different Secure Boot approaches, but for right now, that's not what I'm focusing on. This talk is all about protecting secrets that we're going to store in the TPMs and VRAM. That's the problem I'm trying to solve here. I'm not looking at trying to restrict what kernels you can boot on the system. In fact, as I've found out as I'm doing the development, there's actually some advantages to be had for being able to boot an arbitrary kernel on your system because when you completely wedge it, that way you don't have to jump through a bunch of hurdles to get your development kernel back on. Also, the last little point. This talk focuses on Intel's TXT implementation. The simple reason for that is the machine I'm using for test has Intel chipset, Intel hardware in it. In theory, AMD's SVM should have similar capabilities. I just don't happen to have an AMD system to play with. With that, let's go into the problem. As I said earlier, this is all about protecting secrets that I've got stored in the TPM. This could really be anything, but as the straw man example I'll use today, just imagine we're storing storage encryption keys in the TPM, but really could be anything you want. It's just something that you're going to put inside the TPMs and VRAM and you want to protect. How do you go about doing that? In my particular case, I want to make it so that only kernels, which I've authorized, can actually have access to that protected TPM secret. This third point is the real rub. When I first started looking at this, this third point is what caused me the most anguish. I wanted something that works on a legacy biosystem as well as a UEFI-based system. It's worth noting too that when I say UEFI, I'm talking about both a modern UEFI system that's got secure boot and all that stuff as well as perhaps older UEFI systems that maybe don't necessarily have all the secure boot functionality. I need something that is really as firmware agnostic as possible because I want to run this on a bunch of different systems, old and new. The last part I feel like I had to throw this in because this is kind of an important point as we go on, but I want this to be easy to manage, handle kernel updates gracefully. There's a new kernel all the time these days, and I want to be able to throw a new kernel on there and have a minimal risk that I'm going to get locked out of my system. So if we're talking about, like I said, the straw man example of a storage encryption key in there, if I screw this up, that means I can't boot, right? So that's bad news. We also have stretch goals of world peace, curing the common cold, but that's left for future follow-on work. So this is probably not new to most people in the room, but I just wanted to have a slide to talk about protecting TPM secrets, how do you go about doing that? Well, you usually go about doing this through something called ceiling, which is where you have your little chunk of NV RAM, and you protect access to that by sealing it to a set of PCR values. PCRs are those registers inside the TPM. We heard those mentioned earlier today, so I don't feel like I need to go over it anymore. But basically, ceiling allows you to basically take a subset of those PCRs and use that effectively as a key to lock or unlock those NV RAM sections. And this works well. This isn't something new. This is part of the way the TPM works. And as a result of that, TPM has a lot of provisions in there for protecting these PCR values from being tampered with. So we want to try and leverage this as much as possible. We don't want to come up with a new mechanism if we don't have to. So how do we go about actually getting the right values into these PCRs? Well, this is where I start talking about secure boot. And once again, remember, this isn't a secure boot talk. But we do have talk about this because secure boot mechanisms are usually the way that you get values into these PCRs in the early boot stage before you've got the kernel up and running. And as this was great, because we had talks about this earlier in the day, so I don't have to go into too much detail, you saw before that the various secure boot mechanisms go ahead and populate or extend these PCR values with various parts of the system state. And this is the firmware, firmware configuration, boot loader, kernel. There's actually quite a few different things that get stored into these PCRs extended. And the nice part about this is if any one of those components changes, for example, you put a new boot loader in or you're loading a different kernel, these PCR values will change. And so we can use these as a way of saying, in that ceiling process I talked about previously, we can use this as a good way to come up with the key and we're saying, okay, the system state is what we expect of it. So now I'm going to take a quick little detour. Once again, this isn't a secure boot talk, but we have to talk a little bit, give you a little background. There's two main approaches to secure boot we're going to talk about. Probably the big one, the one that you hear a lot about from the past several years, is UEFI secure boot. And once again, probably not new to anyone in this room, I'm guessing, but quick overview. UEFI secure boot, it's a static root of trust mechanism. It works by verifying the signature of everything that it executes. And this isn't just, you know, the boot loader that your firmware starts up. This is the firmware itself. If you have any PCI add-on cards in there, let's say you've got a RAID controller, a network card that you might pixie boot, it measures all of those option ROMs, which is nice, because you know that anything that's in the system that's going to affect your boot, it's measured and given the thumbs up to. And it does this, the public keys are actually embedded in the firmware by your device manufacturer. And in general, Microsoft controls these master keys. There are mechanisms if you want to put your own keys in, you can do that. However, you have to be careful sometimes, because I talked about the PCI add-on cards. You know, if you want to go ahead and rip out the Microsoft key or revoke that, you might not have access to your PCI RAID controller, which if that's got your boot disk on there, that's going to be a problem. So just something to keep in mind. One thing that is nice about UEFI Secure Boot, which we're going to get into a little bit more, but get your mind going a little bit, PCR7 measures the kernel's signing authority. And this is really great, because it's not actually measuring the kernel itself, it's measuring the CA, which is used to sign the kernel. And that's nice, because that means you can put on a different kernel, and as long as it's signed by the same CA, as long as it's signed by that same key, PCR7 is going to have the same value. So if you're running a Fedora kernel, or if you're running an Ubuntu kernel or whatnot, as long as you stick with that same signer, as long as you keep running Fedora kernels or keep running Ubuntu kernels, PCR7 is always going to be the same. You can load a new patch kernel, PCR7 won't change, which if you remember about the ceiling talk earlier, that's good. We're looking for stable PCR values, and UEFI Secure Boot has that in PCR7. And so now one tells TXT, Trusted Execution Technology. So this is an dynamic route of trust. We already heard the presentation earlier today. It's based on this SNIT ACM, which I was going to tell you what that stood for, but I can't right now. And basically, as we learned, this is a special part of the hardware. It's built into the chipset, it's built into the CPU, and it's a little bit of firmware blob that gets executed, and does a bunch of things, as we saw earlier. But one of the big things is it's got this measured launch environment, which actually does the next step of verification. That's what goes out and verifies and bootstraps the kernel, the NIT RAM, NIT RAM FS, the kernel command line. And in TXT, that's Tboot. You probably all heard of that, probably haven't used it, but you at least know that it exists. And we heard about that earlier today as well. And for these, not quite as nice as UEFI Secure Boot. Tboot, once again, makes all the measurements, stores them in the PCRs. But in the case of Tboot, those PCRs are based on the hash of the NIT RD, the kernel and the kernel command line. So whenever you throw in a new kernel, whenever you just change the command line arguments, you're going to get a different value in these PCRs. So it's great in the sense that you can detect them when the kernel changes, but for our purposes of having something that's stable and easy to manage across kernel upgrades, it's not quite ideal. So how do we go about solving our problem? Well, first we want to look at what we have for Secure Boot and how can we apply this to our problem. UEFI Secure Boot, it gives us a stable PCR we want. Downside is it only works on modern UEFI systems. Now, that's still a lot of systems, right? And so for most people, that's probably sufficient. But in my particular case, I need to support older systems as well. So this is kind of, I hate to say, it's a non-starter right out of the gate for me. The next thing is Intel TXT. This works on older legacy biosystems. It works on UEFI systems, old and new. The one little asterisk I'm going to put on here, for anybody who hears this talk and was like, I want to play with T-boot now. If you've got a UEFI system, some distributions don't build the multi-boot capability into Grubb for reasons which are long and involved. Mainly relating to UEFI Secure Boot. So if you want to play with this, you might have to go out and build your own Grubb to enable multi-boot to support. It's the only little thing I'll mention. If you actually want to do that, let me know, come and talk to me. I can give you some other tips, too. Anyway, so Intel TXT works everywhere. This is great. The only problem is we have that unstable PCR problem, which is also a bit of a non-starter for us. So without getting into some weird esoteric stuff, these are our two main secure boot options, and neither one works. So what can we do to fix that? What are some of the lessons that we can take from this? The first one is that signature-based PCR measurements are the way to go, right? Based on hashes, it's great. It tells you in every little particular kernel or NIDRD changes, but that's not what we're going after. This isn't one particular laptop where when we make a change to the kernel, it's easy enough to update. This is something where I deploy in a data center or in a locked closet somewhere and just never have to touch the system. So we want to make sure our PCR measurements are based on signatures as opposed to hashes. We also always talked about this. We need something that works on all the different firmwares. That's TXT. And the other important part about this, this last part, it's a little difficult when you want to start playing around with UEFI secure boot because the magic in UEFI secure boot that allows Linux kernels to work with the Microsoft signed firmware is something called the SHIM, which some of you may or may not be familiar with. And that needs to be signed just like every other part of the system. And getting a SHIM signed by Microsoft is not necessarily a trivial task. This is where your favorite Linux distribution, if you ever run across the person that's in charge of their secure boot approach, buy them a drink the next time because they have to go through a lot of stuff to make that work for you. And once again, you can put your own keys in there so there are steps around this, but there's some trade-offs that come with those. So anyway, the nice part about TXT is that all the verification of the things that we care about for this particular problem, the kernel, the init-rd, the command line, that all happens in Tboot. Tboot is just a piece of software. It's not that SNIT ACM blob that lives off in the firmware and has to do magic with the chipset and the processor. This is just a bootloader that you and I can update and do what we want to. So that makes this problem now something possible. And so that leads me into the proposed solution. It's pretty simple. Basically, what we're going to do is we're going to extend Tboot support to enable signature verification using the PECoff format. First of all, you can laugh. That is a TPM joke. Extend. Yeah, okay. Thank you. Somebody had to laugh. That's also why you don't do slides late at night. But anyway, so the PECoff format, for those of you that don't know, that's the signed kernel format that gets used for UEFI secure boot. So the nice part about this is you can take all of the same build infrastructure you might have, all of the same kernels. You could take your Fedora kernel. You could take your Ubuntu kernel and use it with this approach. You wouldn't have to change anything. You don't have to hold of that certificate, the public key that they used to sign it and put it as part of the policy, but you can do it so you don't have to come up with anything new in that regard. So basically, we extend Tboot and then to do the actual verification of the PECoff format, which is kind of ugly, I'll be honest with you. And then the other thing we have to do is we have to extend the Tboot policy format, because Tboot is actually somewhat flexible in how you define the measurement policies and the enforcement. So we need to extend that to contain not just the hashes that you want to allow, but we need to extend that so that it has support for the signing authority CA. Like I said before, no changes to the SNET ACMR required. So this is something that you can do without having to get in and get some sort of NDA from Intel or AMD and do all that stuff. So open issues. So the big thing is that as it stands right now, there's no signature verification of the NITRD or the kernel command line. And this is a problem that's shared with UEFI secure boot as well. At least with Tboot, you can measure those things, but it's just a hash measurement. So there are existing digest verification mechanisms for the command line and the NITRD that would work. It's also possible that we could reuse some of the work rounds that the UEFI secure boot people have been doing. I'm not sure if you're aware of this, but you can actually take your kernel, your NITRD, and your command line and smoosh it all into one blob that's bootable and execute it there. And that's what the UEFI secure boot people do from what I understand if you want to protect everything. And in theory, that should also work with this TXT solution because once again, we're sticking with the same format. The kernel already knows how to unpack that NITRD and the kernel command line, so that should work. I say this without having tried that yet, but theoretically it should be there. There's also the open issue of just I don't know how receptive the Tboot upstream is going to be on this. The prototype is still a work in progress. My goal is to, once I have something that at least works and it's a demonstration that people can play with, to post this to the Tboot mailing list and get their feedback on this, but like I said, I want to have something that's working first. If Intel and the Tboot people aren't interested in, you know, taking this on, I'll be honest with you, it's unlikely that I will probably fork and continue this as a separate project, but that's the way it is. I would be if anyone was interested in doing that, I'm more than happy to hand it off. And so the current status. Modifications to Tboot are ongoing. I've got it right now, so that Tboot does actually manage to verify all the different PE cough digests. And once again, I don't know if you've ever played with PE cough, but there's a few different digests to verify. Everything checks out okay. So that means that basically Tboot can safely sign UEFI kernel. That's not a problem. And that Tboot also doesn't do anything bizarre with the kernel. It doesn't munch anything so that the digests no longer check out. However, the signature verification part, the thing that you really want to work, that's still failing. The code that I've written, which actually does that, it does work in the little user space test harness I have, but I just screwed something up when I pulled it in Tboot. It's entirely likely because I write crappy code and also because the Tboot environment is very interesting. It's like every other kernel or low level environment. There's no libc. There's nothing. So I had to write a bunch of basically like libc function replacements and there's even some heap allocation that goes on in there so that I can, you know, simulate a malloc for some of the crypto libraries that I pulled in. And that's ugly enough that we won't talk about. So anyway, so it's failing, but it's largely probably just due to errors on my fault or on my part, rather. And I basically had to stop working on that so that I could come here and put these slides together. So I do expect to have this working soon. I am currently slated to talk about this in the Link Security Summit in France in a few months. So if you're going to be at the Security Summit in France, hopefully I'll be able to give you a completely different story and fill in some of the blanks here. But that's where we're at currently. There's also some challenges around licensing. T-Boot is kind of the standard BSD, you know, very permissive license. A lot of the crypto libraries and the Peacoff libraries that I could find were not. They were GPL or some other. So a lot of the stuff I had to kind of write from scratch, which was not ideal, but sometimes you got to do that. So anyway, that's where things stand currently. If you have any questions, I wanted to leave a bunch of time and we actually do have a bunch of time here, so I'm more than happy to answer any questions you have. And like I said, I'm here up through Wednesday. That's how you can get a hold of me after the fact if you're more comfortable that way. Where would I be without Casey? So what's your end goal with this? Sorry. What is your end goal? What is my end goal? To be able to protect secrets in the TPM regardless of what the firmware is. There's no follow-up to that? That seemed like a loaded question. All right, I guess not. Since you're only concerned with the signing authority, are you doing anything to prevent kernel rollback to like an earlier less secure kernel or anything like that? Yeah, so I think there's an interesting thing about revocation and all that. For right now, the goal is just to prove that this works and that this isn't too terrible and impossible and that this might be something that the Tboot people would want to take on. There hasn't been any real serious thought given to that. I mean, it's entirely possible. If you wanted to, if you're really concerned about that, you know, you could also look at... My goal would be to not replace the TXT hash measurements. So if you were concerned about that, you could also do something with the hash verification, the digest verification that's in Tboot and probably any other number of ways to solve that. But I haven't put any serious effort into a solution for that yet, no. All right, so you kind of touched on it a little bit. I'm back here, sorry. Yeah, sorry, thanks. Have you looked at the discreet and authorities mechanisms that's defined in the TCG on this? Because they addressed this specifically, of splitting the signing authorities away from the data hashing. No, I haven't. But can you give me a one or two-minute explanation? So it's exactly what you're discussing, right? There's the discreets, which is your code blobs. They get hashed into one PCR and your authorities get hashed into a second PCR. TXT has adopted that since the 2.0 to move to TPM 2.0 and Tboot doesn't do it today. Like you said, it just hashes everything. But you could, in theory, make it follow that pattern. Now, is this, so there's the... And you'll have to forgive me, I'm notorious for swapping these around. So there's the launch control policy, which is actually used to measure Tboot, for example, the measured launch environment. And then there's the verified launch policy, which is actually part of Tboot. And my understanding is that the launch control policy can be signed, and I believe that that's supported, but that the verified launch policy, which is implemented by Tboot, does not support that. So that first part, they do support signatures so that you can change your BIOS, for example, and you'd still be okay. So this isn't the LCP. This is what the ACM does when it does its measurements, or it actually does the authority measurements. It measures its ACM key into the authority's PCR. But that doesn't help us with the kernel, though. No, and that's my point. If you take that further and continue the discreet and authorities for the kernel stuff inside of Tboot, then you would get back to the rollback question. You could have the signature, the hash of the data in one PCR. So if you want to check that, and then you have your authorities in a separate PCR that you can give you one to enforce that. Yeah, and I think what you get right now, Tboot, I think uses 19 and 20. Correct. So I mean, there's provisions for where you could do something. Assuming that you're okay changing how 19 and 20 behave. So 17 is used by the ACM and TXT, and then 18 is used by both of them for the authorities. Yeah, and then your VLP just specifies whether you want to do 19 or higher. Sure. Yeah, I mean, that's a possibility. I mean, definitely want to look at using a signed approach for the launch control policy for similar reasons why we want to use signatures for here. So yeah, extending both those signing authorities into the same PCR would be very reasonable. But I still got to get the code working first. Thank you, though. One note, we forgot to grab. Sorry. You told that currently, as I remember, Red Hat and Fedora disabled multi-boot to... sorry, multi-boot protocols due to some security concerns. Currently, this issue is removed in upstream grab, and if you wish, we can discuss a bit longer after the presentation that. And one suggestion we forgot to... and signing. Currently, PESign tool, as I remember correctly, provides something which is called detached signatures. Of course, you can use this thing just for PECO files, but maybe you should consider such a solution in IDRD. Also, grab supports PGP detached signatures, so maybe it is possible to do something similar, which is provided by grab and by PESign. So that's it, I think. Yeah, and I mean, I want to say to start off, I haven't had a chance to look. I saw the trench boot on the agenda, and I saw the abstract. It should be actually interesting. And obviously, I saw your talk earlier today that the two of you gave. And so it's something I definitely want to follow up on, and look, I mean, LSS is a very busy time, as you know. So a lot of times I end up collecting bookmarks, and then when I get back, I kind of start digesting it. So don't be too surprised if you guys... if this actually looks reasonable and ends up working out for my needs, you might get some email from you guys, and I think we have very similar goals. Perhaps not the same, but I think there's some overlap there. And yeah, as far as all the different signatures and detachment went out, those are all things to look at. My goal right now is to get at least a prototype stood up that works, and then there's all sorts of things. Like how do you handle the NITRD? How do you handle rolling back to previous versions? All that sort of stuff. But right now I just want to get something to sample and to see if the T-Boot people are even interested. But even if one of the things I've taken away from TrenchBoot is even if T-Boot is not interested in supporting this, there might be something we can do with upstream grubs since you're basically replacing T-Boot in a lot of the ways. That was one of the takeaways I had from your presentation. So yeah, so anyway, I'm sure we'll be talking in the future. Even if I don't get a chance to sit down with you during LSS, I'm sure we'll be exchanging some email at some point. Thank you. My question... Sorry, thank you. My question here is you're sealing some data based on the PCR value that you expect the T-Boot to write. So what prevents some unauthorized kernel to put that similar value in the PCR and get access to the data in the DPM? So what would prevent someone from going on and... Are you talking about... There was a presentation a long time ago now where somebody actually loaded a hypervisor in before the executed T-Boot and then something like that. The generally accepted solution for that was basically that TXT and T-Boot wasn't fully leveraging the TPM, like there was nothing stored in the TPM because you can emulate a TPM, but unless you happen to know beforehand what that secret is inside the TPM, you can't really successfully fool whatever is lying on top, whatever is using T-Boot for verification. And in the particular case that I'm looking at, since I do have secrets stored in the TPM, that shouldn't be an attack vector I have to worry about. However, if I'm missing something, please let me know. No, like you install a kernel, right? And then it's signed by a key, so you seal the data based on that certificate authority. I can go and install a totally different kernel. I may not even use T-Boot, I might use Grubb or something. And then I can still get access and rest or so. You're not targeting that kind of attack? So where basically a malicious kernel would go in and impersonate? Well, this kind of gets to that whole point of these are kernels that I've authorized, I've signed this kernel, and so I think implicit in that signing of the kernel is I'm not just physically signing it with my digital signature, I'm also signing off from a perspective of, like, I verify that this kernel is not malicious. You know, this kind of goes to the point of, like, don't run random things off the internet, don't take a random kernel that some guy off the street gave you and sign it with your key and boot it. But it's okay to use curl to get something from a website and then pipe it into sudo. That's totally fine. No problem with that. My question is a follow-up to her question, actually. If you do not assume that the system has UV and secure boot and you do not validate T-boot's signature itself, how do you ensure that T-boot is... Well, I never said I didn't necessarily verify the T-boot signature itself. I mean, part of the, and correct me if I'm wrong, guys, part of the launch control policy can measure the T-boot signature. And I think for the same reason, so it's a very similar question was posted earlier in the talk, you know, what about some of the static root of trust measurements? You definitely need to make sure that the T-boot that you're executing is your T-boot, because otherwise... I mean, how, without UV secure boot, how? How do you do that? Yeah. So T-boot now and the S&A ACM as part of the launch control policy, the ACM code looks at a hash, measures T-boot, and then it looks at a hash as part of the launch control policy and compares it, and if there's divergence in it. Okay. So that provision is in there, because you're right. I mean, definitely, if somebody else has, you know, put in a malicious T-boot, then all bets are off, right? Yeah. I think that did I... He's begrudgingly knotted, so I probably got about half of it wrong, but I'm not seeing any other questions and I'm standing in the way of you open coffee break, so... Are we good? Thanks, Paul. All right. Thanks, everybody.