 Hi everyone. My name is Andreas. I'm here to give a talk about the TPM2 ecosystem in Linux and how we're trying to build up a community around it. I'm not the original speaker. Originally Peter was supposed to give a talk. He's from Infineon. I'm not from Infineon, so the schedule got kind of mixed up, just if you're wondering. So I'm actually, so who am I? I'm, as I said, Andreas. I've been working with TPMs for on and off 13 years now. I work for Fraunhofer, which is a R&D institution in Germany, and there I have a group, a research group, focusing on trustworthy platforms with a large focus on TPMs. I'm also a TCG member, so writing the specs that then I have to implement, unfortunately, because being the maintainer of three of the projects from the ecosystem, the core library, and two others that I'll just talk about real quickly. Just real quick, what do we do at Fraunhofer? Well, we put TPMs into things for fun and profit, be that like railway systems as you see up there, or these famous cars, so these electric vehicles that you see there, yeah, they all can benefit from it. So what we're going to talk about, I'll give you a very, very quick introduction to what TPMs are, then to what the TSS, the TPM Software Stack is, and quickly talk about existing TSS software that's already out there and being shipped. And this is everything that I already talked about at Linux Plumbers, so for those of you who were there at that talk, you can go to sleep until the next topic point, which is what's new, because that's new stuff is going to be. And then I'll talk real quickly about the community we're trying to build. So what is a TPM? A TPM is a little security chip with smart card-like capabilities that nowadays gets put into almost every consumer level, laptop, desktop, whatever. Big thanks here to Microsoft for the Microsoft Windows logo program that requires TPMs, because that allows each and every one of us to actually make use of them under other operating systems as well. A TPM is, as I said, usually it's a chip that's connected to the main CPU via LPC, SPI or SQC buses. There's also TPM implementations in firmware. I don't know, there has been like TE trust zone, whatever kind of implementations or in what I used to call a Southbridge. I don't know what you call it nowadays. So this is where the module lives. And then we have the CPU on the other side where I'll be focusing on, because that's where the software is that lives and where the applications that actually make use of it live. Just a very quick pointer. If you want to get started with TPMs, well, you just take whatever laptop, desktop, whatever you have. The TPM is automatically discovered via the ACPI tables by the kernel. And you already have a dev TPM zero device and can just go ahead and use our software. You might have to activate it in in BIOS that depends on your specific device. Or if you like to think around with raspberries, there's a bunch of respiratory daughter boards. And nowadays, Raspbian even has support for TPM. So it just changed those two lines in the conflict TXT. And you're all there and just go ahead and go ahead and follow the instruction from the install MD from from the upstream projects. Right. So what is the TSS? As I said, the kernel driver exposes to user space just a character device dev TPM zero. And this character device consumes bite buffers and spits out bite buffers. And so you either have to do a lot of manual tinkering around with it. Or you can go ahead and utilize a software stack kind of a middle where I would say for for accessing the TPM. So TCG, that's the standard, the specification consortium where the TPM originates from. We also defined a set of specifications for software stack, specifying API's that you might want to be using. And then we have TPM to TSS, which is an implementation of those libraries. It's not the only software stack for utilizing the TPM out there. But it's as far as I know, the only open source standards compliance one. As I said, it provides API's for for application integration. And our hope is to get adoption either by the TSS directly or to have additional modules that are already integrated with software to pick up TPM functionality. So such that it can seamlessly integrate. So what what kind of API's that we specify there. This is basically the stack as you would have it the software stack on your on your device, the TPM device driver, as I said, usually lives within the kernel space. And then you can have a because the TPM is somewhat resource limited, because it's a small chip shouldn't cost too much money. You need some kind of resource manager. So you can either have a resource manager inside the kernel nowadays, which you can access via depth TPM RM zero, instead of TPM zero, or you can have a user space resource manager that also provides you this functionality of multiplexing the access to the TPM device. So you don't applications don't step on each other's toes. On top of that, we have the TPM command and transmission interface TCT I this basically a IPC abstraction layer, because we already figured that you might be accessing the TPM via the user space resource manager, you might be accessing TPM via the kernel space resource manager, you might be wanting to access a TPM simulator during the development. So we already designed into the whole approach, this idea of an abstraction layer that you have underneath the actual user space libraries. And during initialization, you can define which kind of TPM you want to connect to and which way you want to connect to it. And nowadays, there's even like TCT I modules that talk from an SGX enclave to the actual user space or that work in UFI environments, if you're into that kind of hacking. And then further up, those are the most interesting APIs for user space development. We have the system API, which was the first API we defined the enhanced system API for names, and the feature API the latest latest edition. And depending on what kind of application scenario you're trying to solve, either of these APIs might fit you. The system API is mostly designed for highly constrained embedded devices, where we don't require any file IO, we don't have crypto libraries back in crypto libraries compiled into the source, for example, or where you don't want to do any heap allocations, because the interface is designed such that it works in a stack only allocation way, or global variable allocation way. The enhanced system API, then bring some nicer features. So this is what you probably want to aim for for most of your low level design on an actual system, because it does a lot of the bookkeeping for you. So it when you communicate with the TPM, you need to store certain metadata for all of the TPM objects, you need to calculate HMAX for authentication of commands and responses exchanged with the TPM. And that's all the kinds of things that the enhanced system API does for you. Now we have the feature API, the latest edition, which provides a lot of convenience functions and opposed to the other two, that were kind of bottom up, we look at the TPM functionality and designer interface to access it. With feature API, we went to top down design approach. So we looked at use cases and defined functionality for those use cases, but I'll go a little more into detail on this later. So here's a quick project overview. As I said, this is about the ecosystem that we're trying to build. And as you see, we have currently what two, four, six, seven projects in the core community space that are enabling you to use the TPM. And then there's also other projects that are not in our, well, in our namespace, I would say on GitHub, that are also starting to pick up functionality for TPMs based on our libraries. The one that I'm most involved with is, for example, Crip Setup, which I'm going to visit a little later. But there's also OpenConnect, Strong Swans, which are two VPN solutions that you might be familiar with. Yeah. So those core projects, we tried to keep them as low profile as possible. So here's just an example on the dependencies we have for the core tools and the resource manager, because there's been some, some rumors running around that it's so complicated and you need so many dependencies in order to build the TSS. That's actually not true, because we currently build with only one dependency, which is LibCrypt or LibGcrypt for the cryptographic operations in the background. And coming up with the next release will be also linking against LibCurl and LibJSON C, but that's three dependencies and nothing more. Yeah, just to debunk a myth here. Going further down to the user space resource manager again, so we do inter-process communication using LibDebuss. And since Debuss and Glib go along so nicely, that's also dependency and the tools again to dependencies OpenSSL and LibCurl. Other projects you might be interested in the Python bindings, which I'm not going to go too much into detail here, or not going to mention it at all anymore. And the TOTP, which is a PC to human authentication process, thinking about evil maids or I don't know, airport security infiltration, stuff like that. All right. The community we're building only builds upon people. So we have this rather large set of maintainers from several companies, some from my research institute, some are from Infineon, a lot of them are from Intel, and always have to highlight we have a volunteer hobbyist maintainers, which is always great to have in such a project. And overall, we accounted, we have more than 100 individual contributors by now. So we're trying to actually build up a thriving community, which is why we're giving these kinds of talks. Other than that, we're trying to adhere to common best practices. So we have, well, Travis CI with scan build, always aiming for more than 80% test coverage. We're actually now, thanks to the efforts, I think it was Imran who did it or John, we're now building the CI on, I think, six different Linux distros in Docker containers, just to make sure that we compatible with all of them, and also follow the latest warnings and scan build findings that you get with newer distributions and your versions of clang. So we're trying to follow best practices. And on that note, badges, badges, badges, I think we're trying to get into the Guinness Book of World Records for the most badges. But I would say each and every of those badges actually contains some very good best practice that we're trying to follow, be that, as I said, caverity or code coverage, CI best practice guidelines, or I think one of the latest additions are read the docs or looks good to me, stuff like that for doing code analysis or automatic generation of documentation. The graphics you see on the right hand side. This is actually an overview of the packaging we have. Don't be too concerned with the red markers. Those are packages that exist. They're just not the latest version. So some of them are from an earlier main minor version release. Still, most of them include the latest bug fix releases. And as you can see, we have quite some adoption. I think the latest being Alpine Linux. And I think there's also some net BSD stuff going on now. So that's pretty cool overall. All right. So what can you actually do with this TSS and TPMS? Well, already exists. As I said, currently, most applications, almost everything that's running TPMS is linking against this Isis namespace, the lib TSS to Isis libraries. And that provides you a one to one mapping of all of the TPM functionalities, including also its data types. So you need to know the data types and the general operations of the TSS. What the library does is first of all, it gives you a nice functional interface. And then it automates for you the process of marshalling, un-marshalling, metadata handling, encryption sessions, session authentications, memory allocation for return types. And it even does some some detection sequence for TPMS. So it first looks for a user space resource manager, kernel resource manager, kernel, and then for a simulator. So that's such that you can you can most definitely rely on a TPM being found if there is one on your system. Also the TPM tools, which is a collection of command line tools, since version 4.0, which took a little longer to develop than originally anticipated. But we finally here also uses ESUS and also the Python binding. So this is your primary, I guess, low level interface. Now, what kind of actual things or what kind of implementations exist there? So I tried to structure this a little from a use case perspective. One of the things you typically want to want to avoid in a system is you want to keep your keys from leaking. And keys and RAM are pretty bad idea, as we've all seen during during the whole hot bleed thing. Keys on disk are just as dangerous. If you think about, I don't know, people grabbing a hard disk from your from your server environment, or if you're thinking about the kinds of devices I showed you earlier, the embedded devices, you might assume that an attacker is easily capable of removing an SD card from a slot and extracting private keys from there. So what you want to do is you want to have some way to prevent them from, well, first of all, extracting the keys, and then even worse, to duplicate the keys because if they are only removing a smart card or whatever, or steal the device, you could at least know that the key is gone and somebody else has it now. If they copy it, you might not even be aware that there is a duplicate of your device somewhere on the internet. And so the easiest way to do that is using the TPM. And as an example, what we have is we have an open SSL engine to do that. So if your software is already using open SSL for, for example, remote authentication of your device, open SSL has this mechanism of engines where you can load different cryptographic providers into the namespace at runtime, actually. So you don't need to recompile open SSL. You only need to install the engine libraries on your system and give some config parameters. And then what happens, you come up or you, can you actually see the, oh, you cannot see the mouse pointer. So what happens is this engine will then instead of using key stored directly on disk and loading them into RAM and processing everything in RAM, it will load encrypted blobs that are lying around on disk, which are still in a PEM format, but a different kind of PEM format. So it's a TPM private key and not a regular private key. Load those into the TPM where they get decrypted by the TPM and then hand off all cryptographic operations to be performed by the TPM. That way, you know that an attacker who gains access to your application memory cannot do any harm, any extraction. So if that was, if you had something like that during the hot bleed cases, of course, you would still have to patch your systems, but you could just keep using the same credentials afterwards because only an attacker using hot bleed would only have been able to capture running sessions, but not be able to compromise your long term secrets because those would have been protected by the TPM. Another use case that I'm very keen on nowadays is disk encryption because I get tired by those long, ugly passwords that you have to type in on every boot in order to decrypt your disk. So what I want to do is instead I want to just enter a short pin and the problem with short pins is password derivation functions are only as strong as the passwords that your key derivations functions for passwords are only as strong as the passwords you put in. So they're easily brute forcible if you just use a pin for that. However, if you use a TPM, the TPM can be throttled or the TPM actually even has a smart card like lockout mechanism. So if a password has been entered too many times falsely, the TPM will go into a lockout mode and will have a cool down time usually that you can configure and so it will block any further authentication for the next hour or two or whatnot. Until next reboot. It's even, it's also utilizable in again other scenarios if you think about your data center where people can just take a hard disk from the rack. The problem is of course you could theoretically encrypt this hard disk, but the problem remains where do you store the keys for this hard disk encryption. Probably on the hard disk as well because you cannot have an admin running through the data center trying to type in all passwords into each of the servers on boot. So what you could do instead is use a TPM, store the encryption keys, the actual like on disk encryption keys inside the TPM and then if somebody goes along and steals even all of the hard disks and tries to carry them out, you know that they cannot access the data itself. Same is true for embedded devices and we're even working towards this attestation capability of the TPM. So you can define the BIOS and kernel configuration that the device shall be in when the TPM releases the keys for disk decryption. Such that means that an attacker on an embedded device cannot go ahead and easily they can maybe more effort is spent by hardware attacks, but they cannot easily replace the SD card with a different SD card to load a different kernel image from and then gain access to the credentials for disk encryption but they actually have to boot the original kernel which prevents a lot of easy extraction methods. So the way we're implementing that is together with upstream because that's what you're supposed to do. So there is an implementation out there hanging around in a in a merge request that's fully functional actually and you see the only thing that you have to change is you have to add the dash dash TPM to the crypt set up executable and the keys are stored inside the TPM instead of on disk and we utilize the JSON based Lux2 on disk format and just introduce a new type as you can see type TPM2 and there's the PCR selection up there. Currently I'm in Milan where in the process of reworking the architecture a little because you wanted to see this implemented a little differently also to support further use cases going forward but for the next release of crypt set up which should be 2.3 we're expecting to be able to merge this feature into upstream which would be kind of cool I guess. Finally as I mentioned earlier already VPN user authentication there's already two implementations out there so the idea is that instead of just typing in your username and password you now have the capability to define that a certain user at a certain PC needs to be present and the users cannot go around and use their private PCs to enter their passwords there or usernames there so there's an implementation for open connect by David Woodhouse and there's also strong spawns which is an open connect isn't any connect compatible open source implementation and strong spawns is just a is an IP second implementation and we I yet have to test that but theoretically open VPN should be easily compatible with the open SSL engine that we built as well but that needs to be verified alright so that's what I already talked about during Linux plumbers just a recap for everybody who was not there now what's new already teased at linus plumbers and also here that we have a new library coming up that's currently taking up a lot of our efforts and so from the TCG saw we released two new specifications the feature API specification as I mentioned that the idea is to have a top-down approach looking at common use cases and taking away a lot of the flexibility of course that you would have from a one-to-one mapping to TPM functions but trying to make it a lot simpler and easier for people to get at and that's also the reason for the second specification the JSON and policy data specification so instead of having the I have to admit even after working with those for several years now the somewhat complicated TPM data structures we now put everything into JSON so you can more easily edit it and you can especially more easily serialize it out to this candidate after someone else get it back from disk and just pass it into the API without having to actually understand all of the data types so that's that was one of the design goals we we got in there the next one was that even though I cannot understand it but apparently there's not only cryptographic experts programming out there but there's actually people who don't know too much about cryptography so we tried to decouple the functional aspects of the API which is calling into the API for signing or things like that from the cryptographic side of the API and we did that by specifying what we call cryptographic profiles so you can have a security administrator defining cryptographic profiles for use with the TPM so whether you want to be using rsa1k, rsa2k, ecc, p256 or whatever other curve you want to be using and they can specify that in combination with like schemes and hash algorithms and define what they are comfortable with and then you have the programming side where you then only call create key and the key gets created using those profiles that was our attempt to decouple those two roles that you have in a typical deployment scenario another thing we did is we added a key store so as I said the TPM is a very constrained device it only carries around like 10 or something kilobytes of NV flash that needs to be enough for all the keys and all the metadata for the keys authorization values and what not so usually what you do is you store your key blobs encrypted outside of the TPM and only the TPM knows the key to gain access to those encrypted blobs and therefore to the keys themselves and also you have to keep track of all the metadata that you need for a session authentication between the CPU and the TPM and so what we did was we added this key store to have those keys be stored automatically for you so all you need to do is now reference the key using a path as we call it which is just a few lines of just a few characters of text so you can artificially name your keys and all TSS we had the infamous UU IDs that nobody really likes I guess now we instead have just character strings which allows users to more easily reference keys and then the last thing we did was we added a policy language so the TPM has a very very capable interesting but also kind of complicated way to do policy for satisfaction and policy value calculations so you're building up hash trees and then you have to satisfy hash trees and provide a set of proofs to the TPM via command sequence that a certain policy is actually fulfilled currently and so we abstracted all of this away and instead we just defined a well suited JSON based format where you can specify your policies and all of that goes up to more than 25,000 lines of code that we're currently having for public review in pull requests on the main library the tools and the PKCS 11 project and just to give you an idea of what that looks like so as I said the system API up there basically doesn't do anything for you and you have to do everything yourself especially the metadata handling so you have quite a lot of code in eSAPI the exact same use case would be way shorter because it does all the metadata handling but you still have to do a lot of manual handling of resources for the TPM telling it which which wants to load which wants to unload stuff like that and with a feature API it basically boils down in this case to one command where there is async and finish some asynchronous scheme so it boils down to just one command which includes automatic satisfaction of a policy to give you an idea of what that looks like this is like the simplest policy you can think of which requires a certain value in the platform configuration registers so the platform configuration inside the TPM to be all zeros and on the right-hand side you see how we represent that in this JSON policy language just declarative and but if you're going one one level deeper into eSAPI this would be the sequence of functions you would have to call and you would have to allocate all of these things and especially for example this PCR digest zero thing needs to be calculated by you in advance so you need to know how exactly to mingle those hashes together so that's why we try to make this a lot simpler here and the first consumers as I said we we are extending the the TPM tools for that and the next consumer is going to be the virtual smart card project that we have so instead of requiring you to carry around a smart card and doing authentication that way the idea here is to provide a virtual smart card on your laptop whatever and so you can have proof of possession by possessing the laptop instead of the smart card and you still have the whole the the second factor the proof of knowledge by entering the pin and the idea is to have a fully compatible pkcs 11 implementation here use that uses the tpm as backing device and as I mentioned there's currently some heavy rework happening from the original isis based implementation now going into a feature API based implementation specifically to utilize the the key store capabilities because we have to store the virtual smart card token somewhere but also going forward probably to include some more advanced policies that allow you to further restrict usage of those keys having said all that community building so this is the the main website that we're currently running and let me quickly switch over there yeah so this is the the website where we are just gathering a bunch of resources about specifications teaching presentations we're giving we already have this presentation up there as well with a link where and how we're packaged which software supports tpm we have more badges in there of course one thing we've we're missing so far is a lot of tutorials so if you're entry level and you're trying to get familiarize yourself with the tpm we would greatly appreciate if you could just take your experience put them into tutorial and send a pull request for the site and of course the latest addition we have a guitar in here as well where people can chat so if you have any short quick questions feel free to just post them there one of us is always online thanks to time zone differences so you might get some quicker answers than on the mailing list as long as the question is kind of short yeah what's missing um well one of the main capabilities that the tpm used to be marketed with was the attestation capabilities so we're building up some support for that through the feature api but we still have to see for protocol bindings and whatnot and we of course want to have more core system integration so we are looking at network manager for iEEE what is it 802.1x integration of tpm's i would love to see my gnome key ring be integrated with a tpm or maybe having GNU PG for signing my my tower balls use the tpm as well so if any of you are in any of these communities come and speak to me and maybe we can make something happen and also if there's somebody who knows open SSL very well I could use the second maintainer there as well especially if you know the evpp key interface I would really want to have that implemented all right so there was a kind of quick speaking I'm sorry if I lost some of you along the way but I guess we have a few more minutes for questions yeah what about hardware attacks to the tpm how do you protect or how is the tpm really protected against hardware attacks so we are sure that what we put in there is not side channeled attack so the tcg has defined a protection profile that all compliant tpm's need to fulfill and this needs to be evaluated following common criteria el4 plus so that might assure you that nothing's happening or that might not assure you but that's like what they do and the companies themselves the the producers usually use some technology that's similar to other smart cards or embedded security elements that they sell for tpm's as well so you get about the same protection level as on those devices possibly even more because there's no self-programmed java card applet running on there but like all the code stack up to application level comes from the company that cc evaluated okay but let me phrase slightly with the software stacks that we have that is running on the main spu how can we avoid how do we avoid the side channels between the main spu and the actual tpm oh okay so there are several ways you can or several things you can do in general it's a not fully solved problem yet if you're going for FAPI then the communication between your main cpu and the tpm is completely encrypted after the provisioning step um the problem of course is then you need a trustworthy storage on the cpu side of things and this is where the chicken egg problem arises from if you get if you get hold on a cpu that has an internal secure storage on the on on the die or on the soc you can store some credentials of the tpm on the cpu and thereby from the very very beginning start with a authenticated communication with the tpm you can after the fact do an attestation to prove that there's some ideas running around the tpm dd devil mailing list where you have ephemeral sessions so the tpm on every boot creates new secrets and you use those ephemeral sessions in early bios and then that you hand them off the boot chain on the cpu and at a late stage after linux is booted you can have a remote attestation to check whether those are still the same sessions as they were in the beginning of the boot cycle in order to have to detect any kind of reset attacks on the tpm so stuff like that but the problem itself is not fully fully solved yet thank you so i i think i'm saying something i understand how this helps you if somebody takes your hard drive and tries to use it somewhere else but if i put a new sd card and it's signed by the same thing how does and if i'm not typing a pin like i'm on a server or embedded device how do i bless this hard drive to this tpm so it doesn't trust any other oh okay so the idea with this crypt setup thing without a password entry was that you're initially set up looks a lux partition whatever but instead of storing the credentials on the disk itself because you have nowhere else to put them you store them inside the tpm so if then somebody steals the hard disk they don't have the key with it there's no such thing as i guess the initial binding would be the lux format command where you set up the encrypted storage all right um i think i'm already two minutes over over my time so i'll be just standing out in the hallway if you have any more questions or comments or whatnot thank you