 My name is Cole. I'm going to talk today about TPMs and how we've used the TPM to provide some secure attestations using Spire. My name is Cole Kennedy. So a little bit of the work I've done recently. I co-authored the CNCF Secure Supply Chain Best Practices paper. I've contributed to Spire and Toto and a lot more open source projects. Open source is really a passion for me and I think it's really driven a lot of our innovation forward over the past 10 years. I'm a security and dev tech architecture SME. I've done architecture and security for Duke Energy, Colorado State University, Platform One, GBSD. And then most recently I worked on the city secure software factory. SME with air gap and high compliance networks. And then I'm also a Iraq and Afghanistan veteran. So I work for a company, thank you. I work for a company called TECSER. I own TestifySec. We just launched last Wednesday. So we're providing cybersecurity professional services and software to enterprise and federal customer. We're focusing on software supply chain zero trust, automated governance and open source software risk management. But enough of that. So what are we doing? We want to use workload identity to secure systems all the way from source to production. So when we threat model CI systems, we're looking at three different things that we really need to attest. We need to attest the materials that are going into that build. We need to attest the environment that the build is taking place in. And then we need to attest the actual process that is acting on those materials in that environment. And then we need to protect private key material with trusted hardware. And that way our attacks are either limited to hardware attacks, which are tough, or critical software components that we know to monitor. So really what we're trying to do is we're trying to understand what was a system state when we issued that identity. And we're using Spire to do this because TPM policy is pretty difficult to manage per machine. We're using fleets of machines that are ephemeral, they're coming up, they're coming down. We're changing them all the time with these immutable states. So if we got to change the TPM policy for that, the tooling around that might be a little bit complex. And then Spire provides an identity management engine. This identity management engine is federated, it's distributed. And Spire, best of all, it's really ready for production deployment. We've been running Spire in some production deployments for various customers for a long time. It's been rock solid, we really love it. And its plugable design really meets needs for complex use cases. You can take Spire and really make it whatever you want it to be. So Spire is a community project and it's backed by a bunch of major corporations. We've got a bunch of corporations are in this room like VMware, HPE. So it's a project that has money behind it and really good solid devs. I consider Spire high assurance open source. So again, that TPM that we're talking about, that's going to provide selectors for Spire's identity issuance. The Spire selectors framework works really good with the TPM. You'll see that in a second. The architecture of Spire really simplifies how we use TPMs in our system. And finally, Spire provides some really good APIs that allows us to build on our secure systems. So what are we going to show you today? I'm going to show you remote attestation of a machine or edge system if you want to use the marketing term. So with a cloud-based Spire server. So cross your fingers, please pray to the demo gods now. Hopefully it works. And then we're going to use the use of the TPM platform configuration registers to remotely attest that system. We're going to test the boot state of that system. And then we're going to issue an identity to that system based upon the public hash of that attestation key and that boot state of the system. So let's go back a little bit and talk about what is a TPM? Why is it important that we're building secure systems around this device? So there's different types of TPMs. It's really important because they all have different threat models. So you have a discrete TPM. This is what the trusted computing group considers the most tamper resistant. Most of our TPMs that we're going to be talking about, I think, are going to be integrated TPMs. And that's going to be a hardware component that's integrated onto the chip. There's a firmware TPM, right? And that's actually integrated on that CPU. Those might be vulnerable to like management engine attacks, for example. There's a software TPM. Don't ever use these unless you're testing. There's really no use to actually secure an environment. They may be good for metadata if you're in a trusted environment, but really TPMs are not that hard to find. And then virtualized TPM, right? So if you're running Cloud, if you're running your builds in the Cloud, actually Google actually gives us a shielded virtual machine that includes a virtualized TPM. And there's some proofs that they have about how secure that is. So you can go ahead and look at that yourself. And then if you're using like a virtualized system, I know VMware or KeelMU also offers TPMs. So TPMs, right, they can do a lot of things. They're the list of some of the things they can do. But really today, well, we're going to focus on our two things, right? We're going to focus on platform identities, and then we're going to focus on the protective persistence store, right? That's where our PCRs are going to be. So how do we use a TPM for identity? Wow. Look at this. We have selectors that we can select identities on. So with a TPM 2.0, you see we have these PCR registers and we have some hash that identifies that system state. Also, we have the public key hash or the CA certificate hash, right? This TPM plug-in was actually forked from Bloomberg to Boxboat and then we forked it from Boxboat. So there's a lot of different things you can do with this. And then also, we're going to get that process identity from the workload API. So what does this trust actually look like? How does it work? Well, the server takes the attestation data that was provided by the agent and encrypts it with the public key, right? So then we take that and we ask the agent then to decrypt that. If the agent is able to decrypt that, right? We know that the agent is who it is. The agent owns a private key for the public key that we have. So we take that public key hash it and use it as an identity selector. Not shown in this, but there's also PCR data that is attested. So we need to do TPM quote verification. It is going to want what you want to look up on that. But we actually do that to verify that those PCR registers are in fact what they are on the server side. So what exactly is in a PCR register? Well, here's an example of what normally is in one for an x86 PC. Now, depending on where your TPM is, right, that's going to dictate what gets put into it. A device manufacturing can change this, but trusted computing group, this is generally what we're looking at. So what we're going to look at right now is PCR4 and PCR5. That's that master boot record. Now, if we have a hash of that and we have a hash of the config, we can assert that nothing changed in that MBR and our boot state is what we expect it to be. Also, we can select on the BIOS hash, the option ROM hash, right? All of this. One that you might not want to use there is PCR6, that's state transition, so if your computer goes to sleep and wakes back up, that's going to change. And then PCR10, that is a really interesting one. The Linux integrity management system actually uses PCR10 when it's able to do integrity checks on all the files in the system. So if something like SolarWind happened on your system, if you had that enabled, you could look at PCR10 and verify that along with IMA to see, okay, there was something that happened in the system that we didn't expect, so we're not going to issue an assert. So demo time. All right. This will go actually pretty quick. So we are going to... So the first thing we're going to do is actually go look at the PCRs right now because let's assume that this machine is in a trusted state, so we want to get those hashes. Those hashes are pretty hard to predict. There's some work being done on it, but it's best probably practice to trust on first use, grab those hashes, and then register in the system. So that's what we're going to do. So we can see we have our PCR hashes there. Now if you look, we have PCR4 and 5. As long as our kernel stays the same version and we don't have any kernel modules or anything else going to NBR, that's going to stay the same. And I think that's some important information that we want to include in our build metadata. So then we're going to do a SPIR registration. All right. And then we are going to start our SPIR agent. And there we go. And you can see we have a SPIFI ID issued to this node based upon those PCR registers. So if we go in and we do add a kernel module to here and we try to get that identity again, even though nothing else has changed, even though that TPM still has that attestation key, the same one, right? We're not going to issue an identity. So this is important, right? This is important because when we are building software on systems and we are assigning that metadata for that software, we now have a way to assert the state that that software was built in. We can now ship that data either downstream to our production systems or off to our consumer of our software to give them confidence that we have done the right thing and the risk level of running the software on their system is low. So what's the future work look like? So unfortunately, this plugin was written on free plugin SDK. So in the next few weeks, Mikhail and I, we're going to be rewriting this to use the new plugin SDK. We're looking at using a key manager plugin, TPM key manager plugin for the server so we can securely store those keys whether you're in the cloud or on bare metal infrastructure. And then we're also starting some work on IMA hooks into the Unix Workload API, right? So that way when we issue a certificate to that workload, let's go check that PCR register and see if it matches. And that will allow us to make sure that not only the boot state is consistent, but also the current state of that system is consistent with what we expect it to be, right? If any of those files are different than what they expect it to be on that IMA 10, that IMA 10 will show it. And then I know VMware is also working on some spire like trust on first use semantics. There's some work going on in there. I think there's a GitHub issue. I think that's another issue that we need to look at because we don't want to trust that certificate that we issued to the agent for a reissuance, right? We want to go check those PCR registered to make sure that system state is still within the constraints that we set, right? Well, that is my presentation, but I'm sure you all have a lot of questions. Q&A works differently now that we're in person. Our moderator, Andrew, here will read any questions that come from the platform, and I can walk around with a handheld for any questions in person. Question in person number one. You have to raise your hand if you have a question. Hey, cool. This is awesome work. I noticed you mentioned IMA for PCR 10. So do you see kind of there being a separate server to kind of validate locks before you kind of, you know, create the entry, or do you think you can specify your IMA policy within the node attested cell? How do you see that working? I'm looking at building it into the Unix plug-in for the workload attester, because I think that's where it belongs, right? Because if we want to test a state that's changing, we want to check that every time we issue a certificate. So I'm open to figuring out where that fits in, and we've been talking about it a little bit, but I think that's where I want to explore first, and then we can add additional selectors when we hand out certs to workloads. Cool. Thank you. Any other questions? We will give one minute for the folks on. We've got one already here. So you kind of pointed out that, you know, getting your hands on those PCR hashes is kind of like a trust on first use sort of process where you kind of like go onto a machine that's in some sort of good state, and you dump them and then you kind of figure out what's in your policy and whatnot. What are some of the ideas, if you have any, right now on how you might make that process a little more easy for folks? I think, you know, it's hard to say, right? I think there needs to be somewhere to share those hashes. We haven't quite got there yet. We're just kind of trying to get this whole thing working from the left to the right. But yeah, I think that's going to be an organizational thing, right? I think a lot of those hashes should be similar. Organizations buy the same hardware a lot. So I think that could really aid, like let's say this, we get two of these Dells, right? It's shipped on the same day, but their PCR hashes mismatch, right? It might be worth some investigation. We might not want to issue that device a certificate. Sorry, I didn't mind for timing on that a little bit. In IBM research, we have figured out a way to kind of reliably validate a boot log. So the idea of what we're doing is all the PCR values on the different machines are going to be different. But we have a process to take in a boot log, take in a policy that you define an organization, validate it and to compute or pre-compute the PCR to see whether they are valid. And then use that to kind of create the association. There you go. Learn something new every day. Can we get a talk on that next time? PCR hash pre-computation, yes. Next time we want to talk on that. I actually have a question. I saw on your slide, and I don't think you covered this. I apologize if you did, but I saw on your slides that the PCR, there's like a six or seven of them. Yes, here. So we got, yes, seven, I guess. PCR 8 through 15 reserved for us, yes. And then within that range, the next IMA, which is obviously operating system features. I'm wondering, you know, is 8 through 15 not yet commonly used? Is IMA really the only thing that has picked it up? How far up into user space can we go with this thing? So I know BitLocker uses them, but I haven't really messed around with Windows in a while. Other than some, Microsoft has some really good docs on TPMs. So they talk about BitLocker a lot in there and the PCR registers they use. Okay, so what I'm hearing, if I'm hearing this correctly, is kind of like, hey, these things are in use. Each operating system makes its own choice on how to use it. Yeah, traditionally, the way that people will use these PCR registers is that they'll set a policy inside the TPM that says, okay, PCR registers much mass. What PCR registers, 0, 1, 2, 3, 4, must match these hashes, and then we're going to unlock that key. But that's difficult to deploy and change across the fleet, securely at least. Totally. Are there any other questions or about out of time here? Going once, going twice. Awesome. Thank you so much, Cole. This was great. Thank you. And if anyone's got any questions, there's my information. Just hit me a DM or talk to me in the hallway. Thank you all.