PCR 9: How a Simple Misconfiguration Can Break TPM Full Disk Encryption

um hello everybody uh are we good to go okay cool uh hello everybody um thank you for coming uh this is PCR 9 how a simple misconfiguration can break TPM full disc encryption um so a little bit about me uh my name is Max Arnold I'm a security engineer at security innovation uh we're a relatively small ABC consulting company um you can reach me at Mar Arnold security innovation.com also I'd like to say thanks to my company for giving me both uh the server Hardware that I I did this research on as well as giving me time to do the research and thanks to Maxwell Duan for providing support uh during the research process um so this talk uh does have

some prerequisite knowledge um you should have some familiarity with Linux Concepts um especially diss partitions and file systems um as well as some basic understanding of crypto um specifically encryption and hash functions um if you don't have these it might be a little bit hard to follow along but I'm going to try and explain everything else so the talk is going to be structured with sort of an introduction where I explain all of the background information on how automatic dis encryption Works um and then after that I'll explain the problem that's very common and how to exploit that before describing the solutions at the end moving right on then um the first thing we're going to talk about is the

boot process so when we talk about a computer booting up um there's a series of different stages um and they're each responsible for slightly different things um the overall goal is to end up with a a usable computer but when you first turn on the computer most of the resources aren't available um and so you need to have different areas that spin up all the various components um these all need to execute pretty much sequentially uh so once one component is done doing its job it'll it'll stop hand over execution to the next stage and it won't do anything after that this continues until the kernel which is then going to keep running while the OS is

running so for this talk uh the boot process that we care about looks something like this uh you turn the machine on you reach UI or your firmware that's going to go into the bootloader the bootloader will will find and launch the kernel and then it will find the the actual init script that runs and hand handles user processes um you might be familiar with UI because this is where you change like secure boot settings or you can change perhaps memory timings um and then of course your your boot loader is going to be something like grub um in this talk since we're talking about dis encryption it's also important to note where each of these stages is

stored yui is stored in Flash uh this is pretty much out of scope for this talk although there definitely are some interesting attacks and interesting research being done there the bootloader and kernel are stored in the boot partition of the main Drive these this is a separate area that the UI is able to read um it's in a known format and then the actual init script as well as the rest of your user data and programs are all stored in the root partition when we're talking about full dis encryption um it's actually not quite full disc encryption we're encrypting the root partition um which means we're encrypting all the user data all the programs all the configurations

but we're not encrypting the kernel in the bootloader and this is because we we can't if you have those encrypted they can't run which means your system couldn't start and a similar process actually occurs with the encrypted root partition if that's encrypted how do we have the data to decrypt it so what we do is we add an extra stage to the boot process called init Rd or init ramfs this is a special extra little file system uh it's in a standard format and it's very small it's only purpose is to set up enough of the computer that you can read that root file system and continue with the standard boot process so for something like a software raid um

you'd have your RAID controller stored there uh in this case since we're doing dis encryption we have the decryption logic stored in in it Rd and also importantly this needs to run so this is not encrypted so recapping then uh you turn the computer on it's going to load the U from flash this will look around and find the bootloader which will run it'll set up the system enough that it can launch the kernel the kernel will find init Rd load that run all the scripts there that'll decrypt the hard drive main root partition and then it'll find the init script and run the second area of knowledge that we need to build out is the trusted

platform modable um you may have heard of this there was Some Noise about it with Windows 11 requirements uh it's a standard for a dedicated security Cod processor uh there's a number of features that the TPM has but we're only going to talk about a few of them for this talk since most of them are out of scope so the first thing the TPM can do is it can do key storage and management it can hold encryption Keys securely on the device um and to determine whether or not to return those back to the user um it can do cryptographic computations like symmetric and asymmetric encryption as well as H functions um it can do

system Integrity verification where it actually determines the the state of your machine by looking at the boot process and it can do remote attestation we're not going to talk about that last one here the first two are fairly straightforward so I don't think they need much more explanation but the system Integrity verification is somewhat strange so I'm going to go into more detail on exactly how that works so the idea is that we want to be able to know is our computer at any given point in a state that we trust um or is it set up wrong something looks often and we don't want to trust it um this is mainly for the boot sequence

because the boot sequence is so sequential once you get to user land you have a bunch of processes that are all running at the same time and it becomes a lot harder to understand exactly which code has been executed it's also important to note that in this case the TPM is totally passive so it's not reaching out into the hard drive to measure things um rather measurements are written into the TPM where it stores them securely so the system that they came up with is called platform configuration registers or pcrs um there's a large number of these and they are append only so when you write to a PCR um you're actually giving it some data and then

it'll compute the hash of the existing Value Plus the new data um this means that all of your rights will form a sort of chain um and the the final result is based on every single right since it was initialized um and the idea is then that every single step of the boot process is going to make a measurement of The Next Step before before it runs it that there's a log in in respect of the code that was run um in order to make your life easier they have a number of different pcrs and so you can pick which PCR you write to to mean that you don't have to look at all of the data all the

time here's a visual to explain this a little bit better when we first turn on the system there's going to be a little snippet of code that's going to measure the UI executable image it's going to Hash that and write that into PCR Z then the yui is going to run it's going to measure the bootloader hash that again and write that into PCR the bootload is going to run hash the OS write that into another PCR Etc um now once you're in the OS you can read back those PCR values to figure out if your boot process is good or not in the event that we have an evil boot loader that's been compered with

tampered with or compromised um we'll see how that works here so the root of trust is going to start again and it's going to measure the UI uh and the UI is going to measure the bootloader then it's going to start running the bootloader which is not great because we know that this has been compromised however that measurement in pcr1 is already invalid and since you can't delete values from pcrs you can only extend them there's no way for the evil bootloader to overwrite PCR one anymore and make it look valid and this is the the basis for the the setup that we're going to be looking at today which is automatic disc encryption so with standard dis

encryption you have to type your password every time the computer boots and this is not great um it presents usability concerns because some devices don't have people to type passwords into and it's just very annoying every time you open the lid to do that so the system with a TPM is that the TPM has the dis key stored and it will look at pcrs and determine whether or not to release the dis key based on the value of those pcrs so if everything looks normal it'll give you the key but if there's an evil boot loader it'll notice that it's different and then refuse to give the key so the boot process won't continue um there are a number of

predefined PCR values and i' I've selected a few of the most important ones here um you'll often see these referenced in tutorials um and most significantly is that last one PCR 9 uh is a measurement of the kernel files like the image and the init Rd so that was a lot of information I'm going to go recap that again just to make sure that everything makes sense here here's our whole system now we've got the TPM added as well as all the stuff up top we're going to first power on we're going to measure the UI into the TPM then the U is going to run it's going to measure the bootloader bootloader is going to run measure the

kernel kernel is going to run measure the Rd and now the TPM has all of these measurements the init Rd is then going to request the dis key and since all of those measurements look good the TPM will release it and then the init Rd can decrypt the root partition and we can continue booting normally So in theory this is a great system um your computer will boot up just fine um and then assuming your login screen is secure uh there's nothing that an attacker can do with a turned on computer and if they try and turn it off and tamper with a dis it's all encrypted so there's nothing they can do uh but there's a problem if you go

look online for tutorials on how to do TPM automatic encryption you'll see command lines like this they'll say hey use this utility system decrypt en roll or use cevis and they'll specify what pcrs you should use and and they'll usually say something like oh yeah the default is is PCR 7 which is secure boot that should be fine or maybe you'll throw in zero because you want to check your firmware um this is missing PCR 9 which means that the kernel image and init Rd are not measured um that's a pretty big problem so you know we're attackers what are we thinking in it Rd is not measured it's not encrypted it has the logic to obtain the dis key from

the TPM and it has a well-known structure so what if we just modify that what if we make it print out the key it turns out it's actually very easy to do this so This demo attack that I'm going to show off here um is targeting clevis um if you're using a different disc encryption system you'll have something similar but it might be slightly different so the first thing you need to do then would be obtain the hard drive um this is not an attack you can do remotely uh because you can't really grab a hard drive remotely but once you have that hard drive um go look in the EFI partition and you can find the init

Rd I've highlighted in blue here uh you're going to take that and extract the files um there's a tool unmake init ramfs that's useful um you can also do it manually because these are a CPI archive um inside of the extracted files um there's going to be a few scripts uh the important one that we clear about here is called clevis um in the path shown below so the the main target of the attack is this function here uh there's a lot going on but we really only care about the blue line again um the rest of it is mostly just reformatting and and modifying the data that it's getting uh but that blue line is where it actually

sets the value of this crypted variable which is the raw dis key that it's just obtained from the TPM so all you need to do is just add a few Echo statements and then a sleep so that it'll pause um and when this runs it'll now spit out the dis key onto your screen again it's a standard format so repackaging is quite easy and once you've done that uh you boot the computer when you do this you'll hopefully see an image like like this where I've got a bunch of stars and then I've got the disc key printed out at the bottom there 3j % J whatnot um it's important to add a sleep statement

because otherwise it will scroll by so quickly that you can't read it um but that's it that is the actual dis key for my server at home right now so this is a sort of a weirdly simple attack uh you're taking a little glorified zip file adding a few print statements then putting a back together it may as well be a debugging Command right uh and it has thankfully a similarly simple way to stop uh all you need to do is make sure that you actually measure PCR 9 so in that earlier command um just add PCR 9 um if you're using Crypt enroll it's the same thing um and this completely stops this attack and I wish that more people would

say this and that's why I'm here right now is because online there are so many tutorials that don't talk about how important it is to select the specific pcrs that you're actually using to go into a little bit more detail on this um pcrs each one has a specific purpose and you need to decide what do I what am I worried about an attacker actually changing versus what am I less concerned about because if we look at something like the firmware it might be very hard to actually write malware that compromises the firmer enough to then you know obtain the dis decryption Key by like tampering with the next stage of execution in memory or

something um that's that's a lot of work and so for the average person that's just not really a concern um but I I I think that you know the init MFS one is so simple that it should be a concern for the average user who is using dis encryption um also remember that based on how this works the TPM isn't actually determining if something is malicious all that it knows is that it's changed so if you measure in it MFS and then you run an update that requires you to rebuild that you will need to type in your password until you can re-update the TPM PCR values um so the the more pcrs that you pick the

more secure you will be but also the less usable it will be and that's why I think there's there's a trade-off to be made there um a final note there is people often talk about secure boot using pcr7 in general I'm of the opinion that this is pretty much not relevant uh there are a number of issues with secure boot you might have seen recently that uh a whole bunch of laptops have shipped with secure boot Keys labeled uh a test only do not use or something along those lines of which have known secret Keys um so unless you actually know how secure boot Works uh and you are doing your own Keys locally on your system it's it's

probably not worth configuring um if you want full details on each pcr's function um you can find them at the Linux TPM PCR registry um I have a link to that below you can also just Google it a couple closing notes here um so first off is that even when you do have a manual password system that's not automatic um init Rd is still required to to do that decryption logic so I am pretty confident that a similar attack is possible um it's a little bit more in- depth because now what you're going to need to do is sort of make an implant in in it Rd that will save the password and then cause a process to call out

later to some Beacon server but if you're interested that might be a fun attack to set up um that's why I think that even if you are using a manual password it's probably still a good idea to try and make that work where you have both the password and the TPM um that'll just increase the security of your system even further um secondly this is not sufficient to fully protect you against a physical attacker um if you have a TPM chip on your motherboard uh there's a technique known as bus sniffing where you just plug some wires in and you can measure the data over the wires um I've also done this it is shockingly easy uh

but it requires moderately Advanced Hardware or decent knowledge so if you're actually concerned about a physical attacker doing an evil M attack on your computer be careful there are there are lots of ways they can get you um again I mentioned that earlier that uh updates may require you to enter your password at least once um this is just a general usability thing with TPMS uh there are ways around this like temporarily disabling uh your disc encryption during one single Boot and then deleting the key later but a lot of these have their own issues so that's an area that you should look at if you're actually interested um and finally ask yourself do I need disc encryption

uh I'm not convinced that most people do because the the main threat model that a lot of people have is someone steals your laptop and then flips it for some quick money uh they're not going to go through the files they're just going to try and get it out of the state as fast as possible so they can sell it to a fence um take the time to actually your own personal threat model because that is where a lot of these decisions should stem from so in conclusion use pc9 thank [Applause] you looks like we have uh a few minutes for questions uh does anybody have any questions uh see here over there on the

back

get a DAT yeah so the question was um after you seal uh a a key to the TPM you get a data blob where is the data blob stored um and so there's actually two different approaches you can take the TPM has a very small amount of nonvolatile storage and you can write directly to the TPM um or you can take the sealed blob and write that as a part of your init ramfs um either way it's pretty much not possible to to tamper with it effectively because the the sealed blob is encrypted by a key that never leaves the TPM

yes uh so the the the easiest way to to to know is is during configuration um I believe there may be a way to check the policy that an object was sealed with but it's very awkward to do so because the actual TPM apis are are kind of awkward um luckily updating a system encryption is is quite simple you can just run the command again because you don't need to re-encrypt the whole Drive you'll just sort of re-encrypt the actual key there's sort of a two-layer process there so I don't know if there is a super easy way other than checking what command run when you configured the machines um yes go

ahead uh I am I think it's either PCR 9 or PCR 8 um you'd have to check that one yes it is an option I'm sure sorry uh the question was is the kernel command line measured

yeah so the numbers are all standardized up to seven and then eight and nine are true for grub as well as most other bootloaders but not necessarily all of them uh if you are not using grub you should probably check your documentation the question was are the PCR values all standardized any more questions one more in the back what does Windows uh so Windows bit Locker does a similar thing but I'm not actually aware of how it uses pcrs because you can't configure them uh so it's probably not vulnerable if they did their job right um there is actually another thing related there I'm sort of annoyed about with that but whatever in the back the question was why not just use a

hardware based encryption standard um so there's there's a couple things there one do you trust that the SSD manufacturer who's done opal actually did it properly uh there have been documented instances where uh this didn't happen um and second I'm not actually sure if these necessarily are mutually exclusive uh I think at least sometimes the the configuration for opal is coming from the system and how it's doing dis encryption um so I'd need to do more research on exactly how opal works but there are definitely some reasons to not just trust opal by itself cool I think that's everything thank you very much [Applause]