The TPM2 software community
CC Attribution 2.0 Belgium:
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.
Tricca, Philip
Fuchs, Andreas
Security is and has been a hot topic in recent history. Software and hardware systems are increasingly complex, vulnerabilities increasingly publicised and attack methodologies increasingly sophisticated. This trend began long ago as did efforts to design and implement foundational technologies to curtail it. The trusted platform module (TPM) is one such technology. It was specifically designed to thwart attacks that aim to steal or misuse sensitive cryptographic keys. Despite its obvious benefits, TPM adoption on OSS platforms was historically minimal. The next iteration of TPM implementations (TPM2) is quickly reaching critical mass in consumer computing platforms. Aiming to capitalize on the availability of TPM2 hardware, the tpm2-software organization on Github (-software) has coalesced as a community around the implementation of the TCG standard APIs, and their integration into common software tool and infrastructure. This talk will start with an overview of the tpm2-software community, it's history, it's current direction and how new users can get involved. The talk will then shift to discuss the technical details of the TPM2 software stack (TSS2) infrastructure and programming APIs and our current efforts to improve the security properties of OSS through their adoption. Finally, we'll conclude by presenting a use case driving the implementation of a new TPM2 Command Transmission Interface (TCTI) module enabling use of the TPM2 from with the SGX trusted execution environment. Security is and has been a hot topic in recent history. Software and hardware systems are increasingly complex, vulnerabilities increasingly publicised and attack methodologies increasingly sophisticated. This trend began long ago as did efforts to design and implement foundational technologies to curtail it. The trusted platform module (TPM) is one such technology. It was specifically designed to thwart attacks that aim to steal or misuse sensitive cryptographic keys. Despite its obvious benefits, TPM adoption on OSS platforms was historically minimal.
 Okay, we're gonna start the next session. If everyone can take a seat, please stay out of the aisles. And if we can just ask at the end, if everyone could just stay in their seats until we finish the Q&A period, I know it can be tough to get wherever you're going, but it's really super disruptive if no one can hear the questions. And these guys can answer. Okay, so Phillip and Andreas will talk about TPM. Hello. Excellent. So thanks everyone for showing up. I know we're getting kind of late and we're standing between you and the pub, so we appreciate your attention. We're here today talking myself, my co-conspirator Andreas, about some of the work that we've been doing to both standardize the APIs for interfacing with the trust of platform module, and also to drive adoption in the open source community through an open source implementation of that software stack. So just out of curiosity, just to show a hand from the audience if you're willing, does everyone here know what the trust of platform module or the TPM is? Lovely. Good, because we're not going to be doing a whole lot of background information in this talk. We're mostly going to be focusing on our outreach from the open source community that's formed around our implementation, and the things we're doing to drive adoption in downstream projects that can benefit from using this cryptographic coprocessor. So the agenda for today is actually pretty simple. The first bullet is something we're going to go through really quick. A little bit of background on the actual software stack and the APIs, but very little. So if you're interested in this stuff, we've been speaking at conferences of the last year, and we had a couple of talks at the Linux Security Summit in North America, as well as some of our friends from Infineon were presenting at the European Linux Security Summit. So we highly recommend if you want to see all the background information about the trials and tribulations that we went through in standardizing and implementing the APIs and the software stack, go check out those talks, please. The rest of it is actually going to be very straightforward. We'll give you a little bit of an overview of where we're focusing our efforts for the adoption, how these projects can benefit from the work, and the state of the actual implementation and our efforts to push these things upstream. And the flow of the talk is going to be very much like the way that your computer boots. We'll start with the earliest parts of the software that will be using this stuff, and we'll get all the way up to a full user space and even some of the prototyping and debugging tools that we're building for folks that are looking to use this and adopt it. So one of the cornerstones of the design for the TPM software stack, the second iteration for the new TPM 2 devices, is that it is driven by use cases. Everyone who's involved with the standardization and the implementation has a very specific idea for what they want to use this thing for, and it's not always the same. Oftentimes, you'll have people that are more focused on cloud use cases, or myself, I work for Intel. We're very interested in firmware, and so we go all the way from this very low-level implementation all the way into much higher-level APIs. And so we always have these use cases that are driving the definition and the implementation. And so to make all these things work together and to make it so that it answers everybody's needs, we have this kind of layered approach. One of the particularly useful things that we've done in the second iteration of the software stack is fix a lot of the problems that made using the first iteration very difficult. That second bullet there, the separation of the transport layer from the APIs, was very important. I don't know if anyone here has ever programmed with the TPM 1.2 software stack trousers. It was a very, very tight coupling between the user space daemon that was resource management and the actual applications that were using it. So if you've ever tried to do something in early boot, like in your init ram fs, it was extremely difficult to decouple those things, or you had to launch the daemon yourself and then deal with the penalty of that. And since it's on the boot path, that's kind of ugly. So by separating the transport layer, we can use these higher-level APIs, or rather we can take the programming APIs, and we can make them usable in all sorts of different environments from firmware all the way up. So that's a particularly good feature of the design, and it's something that you'll see spoken about a lot in this talk. So we support both synchronous and asynchronous. Obviously, if you want to have a UI that's sitting in front of your application, you want it to be lively, and you don't want to have to implement your own threading model therein. We expose details if they're needed, so for really embedded use cases, you can get access to very low-level layers of the software stack. But not everyone wants to deal with that complexity, and so we try to pick same defaults, and we try to actually defer to the downstream distros so that they can choose the right defaults for their platform in the appropriate cases. So the upper layers, as we get up this, we're starting to provide more features. A constrained environment like firmware, you probably don't want to have a whole bunch of crypto libraries built into this thing. You really just want the bare minimum, because your goal is really to keep your software small. Flash chip on your motherboard is expensive. Bigger ones are even more expensive. But in the upper layers, we want all these nice things, and so we can add the layers, rather the additional crypto libraries, to enable nice features so that users don't have to implement everything themselves. The TPM2 has this nice transport protection that will provide HMAC and encryption for certain parameters and commands, and so you don't want to have to implement this all yourself, and so we have a higher-level API where all that's wrapped up, and we do it with openSSL or G-Crypt. So this is generally how it looks, kind of in a box diagram here. The lowest level is going to be your device driver, and above that is going to be some kind of access broker and resource manager. The TPM itself is very, very small, has very constrained memory. You can only load a few keys into it at a time, and so they kind of punt to either user space or the kernel to do the resource manager. On top of that, we have that kind of layer with what we call the TPM command transmission interface. This is that layer for transport abstraction. And on top of that, we have two APIs that we have implemented, the system API, which is a one-to-one correspondence with actual TPM commands, does no crypto operations, does no allocations, very strict C99, and very easy to build into embedded applications, and we'll talk about that in, I think, the next slide. The enhanced system API was actually added last year. Thank you to Andreas for that. And this is where we get all those nice features for user space applications. Does the crypto for you, does a lot of the hard, repetitive things that you don't want to have to do in every user space application. The feature API is something we're actually working on right now. We don't have an implementation because the spec isn't yet done, but we're grinding that down, and we're hoping to have that done in, you know, short order. No guarantees on timing. Okay, so the, like I was saying, everything is going to be framed in the way that your computer typically boots up. I'll start by talking about some of the firmware and boot loader use cases. We'll start about, Andreas will take up some of the early boot and it run my Fest stuff, and then we'll kind of switch back and forth as we talk about the user space and kind of more feature-rich experience there. Right, so boot and firmware, UEFI. I work for Intel. Well, UEFI is the firmware architecture that drives Intel platforms, and so being able to use the TPM from UEFI is particularly important to us. The support for the TPM that's in UEFI natively, and this is what's called the TCG protocol, I think it is, it only supports the features that the firmware itself needs. So basically this boils down to configuring platform configuration registers and the algorithms used therein, and a hash and extend function for extending PCR measurements. Then they have one extra command that is just send command, and that sends a buffer that is, you know, a TPM command straight to the TPM. Not a particularly friendly interface if you're trying to write some kind of EFI executables that are doing platform provisioning or something like that. So where you actually need to execute some commands where you may be creating keys, you're going to crypto operations. So, and also bootloaders, things like Grubb. If you want to have an encrypted boot partition and you want to use the TPM for protecting your crypto keys, you don't want to interface directly with the TCG protocol. You want to talk through the TSS, and so we have this, the TCTI layer where we have this thin layer of software. It's maybe a hundred lines of code that just sits on top of that send command interface through the native UEFI driver, and we do all the buffer serialization and send commands through that way. We've got the software linked to the project right there up on GitHub, and this has actually been a bit of a pet project of mine. I've been going through and implementing all of the CI layers for building and testing this stuff, and testing UEFI executables in Travis CI, not exactly the easiest thing to do. So we've done a lot of work to actually, and a lot of respect to the folks from QMU, OVMF, Steph and Bergeron's work on the software TPM layer that we're using in the actual, the test harness, and jump to the next one. So when we're actually running one of these things, this is what you'll see coming out in your QMU window when you're actually running one of these. Now, unfortunately, it truncates the top of it because there's no pager in UEFI. The firmware has a shell. It doesn't have a very robust paging interface. So you can take a look here on the screen. You'll see one of the specific properties that I've called out. This is a command from the get capability command where the TPM just tells you a little bit about what it is. And that one right there specifically is telling you that the NV buffer or the non-volatile storage buffer, the largest thing you can send to it is 1K at a time. So the largest read or write that you can do to non-volatile memory in one read is 1K. A note there, the QMUFI versions, I'm using QMUFI to build this. I haven't integrated it directly into the TANOCOR build, but there's some really, you know, the UEFI is all statically linked and making sure that you get all of the symbols is very important when you're doing that. And so I've run into some problems with QMUFI and missing a few kind of small functions that are usually compiler built-ins. But in 308, if you're trying to reproduce this, that's where you're going to get your best success. So in the previous version, you can roll the next slide. You'll see what a crash looks like. This is what you get to see when you try to execute a function and you don't actually have that symbol built into your executable. It just tells you invalid opcode and you get a big dump. And debugging this is kind of a pain. So what we're doing is we're just building up more infrastructure, just like we do for the rest of the project, Travis CI, automated tests. We can actually run QMUFI, the software simulator. We can launch EFI executables and get output, just like when you run a make check. It's actually pretty convenient. Yeah, and so once we are leaving UEFI and BIOS in early boot, the first thing we're heading into is init.rd. And usually the first thing that you do, I don't know if you're security interested, is you type in your passwords. That's the first user interaction, either to decrypt your disk or to log in or to do remote connection or whatnot. And one of the issues that you have there is you don't know whether you're actually talking, I don't know, to your own machine. Somebody might have exchanged your machine. Or maybe the more likely case is the infamous evil maid attack, which is where somebody comes into your hotel room, the evil maid, and would switch out, I don't know, the init.rd or even BIOS and replace it with something that logs your crypto keys, your passwords to unlock the crypto keys. And on the next iteration of boot, they'll steal your laptop and then they are able to recover the passwords and decrypt your disk and whatnot. So that's nothing new, nothing too new. And apparently, Matthew Gert found that, or found an idea, found a solution for that, which he talked about, I think, three years ago at the KS Communication Congress, and he introduced it as the TPM-TOTP, which stands for the time-based one-time passwords, where basically you would have your computer using the TPM authenticate to you using your cell phone that it is still in a valid state. And what this basically would look like, we will see right now. So this is the interactive part of the session. And if you're quick enough, hold on, yeah. Okay, so this is the command I'm running, and of course this was supposed to happen because it's a live demo. If you're quick enough to scan off this barcode, what it would do is it will register a OTP token with your Google Authenticator, or in my case, the free OTP application, whatever, and once you do that, your PC, your laptop, and your phone are coupled. And during the next boot, something like a calculator operation would be called during early boot, and it would spit out something like that. And I can compare this number that was spit out there to the number that is on my phone. And I don't know if you want to, like, run it as well. This is the interactive part. It actually fits. So what this does is your laptop is able to prove to you that the early boot, in-it-rd, kernel, and BIOS were unaltered while you were away having a few drinks at night. And to see that it actually does work, we can, for example, extend the PCR, which is the platform configuration registers of the TPM, and again, attempt to calculate the TOTP, and we will see we have an authorization failure of the TPM. So the TPM will really not do that. Yeah. So as I said, well, I did a re-implementation because the software stack, the TPM itself, changed drastically between Matthew's implementation and mine, and so I did a few reworks, pushed the key actually into the TPM for the crypto operation, which, well, 1.2 didn't support, so he couldn't support it in his software. And also split up the whole project into a library for reuse and a command-line tool. And you should go check it out, test it, maybe send a pull request for a Plymouth interface to that and whatnot. The next thing we're doing when we're still in early boot is usually we want to decrypt our boot partition, our root partition, not the boot partition. That's where we get the in-it-rd from, but the actual root partition. And, well, why would you want to do the use of the TPM for that? Well, first of all, it's the primary use case for TPMs for a long time, at least in general, I think, which is the BitLocker system by Microsoft for Windows, which does full disk encryption using the hardware security module. And why would you actually want to use that? Well, the first thing is it provides you with hardware-based dictionary attack protection. So if you really want to be certain that your disk, if it's Miro today, cannot be decrypted with somebody running root-force attacks for five years, you don't have any means for that except for very, very long passwords, which I personally cannot stand. And so wouldn't it be nice to just have like a pin for your login, like a three, four, five, six-digit pin, whatever your security level is? That's actually possible if you use a hardware security module that would protect stuff for you. The other thing is that if this is a more philosophical thing, if you have your key encryption keys be derived from your password and you change your password, all you're doing is, philosophically speaking, just adding a password. Because if somebody copied your Lux header beforehand and then you change your password and he copies the same one again, well, they have two targets for the root-force attacks. Whereas, so there's no actual invalidation of the old password, it's only always adding a new password, given an attacker model where we assume that the attacker can always copy the Lux headers. If you have a hardware security module, you can actually change the password because the old password will be invalid. And this is what the Lux headers look like. So here we see the original Lux header where we have the regular key type Lux2. And here's the new implementation where we have the type TPM2. We say it's in this NV index and the TPM. There is no DA protection or there is DA protection and it can even be bound to PCRs, similarly to the TPM TOTP thing. It's still in the PR because we're still figuring out where to put the feature. Is it in the client application? Is it in the library? So that still needs to be discussed. But we have a demo. Isn't that great? So as you see here, the only thing I'm changing is I'm setting the type to Lux2. Let me increase that in size. And I'm adding the minus the dash dash TPM parameter. And this is all you have to do in order to enable that feature. It works seamless. And yeah, now we formatted it. If we want to open it, I'm opening now with test pass because it's test pass phrase because I don't have root access to the device wrapper. It seamlessly, without adding any parameters, open the file system again. So we integrate with systemd, with Dracood, with initrd, with loan disks, you name it. And that's what it's supposed to be like. Similar to using Crip setup alone. And one of the things that we're particularly happy about with the software community we've been trying to build up is that we've gotten some really good participation from other parties. The project started a while ago and we've been kind of picking up new people as we go along. And Red Hat has been a really good partner to us in this. We've been working with this guy, Javier, who actually did a talk not too long ago. I think it was just last weekend at a Red Hat conference. We got a link there, DevConf. If you're interested in Clevis, Clevis is a Red Hat tool that does automated decryption of various things. It's not specific to disks, but it can be used and applied to that. And Javier did a bunch of work to use some of our command line tools as a plugin to Clevis for using the TPM to unlock disks. Clevis is something I'm not particularly familiar with and I'm not going to try to pretend to know too much about it. I know generally what it is and what it does. And I had to go to the Wikipedia page there to figure out what a Clevis is in the first place. They have this model for plugins that they call PINs, which I find particularly difficult to get my head around because we deal with a lot of PINs when people are typing in kind of passphrases. So it's not a PIN like you would think for like a smart card, but it's a PIN as in the PIN that goes through a Clevis fastener, which I found a bit difficult to wrestle with. But one of the interesting things from Javier's talk that was a big takeaway for me as someone who was trying to build this project up was that, you know, the quote down at the bottom, that Red Hat development efforts are based on these TCG specifications and our implementation of it. So we're very grateful to Red Hat and the other folks in the community that showed up and done interesting work like this. Okay, so now we're leaving early boot in at RD and we're actually in the main system. And one of the things that you might be running there is, well, something that uses OpenSL like a web server and MQTT server and I don't know what you name it, or a client for that matter. And of course, one of the easiest big impact points is to provide an engine for OpenSL. So the idea, how that works is that OpenSL provides this plug-in API where you can define your own engine that can be developed independently from the upstream project. And that enables, for example, the use of hardware security modules or crypto accelerators or PKCS 11 and I don't know, there's like a bunch of engines out there. And so the most obvious thing was to come up and implement an OpenSL engine to use the TPM with via the TCG-specified software stack, that is. And so you can find it right there on the GitHub page in the TPM2 software community. And depending on the actual application you're trying to enable TPM usage with, it can be as easy as setting this environment variable to a config file where you define the engine. And then all of a sudden it starts using TPM keys in the background and you don't have to do anything else. And just to show you how easy it is to actually set up that stuff, again we have a little demo. So all we're doing here is we're creating a ECDSA key. We store it in the file My Key. Next thing we do is we generate an X509 certificate and compared to the regular call that you would do, the only parameters we're adding is actually engine, TPM2 TSS, and key form engine which defines that the input key is supposed to be parsed by the TPM2 TSS engine. Well, we can set country codes if you like or I'll go just for the default in this case. And next thing we do is we just start the internal web server of OpenSSL for testing purposes. And again the only thing we're setting is key form engine and engine TPM2 TSS. And we go ahead and, well, use Firefox. Of course we get a warning because we have a self-signed certificate here, so, yeah, I have to accept that. And there we go. Does the result of OpenSSL giving you, well, its standard debug page with all the cryptography that are supported. And up here we see that we had a connection acceptance from Firefox. So there's kind of a common theme for all these things. The TPM is only useful for various cryptographic operations, either encryption, or signing. And so authentication is one of those. And we do a lot of authentication when we're connecting over VPNs. So a big part of the adoption that we've seen that's very encouraging is that some of the existing upstream or downstream projects, both StrongSwan and OpenConnect, have started picking this up and using it either directly through the TSS APIs like StrongSwan does, or like OpenConnect using the OpenSSL engine that Andreas was just talking about. So StrongSwan has actually been using the TPM for a long time. They implemented a lot of the protocols from the trusted network connect specifications from the 1.2 implementation. I think they're probably one of the only ones that I've seen doing that. Where OpenConnect is a little less esoteric in that it's a drop in replacement for the Cisco client VPN. So it's not a full VPN suite like StrongSwan is with both client and server. It's strictly client and it's used to connect to the Cisco SSL VPNs. Again, authentication is really, you know, in these contexts, just the signing operation. And so there have been APIs for doing these types of things and interfacing with hardware crypto accelerators for a long time. And Pkcs11 has been around longer than I've been in the business. And it's really a gateway for us to just support in existing implementations, existing software projects. And we can just by providing a Pkcs11 compatible interface, we can get basically free support for all these things with no code changes in those projects explicitly. And so this is actually a very new implementation from Bill Roberts at Intel. There's a lot of work that went into this project because you're basically building a big kind of mapping between the TPM interface and the Pkcs11 interface. And Pkcs11 comes from the smart card world. So you're basically building an object model, a mapping for an object model between these two things. And it's a pile of work. So a lot of respect to Bill for the time he's put into this. We've actually had some folks at Intel not specifically affiliated with us about working through a partner where we showed a demo at the AWS re-invent conference this past year using the TPM as a hardware protection mechanism for your crypto keys in the AWS green grass architecture. Not something I'm particularly familiar with, but that's nice. That means that we're doing work on kind of the foundation. Other people are picking it up and starting to do useful things completely without our knowledge in some cases. So the easiest way to use Pkcs11 and your TPM for a really big impact on your individual platform, I'm sure people in the room, you log into over SSH to tons of servers. I'm assuming you probably got keys that you're keeping around on your disk. And if you use the Pkcs11 module and open SSL, you can keep those keys in your TPM, which instantly prevents you from having someone steal them off your computer and impersonate you on a different computer. And in some environments, if you're an admin and you're logging in and your account has a lot of permissions and it is very powerful on that system, you really don't want someone being able to get on your system, take your keys and then log in from another machine. So the TPM can be used almost seamlessly to do that. And we have instructions for going through the setup there. And the instructions pretty much break down to this. You can fit all of the commands you would need to do onto a single slide. The default location for the metadata, it's a little bit of a database that maintains this mapping between the two object models. You run a tool that we have that Bill wrote in Python that initializes the entire system. You then create a token. Token, again, is a Pkcs11 ism that comes from smart cards. Your token is a physical thing. And in this case, you know, it's a key slot for the TPM in a way. You then add a key to that token. So it's basically like sticking a smart card in a card reader. And then when you want to actually go and use this thing, you just use SSH key gen to pump out the public part so you can put it onto the server you're logging into. You then insert it into the authorized key file there. And it's one parameter that you pass extra into open SSL to just have it use the Pkcs11 module for the TPM. The login should go just like you would expect from any other SSH login. The TPM tools is actually one of the oldest parts of the project. And it started out as a one-to-one mapping to the old tools from the 1.2 TPM software stack from IBM. This was something we ended up doing away with and rewriting entirely. And so there was tons of refactoring in this code base from 2007 to 2008. And it's gotten very, very stable. It started out using just the system API, which is very low level. And we're now, believe the patches gone in. Joshua has patches that I think got merged that use the ESIS API. They're not merged yet? They are. So now the tools are all using ESIS, which means that we don't have to do any extra work to benefit from using the transport protections from HMAC and encrypted sessions. So you can use the TPM tools and if properly configured, you can get protections for the channel between you and the TPM. This is something that is being used again, like I was saying, in the Clevis project. Red Hat is using these just in a shell script through Clevis to provide an extra pin to get TPM protections in that architecture. And this is actually, you know, looking back at past FOSDEMs, the last two years, 2018 and 2017, both had talks with people talking about the TPM software stack. Back in 2007, we have a friend from Facebook, Davi Aguirre, who gave a talk that showed using these tools and doing just the basic signing operation from the TPM and then using OpenSSL to verify the signature on the command line, just like you would expect to do. And if you actually go back and look at his talk, it's kind of ugly some of the things he had to do to get the tools to spit out a public cert that OpenSSL would recognize. We've gone through and, you know, learned from basically his critique of the tools and we've gone and cleaned this up drastically. So this is just the set of commands to do exactly that. Unfortunately, there are some things in the TPM that we just can't abstract away, so we have to load a primary key and then create a child key. So this is a TPM toism that people need to get comfortable with. But after that, all we do is load the key, generate a digest, sign the digest, get it to spit out the public part, and then just use an OpenSSL digest command like you would expect using any other public key. Yeah. And since you want to be free in what you do with the TPM when you actually start developing, because while shell scripts are nice for prototyping some in-business to stuff and whatnot, but not very suited for actual productive code or actual applications. Well, we have C as the primary API of the libraries themselves, but there's also language support for other things. So there's Google came up with this TPM.js thing. If you go to this, their GitHub I.O., you can actually like use their JavaScript API in the browser in order to do some stuff with an emulated TPM on their end. Or another thing that we've been working on upstream is coming up with bindings for Python in this case. So basically we're not just going for a CFFI wrapper or CFFI bindings directly. We wanted to like get more of the object-oriented parts of Python, of course, into the API. So there's a little object-oriented wrapper around that. And since we're running so great on time, I actually have time to demonstrate that as well. Yeah, again, we are, of course, way too small. But, yeah, if we just enter Python 3 and we do an OK. Of course, we have to enter Python 3 for that. We import star from PyTPM to TSS. Everybody should have seen that at some point. We open an ESUS context and we can already talk to the TPM. There was a TPM command being executed right there having the TPM generate five random bytes. And then we added some convenience functions in order to unpack them. So this would be the actual Python array representation of this TPM to be, which is a TPM-specific data structure of the stuff we did previously. That's how easy it can be. The next one, I didn't want to type down. So this would be an actual serious use of TPM. So all the upper part that's pretty small up there. That's just, I mean, this is just initializing empty structures that apparently need to be provided to the TPM. Then here we have a few settings like what we want to go for an ECC key. We want to have that key be authorized with UtherOth. We want to have that be a sign or encryption key, stuff like that. It should be an ECDSA signing key with SHA256 and the NIST P256 curve. Very straightforward. This way we create the primary key on the TPM. What we get back is X, the handle for the actual key or the other parameters we can actually ignore in this case. And we perform a sign operation. And that's it. You already signed something with your TPM. Something that, when you're introducing a topic like the TPM and trying to bring people up to speed on, how to use it, you know, when helping people fix things when it breaks, having debugging tools is particularly important. The TPM is kind of opaque to a lot of people and, you know, you send a command and you get a response back. And oftentimes it's an error. It's a little bit of a esoteric error because they're all packed into 32-bit integers. And, you know, it's not always easy as thing trying to figure out what's going wrong when things do go wrong. And things always go wrong. So we really just noticed this and in our work we ran into the same problems. None of us started out knowing how all this stuff works. We all had to fumble our way through getting started. And one of the things that we kind of realized would be really useful is if we had a tool that allowed us to visualize the command and response buffers, take a look at the command, make sure that it's sending the command that we think it's sending, and Wireshark was just the perfect example of doing something like this. So if you're setting up an environment trying to learn how this works in debugging, you'll run a software simulator in user space and it communicates with the software stack over an IP socket. So you can configure Wireshark to listen on the communication and you can get these buffers, but you need Wireshark to do a little extra work for you to help you parse through them. And so one of the members of our team, Taddy, has struck, spent a bunch of time in the 2.9 development window doing work in Wireshark to enable the parsing of not just headers, but some of the command bodies as well. You just snip the traffic like I was saying on loopback and you get the capture in the Wireshark UI. You can see the headers, you can see it take apart certain command bodies for ones that it understands. We don't have full coverage of the actual, of every TPM command yet, but the talk today is about trying to communicate to folks the benefits of using this technology and help people to get involved. And so if this is something you're interested in, if you like looking at ones and zeros all day in network and PCAP files, we would love to have some help actually expanding our support in Wireshark. You want to jump to the next one? Thanks. And so if you see here, this is just the familiar Wireshark window that I'm sure everyone here has probably seen. And since we're communicating over loopback, you get the IP headers broken down on the left there, but as you move over to the right, you'll see the protocol is identified as being associated with the TPM, and you'll see kind of request and response buffers being identified. And if you jump to the next one, you'll actually get to see a command body when we actually parse it apart. This is, you know, all the TPM commands are, you know, when they're sent to the TPM, they are network byte ordered, they're packed, so all of them, there's no padding or anything from any of the C structures that you'll be serializing. So it's really nice to have this tool to go through and pull apart the header like you'll see. A header on all the commands is the same, but you'll see the command code there is identified for the create loaded command. That just creates a key and loads it into the TPM in one operation. You can see that we're seeing the handle area and the authorization area. This is something that is just a TPM2 ism, and there's a number of flags and various fields that determine how the TPM will respond to this command. So being able to look at this and, you know, if you don't understand why your command produced a certain result and you think you set a certain number of flags to various values, this is a great way to go through and really identify and make sure that your mental model of what's going on is exactly the model of what's happening in the real world. And so finally, something that is kind of, that's just something I was interested in, and I saw this as a potential use case and decided to hack up a prototype. And there was even a talk here earlier, trusted execution environments, or TEEs, are something that is getting more and more traction across the industry. Pretty much every CPU or major CPUs on the market have some kind of TEE, whether it's trust zone on ARM, AMD has SEV for their chips, Intel has SGX, and, you know, there's a talk today about risk five and what risk five is doing for building an environment for their CPU, where the operations for things that are running in this TEE are protected from, you know, what we think of as general purpose exploits for things that would steal or exploit the kernel and, you know, use that as a way to inspect a process and potentially steal information out of it. So these things are really interesting and they have the potential to provide us with some really useful tools to build stronger systems, but they're actually quite difficult to work in sometimes. TEEs effectively are islands and, you know, if you're on the island and you have everything you need, everything's great. However, as soon as you need something that's not there with you, you have to go out and either bring it in or communicate across the boundary of the TEE to talk to the outside world. Interacting with these external entities like the TPM has a lot of value and could be really useful, but someone has to build the plumbing to cross this boundary, and someone has to, you know, take a look at the added complexity and the risk that comes along with that when you're crossing that boundary, because on one side in your TEE you are protected and on the other it's not. It's basically like sending a network packet over an untrusted network. So the prototype looks a lot like what I was talking about in the UVFI. It just adds kind of an additional layer because the TEE itself is, you know, in SGX terms we call it an enclave. It's this kind of box that I'm drawing here that shows the software stack being used, but when you want to communicate with the TPM you need this layer here, which is just another TCTI layer, to move the command and response boundary or command and response buffers across the enclave boundary. Once you get across the enclave boundary you're in the process that's hosting the SGX enclave, and something there needs to provide this glue code to move it that last step across the boundary out of the process down to the actual TPM itself. So we have just like a lot of things in SGX. You usually have one library that lives in the enclave, and another one that lives outside the enclave providing support to deal with commands that come from inside the enclave. So there's, in green there we have the actual TCTI that lives in the enclave. You can build your TSS to sit on top of that inside the enclave, and then outside the enclave there's this management layer that catches the commands, associates with them with the connection, and then sends them on down through the rest of the software stack so they actually reach the TPM. This is very much a prototype. It was really for me a way to demonstrate the utility of the TCTI layering mechanism and the separation of that transport, and it was also a good way for me to just figure out how to build an SGX enclave. What does it mean when I do certain operations and I have to move across this boundary? What are the implications? And so, you know, this work is still very new. It's still, the link there is to my personal GitHub account. We haven't merged into the real project or the real out, the community's GitHub space, because it's still, you know, it's new. Don't have a lot of use cases. Don't have a lot of documentation. And I'd really like to write a good kind of threat profile so that people, if they decide to pick this up and use it in their enclaves, they have a full understanding of the potential threats, mitigations that need to be put in place, and, you know, the risks that they're taking on by doing this. So if you're interested in developing on TEEs and you think that there's some utility in talking to the TPM, this is probably an architecture that just could be replicated for other TEEs depending on what their architecture looks like. Yeah. So we've been talking about a bunch of stuff here, which had several purposes. First of all, we tried to pick up everybody via some way or another to be interested in this stuff and to see how useful it could be for them. Of course, it also shows you that this is way beyond everything that a single company could do. This is actually a community project, even though it's still backed by like Infineon, Intel, Fraunho, Ferret, Weed, GE, and individuals even catching up and providing our arch user repository builds and stuff. We do have a very good bus factor at this point. One of the companies would pull out, would be no problem, so we can say that we're growing into a very stable and very useful software community here, spanning over a bunch of projects. Of course, this is a bunch of stuff already, but we also wanted to attract you and everybody else to join us, because this is the stuff that we came up with that would still need support for TPMs. If you're involved with any of those communities, if you have any ideas, if you would like to join in and provide patches to upstream, whatever, or if you even know other projects that would benefit from TPM support, which are not listed here, come talk to us. Talk to us here, hunt us down somewhere in the cafeteria or the security room or whatever. Or talk to us on the mailing list or get our, I think we didn't provide our email address, but you could find them on GitHub and send us a message. And if everybody who's leaving is very silent, we can maybe even answer questions now. So are there any questions? I would just ask you to stay seated during the question and answer session if you want to please be quiet and take all the litter with you. There is now the InKernel resource manager with recent kernels. Is there any reason to keep using the user space resource manager? That's a good question. First off, the user space resource manager predates the work that happened in the kernel. This was just a necessity. We've been providing this software for about three years. Back then it was very new, but we needed to have some kind of resource management. We politely asked and were told to provide patches, so it was easier to implement it in user space. And also, how to say this, it was the way that it was done previously, and so there was precedent for doing it that way. Now you're right. The work in the kernel is definitely going to be where the resource manager lives in the future, but it is not fully featured yet. So there are still some things that need to be done in the kernel before. Personally, I'm willing to recommend that people use it for, say, long running systems like a server that's going to stay up for a very long time. There are some weird things you have to do to keep the TPM happy. If you're interested, there's this notion of what's called a context gap. It's an anti-replay mechanism that exists in the TPM for when you're loading and unloading sessions, and that's currently not supported in the kernel yet. We've been talking to Yarko about that work, but it'll happen when it happens. And until then, personally, I'm recommending that folks use the one in user space because it does support that mechanism in the most recent release. It's also useful for when we're testing. So you run a simulator in user space. If your only resource manager code is in the kernel, really hard to test the real life scenario. So I agree. Ideally, in the end, there will be no user space resource manager used in deployed systems. It may live on as some kind of proxy daemon that can do, you know, enforce policy if you're on a system where you want to have blacklisted commands where you don't want any of those going from user space into the TPM. Maybe only something that the kernel would do. You could provide that in a layer that's outside the kernel. Putting policy or mechanisms in the kernel, a lot more tricky than just doing it in user space. So I agree, but I think, you know, we're not just there just yet. We're really close. Hi there. This is a bit more of a policy question. Basically, while you're building this community around this technology and its potential applications, I'm really intrigued in particular in the bitlocker-esque functionality of keeping your disk encryption keys in the TPM. Are you talking to relevant standards bodies and so on about getting this approved as a secure way of storing keys in the hope that Linux will be usable in more secure environments? I didn't get the middle of the question. Sorry, are you talking to relevant standard bodies, like people like the cybersecurity essentials in the UK, to try and get some of this TPM usage in Linux, allowing Linux to be used in more secure environments? So I mean, the TPM itself lives in a standards body. They define both what the TPM is, the interfaces to it, and, you know, the software stack is part of what we've been driving in that direction. As far as the individual uses, so knowing whether or not the implementation, you know, that's using Lux or Clevis or whatever else, whether or not that's acceptable to various standards, I think it's an eventual end goal. I don't necessarily know that that falls under the purview of the open-source community that we're building around the implementation. They're definitely the people that would probably be implementing it and possibly responsible for taking patches that would bring it in line with these standards bodies. It's definitely not something I'm opposed to, but it's definitely not a primary concern at the moment. We're more interested in just getting people to use it, use it effectively to protect their stuff as best they can. And, you know, if it does gain traction, I imagine that would happen just by virtue of, you know, its own utility. They think it's useful in those spaces. They want to make sure that it works properly, and eventually, you know, those people will take a look at it. I hope. Hello, I'm Bien Poisson. One of the biggest stumbling blocks I had when trying to integrate TPMs into my projects is that the documentation for libraries are non-accessible. We get help for it. That's a link to documentation. Are you trying to solve this problem? Andre, I see you like writing documentation. I didn't understand the question. Let me repeat this just to make sure I understood it properly. The documentation is pretty bad. It sounds like what you're saying. There's actually a pile of books. There have been three or four published books that are three, five hundred pages, and I agree, they're almost impenetrable. You read them and it's very deeply steeped in jargon from the standard spotty. I think that the thing that's preventing us from getting...
 Okay, we're gonna start the next session.  If everyone can take a seat, please stay out of the aisles.  And if we can just ask at the end, if everyone could just stay in their seats until we finish the Q&A period,  I know it can be tough to get wherever you're going, but it's really super disruptive if no one can hear the questions.  And these guys can answer.  Okay, so Phillip and Andreas will talk about TPM.  Hello. Excellent.  So thanks everyone for showing up. I know we're getting kind of late and we're standing between you and the pub, so we appreciate your attention.  We're here today talking myself, my co-conspirator Andreas, about some of the work that we've been doing to both standardize the APIs for interfacing with the trust of platform module,  and also to drive adoption in the open source community through an open source implementation of that software stack.  So just out of curiosity, just to show a hand from the audience if you're willing, does everyone here know what the trust of platform module or the TPM is?  Lovely. Good, because we're not going to be doing a whole lot of background information in this talk.  We're mostly going to be focusing on our outreach from the open source community that's formed around our implementation,  and the things we're doing to drive adoption in downstream projects that can benefit from using this cryptographic coprocessor.  So the agenda for today is actually pretty simple. The first bullet is something we're going to go through really quick.  A little bit of background on the actual software stack and the APIs, but very little.  So if you're interested in this stuff, we've been speaking at conferences of the last year,  and we had a couple of talks at the Linux Security Summit in North America, as well as some of our friends from Infineon were presenting at the European Linux Security Summit.  So we highly recommend if you want to see all the background information about the trials and tribulations that we went through in standardizing and implementing the APIs and the software stack,  go check out those talks, please. The rest of it is actually going to be very straightforward.  We'll give you a little bit of an overview of where we're focusing our efforts for the adoption, how these projects can benefit from the work,  and the state of the actual implementation and our efforts to push these things upstream.  And the flow of the talk is going to be very much like the way that your computer boots.  We'll start with the earliest parts of the software that will be using this stuff, and we'll get all the way up to a full user space  and even some of the prototyping and debugging tools that we're building for folks that are looking to use this and adopt it.  So one of the cornerstones of the design for the TPM software stack, the second iteration for the new TPM 2 devices,  is that it is driven by use cases. Everyone who's involved with the standardization and the implementation has a very specific idea for what they want to use this thing for,  and it's not always the same. Oftentimes, you'll have people that are more focused on cloud use cases, or myself, I work for Intel.  We're very interested in firmware, and so we go all the way from this very low-level implementation all the way into much higher-level APIs.  And so we always have these use cases that are driving the definition and the implementation.  And so to make all these things work together and to make it so that it answers everybody's needs, we have this kind of layered approach.  One of the particularly useful things that we've done in the second iteration of the software stack is fix a lot of the problems that made using the first iteration very difficult.  That second bullet there, the separation of the transport layer from the APIs, was very important. I don't know if anyone here has ever programmed with the TPM 1.2 software stack trousers.  It was a very, very tight coupling between the user space daemon that was resource management and the actual applications that were using it.  So if you've ever tried to do something in early boot, like in your init ram fs, it was extremely difficult to decouple those things,  or you had to launch the daemon yourself and then deal with the penalty of that. And since it's on the boot path, that's kind of ugly.  So by separating the transport layer, we can use these higher-level APIs, or rather we can take the programming APIs,  and we can make them usable in all sorts of different environments from firmware all the way up.  So that's a particularly good feature of the design, and it's something that you'll see spoken about a lot in this talk.  So we support both synchronous and asynchronous. Obviously, if you want to have a UI that's sitting in front of your application,  you want it to be lively, and you don't want to have to implement your own threading model therein.  We expose details if they're needed, so for really embedded use cases, you can get access to very low-level layers of the software stack.  But not everyone wants to deal with that complexity, and so we try to pick same defaults, and we try to actually defer to the downstream distros  so that they can choose the right defaults for their platform in the appropriate cases.  So the upper layers, as we get up this, we're starting to provide more features.  A constrained environment like firmware, you probably don't want to have a whole bunch of crypto libraries built into this thing.  You really just want the bare minimum, because your goal is really to keep your software small. Flash chip on your motherboard is expensive.  Bigger ones are even more expensive.  But in the upper layers, we want all these nice things, and so we can add the layers, rather the additional crypto libraries,  to enable nice features so that users don't have to implement everything themselves.  The TPM2 has this nice transport protection that will provide HMAC and encryption for certain parameters and commands,  and so you don't want to have to implement this all yourself, and so we have a higher-level API where all that's wrapped up,  and we do it with openSSL or G-Crypt.  So this is generally how it looks, kind of in a box diagram here.  The lowest level is going to be your device driver, and above that is going to be some kind of access broker and resource manager.  The TPM itself is very, very small, has very constrained memory. You can only load a few keys into it at a time,  and so they kind of punt to either user space or the kernel to do the resource manager.  On top of that, we have that kind of layer with what we call the TPM command transmission interface.  This is that layer for transport abstraction.  And on top of that, we have two APIs that we have implemented, the system API,  which is a one-to-one correspondence with actual TPM commands, does no crypto operations, does no allocations,  very strict C99, and very easy to build into embedded applications, and we'll talk about that in, I think, the next slide.  The enhanced system API was actually added last year. Thank you to Andreas for that.  And this is where we get all those nice features for user space applications.  Does the crypto for you, does a lot of the hard, repetitive things that you don't want to have to do in every user space application.  The feature API is something we're actually working on right now. We don't have an implementation because the spec isn't yet done,  but we're grinding that down, and we're hoping to have that done in, you know, short order. No guarantees on timing.  Okay, so the, like I was saying, everything is going to be framed in the way that your computer typically boots up.  I'll start by talking about some of the firmware and boot loader use cases.  We'll start about, Andreas will take up some of the early boot and it run my Fest stuff, and then we'll kind of switch back and forth  as we talk about the user space and kind of more feature-rich experience there.  Right, so boot and firmware, UEFI. I work for Intel.  Well, UEFI is the firmware architecture that drives Intel platforms, and so being able to use the TPM from UEFI is particularly important to us.  The support for the TPM that's in UEFI natively, and this is what's called the TCG protocol, I think it is,  it only supports the features that the firmware itself needs.  So basically this boils down to configuring platform configuration registers and the algorithms used therein, and a hash and extend function for extending PCR measurements.  Then they have one extra command that is just send command, and that sends a buffer that is, you know, a TPM command straight to the TPM.  Not a particularly friendly interface if you're trying to write some kind of EFI executables that are doing platform provisioning or something like that.  So where you actually need to execute some commands where you may be creating keys, you're going to crypto operations.  So, and also bootloaders, things like Grubb.  If you want to have an encrypted boot partition and you want to use the TPM for protecting your crypto keys,  you don't want to interface directly with the TCG protocol.  You want to talk through the TSS, and so we have this, the TCTI layer where we have this thin layer of software.  It's maybe a hundred lines of code that just sits on top of that send command interface through the native UEFI driver,  and we do all the buffer serialization and send commands through that way.  We've got the software linked to the project right there up on GitHub, and this has actually been a bit of a pet project of mine.  I've been going through and implementing all of the CI layers for building and testing this stuff,  and testing UEFI executables in Travis CI, not exactly the easiest thing to do.  So we've done a lot of work to actually, and a lot of respect to the folks from QMU, OVMF,  Steph and Bergeron's work on the software TPM layer that we're using in the actual, the test harness,  and jump to the next one.  So when we're actually running one of these things, this is what you'll see coming out in your QMU window when you're actually running one of these.  Now, unfortunately, it truncates the top of it because there's no pager in UEFI.  The firmware has a shell. It doesn't have a very robust paging interface.  So you can take a look here on the screen.  You'll see one of the specific properties that I've called out.  This is a command from the get capability command where the TPM just tells you a little bit about what it is.  And that one right there specifically is telling you that the NV buffer or the non-volatile storage buffer,  the largest thing you can send to it is 1K at a time.  So the largest read or write that you can do to non-volatile memory in one read is 1K.  A note there, the QMUFI versions, I'm using QMUFI to build this.  I haven't integrated it directly into the TANOCOR build, but there's some really, you know, the UEFI is all statically linked  and making sure that you get all of the symbols is very important when you're doing that.  And so I've run into some problems with QMUFI and missing a few kind of small functions that are usually compiler built-ins.  But in 308, if you're trying to reproduce this, that's where you're going to get your best success.  So in the previous version, you can roll the next slide.  You'll see what a crash looks like.  This is what you get to see when you try to execute a function  and you don't actually have that symbol built into your executable.  It just tells you invalid opcode and you get a big dump.  And debugging this is kind of a pain.  So what we're doing is we're just building up more infrastructure,  just like we do for the rest of the project, Travis CI, automated tests.  We can actually run QMUFI, the software simulator.  We can launch EFI executables and get output, just like when you run a make check.  It's actually pretty convenient.  Yeah, and so once we are leaving UEFI and BIOS in early boot,  the first thing we're heading into is init.rd.  And usually the first thing that you do, I don't know if you're security interested,  is you type in your passwords.  That's the first user interaction, either to decrypt your disk or to log in  or to do remote connection or whatnot.  And one of the issues that you have there is you don't know whether you're actually talking,  I don't know, to your own machine.  Somebody might have exchanged your machine.  Or maybe the more likely case is the infamous evil maid attack,  which is where somebody comes into your hotel room, the evil maid,  and would switch out, I don't know, the init.rd or even BIOS  and replace it with something that logs your crypto keys,  your passwords to unlock the crypto keys.  And on the next iteration of boot,  they'll steal your laptop and then they are able to recover the passwords  and decrypt your disk and whatnot.  So that's nothing new, nothing too new.  And apparently, Matthew Gert found that, or found an idea,  found a solution for that, which he talked about, I think,  three years ago at the KS Communication Congress,  and he introduced it as the TPM-TOTP, which stands for the time-based one-time passwords,  where basically you would have your computer using the TPM authenticate to you  using your cell phone that it is still in a valid state.  And what this basically would look like, we will see right now.  So this is the interactive part of the session.  And if you're quick enough, hold on, yeah.  Okay, so this is the command I'm running,  and of course this was supposed to happen because it's a live demo.  If you're quick enough to scan off this barcode,  what it would do is it will register a OTP token  with your Google Authenticator, or in my case, the free OTP application, whatever,  and once you do that, your PC, your laptop, and your phone are coupled.  And during the next boot, something like a calculator operation would be called  during early boot, and it would spit out something like that.  And I can compare this number that was spit out there to the number that is on my phone.  And I don't know if you want to, like, run it as well.  This is the interactive part. It actually fits.  So what this does is your laptop is able to prove to you that the early boot,  in-it-rd, kernel, and BIOS were unaltered while you were away having a few drinks at night.  And to see that it actually does work, we can, for example, extend the PCR,  which is the platform configuration registers of the TPM,  and again, attempt to calculate the TOTP, and we will see we have an authorization failure of the TPM.  So the TPM will really not do that.  Yeah.  So as I said, well, I did a re-implementation because the software stack, the TPM itself,  changed drastically between Matthew's implementation and mine,  and so I did a few reworks, pushed the key actually into the TPM for the crypto operation,  which, well, 1.2 didn't support, so he couldn't support it in his software.  And also split up the whole project into a library for reuse and a command-line tool.  And you should go check it out, test it, maybe send a pull request for a Plymouth interface to that and whatnot.  The next thing we're doing when we're still in early boot is usually we want to decrypt our boot partition,  our root partition, not the boot partition.  That's where we get the in-it-rd from, but the actual root partition.  And, well, why would you want to do the use of the TPM for that?  Well, first of all, it's the primary use case for TPMs for a long time, at least in general, I think,  which is the BitLocker system by Microsoft for Windows, which does full disk encryption using the hardware security module.  And why would you actually want to use that?  Well, the first thing is it provides you with hardware-based dictionary attack protection.  So if you really want to be certain that your disk, if it's Miro today, cannot be decrypted with somebody running root-force attacks for five years,  you don't have any means for that except for very, very long passwords, which I personally cannot stand.  And so wouldn't it be nice to just have like a pin for your login, like a three, four, five, six-digit pin, whatever your security level is?  That's actually possible if you use a hardware security module that would protect stuff for you.  The other thing is that if this is a more philosophical thing, if you have your key encryption keys be derived from your password  and you change your password, all you're doing is, philosophically speaking, just adding a password.  Because if somebody copied your Lux header beforehand and then you change your password and he copies the same one again,  well, they have two targets for the root-force attacks.  Whereas, so there's no actual invalidation of the old password, it's only always adding a new password,  given an attacker model where we assume that the attacker can always copy the Lux headers.  If you have a hardware security module, you can actually change the password because the old password will be invalid.  And this is what the Lux headers look like. So here we see the original Lux header where we have the regular key type Lux2.  And here's the new implementation where we have the type TPM2.  We say it's in this NV index and the TPM.  There is no DA protection or there is DA protection and it can even be bound to PCRs, similarly to the TPM TOTP thing.  It's still in the PR because we're still figuring out where to put the feature.  Is it in the client application? Is it in the library?  So that still needs to be discussed.  But we have a demo. Isn't that great?  So as you see here, the only thing I'm changing is I'm setting the type to Lux2.  Let me increase that in size.  And I'm adding the minus the dash dash TPM parameter.  And this is all you have to do in order to enable that feature.  It works seamless.  And yeah, now we formatted it.  If we want to open it, I'm opening now with test pass because it's test pass phrase because I don't have root access to the device wrapper.  It seamlessly, without adding any parameters, open the file system again.  So we integrate with systemd, with Dracood, with initrd, with loan disks, you name it.  And that's what it's supposed to be like.  Similar to using Crip setup alone.  And one of the things that we're particularly happy about with the software community we've been trying to build up is that we've gotten some really good participation from other parties.  The project started a while ago and we've been kind of picking up new people as we go along.  And Red Hat has been a really good partner to us in this.  We've been working with this guy, Javier, who actually did a talk not too long ago.  I think it was just last weekend at a Red Hat conference.  We got a link there, DevConf.  If you're interested in Clevis, Clevis is a Red Hat tool that does automated decryption of various things.  It's not specific to disks, but it can be used and applied to that.  And Javier did a bunch of work to use some of our command line tools as a plugin to Clevis for using the TPM to unlock disks.  Clevis is something I'm not particularly familiar with and I'm not going to try to pretend to know too much about it.  I know generally what it is and what it does.  And I had to go to the Wikipedia page there to figure out what a Clevis is in the first place.  They have this model for plugins that they call PINs, which I find particularly difficult to get my head around because we deal with a lot of PINs when people are typing in kind of passphrases.  So it's not a PIN like you would think for like a smart card, but it's a PIN as in the PIN that goes through a Clevis fastener, which I found a bit difficult to wrestle with.  But one of the interesting things from Javier's talk that was a big takeaway for me as someone who was trying to build this project up was that,  you know, the quote down at the bottom, that Red Hat development efforts are based on these TCG specifications and our implementation of it.  So we're very grateful to Red Hat and the other folks in the community that showed up and done interesting work like this.  Okay, so now we're leaving early boot in at RD and we're actually in the main system.  And one of the things that you might be running there is, well, something that uses OpenSL like a web server and MQTT server and I don't know what you name it,  or a client for that matter. And of course, one of the easiest big impact points is to provide an engine for OpenSL.  So the idea, how that works is that OpenSL provides this plug-in API where you can define your own engine that can be developed independently from the upstream project.  And that enables, for example, the use of hardware security modules or crypto accelerators or PKCS 11 and I don't know, there's like a bunch of engines out there.  And so the most obvious thing was to come up and implement an OpenSL engine to use the TPM with via the TCG-specified software stack, that is.  And so you can find it right there on the GitHub page in the TPM2 software community.  And depending on the actual application you're trying to enable TPM usage with, it can be as easy as setting this environment variable to a config file where you define the engine.  And then all of a sudden it starts using TPM keys in the background and you don't have to do anything else.  And just to show you how easy it is to actually set up that stuff, again we have a little demo.  So all we're doing here is we're creating a ECDSA key. We store it in the file My Key.  Next thing we do is we generate an X509 certificate and compared to the regular call that you would do, the only parameters we're adding is actually engine, TPM2 TSS, and key form engine which defines that the input key is supposed to be parsed by the TPM2 TSS engine.  Well, we can set country codes if you like or I'll go just for the default in this case. And next thing we do is we just start the internal web server of OpenSSL for testing purposes.  And again the only thing we're setting is key form engine and engine TPM2 TSS. And we go ahead and, well, use Firefox.  Of course we get a warning because we have a self-signed certificate here, so, yeah, I have to accept that.  And there we go. Does the result of OpenSSL giving you, well, its standard debug page with all the cryptography that are supported.  And up here we see that we had a connection acceptance from Firefox.  So there's kind of a common theme for all these things. The TPM is only useful for various cryptographic operations, either encryption, or signing.  And so authentication is one of those. And we do a lot of authentication when we're connecting over VPNs.  So a big part of the adoption that we've seen that's very encouraging is that some of the existing upstream or downstream projects, both StrongSwan and OpenConnect,  have started picking this up and using it either directly through the TSS APIs like StrongSwan does, or like OpenConnect using the OpenSSL engine that Andreas was just talking about.  So StrongSwan has actually been using the TPM for a long time. They implemented a lot of the protocols from the trusted network connect specifications from the 1.2 implementation.  I think they're probably one of the only ones that I've seen doing that. Where OpenConnect is a little less esoteric in that it's a drop in replacement for the Cisco client VPN.  So it's not a full VPN suite like StrongSwan is with both client and server. It's strictly client and it's used to connect to the Cisco SSL VPNs.  Again, authentication is really, you know, in these contexts, just the signing operation. And so there have been APIs for doing these types of things and interfacing with hardware crypto accelerators for a long time.  And Pkcs11 has been around longer than I've been in the business. And it's really a gateway for us to just support in existing implementations, existing software projects. And we can just by providing a Pkcs11 compatible interface,  we can get basically free support for all these things with no code changes in those projects explicitly. And so this is actually a very new implementation from Bill Roberts at Intel.  There's a lot of work that went into this project because you're basically building a big kind of mapping between the TPM interface and the Pkcs11 interface.  And Pkcs11 comes from the smart card world. So you're basically building an object model, a mapping for an object model between these two things. And it's a pile of work.  So a lot of respect to Bill for the time he's put into this. We've actually had some folks at Intel not specifically affiliated with us about working through a partner where we showed a demo at the AWS re-invent conference this past year using the TPM as a hardware protection mechanism  for your crypto keys in the AWS green grass architecture. Not something I'm particularly familiar with, but that's nice. That means that we're doing work on kind of the foundation.  Other people are picking it up and starting to do useful things completely without our knowledge in some cases.  So the easiest way to use Pkcs11 and your TPM for a really big impact on your individual platform, I'm sure people in the room, you log into over SSH to tons of servers. I'm assuming you probably got keys that you're keeping around on your disk.  And if you use the Pkcs11 module and open SSL, you can keep those keys in your TPM, which instantly prevents you from having someone steal them off your computer and impersonate you on a different computer.  And in some environments, if you're an admin and you're logging in and your account has a lot of permissions and it is very powerful on that system, you really don't want someone being able to get on your system, take your keys and then log in from another machine.  So the TPM can be used almost seamlessly to do that. And we have instructions for going through the setup there.  And the instructions pretty much break down to this. You can fit all of the commands you would need to do onto a single slide.  The default location for the metadata, it's a little bit of a database that maintains this mapping between the two object models.  You run a tool that we have that Bill wrote in Python that initializes the entire system. You then create a token. Token, again, is a Pkcs11 ism that comes from smart cards. Your token is a physical thing.  And in this case, you know, it's a key slot for the TPM in a way. You then add a key to that token. So it's basically like sticking a smart card in a card reader.  And then when you want to actually go and use this thing, you just use SSH key gen to pump out the public part so you can put it onto the server you're logging into.  You then insert it into the authorized key file there. And it's one parameter that you pass extra into open SSL to just have it use the Pkcs11 module for the TPM.  The login should go just like you would expect from any other SSH login.  The TPM tools is actually one of the oldest parts of the project. And it started out as a one-to-one mapping to the old tools from the 1.2 TPM software stack from IBM.  This was something we ended up doing away with and rewriting entirely. And so there was tons of refactoring in this code base from 2007 to 2008. And it's gotten very, very stable.  It started out using just the system API, which is very low level. And we're now, believe the patches gone in. Joshua has patches that I think got merged that use the ESIS API.  They're not merged yet?  They are.  So now the tools are all using ESIS, which means that we don't have to do any extra work to benefit from using the transport protections from HMAC and encrypted sessions.  So you can use the TPM tools and if properly configured, you can get protections for the channel between you and the TPM.  This is something that is being used again, like I was saying, in the Clevis project.  Red Hat is using these just in a shell script through Clevis to provide an extra pin to get TPM protections in that architecture.  And this is actually, you know, looking back at past FOSDEMs, the last two years, 2018 and 2017, both had talks with people talking about the TPM software stack.  Back in 2007, we have a friend from Facebook, Davi Aguirre, who gave a talk that showed using these tools and doing just the basic signing operation from the TPM and then using OpenSSL to verify the signature on the command line, just like you would expect to do.  And if you actually go back and look at his talk, it's kind of ugly some of the things he had to do to get the tools to spit out a public cert that OpenSSL would recognize.  We've gone through and, you know, learned from basically his critique of the tools and we've gone and cleaned this up drastically.  So this is just the set of commands to do exactly that.  Unfortunately, there are some things in the TPM that we just can't abstract away, so we have to load a primary key and then create a child key.  So this is a TPM toism that people need to get comfortable with.  But after that, all we do is load the key, generate a digest, sign the digest, get it to spit out the public part, and then just use an OpenSSL digest command like you would expect using any other public key.  Yeah.  And since you want to be free in what you do with the TPM when you actually start developing, because while shell scripts are nice for prototyping some in-business to stuff and whatnot, but not very suited for actual productive code or actual applications.  Well, we have C as the primary API of the libraries themselves, but there's also language support for other things.  So there's Google came up with this TPM.js thing.  If you go to this, their GitHub I.O., you can actually like use their JavaScript API in the browser in order to do some stuff with an emulated TPM on their end.  Or another thing that we've been working on upstream is coming up with bindings for Python in this case.  So basically we're not just going for a CFFI wrapper or CFFI bindings directly.  We wanted to like get more of the object-oriented parts of Python, of course, into the API.  So there's a little object-oriented wrapper around that.  And since we're running so great on time, I actually have time to demonstrate that as well.  Yeah, again, we are, of course, way too small.  But, yeah, if we just enter Python 3 and we do an OK.  Of course, we have to enter Python 3 for that.  We import star from PyTPM to TSS.  Everybody should have seen that at some point.  We open an ESUS context and we can already talk to the TPM.  There was a TPM command being executed right there having the TPM generate five random bytes.  And then we added some convenience functions in order to unpack them.  So this would be the actual Python array representation of this TPM to be,  which is a TPM-specific data structure of the stuff we did previously.  That's how easy it can be.  The next one, I didn't want to type down.  So this would be an actual serious use of TPM.  So all the upper part that's pretty small up there.  That's just, I mean, this is just initializing empty structures that apparently need to be provided to the TPM.  Then here we have a few settings like what we want to go for an ECC key.  We want to have that key be authorized with UtherOth.  We want to have that be a sign or encryption key, stuff like that.  It should be an ECDSA signing key with SHA256 and the NIST P256 curve.  Very straightforward.  This way we create the primary key on the TPM.  What we get back is X, the handle for the actual key or the other parameters we can actually ignore in this case.  And we perform a sign operation.  And that's it.  You already signed something with your TPM.  Something that, when you're introducing a topic like the TPM and trying to bring people up to speed on,  how to use it, you know, when helping people fix things when it breaks,  having debugging tools is particularly important.  The TPM is kind of opaque to a lot of people and, you know, you send a command and you get a response back.  And oftentimes it's an error.  It's a little bit of a esoteric error because they're all packed into 32-bit integers.  And, you know, it's not always easy as thing trying to figure out what's going wrong when things do go wrong.  And things always go wrong.  So we really just noticed this and in our work we ran into the same problems.  None of us started out knowing how all this stuff works.  We all had to fumble our way through getting started.  And one of the things that we kind of realized would be really useful is if we had a tool that allowed us to visualize the command and response buffers,  take a look at the command, make sure that it's sending the command that we think it's sending,  and Wireshark was just the perfect example of doing something like this.  So if you're setting up an environment trying to learn how this works in debugging, you'll run a software simulator in user space  and it communicates with the software stack over an IP socket.  So you can configure Wireshark to listen on the communication and you can get these buffers,  but you need Wireshark to do a little extra work for you to help you parse through them.  And so one of the members of our team, Taddy, has struck,  spent a bunch of time in the 2.9 development window doing work in Wireshark  to enable the parsing of not just headers, but some of the command bodies as well.  You just snip the traffic like I was saying on loopback and you get the capture in the Wireshark UI.  You can see the headers, you can see it take apart certain command bodies for ones that it understands.  We don't have full coverage of the actual, of every TPM command yet,  but the talk today is about trying to communicate to folks the benefits of using this technology  and help people to get involved. And so if this is something you're interested in,  if you like looking at ones and zeros all day in network and PCAP files,  we would love to have some help actually expanding our support in Wireshark.  You want to jump to the next one? Thanks.  And so if you see here, this is just the familiar Wireshark window that I'm sure everyone here has probably seen.  And since we're communicating over loopback, you get the IP headers broken down on the left there,  but as you move over to the right, you'll see the protocol is identified as being associated with the TPM,  and you'll see kind of request and response buffers being identified.  And if you jump to the next one, you'll actually get to see a command body when we actually parse it apart.  This is, you know, all the TPM commands are, you know, when they're sent to the TPM,  they are network byte ordered, they're packed, so all of them, there's no padding or anything from any of the C structures that you'll be serializing.  So it's really nice to have this tool to go through and pull apart the header like you'll see.  A header on all the commands is the same, but you'll see the command code there is identified for the create loaded command.  That just creates a key and loads it into the TPM in one operation.  You can see that we're seeing the handle area and the authorization area.  This is something that is just a TPM2 ism, and there's a number of flags and various fields that determine how the TPM will respond to this command.  So being able to look at this and, you know, if you don't understand why your command produced a certain result  and you think you set a certain number of flags to various values, this is a great way to go through and really identify and make sure that your mental model of what's going on  is exactly the model of what's happening in the real world.  And so finally, something that is kind of, that's just something I was interested in, and I saw this as a potential use case and decided to hack up a prototype.  And there was even a talk here earlier, trusted execution environments, or TEEs, are something that is getting more and more traction across the industry.  Pretty much every CPU or major CPUs on the market have some kind of TEE, whether it's trust zone on ARM, AMD has SEV for their chips, Intel has SGX,  and, you know, there's a talk today about risk five and what risk five is doing for building an environment for their CPU,  where the operations for things that are running in this TEE are protected from, you know, what we think of as general purpose exploits for things that would steal or exploit the kernel  and, you know, use that as a way to inspect a process and potentially steal information out of it.  So these things are really interesting and they have the potential to provide us with some really useful tools to build stronger systems,  but they're actually quite difficult to work in sometimes. TEEs effectively are islands and, you know, if you're on the island and you have everything you need, everything's great.  However, as soon as you need something that's not there with you, you have to go out and either bring it in or communicate across the boundary of the TEE to talk to the outside world.  Interacting with these external entities like the TPM has a lot of value and could be really useful, but someone has to build the plumbing to cross this boundary,  and someone has to, you know, take a look at the added complexity and the risk that comes along with that when you're crossing that boundary,  because on one side in your TEE you are protected and on the other it's not. It's basically like sending a network packet over an untrusted network.  So the prototype looks a lot like what I was talking about in the UVFI. It just adds kind of an additional layer because the TEE itself is, you know,  in SGX terms we call it an enclave. It's this kind of box that I'm drawing here that shows the software stack being used,  but when you want to communicate with the TPM you need this layer here, which is just another TCTI layer,  to move the command and response boundary or command and response buffers across the enclave boundary.  Once you get across the enclave boundary you're in the process that's hosting the SGX enclave,  and something there needs to provide this glue code to move it that last step across the boundary out of the process down to the actual TPM itself.  So we have just like a lot of things in SGX. You usually have one library that lives in the enclave,  and another one that lives outside the enclave providing support to deal with commands that come from inside the enclave.  So there's, in green there we have the actual TCTI that lives in the enclave.  You can build your TSS to sit on top of that inside the enclave, and then outside the enclave there's this management layer  that catches the commands, associates with them with the connection, and then sends them on down through the rest of the software stack  so they actually reach the TPM. This is very much a prototype.  It was really for me a way to demonstrate the utility of the TCTI layering mechanism and the separation of that transport,  and it was also a good way for me to just figure out how to build an SGX enclave. What does it mean when I do certain operations  and I have to move across this boundary? What are the implications?  And so, you know, this work is still very new. It's still, the link there is to my personal GitHub account.  We haven't merged into the real project or the real out, the community's GitHub space,  because it's still, you know, it's new. Don't have a lot of use cases. Don't have a lot of documentation.  And I'd really like to write a good kind of threat profile so that people, if they decide to pick this up and use it in their enclaves,  they have a full understanding of the potential threats, mitigations that need to be put in place,  and, you know, the risks that they're taking on by doing this.  So if you're interested in developing on TEEs and you think that there's some utility in talking to the TPM,  this is probably an architecture that just could be replicated for other TEEs depending on what their architecture looks like.  Yeah. So we've been talking about a bunch of stuff here, which had several purposes.  First of all, we tried to pick up everybody via some way or another to be interested in this stuff and to see how useful it could be for them.  Of course, it also shows you that this is way beyond everything that a single company could do.  This is actually a community project, even though it's still backed by like Infineon, Intel, Fraunho, Ferret, Weed, GE,  and individuals even catching up and providing our arch user repository builds and stuff.  We do have a very good bus factor at this point.  One of the companies would pull out, would be no problem, so we can say that we're growing into a very stable and very useful software community here,  spanning over a bunch of projects.  Of course, this is a bunch of stuff already, but we also wanted to attract you and everybody else to join us,  because this is the stuff that we came up with that would still need support for TPMs.  If you're involved with any of those communities, if you have any ideas, if you would like to join in and provide patches to upstream, whatever,  or if you even know other projects that would benefit from TPM support, which are not listed here, come talk to us.  Talk to us here, hunt us down somewhere in the cafeteria or the security room or whatever.  Or talk to us on the mailing list or get our, I think we didn't provide our email address, but you could find them on GitHub and send us a message.  And if everybody who's leaving is very silent, we can maybe even answer questions now.  So are there any questions?  I would just ask you to stay seated during the question and answer session if you want to please be quiet and take all the litter with you.  There is now the InKernel resource manager with recent kernels.  Is there any reason to keep using the user space resource manager?  That's a good question. First off, the user space resource manager predates the work that happened in the kernel.  This was just a necessity. We've been providing this software for about three years.  Back then it was very new, but we needed to have some kind of resource management.  We politely asked and were told to provide patches, so it was easier to implement it in user space.  And also, how to say this, it was the way that it was done previously, and so there was precedent for doing it that way.  Now you're right. The work in the kernel is definitely going to be where the resource manager lives in the future, but it is not fully featured yet.  So there are still some things that need to be done in the kernel before.  Personally, I'm willing to recommend that people use it for, say, long running systems like a server that's going to stay up for a very long time.  There are some weird things you have to do to keep the TPM happy. If you're interested, there's this notion of what's called a context gap.  It's an anti-replay mechanism that exists in the TPM for when you're loading and unloading sessions, and that's currently not supported in the kernel yet.  We've been talking to Yarko about that work, but it'll happen when it happens.  And until then, personally, I'm recommending that folks use the one in user space because it does support that mechanism in the most recent release.  It's also useful for when we're testing. So you run a simulator in user space.  If your only resource manager code is in the kernel, really hard to test the real life scenario.  So I agree. Ideally, in the end, there will be no user space resource manager used in deployed systems.  It may live on as some kind of proxy daemon that can do, you know, enforce policy if you're on a system where you want to have blacklisted commands where you don't want any of those going from user space into the TPM.  Maybe only something that the kernel would do. You could provide that in a layer that's outside the kernel.  Putting policy or mechanisms in the kernel, a lot more tricky than just doing it in user space.  So I agree, but I think, you know, we're not just there just yet. We're really close.  Hi there. This is a bit more of a policy question.  Basically, while you're building this community around this technology and its potential applications, I'm really intrigued in particular in the bitlocker-esque functionality of keeping your disk encryption keys in the TPM.  Are you talking to relevant standards bodies and so on about getting this approved as a secure way of storing keys in the hope that Linux will be usable in more secure environments?  I didn't get the middle of the question.  Sorry, are you talking to relevant standard bodies, like people like the cybersecurity essentials in the UK, to try and get some of this TPM usage in Linux, allowing Linux to be used in more secure environments?  So I mean, the TPM itself lives in a standards body. They define both what the TPM is, the interfaces to it, and, you know, the software stack is part of what we've been driving in that direction.  As far as the individual uses, so knowing whether or not the implementation, you know, that's using Lux or Clevis or whatever else, whether or not that's acceptable to various standards, I think it's an eventual end goal.  I don't necessarily know that that falls under the purview of the open-source community that we're building around the implementation.  They're definitely the people that would probably be implementing it and possibly responsible for taking patches that would bring it in line with these standards bodies.  It's definitely not something I'm opposed to, but it's definitely not a primary concern at the moment.  We're more interested in just getting people to use it, use it effectively to protect their stuff as best they can.  And, you know, if it does gain traction, I imagine that would happen just by virtue of, you know, its own utility.  They think it's useful in those spaces. They want to make sure that it works properly, and eventually, you know, those people will take a look at it. I hope.  Hello, I'm Bien Poisson. One of the biggest stumbling blocks I had when trying to integrate TPMs into my projects is that the documentation for libraries are non-accessible.  We get help for it. That's a link to documentation. Are you trying to solve this problem?  Andre, I see you like writing documentation. I didn't understand the question.  Let me repeat this just to make sure I understood it properly. The documentation is pretty bad. It sounds like what you're saying.  There's actually a pile of books. There have been three or four published books that are three, five hundred pages, and I agree, they're almost impenetrable.  You read them and it's very deeply steeped in jargon from the standard spotty. I think that the thing that's preventing us from getting...
The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_0_167.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_168_2411.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_2412_4259.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_4260_9083.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_9084_10955.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_10956_11555.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_11556_14819.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_14820_16751.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_16752_17471.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_17472_19787.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_19788_19835.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_19836_19883.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_19884_19979.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_19980_20039.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_20040_20087.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_20088_20135.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_20136_21755.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_21756_21959.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_21960_22763.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_22764_26435.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_26436_26495.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_26496_26627.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_26628_27695.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_27696_27755.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_27756_30275.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_30276_32411.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_32412_32483.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_32484_32819.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_32820_32927.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_32928_33023.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_33024_33071.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_33072_33119.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_33120_33179.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_33180_33311.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_33312_33395.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_33396_33443.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_33444_33539.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_33540_33803.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_33804_33887.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_33888_34019.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_34020_34127.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_34128_34247.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_34248_34379.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_34380_34511.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_34512_36335.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_36336_39959.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_39960_41723.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_41724_43595.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_43596_45407.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_45408_46991.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_46992_47123.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_47124_47183.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_47184_47231.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_47232_47363.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_47364_47411.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_47412_47459.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_47460_47555.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_47556_47951.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_47952_48299.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_48300_49631.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_49632_52811.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_52812_53399.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_53400_54875.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_54876_57563.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_57564_60887.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_60888_62627.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_62628_72335.png The_TPM2_software_community_Getting_started_as_a_user__becoming_a_contributor_72336_72460.png