Hacking (with) a TPM
CC Attribution 4.0 International:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Fuchs, Andreas
Trusted Platform Modules (TPMs) are nowadays included in all consumer-grade devices. Whilst "the Trusted Platform Modules available for PCs are not dangerous, and there is no reason not to include one in a computer or support it in system software" (Richard Stallman, GNU) they have yet to gain wide-ranged adoption, especially for the daily needs of your average nerd. This talk will introduce OpenSource software and use cases that are already supported and how your everyday nerd can benefit from those by security your personal credentials, securing your system credentials, encrypting your storage and detecting BIOS manipulations. This talk is based on the-software.github.io contributions. It will also give a quick rundown to debunk some myths and call for participation in the OpenSource efforts for supporting more use cases via TPMs. TPMs provide several features. Most talked about are the capabilities to perform "attestations", i.e. to reliably determine the software (BIOS, OS, applications) that are running on a given system. Most commonly useful are its capabilities to act similar to a "built-in smartcard". It provides storage for keys and secrets on the device that can be protected by PINs, i.e. that are protected against bruteforce attacks. It further provides an encrypted swapping mechanism for such keys, enabling almost infinitely large storage for said keys. With this range of features available at your average nerd's disposal, it would be a shame not to use them. 1. Securing your personal credentials The most frequent application of TPMs stems from logging into other system. This includes ssh client logins or browser based client certificates and becomes even more frequent when put into context with git+ssh, git+, sftp or webdav. All these technologies and mostly all implementation support PKCS11 to allow storage of secrets on a smartcard. But SmartCards or Yubikeys require extra readers, occupy USB-slots, have to be carried around. The tpm2-pkcs11 library allows anyone to seamlessly use the TPM instead of an external smartcard. This approach provides much higher convenience compared to smartcards and even compared to passwords, since you merely need a short pin instead of a username+vErys3cur3passwor! combinations. It maps the smartcards property of possession to possession of the device, i.e. notebook. 2. Securing your system credentials Heartbleed is old but the principle problem of having keys lay around in RAM and disk is as relevant as it used to be. This is where the tpm2-tss-engine for OpenSSL comes into play. It allows the use of TPM-based keys for authentication via TLS (server and client side). Of course, if your system get's owned, it's owned, but once the attacker is gone (reboot, update, etc), you can be sure that he could not have copied the private key. Thus, no revocation or similar action is needed. 3. Encrypting your storage Basically "BitLocker for Linux" is the keyword. By extending LUKS(2) and cryptsetup, we're enabling anyone to encrypt their disk and protect there data from bruteforce password guessing if the device or disk ever got stolen. This even provides a lot more convenience, since the TPM operations can be faster than the typical KDF'ing and you can work with PINs and short passwords instead of vErys3cur3passwor! ones. 4. Detecting BIOS manipulations Talks and news about evil maids, government trojans installed at airport inspections and BIOS-based backdoors are present anywhere. The tpm2-totp project is a clone of Matthew Garrets tpm-totp that he presented at 32c3. It enable the user to authenticate not only the device to be theirs, but also if the BIOS and kernel are still in the same state as they were when they left it. Most use cases are actually running code shipping with more and more distros. The talk will give some deeper explanations into each of these and possibly some live demos.
 The next talk is hacking with a TPM. Ask what you can do for TPMs. Ask what a TPM can do for you. It's a kind of introduction into TPM and what you can do with it. And your guest host is Andreas. And here he is. Give a big applause, please. Thanks. Hi, everyone. So I'm Andreas. I'll be presenting some stuff on TPM. This is my GitHub handle and also my GitHub namespace where you can find some of the stuff or see what I'm working on. And the most important resource for everything I'm talking about is this. Weplink. But you're going to see it in the conclusions at the end again. So who am I? Some disclosure. I'm actually working on TPMs. I'm being paid to work on TPMs or I found someone willing to pay me to work on this stuff. And I'm also a member of the trust computing group, this industry consortium doing all the specification stuff. However, I started working with TPMs about 13 years ago. It was still 1.2 times at that point. I was trying to get things working for me and didn't work out too nice because the software was kind of not too well maintained and the API was some kind of a little hideous to work with. And so about five years ago when the call for participants for working on a TSS2 came up, I basically jumped into the rabbit hole right away of what specification, writing, negotiating and whatnot in TCG and also implementing the stuff and maintaining the stuff on GitHub later on becomes. And the results of this endeavor I want to present to you. So I'm going to go through some very minimal introductions to what TPMs are. And then we're going to jump right into those two topics of credential protection and some early boot protections and then just some minor information on how you can get started working on this yourself. And here comes the fun part. So for your amusement and my personal adrenaline rush late at night, I opted to go for some live demos. So what I'm going to be doing is I'll be going ahead and copying all this stuff, switching over into my trusted virtual machine here. And of course it doesn't work right away. So yeah, I should have unlocked Zulu first. Yeah. So I'll be doing some live demos every now and then. Please don't dust the Wi-Fi here, otherwise the presentation will get to a halt very quickly. Okay. What are TPMs? A TPM is basically a security chip that soldered onto your main board. And thanks to Microsoft for giving TPMs to most of us, basically for cheap, because thanks to the Microsoft logo program, every consumer, laptop, desktop, whatever nowadays has a TPM more or less. So why not make use of them? They are pretty high security, security chips, I would say. There's like some assurance from come criteria certification, which you can trust, must not trust, may trust, but every evidence counts, I guess. Of course, there was some TPM dot fails and Tanya and David just talked about it about two hours ago or three hours ago. So it was very interesting. And what is capable of, it's capable of doing crypto, which is what we're going to be talking about. It's capable of doing some storage. And it's capable of recording boot hash values. And that's basically all it can do. So it's a completely passive device. That's the most important part here. And on the right hand side there, you see some old 1.2 versions of a TPM. Nowadays, the chip package is actually a lot smaller. Our TPM is dangerous. I think we've heard talks in the past at the Congress for both arguing for both sides. TPMs reputation when it first got into the market was these are these nasty evil DRM devices that are going to remote control our PCs. As I said, they are completely passive. And what TPMs are in reality, first of all, they are an embedded smart card. So you have some kind of secure element in your PC that you can leverage. And then there is this whole integrity reporting and attestation capabilities that I'll go a little more into detail on later. But don't just take my word for it. Take Richard Stallman's or GNU Foundation's word for it. Because they concluded that the trust platform module available for PCs is not dangerous. And there is no reason not to include one in a computer or supported in your system software. So I would call that Stallman approved. And therefore, why not just go ahead and use it? But let's get into the meat of it. Credential protection. Who in here is using public key cryptography in one way or another? And yeah, I'm basically expecting all hands to raise. Who is using a smart card or a Yubi key or a TPM to protect their credentials? Okay. And who has optimized this process by just leaving the smart card in there or cutting parts of the smart card out and wrapping this with TESA or using a Yubi key nano? Okay. Those are only very few. For you few, basically this is the same assurance level that the TPM is going to give you as well. And for all others, well, smart cards, you can use a TPM instead to be more convenient. All of you who are not using smart cards but public key crypto, you should maybe consider using a TPM because you got one already and you paid for it. So why not use it? All right. What's the security idea of protecting credentials that comes with smart cards and TPMs similarly? Basically, we want to divide down our authentication guarantees into a proof of possession and a proof of knowledge. So we have two factors that are required or requested from us in order to authenticate. The proof of knowledge is pretty straightforward. It's entering a password, entering a pin to unlock your smart card, whatnot. And the proof of possession is the second factor. Well, what does this actually mean? Well, what you need in order to create a proof of possession is you need something that is not duplicable or not cloneable. So that's the primary feature of what the smart card gives you. What, for example, a soft token or a public key hanging around on your hard disk doesn't give you. Because you can just see P software, a soft token file and bring it to a different computer and have it run simultaneously on multiple computers. So by having something that's non-duplicable, you have something that can be in the possession of only one person at a single time and therefore you gain this extra security. And this becomes especially important on every kind of hacker congress like here or blackhead or whatnot because people around those conferences seem to be very good at recording passwords from looking at you, typing them into your keyboard. So this is definitely a good argument to have the second factor. So the proof of possession, which is usually like your smart card or your Ubi-Kinano can be basically translated into, well, we have a proof of possession of my laptop that contains a TPM. So only if somebody has access to this laptop and knowledge of the pin, those two factors allow them to authenticate in my name or in the name of this credential. So the question is, but what if you're hacked? Well, this is a problem for every kind of proof of possession means. It's the same if you have a smart card in your smart card reader slot. For the time that somebody is able to control your system, they are able to more or less use your credential as well. But there's two differences. It's temporarily bound to the amount of time that you are hacked. So if you clean up your system, you can continue working normally again afterwards. And there's the second thing. There's no chance for an attack such as heart bleed where people would, because not every exploit is capable of gaining like full privileges. Sometimes exploits like heart bleed are only able to dump certain memory pages out where maybe your key was living and then you're screwed. You don't have that problem if the key is not known to the computer, to the CPU and never stored in RAM or on disk. All right. Demo time. How can you actually implement or how can you make use of these credential protections? The simplest way to do so is with the TPM2 TSS engine from the TPM2 software project. I probably should have mentioned that here. So there was one of the softwares that we installed earlier and actually they did install. That's very nice. All right. In order to use that, all you need is these, I don't know, three commands. And therefore I just want to show them to you real quick. By the way, I'm not using a TPM simulator. I just wanted to show that I'm using an actual hardware TPM here. I just forwarded it to the virtual machine for fun and glory. All right. Virtual desktop switching. All right. So what we're going to do first is we are realizing, yeah, now it's working. We are generating a key for the TPM and the next command is then we're going to generate a self-signed certificate. As you can see, for those of you who've worked with OpenSSL in the past, the first command is a custom command of the software. The second command is just a regular OpenSSL, create a self-signed certificate command with some mentioning of the engine and mentioning that we have a key form that comes from the engine. And that's basically it. So we're going to go ahead and take that. Post that in here as well. Well, we're going to take that from Austria now. Who cares? All right. And now we have curl. And curl is actually capable of connecting us. Come on. I should have brought a mouse. So curl is capable of making use of OpenSSL engines and don't get irritated by the dash dash insecure here. That's I'm running an engine X server right now on the host system. And from the virtual machine now, I'm using curl to authenticate using client certificate authentication via TLS. And I guess everybody knows what that means to talk to the engine X. And as you can see, this is the website. And the first time I executed that command, I couldn't quite believe it because it was so fast. And I thought I made a mistake or something. So just to verify to all of you, I'll be enabling trace logging. And then we see that we have a bunch of communication happening with the TPM. So we actually are using the TPM to do client side authentication to the server. Thanks. Next thing. So this is why, first of all, why I'm doing this. I'm of course doing this to scratch my own itchers. So I want to be using TPMs at home maybe for like simple bash script based stuff. And whenever you're doing a bash script, you don't want to put your passwords in there because when you push them to GitHub, other people will download them and use your passwords. Yes. So that's another advantage of these. And the second thing I want to be doing at home, I have some web server facing the internet that's basically a reverse proxy on engine X that forward stuff to home assistant and octoprint and whatnot. And I want to enable this thing to store its credentials safely and securely as well so the next engine X hardly doesn't ruin everything for me. And for engine X, it's actually pretty simple to do that. If we look into the sites enabled here, it's basically just the default site, we see that we had to post in the SSS certificate and under the SSS certificate key, you can use this keyword engine. So hopefully you never store your key in a file called engine because that's going to be a problem. And we point to the TPM to TSS engine. And because of some hideous bug in engine X that people on the engine X forum have been talking about but didn't find a good solution to fix it, we also have to specify the engine a second time over here. So once we have all that, we can just restart engine X and this time we're going to turn it around so I'm going to go ahead and take my trusty web server on the host system, try to connect to that thing and yeah, because it's a SSS certificate, of course, we don't trust it right away. But we just used the TPM in order to authenticate the TLS connection from the server side as well so with both sides that we can now start scripting. Cool. There we go. All right. So that's the easiest way to get started when you're trying to integrate TPMs into any of your daily bash routines or whatnot. The next a little more complex way to do things is PKCS 11. So PKCS 11 is this standardized API by the open group that is what Firefox uses in order to talk to smart cards, for example. And of course, we're also working on or the like this community is also working on something for that. We even have a maintainer sitting here in the room. Calling you out there. All right. And we're currently in the 1.0 RC0 phase for this thing, which is also the reason why there is some weirdness that the setup tools don't install whenever you call make install. So if you're trying to rerun this stuff from home based on these slides, note that this is a path into the checked out Git repository for the TPM to P tool. And the only thing that actually gets installed is the library, the PKCS 11 library that's later on used. So anyways, we're taking these few commands here. And basically what we're doing is we're initializing. First of all, we're setting some Python pass stuff and stuff like that. We're pointing to storing the database under home. We're initializing the database, adding a token, which is basically creating a new smart card out of nothing. And then we're adding a key. All right. Let's see. Is that running as well? Looks good. Yep. And there we have it. We just generated a smart card with this random, what not, smart card ID that you don't really have to care about. But what the cool thing is about this, and why I'm actually going into this problem is I want to use that in order to authenticate via SSH. Because I don't know how many of you are using SSH client authentication using public keys? That's basically almost everyone. That's cool. Hacker Congress. So and who of you is not protecting their key with a password but using an empty password for that? All right. For all of you, this might be interesting. So what we're going to do is we're going to call SSH key gen. What this is going to be doing is it's going to just, yeah, generate an SSH key. And you've probably all seen this. So I'm going ahead and copying this and going into my host machine. And here I'm going to edit the authorized keys. And I'll add this key. That's all. And going back to the virtual machine. Virtual desktop inside of a virtual desktop. So I can write. All right. And then we can log in using SSH. And this should also be working now. And here we asked for the pin for the smart card that I originally called label, which probably you can find a better name for that. And now I'm in. So it's working as well. But to make things even cooler, what else do we use SSH for? Well, we use it or at least I use it for Git. Git together with SSH. So we'll go ahead, take this key again. And we're going to head over to GitHub. And this is my GitHub account. Now it gets interesting. So I'm adding this SSH key. And yes, I'm storing passwords. They don't have client certificate authentication. What else should I do? So the thing we're doing here is basically I'm creating this awesome shell script that contains often SSH invocation with the PKC11 library. And then we're exporting that under the Git underscore SSH environment variable, which means that instead of SSH, Git is going to be calling our new SSH thing. And this then translates to invoking the PKC11 provider. So let's go ahead and clone. And here we have the TPM invocation again and a lot more TPM invocation. And there we are. And we can now even go ahead and check out a branch. I think I've used this in my tests. I'm just going to call it now. No. Of course. Check out a new branch. Git push origin. And it's pushed. And you can just go ahead, go to my name space on GitHub and you should be seeing this awesome TPM authenticated branch push over there. All right. As I said, this is RC0. Hopefully there's going to be a few hiccups and bugs that we're going to fix before the final release. But it looks kind of usable, I would say. All right. Coming to the next thing, which is highly work in progress. So basically this is about BitLocker for Linux. And I've written this, I don't know, I think more than a year ago. And there was a merge request on the Crypt setup upstream. And we're basically re-architecting the whole thing. But I just thought for fun and glory, I would bring this work that I did back in the days. So what this is doing, so for Lux and Crypt setup, the idea is you have a volume key that the whole volume is encrypted with. And then you have multiple key slots that are stored in the Lux header of the partition where this volume key is encrypted usually with a key that is derived from the password you're entering. And this then looks like the thing we see here in the middle where we have key slot zero of this type and whatnot. And so what I did back then was I extended these, yeah, this is JSON. So if you're using Lux, at least in a new on-disk format, you have JSON in your partition headers, which is kind of awesome actually to extend. Made my life a lot easier at the time. So we have there a key slot, so something like that. And what we do is we take the volume key and we use one of the TPM's non-volatile memory spaces and we just store the volume key directly in there. And so there's, yeah, nothing else we need to do. And then what we do on the on-disk format for the Lux headers, we're just storing some metadata. For example, what the NV index number is that we stored the stuff under. All right. So demo time again. And, whoop. So this is the crypto setup branch that I checked out and will be compiling this live. In the meantime, maybe one more note. So the operating system running there in the virtual machine is just a standard Ubuntu installation. And I just chose disk encryption in LLVM during the Ubuntu whatever setup wizard. And, however, unfortunately, that's still using the Lux 1 on-disk format. So what you have to do from the install media, if you want to do that, is you have to call this crypto setup convert that converts the Lux 1 to the Lux 2 format header. And then you should be ready to go. All right. So, yeah, we compiled, we installed. Now we're updating the inner drum FS. Just replacing it. Crypt setup who doesn't do that all the time. And the next command that we're running, and you will see that the only difference in the command is we're adding a dash dash TPM here, which, yeah, calls out to using a TPM slot for that. And we're entering an existing password. We're entering a new password. And this new password is then used for the TPM to authenticate. And we only have five minutes. So I'll just skip it right ahead. So this is now all set up. And on the next reboot, the system is going to ask me for the TPM-based password. And let's see at this. So what we see here is this second key slot is now of TPM 2 type. All right. One more thing I want to present for early boot is integrity checking. This is based on what Matthew Garret talked about at the 32 C3. And this is the link to his talk. You should definitely go watch it. So this is about verifying the integrity of your early boot by sharing a secret between your TPM and your smartphone. And, yeah, I just did a re-implementation. I'm going to showcase that as well. So in preparation for that, it's time for all of you to get out your smartphones and open your free OTP app or your Google authenticator so you can verify that everything works as intended. And this one I actually pre-compiled. By the way, if there's somebody in the audience who's good at GTK GUI design, please come talk to me after because that was my attempt at doing this. All right. We're going to be protecting by binding to PCRs 0 through 7. And this is going to basically validate on each boot that these PCR values were the same that they are right now when we are trusting the system. So that means if you have a kernel update or you update your init RD afterwards, there's going to be different PCR values. So you will have to go through this process again. So everybody has scanned this, hopefully, into the free OTP or Google authenticator. Then we can go ahead and we can actually start rebooting the system. And hopefully this works now. Because the most complicated part about all of these demos was actually mode setting for Plymouth between Grubb and Plymouth, believe it or not. All right. And there is this number, which is very large and on the screen. So it was 828688. Was that correct? Awesome. And the second thing I'm doing now is instead of the highly secure password Andreas, I'm typing in 1234. You have to believe me. Which is the TPM password. And it's actually booting through using the TPM here. Which is, come on. There it is. So that also worked with Lux. All right. I hope this gave you some impressions of what you can do with TPMs today already. If you want to get started joining the effort, joining to Hecaron stuff, this website up there is like our community page where we have a Gitter. So you can come talk to us, talk to me, talk to the other devils. You can have a look at those two header files, which are the most important ones right now. So the FAPI is rather new. We just merged it into master, I think, one week ago. So go ahead, have a look at that, test it thoroughly. Have a look at the tools. All the tools that start with TPM2 underscore are basically one-to-one mirrors of eSAPI or ESUS. And all tools prefixed TSS2 underscore are one-to-one FAPI mappings. And here's one more pro tip. When you're developing and something randomly fails all of a sudden, it usually has to do with TPM resource exhaustion. And this command down there frees up the TPM's internal RAM again so you can continue working. All right. Thank you. Thank you. Thank you. That was Andreas. And it's question time. We have questions from the Internet and we have questions here in clock. And look at it. You two have the same shirt. A very nice shirt. Resource exhaustion. Okay. So maybe we start with number four, please. Okay. So let's say you have your encryption keys in the TPM and your FAPI government is somehow influencing the vendor of the TPM. So there could be maybe some way to get the encryption keys. So this is not a good approach. So it would be nicer to enter your big fat mantra to get your keys. And they are x-word with some other keys that are in the TPM. And so you need to have both to decrypt your look stuff. So this should be bait like this. So you could not, let's say, take the person, torture the person and try to decrypt the data on another computer because it has a different TPM without a secret. So you should have real two-factor authentication, not having the keys in the TPM because I would not trust it. Okay. Depending on your paranoia level, but that's definitely a nice idea. Thank you. Only having questions, please. No comments. Questions. That's the role. Number two. I have to use Windows, which is encrypted with BitLocker and a second petition. How likely is it to accidentally destroy the credentials for BitLocker when working with these tools? Well that highly depends on which tools you're using for which purpose. The tools that I used here and everything that I showed does not install persistent keys. I think, actually PKC11 is installing a persistent key so that drains some of your resources. And also the crypt setup stuff and the TOTP stuff consumes some NV space. And depending on how much of the TPM's resources Windows wants to claim for itself, you could run into resource exhaustion there. But other than that, there's no keys that these tools or the demos I showed would be deleting. So you can just go ahead and use those. Okay. Thank you. Maybe we'll have a question from the Internet. Do you signal, Angel? Yeah. Other hardware tokens like a UB key, for example, they might have a button that you need to press in order to have some kind of proof of presence so that software cannot use it in the background without you knowing it. How to do that with a TPM? Currently not. But I'm hoping or I have been hoping for a TPM with an embedded LED for 10 years now. More likely maybe we'll see some GPIO enabled TPMs at some point in the future. And depending on what we can do with those, we might be able to include this or similar features in there. But so far, I think there's only been research prototypes. I once implemented a TPM on Cortex M3 myself in order to demonstrate the usefulness of GPIO coming right out of the TPM, but that would need to be developed first. Okay. Thank you. Number five, please. Yeah. Hi. Can you implement the universal second factor or video to NTFS? Do you plan to do it? Yes and no. You can implement parts of FIDO using a TPM, which is the basic crypto operation. However, FIDO also includes custom data formats that are usually also handled in the FIDO token where you have some counters that you're incrementing something like that, which the TPM does not store internally because the TPM doesn't know about FIDO data structures and vice versa. However, for FIDO 2, I think there was this TPM attestation mode, but that would need to be implemented by someone. So if you want to start working on that, please come talk to me. I'll gladly be of help. So there's a lot to do and yes. So if any of you are searching for something to do, you can just go ahead and look at this GitHub I O community page. If you go to the software tab at the top and you scroll down, there is a list of programs. So we started with the programs that already have TPM support and then we have an even longer list of programs that we wish had TPM support. So there's also other things like WebAuth N or WebCryptoKi or whatnot where I would love to see more TPM support or even as simple as GPG, which yeah. Okay. Number two, please. How many different keys or smart cards can you store in a TPM? Is it just one or can you save more in there? The nice thing is that the principle concept of a TPM is that the TPM stores only very few keys. Usually it's just one in this case. And all the other keys are then encrypted with this key and stored on disk on hard disk. So with this PKCS 11 that we have here, you can have as many keys as you have hard disk space available or as many keys as SQLite will allow you to store in a database with reasonable search times, I would say. Thank you. Number four, please. Hi. Thank you for the presentation. I have a question related to kernel upgrades. If I upgrade my kernel, is there a way I can measure what the kernel will be on the next boot and tell my TPM that just resealed the currently sealed keys with the future PCR values that it should expect on the next boot? In theory, absolutely yes. That's totally simple. So a researcher will tell you this is not a challenge. The engineer is going to tell you, well, this is kind of a problem. And the problem is that you somehow need to know the reference values beforehand. And then you have to recalculate the whole measurement chain that went into that. And so this is a question of reference integrity measurement distribution that there was also a track at the Linus Plummas conference tackling this problem. So this is mainly an infrastructure problem rather than an actual problem of the TPM or the TPM base software. Okay. Thank you. So we just have one more minute, so I'm very sorry we can't take any questions more in the room. But I'll have one last question from the Internet. Yeah, if I don't trust the TPM and my machine, can I just solder in a different one from a more trustworthy vendor? Are they compatible in that sense? Yes, as far as I know, they have a compatible pinout and a compatible SPI protocol. And that's the nice thing about standardization is that they are compatible. So sure, go ahead. Except for maybe inter-PTT FTPMs that run in the management engine, those of course, if you solder those out, you won't have any IO anymore. Okay, thank you so much. If you want to get in touch with Andreas, go to the website. You've seen it before. And thank you for now. And maybe another applause for Andreas. Thank you.
 The next talk is hacking with a TPM.  Ask what you can do for TPMs. Ask what a TPM can do for you. It's a kind of introduction  into TPM and what you can do with it. And your guest host is Andreas. And here he is.  Give a big applause, please. Thanks.  Hi, everyone. So I'm Andreas. I'll be presenting some stuff on TPM. This is my GitHub handle  and also my GitHub namespace where you can find some of the stuff or see what I'm working  on. And the most important resource for everything I'm talking about is this. Weplink. But you're  going to see it in the conclusions at the end again. So who am I? Some disclosure. I'm  actually working on TPMs. I'm being paid to work on TPMs or I found someone willing to  pay me to work on this stuff. And I'm also a member of the trust computing group, this  industry consortium doing all the specification stuff. However, I started working with TPMs  about 13 years ago. It was still 1.2 times at that point. I was trying to get things working  for me and didn't work out too nice because the software was kind of not too well maintained  and the API was some kind of a little hideous to work with. And so about five years ago  when the call for participants for working on a TSS2 came up, I basically jumped into  the rabbit hole right away of what specification, writing, negotiating and whatnot in TCG and  also implementing the stuff and maintaining the stuff on GitHub later on becomes. And  the results of this endeavor I want to present to you. So I'm going to go through some very  minimal introductions to what TPMs are. And then we're going to jump right into those  two topics of credential protection and some early boot protections and then just some  minor information on how you can get started working on this yourself. And here comes the  fun part. So for your amusement and my personal adrenaline rush late at night, I opted to go  for some live demos. So what I'm going to be doing is I'll be going ahead and copying  all this stuff, switching over into my trusted virtual machine here. And of course it doesn't  work right away. So yeah, I should have unlocked Zulu first. Yeah. So I'll be doing some live  demos every now and then. Please don't dust the Wi-Fi here, otherwise the presentation  will get to a halt very quickly. Okay. What are TPMs? A TPM is basically a security chip  that soldered onto your main board. And thanks to Microsoft for giving TPMs to most of us,  basically for cheap, because thanks to the Microsoft logo program, every consumer, laptop,  desktop, whatever nowadays has a TPM more or less. So why not make use of them? They are  pretty high security, security chips, I would say. There's like some assurance from come  criteria certification, which you can trust, must not trust, may trust, but every evidence  counts, I guess. Of course, there was some TPM dot fails and Tanya and David just talked  about it about two hours ago or three hours ago. So it was very interesting. And what  is capable of, it's capable of doing crypto, which is what we're going to be talking about.  It's capable of doing some storage. And it's capable of recording boot hash values. And  that's basically all it can do. So it's a completely passive device. That's the most  important part here. And on the right hand side there, you see some old 1.2 versions  of a TPM. Nowadays, the chip package is actually a lot smaller. Our TPM is dangerous. I think  we've heard talks in the past at the Congress for both arguing for both sides. TPMs reputation  when it first got into the market was these are these nasty evil DRM devices that are  going to remote control our PCs. As I said, they are completely passive. And what TPMs  are in reality, first of all, they are an embedded smart card. So you have some kind  of secure element in your PC that you can leverage. And then there is this whole integrity  reporting and attestation capabilities that I'll go a little more into detail on later.  But don't just take my word for it. Take Richard Stallman's or GNU Foundation's word for it.  Because they concluded that the trust platform module available for PCs is not dangerous.  And there is no reason not to include one in a computer or supported in your system  software. So I would call that Stallman approved. And therefore, why not just go ahead and use  it? But let's get into the meat of it. Credential protection. Who in here is using public key  cryptography in one way or another? And yeah, I'm basically expecting all hands to raise.  Who is using a smart card or a Yubi key or a TPM to protect their credentials? Okay.  And who has optimized this process by just leaving the smart card in there or cutting  parts of the smart card out and wrapping this with TESA or using a Yubi key nano? Okay.  Those are only very few. For you few, basically this is the same assurance level that the  TPM is going to give you as well. And for all others, well, smart cards, you can use  a TPM instead to be more convenient. All of you who are not using smart cards but public  key crypto, you should maybe consider using a TPM because you got one already and you  paid for it. So why not use it? All right. What's the security idea of protecting credentials  that comes with smart cards and TPMs similarly? Basically, we want to divide down our authentication  guarantees into a proof of possession and a proof of knowledge. So we have two factors  that are required or requested from us in order to authenticate. The proof of knowledge  is pretty straightforward. It's entering a password, entering a pin to unlock your smart  card, whatnot. And the proof of possession is the second factor. Well, what does this  actually mean? Well, what you need in order to create a proof of possession is you need  something that is not duplicable or not cloneable. So that's the primary feature of what the  smart card gives you. What, for example, a soft token or a public key hanging around  on your hard disk doesn't give you. Because you can just see P software, a soft token  file and bring it to a different computer and have it run simultaneously on multiple  computers. So by having something that's non-duplicable, you have something that can be in the possession  of only one person at a single time and therefore you gain this extra security. And this becomes  especially important on every kind of hacker congress like here or blackhead or whatnot  because people around those conferences seem to be very good at recording passwords from  looking at you, typing them into your keyboard. So this is definitely a good argument to have  the second factor. So the proof of possession, which is usually like your smart card or your  Ubi-Kinano can be basically translated into, well, we have a proof of possession of my  laptop that contains a TPM. So only if somebody has access to this laptop and knowledge of  the pin, those two factors allow them to authenticate in my name or in the name of this credential.  So the question is, but what if you're hacked? Well, this is a problem for every kind of  proof of possession means. It's the same if you have a smart card in your smart card reader  slot. For the time that somebody is able to control your system, they are able to more  or less use your credential as well. But there's two differences. It's temporarily bound to  the amount of time that you are hacked. So if you clean up your system, you can continue  working normally again afterwards. And there's the second thing. There's no chance for an  attack such as heart bleed where people would, because not every exploit is capable of gaining  like full privileges. Sometimes exploits like heart bleed are only able to dump certain  memory pages out where maybe your key was living and then you're screwed. You don't have that  problem if the key is not known to the computer, to the CPU and never stored in RAM or on disk.  All right. Demo time. How can you actually implement or how can you make use of these  credential protections? The simplest way to do so is with the TPM2 TSS engine from the  TPM2 software project. I probably should have mentioned that here. So there was one of the  softwares that we installed earlier and actually they did install. That's very nice. All right.  In order to use that, all you need is these, I don't know, three commands. And therefore  I just want to show them to you real quick. By the way, I'm not using a TPM simulator.  I just wanted to show that I'm using an actual hardware TPM here. I just forwarded it to  the virtual machine for fun and glory. All right. Virtual desktop switching.  All right. So what we're going to do first is we are realizing, yeah, now it's working.  We are generating a key for the TPM and the next command is then we're going to generate  a self-signed certificate. As you can see, for those of you who've worked with OpenSSL  in the past, the first command is a custom command of the software. The second command  is just a regular OpenSSL, create a self-signed certificate command with some mentioning of  the engine and mentioning that we have a key form that comes from the engine. And that's  basically it. So we're going to go ahead and take that. Post that in here as well. Well,  we're going to take that from Austria now. Who cares? All right. And now we have curl.  And curl is actually capable of connecting us. Come on. I should have brought a mouse.  So curl is capable of making use of OpenSSL engines and don't get irritated by the dash  dash insecure here. That's I'm running an engine X server right now on the host system.  And from the virtual machine now, I'm using curl to authenticate using client certificate  authentication via TLS. And I guess everybody knows what that means to talk to the engine  X. And as you can see, this is the website. And the first time I executed that command,  I couldn't quite believe it because it was so fast. And I thought I made a mistake or  something. So just to verify to all of you, I'll be enabling trace logging. And then we  see that we have a bunch of communication happening with the TPM. So we actually are  using the TPM to do client side authentication to the server. Thanks. Next thing. So this  is why, first of all, why I'm doing this. I'm of course doing this to scratch my own  itchers. So I want to be using TPMs at home maybe for like simple bash script based stuff.  And whenever you're doing a bash script, you don't want to put your passwords in there  because when you push them to GitHub, other people will download them and use your passwords.  Yes. So that's another advantage of these. And the second thing I want to be doing at  home, I have some web server facing the internet that's basically a reverse proxy on engine  X that forward stuff to home assistant and octoprint and whatnot. And I want to enable  this thing to store its credentials safely and securely as well so the next engine X  hardly doesn't ruin everything for me. And for engine X, it's actually pretty simple  to do that. If we look into the sites enabled here, it's basically just the default site,  we see that we had to post in the SSS certificate and under the SSS certificate key, you can  use this keyword engine. So hopefully you never store your key in a file called engine  because that's going to be a problem. And we point to the TPM to TSS engine. And because  of some hideous bug in engine X that people on the engine X forum have been talking about  but didn't find a good solution to fix it, we also have to specify the engine a second  time over here. So once we have all that, we can just restart engine X and this time  we're going to turn it around so I'm going to go ahead and take my trusty web server  on the host system, try to connect to that thing and yeah, because it's a SSS certificate,  of course, we don't trust it right away. But we just used the TPM in order to authenticate  the TLS connection from the server side as well so with both sides that we can now start  scripting. Cool. There we go. All right. So that's the easiest way to get started when  you're trying to integrate TPMs into any of your daily bash routines or whatnot. The  next a little more complex way to do things is PKCS 11. So PKCS 11 is this standardized  API by the open group that is what Firefox uses in order to talk to smart cards, for  example. And of course, we're also working on or the like this community is also working  on something for that. We even have a maintainer sitting here in the room. Calling you out  there. All right. And we're currently in the 1.0 RC0 phase for this thing, which is also  the reason why there is some weirdness that the setup tools don't install whenever you  call make install. So if you're trying to rerun this stuff from home based on these  slides, note that this is a path into the checked out Git repository for the TPM to  P tool. And the only thing that actually gets installed is the library, the PKCS 11 library  that's later on used. So anyways, we're taking these few commands here. And basically what  we're doing is we're initializing. First of all, we're setting some Python pass stuff  and stuff like that. We're pointing to storing the database under home. We're initializing  the database, adding a token, which is basically creating a new smart card out of nothing. And  then we're adding a key. All right. Let's see. Is that running as well? Looks good.  Yep. And there we have it. We just generated a smart card with this random, what not, smart  card ID that you don't really have to care about. But what the cool thing is about this,  and why I'm actually going into this problem is I want to use that in order to authenticate  via SSH. Because I don't know how many of you are using SSH client authentication using  public keys? That's basically almost everyone. That's cool. Hacker Congress. So and who  of you is not protecting their key with a password but using an empty password for that?  All right. For all of you, this might be interesting. So what we're going to do is we're going to  call SSH key gen. What this is going to be doing is it's going to just, yeah, generate  an SSH key. And you've probably all seen this. So I'm going ahead and copying this and going  into my host machine. And here I'm going to edit the authorized keys. And I'll add this  key. That's all. And going back to the virtual machine. Virtual desktop inside of a virtual  desktop. So I can write. All right. And then we can log in using SSH. And this should also  be working now. And here we asked for the pin for the smart card that I originally called  label, which probably you can find a better name for that. And now I'm in. So it's working  as well. But to make things even cooler, what else do we use SSH for? Well, we use it or  at least I use it for Git. Git together with SSH. So we'll go ahead, take this key again.  And we're going to head over to GitHub. And this is my GitHub account. Now it gets interesting.  So I'm adding this SSH key. And yes, I'm storing passwords. They don't have client certificate  authentication. What else should I do? So the thing we're doing here is basically I'm  creating this awesome shell script that contains often SSH invocation with the PKC11 library.  And then we're exporting that under the Git underscore SSH environment variable, which  means that instead of SSH, Git is going to be calling our new SSH thing. And this then  translates to invoking the PKC11 provider. So let's go ahead and clone. And here we have  the TPM invocation again and a lot more TPM invocation. And there we are. And we can now  even go ahead and check out a branch. I think I've used this in my tests. I'm just going  to call it now. No. Of course. Check out a new branch. Git push origin. And it's pushed.  And you can just go ahead, go to my name space on GitHub and you should be seeing this awesome  TPM authenticated branch push over there. All right. As I said, this is RC0. Hopefully  there's going to be a few hiccups and bugs that we're going to fix before the final release.  But it looks kind of usable, I would say. All right. Coming to the next thing, which  is highly work in progress. So basically this is about BitLocker for Linux. And I've written  this, I don't know, I think more than a year ago. And there was a merge request on the  Crypt setup upstream. And we're basically re-architecting the whole thing. But I just  thought for fun and glory, I would bring this work that I did back in the days. So what  this is doing, so for Lux and Crypt setup, the idea is you have a volume key that the  whole volume is encrypted with. And then you have multiple key slots that are stored in  the Lux header of the partition where this volume key is encrypted usually with a key  that is derived from the password you're entering. And this then looks like the thing we see  here in the middle where we have key slot zero of this type and whatnot. And so what  I did back then was I extended these, yeah, this is JSON. So if you're using Lux, at least  in a new on-disk format, you have JSON in your partition headers, which is kind of  awesome actually to extend. Made my life a lot easier at the time. So we have there a  key slot, so something like that. And what we do is we take the volume key and we use  one of the TPM's non-volatile memory spaces and we just store the volume key directly  in there. And so there's, yeah, nothing else we need to do. And then what we do on the  on-disk format for the Lux headers, we're just storing some metadata. For example, what  the NV index number is that we stored the stuff under. All right. So demo time again.  And, whoop. So this is the crypto setup branch that I checked out and will be compiling this  live. In the meantime, maybe one more note. So the operating system running there in the  virtual machine is just a standard Ubuntu installation. And I just chose disk encryption  in LLVM during the Ubuntu whatever setup wizard. And, however, unfortunately, that's  still using the Lux 1 on-disk format. So what you have to do from the install media, if  you want to do that, is you have to call this crypto setup convert that converts the Lux  1 to the Lux 2 format header. And then you should be ready to go. All right. So, yeah,  we compiled, we installed. Now we're updating the inner drum FS. Just replacing it. Crypt  setup who doesn't do that all the time. And the next command that we're running, and you  will see that the only difference in the command is we're adding a dash dash TPM here, which,  yeah, calls out to using a TPM slot for that. And we're entering an existing password. We're  entering a new password. And this new password is then used for the TPM to authenticate.  And we only have five minutes. So I'll just skip it right ahead. So this is now all set  up. And on the next reboot, the system is going to ask me for the TPM-based password.  And let's see at this. So what we see here is this second key slot is now of TPM 2 type.  All right. One more thing I want to present for early boot is integrity checking. This  is based on what Matthew Garret talked about at the 32 C3. And this is the link to his  talk. You should definitely go watch it. So this is about verifying the integrity of your  early boot by sharing a secret between your TPM and your smartphone. And, yeah, I just  did a re-implementation. I'm going to showcase that as well. So in preparation for that,  it's time for all of you to get out your smartphones and open your free OTP app or your Google  authenticator so you can verify that everything works as intended. And this one I actually  pre-compiled. By the way, if there's somebody in the audience who's good at GTK GUI design,  please come talk to me after because that was my attempt at doing this. All right. We're  going to be protecting by binding to PCRs 0 through 7. And this is going to basically  validate on each boot that these PCR values were the same that they are right now when  we are trusting the system. So that means if you have a kernel update or you update your  init RD afterwards, there's going to be different PCR values. So you will have to go through  this process again. So everybody has scanned this, hopefully, into the free OTP or Google  authenticator. Then we can go ahead and we can actually start rebooting the system. And  hopefully this works now. Because the most complicated part about all of these demos  was actually mode setting for Plymouth between Grubb and Plymouth, believe it or not. All  right. And there is this number, which is very large and on the screen. So it was 828688.  Was that correct? Awesome. And the second thing I'm doing now is instead of the highly  secure password Andreas, I'm typing in 1234. You have to believe me. Which is the TPM password.  And it's actually booting through using the TPM here. Which is, come on. There it is.  So that also worked with Lux. All right. I hope this gave you some impressions of what  you can do with TPMs today already. If you want to get started joining the effort, joining  to Hecaron stuff, this website up there is like our community page where we have a Gitter.  So you can come talk to us, talk to me, talk to the other devils. You can have a look at  those two header files, which are the most important ones right now. So the FAPI is rather  new. We just merged it into master, I think, one week ago. So go ahead, have a look at  that, test it thoroughly. Have a look at the tools. All the tools that start with TPM2  underscore are basically one-to-one mirrors of eSAPI or ESUS. And all tools prefixed TSS2  underscore are one-to-one FAPI mappings. And here's one more pro tip. When you're developing  and something randomly fails all of a sudden, it usually has to do with TPM resource exhaustion.  And this command down there frees up the TPM's internal RAM again so you can continue working.  All right. Thank you.  Thank you. Thank you. That was Andreas. And it's question time. We have questions from  the Internet and we have questions here in clock. And look at it. You two have the same  shirt. A very nice shirt. Resource exhaustion. Okay. So maybe we start with number four,  please. Okay. So let's say you have your encryption keys in the TPM and your FAPI government  is somehow influencing the vendor of the TPM. So there could be maybe some way to get the  encryption keys. So this is not a good approach. So it would be nicer to enter your big fat  mantra to get your keys. And they are x-word with some other keys that are in the TPM.  And so you need to have both to decrypt your look stuff. So this should be bait like this.  So you could not, let's say, take the person, torture the person and try to decrypt the  data on another computer because it has a different TPM without a secret. So you should  have real two-factor authentication, not having the keys in the TPM because I would  not trust it. Okay. Depending on your paranoia level, but that's definitely a nice idea.  Thank you. Only having questions, please. No comments. Questions. That's the role. Number  two. I have to use Windows, which is encrypted with BitLocker and a second petition. How likely  is it to accidentally destroy the credentials for BitLocker when working with these tools?  Well that highly depends on which tools you're using for which purpose. The tools that I  used here and everything that I showed does not install persistent keys. I think, actually  PKC11 is installing a persistent key so that drains some of your resources. And also the  crypt setup stuff and the TOTP stuff consumes some NV space. And depending on how much  of the TPM's resources Windows wants to claim for itself, you could run into resource exhaustion  there. But other than that, there's no keys that these tools or the demos I showed would  be deleting. So you can just go ahead and use those. Okay. Thank you. Maybe we'll have a  question from the Internet. Do you signal, Angel? Yeah. Other hardware tokens like a  UB key, for example, they might have a button that you need to press in order to have some  kind of proof of presence so that software cannot use it in the background without you  knowing it. How to do that with a TPM? Currently not. But I'm hoping or I have been hoping  for a TPM with an embedded LED for 10 years now. More likely maybe we'll see some GPIO  enabled TPMs at some point in the future. And depending on what we can do with those,  we might be able to include this or similar features in there. But so far, I think there's  only been research prototypes. I once implemented a TPM on Cortex M3 myself in order to demonstrate  the usefulness of GPIO coming right out of the TPM, but that would need to be developed  first. Okay. Thank you. Number five, please. Yeah. Hi. Can you implement the universal  second factor or video to NTFS? Do you plan to do it? Yes and no. You can implement parts  of FIDO using a TPM, which is the basic crypto operation. However, FIDO also includes custom  data formats that are usually also handled in the FIDO token where you have some counters  that you're incrementing something like that, which the TPM does not store internally because  the TPM doesn't know about FIDO data structures and vice versa. However, for FIDO 2, I think  there was this TPM attestation mode, but that would need to be implemented by someone. So  if you want to start working on that, please come talk to me. I'll gladly be of help. So  there's a lot to do and yes. So if any of you are searching for something to do, you  can just go ahead and look at this GitHub I O community page. If you go to the software  tab at the top and you scroll down, there is a list of programs. So we started with  the programs that already have TPM support and then we have an even longer list of programs  that we wish had TPM support. So there's also other things like WebAuth N or WebCryptoKi  or whatnot where I would love to see more TPM support or even as simple as GPG, which  yeah. Okay. Number two, please. How many different keys or smart cards can you store in a TPM?  Is it just one or can you save more in there? The nice thing is that the principle concept  of a TPM is that the TPM stores only very few keys. Usually it's just one in this case.  And all the other keys are then encrypted with this key and stored on disk on hard disk.  So with this PKCS 11 that we have here, you can have as many keys as you have hard disk  space available or as many keys as SQLite will allow you to store in a database with  reasonable search times, I would say. Thank you. Number four, please.  Hi. Thank you for the presentation. I have a question related to kernel upgrades. If  I upgrade my kernel, is there a way I can measure what the kernel will be on the next  boot and tell my TPM that just resealed the currently sealed keys with the future PCR  values that it should expect on the next boot? In theory, absolutely yes. That's totally  simple. So a researcher will tell you this is not a challenge. The engineer is going  to tell you, well, this is kind of a problem. And the problem is that you somehow need to  know the reference values beforehand. And then you have to recalculate the whole measurement  chain that went into that. And so this is a question of reference integrity measurement  distribution that there was also a track at the Linus Plummas conference tackling this  problem. So this is mainly an infrastructure problem rather than an actual problem of the  TPM or the TPM base software. Okay. Thank you. So we just have one more minute, so I'm  very sorry we can't take any questions more in the room. But I'll have one last question  from the Internet. Yeah, if I don't trust the TPM and my machine, can I just solder in a  different one from a more trustworthy vendor? Are they compatible in that sense? Yes, as  far as I know, they have a compatible pinout and a compatible SPI protocol. And that's  the nice thing about standardization is that they are compatible. So sure, go ahead. Except  for maybe inter-PTT FTPMs that run in the management engine, those of course, if you  solder those out, you won't have any IO anymore. Okay, thank you so much. If you want to get  in touch with Andreas, go to the website. You've seen it before. And thank you for now.  And maybe another applause for Andreas. Thank you.
36c3-10564-eng-deu-rus-Hacking_with_a_TPM_hd_0_107.png 36c3-10564-eng-deu-rus-Hacking_with_a_TPM_hd_108_1283.png 36c3-10564-eng-deu-rus-Hacking_with_a_TPM_hd_1284_3479.png 36c3-10564-eng-deu-rus-Hacking_with_a_TPM_hd_3480_4151.png 36c3-10564-eng-deu-rus-Hacking_with_a_TPM_hd_4152_4499.png 36c3-10564-eng-deu-rus-Hacking_with_a_TPM_hd_4500_4907.png 36c3-10564-eng-deu-rus-Hacking_with_a_TPM_hd_4908_10067.png 36c3-10564-eng-deu-rus-Hacking_with_a_TPM_hd_10068_10583.png 36c3-10564-eng-deu-rus-Hacking_with_a_TPM_hd_10584_10859.png 36c3-10564-eng-deu-rus-Hacking_with_a_TPM_hd_10860_10931.png 36c3-10564-eng-deu-rus-Hacking_with_a_TPM_hd_10932_12335.png 36c3-10564-eng-deu-rus-Hacking_with_a_TPM_hd_12336_12863.png 36c3-10564-eng-deu-rus-Hacking_with_a_TPM_hd_12864_13307.png 36c3-10564-eng-deu-rus-Hacking_with_a_TPM_hd_13308_14159.png 36c3-10564-eng-deu-rus-Hacking_with_a_TPM_hd_14160_15551.png 36c3-10564-eng-deu-rus-Hacking_with_a_TPM_hd_15552_15791.png 36c3-10564-eng-deu-rus-Hacking_with_a_TPM_hd_15792_15947.png 36c3-10564-eng-deu-rus-Hacking_with_a_TPM_hd_15948_16511.png 36c3-10564-eng-deu-rus-Hacking_with_a_TPM_hd_16512_16919.png 36c3-10564-eng-deu-rus-Hacking_with_a_TPM_hd_16920_18203.png 36c3-10564-eng-deu-rus-Hacking_with_a_TPM_hd_18204_19439.png 36c3-10564-eng-deu-rus-Hacking_with_a_TPM_hd_19440_22679.png 36c3-10564-eng-deu-rus-Hacking_with_a_TPM_hd_22680_22895.png 36c3-10564-eng-deu-rus-Hacking_with_a_TPM_hd_22896_23291.png 36c3-10564-eng-deu-rus-Hacking_with_a_TPM_hd_23292_23351.png 36c3-10564-eng-deu-rus-Hacking_with_a_TPM_hd_23352_24731.png 36c3-10564-eng-deu-rus-Hacking_with_a_TPM_hd_24732_27599.png 36c3-10564-eng-deu-rus-Hacking_with_a_TPM_hd_27600_27755.png 36c3-10564-eng-deu-rus-Hacking_with_a_TPM_hd_27756_27947.png 36c3-10564-eng-deu-rus-Hacking_with_a_TPM_hd_27948_28127.png 36c3-10564-eng-deu-rus-Hacking_with_a_TPM_hd_28128_28403.png 36c3-10564-eng-deu-rus-Hacking_with_a_TPM_hd_28404_29075.png 36c3-10564-eng-deu-rus-Hacking_with_a_TPM_hd_29076_29627.png 36c3-10564-eng-deu-rus-Hacking_with_a_TPM_hd_29628_29699.png 36c3-10564-eng-deu-rus-Hacking_with_a_TPM_hd_29700_29891.png 36c3-10564-eng-deu-rus-Hacking_with_a_TPM_hd_29892_30671.png 36c3-10564-eng-deu-rus-Hacking_with_a_TPM_hd_30672_32075.png 36c3-10564-eng-deu-rus-Hacking_with_a_TPM_hd_32076_35099.png 36c3-10564-eng-deu-rus-Hacking_with_a_TPM_hd_35100_35555.png 36c3-10564-eng-deu-rus-Hacking_with_a_TPM_hd_35556_36539.png 36c3-10564-eng-deu-rus-Hacking_with_a_TPM_hd_36540_37763.png 36c3-10564-eng-deu-rus-Hacking_with_a_TPM_hd_37764_38159.png 36c3-10564-eng-deu-rus-Hacking_with_a_TPM_hd_38160_39251.png 36c3-10564-eng-deu-rus-Hacking_with_a_TPM_hd_39252_40715.png 36c3-10564-eng-deu-rus-Hacking_with_a_TPM_hd_40716_41915.png 36c3-10564-eng-deu-rus-Hacking_with_a_TPM_hd_41916_44003.png 36c3-10564-eng-deu-rus-Hacking_with_a_TPM_hd_44004_44567.png 36c3-10564-eng-deu-rus-Hacking_with_a_TPM_hd_44568_44867.png 36c3-10564-eng-deu-rus-Hacking_with_a_TPM_hd_44868_46451.png 36c3-10564-eng-deu-rus-Hacking_with_a_TPM_hd_46452_47615.png 36c3-10564-eng-deu-rus-Hacking_with_a_TPM_hd_47616_49259.png 36c3-10564-eng-deu-rus-Hacking_with_a_TPM_hd_49260_51179.png 36c3-10564-eng-deu-rus-Hacking_with_a_TPM_hd_51180_51731.png 36c3-10564-eng-deu-rus-Hacking_with_a_TPM_hd_51732_51791.png 36c3-10564-eng-deu-rus-Hacking_with_a_TPM_hd_51792_55787.png 36c3-10564-eng-deu-rus-Hacking_with_a_TPM_hd_55788_56099.png 36c3-10564-eng-deu-rus-Hacking_with_a_TPM_hd_56100_56674.png