BSidesSF 2026 - The Trusted Platform Module (Eric Chiang)

Hello everyone. Hi, welcome welcome to the uh third talk of the day in uh theater 2. Thank you for joining us. I'd like to introduce our speaker today. His name is Eric Chang. He's going to be speaking about the trusted platform module. Uh as you guys know, if you have any questions, stick them on the Slido app. Um and I'll give it away to Eric. Quick round of applause for him. Uh hello everyone. Um, as is tradition when I speak at Bides, I have too many slides. There's no way we're going to go into Q&A. So, uh, you all probably know where to find me, which is either at the Oblique booth or at the bar. So,

afterwards, just kind of let me know. Anyway, so hi. Uh, my name is Eric. I'm the co-founder and CTO of a company called Oblique. We're a little startup uh that does group management. Um previously before that I was at um Google security in the corporate side for about six eight years and way back in another lifetime I was doing some stuff with the Kubernetes o special interest group. Um there's some really important uh shoutouts I have um a bunch of this work involves work that I was doing at Google along with a few other people. So, Matthew Garrett, Tom Detto, and Brandon Weekes, uh, thank you all for, you know, bashing your head against the wall so I

could make some good slides. So, welcome. Uh, we're going to talk a little bit about the trusted platform module today. So, I'm just going to go over a little bit of background. Uh, then we'll be having some fun with learning about, you know, how to store keys in the trusted platform module. And then we'll slowly try to break you down and have you questioning the fundamental security of your hardware later on. And then if I get some time because a lot of my work at Google was on G Linux which is Google's internal Linux distribution um I'm going to talk a little bit about all the funness around Linux's use of the TPM because uh Windows is the

predominant user of it otherwise. So yeah the trusted platform module why you all are here. Uh as a quick refresher um the trusted platform module is an API specification. uh it is several thousands of pages of PDFs of specifications. So good luck. Uh this is why you have a cloud subscription assuming um but it can be implemented in just like a number of different ways. So on the right here, excuse me. Um you can see for example that it can be implemented as discrete hardware. So when I needed to upgrade a gaming PC, for example, to Windows 11, there was just on the motherboard a little slot that says for TPM, you go and you buy a

TPM and you insert it in there. But more commonly, you can also have stuff that is like on the CPU. So this could be, you know, an FTPM, a firmware TPM that is running in the CPU sort of concurrently to all the other things that it do does. And increasingly, as you know, cloud providers want to support Windows, uh, they are also shipping all of their TPMs. They don't really tell you where those are stored, right? Whether those are in software or hardware. But again, uh the TPM is an API specification. It's not, you know, one specific piece of hardware. Um and it's actually super easy to interact with the TPM. Um this is an

example using a Go package by Google that we've used heavily. Um and it just opens a quick file called dev TPM RO R0. Um and this is a uh interface that the the Linux kernel provides to mediate access to this. So you just open it up, you declare this and you send some packets along in terms of commands. Uh this particular program asks the TPM and says hello, I would like 16 bytes of random data and then you know the TPM can now be your most ineffective uh or inefficient uh random number generator ever. So it can do stuff like that. But the actual way that you interact with it as long as you know you have the

appropriate permissions usually root uh on machines is really really trivial. And then the TPM kind of does a number of different things again thousands of pages of specifications you'd expect at least a few. Um most commonly and I think this is what people think of when they think of secure hardware is storing private keys. So this is, you know, I'm going to generate an ECDSA key here and the private key will be in the TPM and never leave it. And I can call APIs to get it to sign things. Um, but it's a way of saying having some guarantees at least that you have to be, you know, on the physical machine in order to use

that private key. Um, it can also hold just arbitrary secrets. You can shove data into a TPM and have it be relatively secure. Uh, this is incredibly common with disk encryption keys. So there's plenty of um sort of schemes that allow you to take a dis encryption key, sort it in the DBM, and then as you boot, read it back out. There's also a much messier set of components that involve measuring boot processes. So this can be things like what is the firmware that you booted with? Uh what is the bootloadader? What are the secure boot keys? And so on and so forth. And as you're using more and more of this, you're effectively going

to want to be able to prove to other systems that yeah, that key is in the TPM or that this was the that was the hashes that I booted with. And that gets into a whole set of uh components around remotely attesting the state of either private keys or boot to other servers that you can do interesting stuff with. Um, as you can see, you can kind of start pretty simple, but I think as soon as you, you know, do one thing or another, you start bleeding very quickly into other components of what the TPM might be doing for you. So, I think we're just going to start with a pretty basic side of stuff, which

is storing keys. So, TPMs have a a key hierarchy. Um, this slide isn't super important for you to actually understand. Um, and I have a blog post if you're really into this kind of thing. But, um, effectively the important part is that the TPMS have many many different kinds of keys and these all have different roles and responsibilities. Some of these might be used to attest to other keys. Some of these might be used by applications. Some of these uh, might be used simply to anchor other keys and have policies along the hierarchy, which we'll kind of get into later. And an interesting aspect of the TPM is that any key that's in the TPM hierarchy can attest to

another key. It doesn't necessarily have to be in the same hierarchy. And this is kind of cool because as soon as you can prove that one key is on the TPM, you can now prove that any other key is on the TPM and that it has specific uh states and metadata. You know, this is an exportable key or non-exportable, this is an application key and so on and so forth. And kind of getting into that um you know the the TPM provides basically anything that you the normal subset of things that you would expect from any thing to store keys. uh it has the cutting edge of cryptography from like 2000 which is RSA and ECDSA. So for

all you wireguard fans uh it does not have ED25519 for example. Uh and as soon as we have conversations about you know postquantum everyone's eyes are going to bleed and it's going to be great. Um there's also this concept of restricted versus non-restricted. Uh all this basically means is that a restricted key cannot sign arbitrary data. It can only sign particular challenges about the TPM. So these are keys that are explicitly used to prove other facts about the TPM versus a non-restricted key which can be used for you know your TLS connections or Matthew will be giving a talk about SSH uh sighting which you know you can use for that kind of stuff and then in a very antiquated I

think component there are also weird keys that can only decrypt and not sign and this will be important in a couple minutes um just because of somebody once was like oh for privacy reasons we'll have some of the important keys only be decryption keys, so you can't anchor them back. Whether or not that actually panned out is interesting, but that's something to definitely consider. Um, also all of this is just super resource constrainted. Um, if you're looking and like this is a great idea, it's not. Um, the, you know, we were doing benchmarking of like RSA signatures, you know, 300 400 milliseconds totally normal. uh ECDSA is much better, but if you're looking at this as a solution to

all of your problems, um you really have to use the TPM quite uh you know as a as a limited resource. Uh it it can't be used to sign everything that you might consider. And then um as I said before a really interesting part about any particular TPM is that they can if you have confidence that one key is in the TPM you can then prove that any other key is in a TPM and uh it depends on what kind of key you have. So I mentioned basically that there are decryption only keys keys that can't sign but are allowed to decrypt. Uh this goes through a song and dance called credential activation. And all this does is if

you're a server and you want to do some attestation around, you know, proving that one key is on the TPM, you you know can create a encrypted challenge to that key and this will return both the challenge back to you as well as other metadata about the key. So again, this can be stuff like is this a restricted key or not? Is this exportable or not? Hopefully not. Uh was this imported into the TPM? Because of course it supports weird stuff like that. Um, and then the first thing you generally do with this is you take that weird decryption only key and you immediately turn it into just a regular key that can sign challenges. Um, and this is a a simpler

attestation format called credential certification. It's basically just hi uh please sign some data and give it back to me which is again much simpler. And in terms of the first key because you know how do we figure out that how do we have confidence that any one particular key is stored on a TPM um there's a really interesting property in a TPM in the hierarchies and these things called seeds and the idea behind the seeds is that they are random bits of data that are on a TPM that allow for deterministic generation of public and private key material given basically the input that you the parameters that you give So the idea is that if you've not reset

a key or not reset a TPM, if I feed in the same basically template parameters for key generation for the same TPM, I will produce the same public and private key pair every single time. Um, and this is kind of cool, um, because then that means that even if all of the data surrounding the TPM is blown away, that as long as I still have those seeds, I can still produce something that gives me a concrete identifier for the TPM. And this is where we talk about the endorsement key. So the ento key is a well-known uh template basically parameters of things in the key that um are speced and allow the uh allow you

everybody basically to generate the same key multiple times. So both the manufacturer can generate a TPM key using this template and then later on down the road um when I'm using the TPM or challenging it if I send these same parameters I'll get the same key out. And what's really nice about that is that technically um TPM manufacturers can sign certificates over that key. So this is called an EK certificate. Generally this is signed by your TPM manufacturer and shoved in NVRAM. And then when you can read it out, you can now chain information about a particular TPM back to its manufacturer, which is honestly quite cool. Um, there's also technically supposed to be these things

called platform certificates. The idea being that EK certificates are by the TPM manufacturer, but if you are building a laptop or you're building a server and you're shipping that, they're also technically or manufacturers are also technically supposed to provide platform certificates which are certificates over the EK certificates so you can chain back. Ideally, what would happen is that you could get a laptop, you could remotely attest it, you could get the EK certificate, platform certificate, chain everything up, and then identify a particular device down to its serial number. Whether or not the manufacturers you work with actually do this is a totally different story. Uh certainly if you're Google, you might be able to have conversations. If you're,

you know, Joe Schmo, definitely not. Um and in this case on the on the left here, uh this is the NSA trying to do this. So for example um they put out guidance uh a few years ago basically saying hi we would like to require from all our devices platform certificates so we can identify devices that are shipped. Um the sort of goal here is that if I have a remote employee I can ship them a laptop and then attest the identity of that laptop without ever um sort of touching the device. So yeah storing keys probably the simplest thing right you can store some private keys in the TPM. there's all of this song and dance around attestation

but it just boils down to the ability to prove that you know this is on the TPM and then um in a theoretical world you can actually identify TPMs. Uh this is actually probably more interesting in things like cloud providers where they have specialized APIs for this and they look more normal. Uh manufacturers are not used to being certificate authorities. I will I will just say that out there. And now we get into a little bit more of the cursed side of TPMs. So, we're going to talk about boot state. So, the TPM has 24 uh running hashes that basically store boot measurements as your computer boots. And there are different banks for different uses. And

we'll be getting into why these are different versus having one and some can combined. Don't worry too much about that. We'll get into that in a bit. But this stores information like what is the firmware that your computer executed when it was loading? what is the hash of the bootloadader? What is the secure boot state? What was its configuration? And so on and so forth. And technically um when you look at the outcome of PCRs, it should be the result of all of the events that um led up to, you know, your computer being in the current state where it is. So theoretically, you should be able to say, okay, this computer is in a good state versus this

one is not. The way that PCRs work, of platform configuration registers, is that um during boot, various components such as your UFI will um basically take Crus and flatten them out and hash them, which is very '90s. Um but when you provide that digest to the TPM, it will take its old state, concatenate it, hash it, and provide the new state of the PCR. And this is, you know, a hashing algorithm. So it can go one way. So as your computer boots, it will be recording events and moving forward and there's no way to go backwards. Um once you are in and recorded a state, you can't get back to an old state and PCRs or sorry the trusted platform

module is also able to attest the state of these PCRs. So it's able to say you know you can go to a computer and say please you know take a challenge sign this with an atization key. So, you know, doing some of the dance that we talked about earlier and sign both the state of your PCRs as well as this challenge. And you get this thing called a quote back, which is just a signature over both the PCR state and the challenge. So, it requires some freshness. And again, what's nice here is that um you don't have to trust the actual computer is being faithful when it's relaying this information to the TPM. As long as you're very certain that

that uh key resides in the TPM, you can get a quote out regardless of if the TPM sorry if the computer that that TPM is on is malicious or trying to do weird stuff about this. And this uses a key generally known as the add astation identity key. So this is a signing key. Um while your computer is booting, it will also write auxiliary events to this thing called the event log. Uh this is when we're getting into some fun, but technically basically every time your TPM or your your boot events extend the TPM PCRs, they should also be writing similar events into this structure um called the event log that is stored externally from your TPM. So it should

say this was the first boot event, this is the second one, this is the third, this is the fourth, so on and so forth. And it'll say like this is the exact PCR that was extended. And the way that you can then validate that is you can just roll those digests on your own side. So let's say that you give me the stated uh PCRs, the quoted values of those PCRs and the event log. I should be able to go one at a time through each of those events and get the same hash out at the end. And if you do that, then technically I'm confident that this event log is actually what happened when

you booted your computer. Uh so we can give you not only the end state of it but also every single event that happened throughout which is really really interesting if you have you know something in the middle that might be dynamic in some capacity. So we've tried to verify a lot of event logs. Um I will say that all of this is sounds relatively simple until you hit literally any stag. So the obvious value for your bootloader might be kind of wellnown right like I shipped you your bootloader if I am the operating system but what is the correct value of the firmware that is running on your motherboard. Uh you can ask a manufacturer that um it is very unclear

if any of them know or anyone would know necessarily how to ship you the update of here's the new value that is going to come with a particular firmware update. Um values can also change many many times right if you modify and let's say that you ship an update to your secure boot certificate bundle um that's a totally legitimate change but now the value of a PCR is different uh there are in lots and lots of states where we're talking about disc encryption of people encrypting their uh device to a particular PCR state they update the firmware and then they can't get back into their computer that's just super common um also it's sometimes quite

unclear what values are dependent on others. Um, right? Like do you trust the secure boot state if you don't trust the hash of the UFI firmware? Technically, you shouldn't, but it is quite a lot of work to go back in one direction and the other. And then uh parsing subtleties, which are which are my favorite. So, my good friends wrote an event log parser a long time ago. Um, and I noticed that for some terrible terrible reason when you look at an event log, the event type is not actually part of the digest. um which was not particularly well documented in the specification and I noticed that oh if I just change all the event types to something your parser

doesn't understands then append my own malicious events uh that totally passes all the replay because that's not actually part of the digest. Uh we reported this to the trusting computing group which was a fun process and I got a CVE and a Windows product because of this. Um I think the only thing that this really taught me is no one's actually doing this more than anything. uh because this seems like something that like I don't actually know if you can parse an event log safely but you know certainly lots and lots of people have tried so yeah boot state quite simple in concept right you have this TPMS you have these PCRs these rolling hashes and

you have these events difficult in practice right um whenever you have to reason about anything low-level you really start to notice just how um unwieldy it can get very quickly Okay, cool. And now we'll be talking about uh disk encryption, which is also a fun part. So, as I alluded to earlier, um TPMs can have policies around keys or even random blobs of data that you want to put into the TPM. So, uh you can get access based off of things like a user supplied PIN or more interestingly stuff like the PCR state. So the example on the right here is creating an O session generating a PCR policy or a policy based off of PCR

of PCR 0 4 5 and 7. Um don't quiz me on which ones those actually are. Seven is definitely the distributed state at least. There's also a kind of crazy or anding you can start doing. Um, so you can build arbitrarily complex expressions of like allow a pin or a PCR state or you know allow these PCRs or this new set that will be the new value after the update. Um, good luck with that. I think it's the main thing. But um, there are some hierarchies that you do have to consider these. And this is also kind of how this is used for disc encryption. So a very common example for anyone with a Windows machine is Windows

Bit Locker. Um the idea is that um the Windows Bit Locker binds the disc encryption state or the encryption disc encryption key to PCRs 7 and 11. 7 is uh the secure boot state. 11 is in the range that is allowed basically for the operating system. It gets to declare I think it's 8 through 15 and just use that for its own purposes. So you power on the BIOS UFI kind of writes um PCR7 data which is the secure boot data. If you know your boot manager passes that it runs you know if it's signed correctly and then it accesses the disc encryption key because PCR7 hopefully is in the correct state it then will

immediately extend PCR11 which is also bound in here. And what that means is that any future program can't access that value ever again. Um, I tried to figure out how key rotation works in this. I didn't get very far. If you know, you're you're way deeper in the weeds than I am. Um, but it also is kind of weird, right? Like why just PCR7? Um, even Microsoft's own documentation says like, yeah, you can do this, but maybe you should also require a user PIN, which is kind of funny more than anything. Um, there's also some fun with like discrete TPMs. So this article, a version of this article gets posted every couple years where somebody

realizes, oh yeah, when you have a discrete TPM, you can just sniff the bus and see the Bit Locker keys because like why not? This is much better if you have an FTPM like that's colloccated with your um CPU and you can technically encrypt sessions to a TPM. You know, you have a key and you do that. Uh it's prohibitively expensive. for example, Linux disabled this by default just because of um hard certain hardware not really supporting that. Um, but I also think it just brings up broader architectural questions like, okay, if you're encrypting to a key, but you're in a state where you don't have any unencrypted, like everything, your bootloader is unencrypted, like where is

that key stored? How do you bootstrap all this? I I once had somebody just ask me like, can't I just take a TPM and feed it arbitrary values? Um, and I'm sure some smarter people than me will understand why that is difficult. But, uh, fundamentally, yeah, you you start getting in these weird chicken and egg scenarios when you are working with hardware like this. Okay. Finally, uh, I'm going to take a little bit of fun and and talk about Linux. So, I while working at Google worked on, um, Google's corporate Linux distribution. So, this isn't the stuff that runs in prod um, called G Linux. and I was uh sort of helping out from the security perspective trying to okay

a lot of their designs and as I mentioned the team we were on did a lot of work around TPMs and testing information and that kind of stuff and what's like really unfortunate about a lot of that work is that G Linux is based off of Debian but a tremendous amount of that work required us to shape the distribution in a way that like complied with secure boot and we shipped our own secure boot certificates and and so on and so forth and we were also having to write custom data into the PCRs as we were trying to get information about certain uh boot events that we found critical to our security stories. But this was not generalizable,

right? It's like our one specific operating system. We're not going to be able to go to even upstream Debian and say like, "Oh, this is the way all of you should run this." So much of this work is still closed source. I think actually for quite a good reason. Um but it was unfortunate because you know as you look at the Linux distribution space uh it was not catching up with maybe the work that we could have done internally. That is until one German named Le and Pottering comes in and like all Linux things uh comes to the rescue. So uh around 2022 um the maintainer of systemd wrote an article called a brave new

trusted boot world and this articulated this need for Linux distributions in general to have standardized ways of doing things like secure boot understanding uh you know what kind of things were going to be measured in the PCR. This even goes into stuff just like what is the disk layout when you're trying to boot and systemd has since produced many many kinds of uh tooling around doing disc encryption secure boot and and so on and so forth and booting the machine and there's now this cool um group with terrible name called the Linux user space API U API group um but they have been doing a lot of work around standardizing the boot process uh for Linux distributions and saying that

when you boot, you know, here's the shape of um here's the shape of like the unified kernel image. So, um as an example, when you when you want to uh run a uh a Linux kernel with secure boot, what you sign is actually kind of hard because traditionally it would just be the bootloadader and then you would inject, you know, additional ways of the bootloader verifying the MFS and the kernel. Whereas G Linux and now many other distributions are doing this thing called the unified kernel image where you take the bootloader and if MFS and kernel combine it and sign that entirely and that is what is signed by the secure boot keys. Um there's also some

interesting work within this group around just trying to define what the set of Linux TPM PCRs are. um when you look at a PCR uh sort of event log for Windows, you get stuff like is disk encryption enabled whereas if is disk encryption enabled on a Linux distribution is more of like a philosophical conversation than like one specific thing. So trying to kind of move it in a direction where um if you are trying to parse the event log for some random distribution hopefully um these distributions will start standardizing on this. So you can have assertations about like you know I wouldn't say disc encryption but you know certain other parts of it like what

was the bootloadader or what is the shape of the bootloadader what do we expect of that and I think at the end what you might kind of question is what the heck is Eric talking about for the last 30 minutes we talked about some keys we talked about some boot events surely you know we're doing some security here um I think I see a lot of companies reaching out for TPMs as like a solution to their problems and it's very much like a now you have two problems kind of world. So it is quite easy I think to store like keys in a TPM that sounds great. Even identifying devices is great particularly again if you're on a cloud

provider that already has a lot of the infrastructure to provide you like here's the EK certificate in an API that's convenient. If you ever do anything related to verifying the state, please talk to me or one of my other, you know, comrades that we I I talked about at the beginning because um it's gnarly. Um and I think we're really really always interested in seeing what other people are doing in this space and uh trying to figure out, you know, who has success stories because um we had some mild success, but I I wouldn't call it resounding. Um I would also like to preemptively mention that Matthew Garrett um has who loves TPMS I would describe him has

another talk on this um related to using TPMS to sign get commiss messages in theater 9 at uh 950. So if you're interested or anything in this talk was interesting uh go check out Matthew's talk as well. Uh thank you. Um, you can find me at the Oblique booth if you're interested in having any other conversations. Thanks. >> Amazing. Thank you guys. Um, just a gentle reminder to those who need it, uh, coffee stations are available until 4 today. Take a break from today's events with a stop at the bar and a chill out space sponsored by Run Zero. Two complimentary drink tickets were provided to you at registration if you didn't know that. uh we already paid for

them so please use them. Both non-alcoholic and alcoholic options are available. And as always uh thank you for attending this presentation. We would like to thank all the sponsors especially our gold sponsors Aikido Arkjet Clover Data Dog Socket and Sublime Security for supporting the Bites SF. Thank you.