"TPM based attestation - how can we use it for good?" - Matthew Garrett (LCA 2020)

welcome back after morning tea everyone I know it's a bit of a sad day because it's the last day of the conference but I'm glad we're all here we're all ready our first speaker is all the way from San Francisco originally from Ireland we have Matthew Garrett here today please help me welcome him as he's here to talk about TPM based at a station and how we can use it for good good morning as always it's an immense pleasure to be here my name is Becky Garrett I work at Google on internal security I do not work on anything production releases I do not work on anything product releases if your phone doesn't work it's not my fault I'm very sorry today I'm going to be talking about how we can improve the security of individual computers and we live in a world where unfortunately computers are not very good and this is sometimes a problem in this it gets in the way of you doing work and sometimes it's a problem because somebody compromises the security of your computer and then gains access to the email accounts where you're engaged in various types of activism and then the next thing you know you're in a dark sites somewhere in a very different country and you don't get to see your family again so we would like ideally to attempt to provide more mechanisms for people to avoid that sort of thing happening to them and sorry to be clear I say that as an individual and a community member as opposed to saying that this is Google's official position so we have various bits of hardware functionality that make this more possible and so far we haven't really been taking much advantage of them as for a mixture of just like for awareness of how this can be used and concerns about these things being used to violate our privacy and security as opposed to enhancing it so today I'm going to be talking about work that we've been doing to build internal infrastructure and then worked as I've built on top of that in order to give people the ability to make use of that without having to be a giant enterprise so to begin with what is a TPM a TPM is a trusted platform module it's a small chip generally fairly resource constraints not particularly performance the most high-performance TPMS are usually in the 100 megahertz or so range they're really not particularly fast they have built-in cryptographic capabilities TPM 1.2 devices rely on RSA and the sha-1 for its graphic hashing algorithm as you may have heard last week sha-1 is not as strong as we would like it to be and so TPM 2 which is now has been available for several years now is much more reasonable it does still support RSA and sha-1 for backwards compatibility but it also supports elliptic curve cryptography and it also supports more advanced cryptograph akashic algorithms such as char 256 and the TPM two spec has actually been written to allow additional algorithms to be added without breaking backwards compatibility now one important thing to realize is that the TPMS cryptographic capabilities are not a cryptographic offloads the TPM is slower at doing this cryptography than your CPU is by like a lot you do not get the TPM to do stuff so the CPU doesn't have to the reason you do is on the TPM is that the TPM can hold data and then refuse to provide that to the operating system but the TPM also has some secure storage in the form of these platform configuration registers which I'm going to discuss in a moment but they're important remember those TPMS are there in order to provide a space that can still be considered trustworthy even if the rest of the system has been compromised in principle a TPM will hold secrets and only release those secrets if the conditions are correct and the conditions can be defined by you when you provide that secret to the TPM in the first place so an example is you can ask the TPM to generate a cryptographic key pair and then give you the public key the private key is only accessible to the TPM so if someone steals your computer and manages to gain access to your hard drive they can only get the public half of that keep the private half is inside the TPM so the only way they should be able to make use of that private key it's a sign stuff is if the system is in if the TPM is in this state that corresponds to the policy that was associated with the key when you generated it and it can also hold data so you can ask the TPM to encrypt some data and then the TPM will not decrease that data unless again the conditions are correct one of the things that's important in all of this is the ability to identify a computer this turns out to be a harder problem than you think you have two computers that look identical which one of them is yours and in my case it's one with a whole bunch of stickers on which is fairly straightforward but that's not always the situation we're working with sometimes we have to do this over a network so how do we verifiably determine the difference between two machines and one answer is well okay we are the computer it's serial number and then we look that up that's not ideal because you could just lie turns out that this is a new thing that computers are able to do the TPM though there's only one TPM per system and it's soldered onto the motherboard so it's difficult to transfer the TPM to a different computer with software I'm going to largely ignore the case of an adversary who is willing to take your computer apart and remove pieces and put new pieces on because that's a fight that we can't really win the TPM has what's called an endorsement key every TPM in theory has a unique endorsement key that was generators at the factory and which is not extractable from the TPM the private half of the TPM of the endorsement key is fixed for the TPMS entire lifetime now that doesn't help you much because a single cryptographically tells you little about where that Krita graphic key came from there's no way using raw cryptographic primitives to say this key was a TPM generated key I could generate an identical looking key pair myself and then say this is a TPM T so this problem is solved with something called the ek certificate and that's a cryptographic x.509 certificate generated by the TPM manufacturer when they produced the TPM and that is then placed in NVRAM on the TPM so if you ask the TPM for its endorsement key you can also mask the TPM for these certificates that ties that back to the manufacturer and you can say okay this keeper definitely came from a real TPM the problem there is that that ties identity that's the TPM manufacturer so you now know you're talking to a TPM but you don't know for certain that that TPM is associated with a specific computer now we can sort of elide this a little and just go with ok I'm sitting in front of this computer and reasonably sure it's me I will make a one-time assertion myself that this TPM identity corresponds to this computer but if we want to do this at scale then ideally there's a better way of doing that and by better I mean automated and this is solved by something called a platform certificate which is an x.509 attribute certificate that is provided by the system manufacturer and associates various bits of platform metadata with the TPM identity so the platform certificate might contain the manufacturing name the model number the serial number and a reference to the TPM identity so if you have a platform certificate you can use that to verify that this endorsement key corresponding to this machine and again that's generated at system manufacturing time right now not many vendors are doing this but there's increasing movement that in the industry to meet this achievable so the goal there is if you have a machines platform certificate then you're able to verify the identity of that machine verify its TPM identity without any manual intervention or without any physical intervention unfortunately one of the things we want to do in many of the operations we perform here is sign things we want to be able to take information from the TPM sign it and then based on that signature verify that the information we are looking at came from the TPM unfortunately the endorsement key in general cannot be used for signing it can only be used for encryption the TPM will refuse to sign things with the endorsement key so we have a slightly convoluted process where there's a second level of keys and these are called a cessation keys they are keys that can be used for signing and which can be used to prove information about what is being signed so there's a challenge response protocol where you basically give the TPM a reference to the Association key and a secret and then the you've encrypted that with the public half of the endorsement key the TPM then loads the association key if it can successfully load the association key it then decrypt the secret and gives you back the secret and that's way the TPM has demonstrated that it is what generates a data station key otherwise if it has a difference endorsement key its would sorry if it were a different TPM it would not be able to load the attestation key if it were a different endorsement key then it wouldn't be able to decrypt the secret so that's where you know that the e K and the a K are tied together so why do we do this instead of just using the ek and one of the problems here is that there is only one ek and it exists for the lifetime of the TPM the original model we're going to talk about for remote Association involved you proving to a remote site who you were oh sorry ideally not proving who you were proving the state of your system without giving up your identity and if all your signatures are with the same endorsement key then people would be able to look at signatures on different places and associate them with the same machine so the idea was you would generate different Association keys for each service you wanted to attest to and then a third party service would be used to prove the ek and the a K were associated so you knew the a came from a real TPM and then it would give you a certificate that you gave to whichever third party you were trying to prove system state to so this could be used for instance a website providing some sort of DRM content occurred wants to prove that you're running up-to-date firmware you're running ups take graphics drivers you're running in a state where there are no known bugs that was allow you to obtain the content protected material without it just being confined within your browser or something thankfully this never happened there was a lot of concern in the mid-2000s that remote attestation would be something used to restrict people that would be used in order to control what you could do with your computer so if you change the configuration of your system if you were say running Linux instead of Windows or if you were not running a sufficiently up-to-date operating system you would just not get access to various material thankfully this terrible dokyun future did not arise and nobody ever built the privacy cas pushback on that was strong enough all of this is you know it's nice that they were considering privacy but this is a whole bunch of functionality that just never really gained any relevance so what can we do with an association key there's basically as I said the Esso station key is a signing key we use it to sign information about TPM resident material and that might be a key so we can use an association key in order to prove to someone else that another key that was generated on the TPM was generated by this TPM but we can also use it to quote material and a quote is a signature across some information stored in the platform configuration registers that I mentioned earlier so the idea here is the TPM can give you the contents of those platform configuration registers and it can give you a signature and since you're able to associate the signature you can verify that the signature matches the quote you can verify that the signature was created with this attestation key and you can verify that the Association key corresponds to the endorsement key and that means you can say okay this signature came from a real TPM and therefore these values really came from the TPM nobody can fake up a set of pcr values and give them to you so what's in the PCR values why are these so valuable in this respect the PC ARS contain a hash so four TPM one point two devices that's a char one the TPM two devices depending on configuration that could be char one char 256 various other things the firmware or the operating system cannot directly modify the contents of these platform configuration registers if you ask the TPM to store a hash inside PCR to the TPM takes the existing contents of PCR to takes the hash that you gave it puts those together and then hashes those again and stores that and that means that the hash value that is stored inside the PCR depends not only on the value that you gave the TPM it depends on the value that was already present in the TPM so by giving the TPM hashes corresponding to each part of the boot process we end up with a value that should be unique to that set of measurements if you alter any of those if you do them in a different order you'll end up with a different final value PCRs end up containing a bunch of interesting metadata they contain measurements of the firmware itself the first thing the firmware does on most modern pcs is hash the rest of the firmware and then store that into PTR 0 so if someone tampers with the firmware the value of PTR 0 will change the firmware then also hashes the bootloader so if someone tampers with your bootloader again the PTR value will change the boot loader then hashes the kernel and so on each component in the boot process and stalls the next component of the boot process so if someone tampers with any part of the boot process those measurements will change now obviously if the moment you transition into untrusted code that's untrusted code could start lying about the next stages the TPM has no ability to directly inspect the state of the system the TPM can not DMA the TPM has no idea what the CPU is doing so that means the TPM only knows what the operating system or firmware tells it so you load one untrusted component and then that untrusted components can tamper with every components downstream of it such that it reports legitimate looking hashes even though they've been compromised so this is the reason we care about the entire boot chain not just the final part of the boot chain we can't just say oh it reported that we load is a good kernel so everything is fine we need to look at each component and verify that those measurements were the measurements we expected we also get a bunch of operating system specific data windows actually puts an incredible amount of stuff into the TPM including information about every driver that it loaded during the early boot state but also additional metadata like was BitLocker enabled on this system at boot time and was BitLocker using the TPM in order to store the disk encryption key did it load the early launch anti-malware stuff that Windows supports digit boots and safe modes did it boots with test keys and you can look at all of this information and you can then make a policy decision around that even though you booted a good kernel if it's possible for an attacker to modify the configuration of that kernel that might still result in you being in a untrusted State for instance in the Windows case if it's enabled the test signing keys then an attacker could load an unsigned or malicious kernel module and then backdoor you that way so you might want to look at this flag to make a security decision at the moment we're not measuring anywhere near as much data on Tillamook size and there's not really a particularly solid process by which we could decide what to measure so that's going to be an exciting conversation to have over the next few years but one of the problems here is that the TPM doesn't store the intermediate states the TPM only stores the final hash so if any part of the process changes if any of the measurements change then the final value will change in a way that doesn't tell us much we know this final value is not the final value we expected but why so we can get around this using something called the events log and the events log contains a record of all the intermediate measurements plus metadata associated with those measurements telling us what was measured and why from here is that the TPM is completely unaware of the event log and can't protect it and the event log lives in system RAM so an attacker could potentially just tamper with the event log so we can't just look at the event log in isolation but the algorithm that the TPM uses to generate its hash values is deterministic and known we can take the individual events from the event log replay them ourselves in the same way that the TPM would and then see whether the values in the event log match the values from these signed quotes that we had and if they do we're able to say ok the individual event log values are themselves trustworthy because they come to the same final value as the TPM gives us and that lets us look at the intermediate states as well so remote test station you generate a quote from the TPM that contains a signature over the final PCR values you provide the measurement log as well you pass that to a remote system and then the remote system verifies the signature on the quote computes the final hash values from the event log make sure they match and then you know the event log is good you can look at the individual of the event log and make some sort of security policy decision around that you can see all the individual parts you can decide whether this is good or bad and that way if the final measurements are different you can look at or not what you expected you can look at which event generated that difference and you can decide whether that's relevant to your security policy or not now the reason we do this on a remote server is that if someone's compromised your system then you can't trust your system to actually do this correctly instead of just lying to you we need there to be an independent trusted system that can look at the information from the TPM and verify that this is legitimate this actually works surprisingly well the values generates by the firmware are largely undocumented by vendors though that's beginning to change and the Linux vendor firmware service lvf s actually has metadata fields for the firmware measurements to be provided by the firmware vendor and some vendors are beginning to do that so we can look at those values and then say ok the expected the value we got is this and based on this information we have we know that that corresponds to this version of the firmware for this device released on this date and then that lets us verify you know if there is a firmware security issue we can then do some remediation around that we can identify machines that's running the old firmware and we know we have cryptographic confidence that they are actually running build firmware so on the software side of things we can calculate the measurements for everything in a fairly straightforward way but as of yet most loans distributions do not provide that metadata in an easy consuming manner I'll get on to that in a bit as well anyway this is all great if you're an enterprise because you can tie into vais identity into your authentication infrastructure you can say I don't care whether I trust the user if the user is not using a computer beside trust they still can't get access and you can also use the device state as an aspect of that if the device is not in the expected configuration even if it's a trust device with a trusted user even still deny access and since the credentials that the machines using for this identification our ties to hardware there's no way to exfiltrate those if someone gains access to the machine temporarily they're not able to then copy that machine's identity to another computer most of you are probably not enterprises so we can still use the TPM locally and this the most common thing that TPM is useful locally is something I can attest earlier with BitLocker for Windows we can store the disk encryption key on the TPM and then if the systems not in the expected state the TPM will refuse to release the disk encryption key and therefore we sort of have this implicit association if the system was not in the correct state you had never unlocked the disk and therefore the machine wouldn't boot the machine booted so it's in a good state now there are convolution attacks around that that make it possible for an attackers who actually circumvent this to an extent so something I came up with a few years ago was a project called TPMT OTP and T OTP is the time-based one-time passwords if you use anything where you have to look at your phone and there's a six digit number that changes every 30 seconds that you type in that's TOTP the way that works is that your phone and the remote service have a shared secret and then a combination of the current time and that secrets are used to generate a six digit number using some pretty terrific hashing algorithms so if you type that six digit number in you prove that you have access to the same secret so TPMT OTP the secret stores on your phone and the secret is stored on the TPM the system boots and the system then shows you a six digit number and you look at your phone and if the system shows you the same number that your phone is showing you you know that the TPM believes the system's in a good state this is still something where you're jumping through a few hoops and again you're not looking at the individual events you're only looking at the final hash values and depending on which PC arse you're using to seal this those PCRs can change for a number of reasons I do do a kernel update if the kernel is now different then the PCR value corresponding to the kernel is going to be different and if you said I want to know if the kernel version changes then suddenly this will just not unlock and you don't know why you then need to go digging and that means you probably need to authenticate against a machine that you don't know is trustworthy or not so typing credentials into it in order to start investigating is it's not necessarily what you want to do so you can get around this to an extent with a lot of infrastructure to automatically reseal the secret with new values whenever you do an update that we're changing of the values but not all updates are things we control for instance firmware updates we don't necessarily know the new good value and we won't know until the system reboots the secure boot database if the list of forbidden keys or hashes is updated then PCR seven changes and if you're doing dual booting then one operating system could update those values without the other operating system knowing about it so that's a problem so yeah they're fragile they can change on to various circumstances they don't tell us what's changed and PCR 7 PC r7 just contains information about the secure boot state and which Keys we use so the idea there is that if you broadly trust your firmware and if secure boot is enabled then the system should never have booted something that didn't have an appropriate signature so really all you want to know is which signing keys were used and what secure boot turned on so if you just look at that states you can just sort of assert hands Waverley that everything else was okay it's not ideal so time to PCR seven reduces the agility because fewer components are used in this policy decision but it also reduces the guarantees you don't have as much certainty that the systems in the states you expected it to be in so what if we could do remove SATA station but in a way that was privacy-preserving that didn't rely on you giving any of your machine identity to a third party what if we could do this offline because if you boot a laptop and it's asking you to type in your disk encryption credentials you're probably not in a position where you can get online and have your laptop prove to remote service that it's in the trustworthy state achievable with hardware you probably already have I wanted a solution where you don't need to go out and buy new hardware in order to achieve this and done entirely with free software and even better if you buy one now you can get another for only the cost of shipping and handling so I'm going to do a demo now so I'm going to warn you that obviously live demos are a terrible idea live demos that rely on working Wi-Fi are an even worse idea demos that involve you using multiple computers to do the demos seem like an astonishingly bad idea and also I'm gonna sleep Bluetooth to work so here we have so here we have this computer and here we have this computer as you can see because you name cannot possibly lie these are provably two different computers on this one I'm going to run a small server and Here I am going to run a client and we will see whether this works so it's now searching for the machine it's waiting for a Bluetooth advertisements to appear so this will take a few seconds until it sees the red packets there we go and then it didn't work let me try that again Bluetooth is amazing I'm not sure whether this is a bug in the Bluetooth stack my code or the Bluetooth codes I'm using or you know all three okay come on let's try that one more time that's better so you saw a bunch of Bluetooth traffic happening there and then you can see a bunch of stuff that looks like JSON encoded ER and then we have just graphically proven that my laptop does not have secure boot turned on if I had expected secure boot to be turned on this would be a warning that something bad had just happened so back to the demo well that's the presentation so the laptop was running a Bluetooth Low Energy server btle and the second laptop connected to it over bluetooth and then just did a full remote highsedation handshake over bluetooth so this is using there's no defined protocol for this this is just using a protocol I wrote yesterday it's got the EK from the TPM here it asks the server laptop to generate an attestation key it verifies that the association key was associated with that ek it asked for a quote of the PCR values it verifies that that quote was signed with that association key it verifies that the event log matched those PCR values and then it looked through the event log in order to extract the secure boot State now from the demo I was just taking secure boob States you could check every single measurement if you want it and you cos display that in whatever way you want it and you can make whatever sort of policy decisions around that you want it now the reason I'm using Bluetooth Low Energy here is that Bluetooth Low Energy is very easy to implement on phones as a client so the goal would be rather than using two laptops to just use your phone and your phone has the added benefits that your phone probably has the ability to connect to the internet some of you might use phones to just make phone calls I know I'm not judging but when you so the idea here would be your system boots it runs this service and before you authenticate you pull your phone out your phone then gets this information and your phone is then able to get ideally meta data from your system vendor and from your operating system vendor and look at all these values and locally tell you whether these are legitimate expected values or whether there's an indication but you're running something malicious if someone modifies your bootloader then your phone would be able to tell you that before you typed your password into your machine so that's pointer this is very much not ready for production there's no authentication so when I said this is privacy-preserving yeah it's pretty preserving assuming that we actually add the bit that preserves your privacy right now anybody could extract that information from my laptop and then no my laptop's unique identity and also know exactly what my laptop uses that sub-optimal should really add something to education it's also hard coded to TPM 1.2 at the moment that's a pretty straightforward thing to fix and I'm genuinely surprised that this works at all so yeah that was nice it did take three attempts but that's fine so need to add the missing features like you know privacy Nisa actually pause it two phones and the bigger problem is standardize a way to get known good values and allow the client to download these values and use those when making its policy determination so this is not yet a thing where we can say yes all of these problems are solved this is a thing where we're going to need to work with distros in-laws to standardize stuff and then tie that in to build and repository infrastructure and then have a guessing multiple Linux distributions to agree on something yeah that's going to be fun so I have pushed this to a branch in this repository obligatory warning here while Google owns this code this is not an official Google product if it's canceled again not my fault but yes so feel free to grab this play with it we are this is for reference the code base that we are using for our internal remote attestation infrastructure so the codes that I'm using for validation they're the only thing that was not comparable to what we're doing internally is the Bluetooth code everything else we're using the same code base to generate these measurements there's nothing super secret internal Google in what we do what you see here is what we're doing so this is a case where we want the level of protection and security that we're building internally to be available externally as well that is the end of my content so we have ten minutes or so if people have any questions there's a microphone here so ideally if you could come down there's a mic for ya if you can't come down then shout and I'll repeat the question it seems like authenticating the laptop to the phone the phone to the laptop is a bit of a challenging issue how might you go about that so ideally the authentications are basically solves problem the idea here would be you get your laptop for the first time while you're doing mishil operating system install you do the handshake there's a bootstrapping problem yes if someone has compromised your laptop before you get your laptop you're going to be in a bad place not a lot we can do about that but the it should fail the if we're able to use the platform certificate if we're able to use the TPM identity if someone has compromised your system then we should be able to verify that we are not actually communicating with the TPM on that system or that the TPM we are communicating with it doesn't correspond to the system we're trying to communicate with and that means that in principle even if the machine has been compromised before you install this the only thing it could do would be to stop this working it can not give us fake values that we would believe we're real so in principle we can do a full handshake that is not a bootstrapping issue in theory how does the TPN verify the very first item in the boot chain like does it need to set the bus or something who are great that's a great question so I mentions that's the first thing that is involved here is that the TPM that the firmware measures the rest of the firmware and yeah house we trust that the firmware that does that measurement is itself good so this is a really tough problem the answer we currently have is Intel boot guard which is the thing that stops you installing called boots on modern laptops but the reason it does that is that the the initial stage of the firmware is cryptographically signed and that signature is verified by the management engine and the management engine will only boot its own signed firmware so the management anything comes up is then able to verify the rest of the firmware and it can then measure the first stage of the firmware so the way we do this the way we solve this bootstrapping problem is that we have an entirely separate computer that lives inside your computer that does this for us I suspect your previous answer answered this but if we can't trust the manufacturers to actually either never see the secret keys are generated or just not throw them away which has happen are we screwed and it sounds like not quite right so then all the TPM keys are in theory generators on the TPM so the endorsement key should not have been generated externally and then inject it it should have been generated on TPM and then they just extract the public half and sign that so the main even the TPM manufacturers should not ideally have had access to the private path of the endorsement key and then all the other keys we generate are generated on the TPM obviously the firmware signing key from the system vendor if they lose control of that then yeah we're in a bad place and if Intel lose control of the signing key that's used for the management engine firmware again we're in a very bad place is it tractable and reasonable to do this kind of remote attestation with the client I either the one wanting to attest itself doing this in the unit Rama fest in the bootloader so putting basically a ble stack yeah so the the stuff I've demoed is all written in go so it's giant but it's also completely self-contained so you could just copy that server process binary enter in a tram FS it has no additional dependencies you run that Bluetooth comes up and then you do your check Thank You Matthew um might be a silly question can we trust the manufacturers of the TPMS themselves so at some point you're trusting people who make components for your system you're trusting that your cpu vendor is not actually trying to identify secrets and then exfiltrate those you're trusting that your GPU vendor is not DMA in stuff out of your system memory and then second graphically encoding that into your 3d texture so when you take a screenshot it's actually leaking your passwords we trust that that sort of things not happening and some of that right can we a priori know that they're trustworthy no of course not everybody could be lying to us I don't even know that you're called Donna the higher level answer is that if that's something you're concerns about you should go and see bunnies talk this afternoon because he and others are attempting to solve this problem in a way that you can verify the trustworthiness of something without signs relying on manufacturer so since you mentioned at the very start that you're not going to talk about hardware if somebody has access to the hardware can we assume that if somebody were to tamper with your computer change your software and then d soldier that CPM and replace with another chip are we are we out of luck so if someone removes the TPM and replace it with another TPM so we should be able to identify that that's happened because the ek would no longer be the same but the communications channel between the system and the TPM is not by default authenticated you can sit this up as an authenticated channel but you still have a bootstrapping problem the initial authentication could be tampered with so there's people have demonstrated that you can interpose between the TPM and the system bus and then you can identify incoming measurements and you can modify those so if someone put an interposer on there they can then modify the software and have the interposer still pass good values onto the TPM so this is not strongly resilient against a skilled attacker who's willing to do that the the cost of that sort of attacks not that high but it's obviously someone's going to need access to your system for sufficiently long to take it apart do that we then get into well can we use tamper proof screws just sort of other things that would give us an indication that someone had done this but physical attacks are a really hard problem to solve thank you any more questions no ok thank you [Applause]

Channel: linux.conf.au

Views: 6,833

Rating: 4.9463086 out of 5

Keywords: lca, lca2020, #linux.conf.au#linux#foss#opensource, MatthewGarrett

Id: FobfM9S9xSI

Length: 42min 21sec (2541 seconds)

Published: Fri Jan 17 2020