 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 Philip 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-the-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 hands-from-the-audience if you're willing, does everyone here know what the trust-the-platform module or the TPM is? Lovely. Good, because we're not gonna be doing a whole lot of background information in this talk. We're mostly gonna 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 gonna go through really quick. 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 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 wanna see all the background information about the trials and tribulations that we went through in standardizing and implementing the APIs on the software stack, go check out those talks, please. The rest of it is actually gonna 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 gonna be very much like the way that your computer boots. We'll start with the earliest parts of the software that'll 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 the kind of one of the cornerstones of the design for the TPM software stack, the second iteration for the new TPM2 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 wanna 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 separating the transport layer from the APIs was very important. I don't know if anyone here has ever programmed with the TPM1.2 software stack trousers. It was a very, very tight coupling between the user space daemon that was a 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 whether 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 wanna have a UI that's sitting in front of your application, you want it to be lively and you don't wanna 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, you know, a constrained environment like firmware. You probably don't wanna 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, right, 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 wanna 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 GCrypt. So this is generally how it looks kind of in a box diagram here. The lowest level is gonna be your device driver and above that is gonna 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 management for them. 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 wanna 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 short order. No guarantees on timing. Okay, so like I was saying, everything is gonna 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 right in the FES 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. 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 in this 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 the 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 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. It's where you actually need to execute some commands where you may be creating keys, you're doing crypto operations. So, and also boot loaders. Things like grub. If you want to have an encrypted boot partition and you wanna use the TPM for protecting your crypto keys, you don't wanna interface directly with the TCG protocol. You wanna talk through the TSS. And so we have this 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, Stefan Bergeron's work on the software TPM layer that we're using in the actual, the test harness which up 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. It's 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 GNUFI versions, I'm using GNUFI to build this. I haven't integrated it directly into the TianoCore build. But 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 GNUFI 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 gonna 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 in your executable. It just tells you invalid off-code 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 QMU, the software simulator. We can launch EFI executables and get output just like when you're on a make check. It's actually pretty convenient. Yeah, and so once we are leaving UFI and BIOS in early boot, the first thing we're heading into is initRD. 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 initRD or even BIOS and replace it with something that locks your crypto keys, your passwords to unlock the crypto keys. And on the next iteration of boot, well, 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 Gerrit found that or found an idea, found a solution for that which he talked about, I think, three years ago at the Cares 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. And 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 either 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 wanna 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, init, 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 wanna decrypt our boot partition, our root partition, not the boot partition, that's where we get the init, RD from, but the actual root partition. And well, why would you wanna 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 wanna use that? Well, the first thing is it provides you with hardware-based dictionary attack protection. So if you really wanna be certain that your disk, if it's mirror 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 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 that, 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, well, this is what the Lux headers look like. So here we see like 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, well it's in this NV index and the TPM. There's 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, ain'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 wanna open it, I'm opening now with test pass because 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'll integrate with systemd, with Dracood, with init.rd, with loan disks, you name it. And that's what it's supposed to be like. Similar to using Crips set up 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. You know, 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's 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 and 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 gonna 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 are 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 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 something that uses OpenSSL 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 OpenSSL. So the idea how that works is that OpenSSL 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 OpenSSL 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 and we store it in the file MyKey. 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. Or we can set country codes of who like or I'll go just for the defaults 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 we'll 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. There's the result of OpenSSL giving you well it's standard debug page with all the crypto algorithms that are supported and up here we see that we had a connection acceptance from Firefox. So there's kind of a common theme through all these things. The TPM is only useful for various cryptographic operations, either encryption and really 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 in these contexts as designing operation. And so there have been APIs for doing these types of things and interfacing with hardware crypto accelerators for a long time. PKCS 11 has been around longer than I've been in the business and it's really a gateway for us to just support in implementations, existing software projects and we can just by providing a PKCS 11 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. He, there's a lot of work that went into this project because you're basically building a big mapping between the TPM interface and the PKCS 11 interface and PKCS 11 comes from the smart card world. So you're basically building an object model that 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 but 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 PKCS 11 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 PKCS 11 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 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 PKCS 11 ism that comes from smart cards. Your token is a physical thing and in this case, it's a key slot for the TPM in a way. You then add a key to that token. So it's basically sticking a smart card in a card reader. And then when you wanna 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 into the authorized key file there and it's one parameter that you pass extra into OpenSSL to just have it use the PKCS 11 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. Oh, they're not merged. 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 in a 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, 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, David Aguirre, who gave a talk that showed using these tools and doing just a 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 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 tourism 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 wanna be free in what you do with the TPM when you actually start developing, because well, shell scripts are nice for prototyping, some administrative 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 their GitHub I.O., you can actually 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, but we wanted to 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 three and we do an, okay. Of course, we have to enter Python three for that. We import star from PyTPM 2.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 2B, 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 UtherAuth. We want to have that be a sign or encryption key, stuff like that. It should be an easy DFA signing key with SHA-256 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, 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 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 it's not always the easiest 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 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, Taddeus, 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 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 and network and PCAP files, we would love to have some help actually expanding our support in Wireshark. You wanna 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 order, they're packed, so 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 TPM to 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 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 what we think of as general purpose exploits for things that would steal or exploit the kernel and 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 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 with 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 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 UVFI. It just adds kind of an additional layer because the TEE itself is, 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 wanna 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 the 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 that 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 do you 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 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 of the community's GitHub space because 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 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 so this is actually a community project even though it's still backed by like Infineon, Intel, Fraunhofer, Red Hat, we had GE, Basuza, I don't know, 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 so even if 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 it would still need support for TPMs and so 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 yeah, and if everybody who's leaving is very silent we can maybe even answer questions now. 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? So 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 and I mean 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 and it was easier to implement it in User Space and it was also, how to say this? So 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 gonna 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 enforce policy if you're on a system where you wanna have blacklisted commands where you don't want any of those going from User Space into the TPM. Maybe only something that with a 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 we're not 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 by 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 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 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 into 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 if it does gain traction, I imagine that would happen just by virtue of 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 Björn Portman. One of the biggest stumbling blocks I had when trying to integrate TPMs into my projects is that the documentation for libraries are non-necessable. We get help for it? Doesn't mean that I don't need a link to documentation. Are you trying to solve this problem? Andreas, you like writing documentation. I didn't understand the question. I didn't understand the question. Let me repeat this just to make sure I understood it properly. The documentation is pretty bad. Sounds like what you're saying. There's actually a pile of books. There have been three or four published books that are 300, 500 pages. And I agree, they're almost impenetrable. You read them and it's very deeply, it's steeped in jargon from the standard spotty. I think that the thing that's preventing us from getting