 Welcome to our talk using the TPM. It's not rocket science anymore. To introduce myself, my name is Johannes Holland. I work at Infineon Technologies since 2018. And in parallel, I was doing my master studies and I just finished my master thesis, which was also about TPM related stuff. Yeah. Yeah. And my name is Peter Huwe. I work as a principal engineer for embedded security software development at Infineon. I've been with Infineon for 10 years and I'm mainly responsible for everything that's related to TPM, on-chip software, off-chip software drivers and all that stuff. I used to be TPM kernel maintainer, but that's quite a long time ago. And now I'm more focused on the TPM2 software stack, which we're going to talk today a little bit about. Okay, so imagine your typical Saturday morning. You're sitting on the table drinking your coffee in the morning and you're just about to contribute to your favorite open-source project. Now you're browsing, of course, your news feed on your phone, looking at the news in the security world. And there you have it, Heartbleed or Spectre or Meltdown. You name it. Basically, you don't know what the next big thing will be. Well, and while you read this news, there go your web server keys and your weekends. Now, we could have all avoided this using hardware security or, as you might suspect, the TPM. Basically, the TPM or trusted platform module is a device for storing keys securely and for performing cryptographic operations like encrypting, signing, and so on. Now, you don't want to use the TPM because it's faster. In fact, it's lower than your PC, most probably, but it's more secure. So, for example, you can set up your keys in a way that it will never leave the TPM. I was not quite precise. In fact, the trusted platform module is not the device itself, but a specification for a device. So, it's an open standard. You can head to trustedcomputinggroup.org and have a look at the specification. It's a pretty long specification, but if you want to, go ahead. And there are multiple manufacturers and vendors of these TPMs, so you can always switch out one TPM with another, and it will pretty much behave the same way. So, there is no proprietary behavior specified in the standard, and you have no proprietary or badly defined interfaces, which makes it really a pleasure to work with. And the TPM, at least nowadays, is in every modern device, which means since Microsoft mandates in their minimum hardware requirements for Windows 10 platforms, that every PC must chip a TPM 2.0, basically, it's there. As I said, you can store keys on it. Of course, there's a random number generator on it for key generation. There are platform configuration registers, which are used for platform integrity measurements, basically, like measuring executables or the kernel, for example, and saving these measurements on the TPM, and it features a very powerful authorization model. Now, if the TPM is in every device, why does not everyone use it? Or do we? So, question to you. Who uses the TPM? Please raise your, well, raise your hands or write it in a chat. Now, why does not everyone use the TPM? Well, the specification is really long and really complex. I think about, well, hundreds of pages of specification alone, plus augmented specification, books about the specification, which are hard enough. So, while the TPM delivers unlimited power, it's also very complex. Now, of course, you might ask, is it possible to learn this power? And the answer is, well, not without the TPM 2.0 software stack. So, yeah, basically, you want to wield that mighty power, and for this, you need a nice TPM software stack, which hides more or less all these nitty gritty details from you. And today, we want to tell you a little about the whole ecosystem of the TPM 2.0 Github project, which includes the stack and many other things. Of course, there might be other software stacks available and out there, but I gave you this nice little flow chart, whatever you want, you can find it within our ecosystem. So, if you have chosen the TPM to use, then, of course, you're attending this talk to learn how to use this, because you don't want to learn about the stack, you want to learn about how we can use your TPM to the fullest extent. And as we heard, most products already ship a TPM, but why don't you use it? Maybe you can actually use it without writing a single line of software code, because the chances are pretty high that your software actually does support TPM already, because the first question you have to ask yourself is, does my application use OpenSSL? Next slide, please. So, if your application uses OpenSSL, then yes, you can use the OpenSSL TSS engine. So, basically, your application does support a TPM. I will show you how you can do this in the next slide. It's just creating a small key with our simple utility there. It's the TPM to TSS GenKey utility. You can either create RSA keys or EZDSH keys, and create signatures out of it, verify the signatures, export the public key, and of course running some TLS web servers if you're interested in that. So, basically, if your application has a nice OpenSSL integration, which supports the engine framework, then you can leverage the capabilities of the TPM as a secure key storage. But not all applications, of course, use OpenSSL. But they might use something different. PKS is 11. So, if you ever talk about any kind of smart card API, or if you ever use a UB key, a need-through key, or any kind of other HSM, you have quite probably already used the PKS is 11 framework. A lot of these cloud providers like Amazon Web Services or Microsoft Azure have a PKS is 11 integration for these crypto tokens. And with the PKS is a TPM to PKS is 11 provider, we already have an app for that. So you can also leverage a TPM there as a secure key storage. There's a lot of basic standard software like OpenSSH support, PKS is 11. And if you want to store your GitHub keys or GitHub SSH keys in the TPM, you can actually do that. In the reading presentation, in the reading of the project, there is a nice detailed guide how you can do that. So if you have a look at the talk by Andreas Fuchs at the last cause communication Congress, he there did a live demo on stage pushing code to GitHub, using the TPM as a key storage. But of course, not everything talks TPM and not not everything talks OpenSSL or PKS is 11. There are many more features of the TPM. So that need a special way to access the TPM and this is the TPM to software stack. So if you have any non standard needs, you have to use the TPM to software stack. And of course, I'm a, I'm a grumpy or firmware developer. I write my software and see. And of course that's the language of my choice it's reliable it's portable. And of course, it's a firmware developer thing. So of course, our TPM to software stack is also written in C. You can bind it of course or link it against C++ if you really want to. But yeah, I'm the C developer there. But of course there's these, these, these new kits on the block just graduated from high school. They don't want to write the good old plain C anymore. They want to have something more fancy. And of course, we have something fancy for you. We have Rust bindings. We have Python bindings. And more specifically, we also have Swig bindings. So whatever fancy language you want to use, you can actually create your own language bindings using the Swig wrapper here. So I might have seen some Node.js integration of the TPM to TSS. Not sure how major this already is. But if you, if you like to do that, roll your own language bindings, and you're good to go. So now back to the cool kit. Go on, Johannes. Yeah, sure. So you decided you want to use the full power of the TPM. Now, of course, you want to use the TPM to software stack, but there are multiple layers, basically libraries, which you can use and you have to choose. The most important one and the newest one, this is the new come the news thing about the TPM to ecosystem is the TSS feature API. Basically, it features a key store store on your host file system, and basically abstract a whole bunch of stuff, which you don't want to worry about. So I'd say 80% of use cases are suited to for leveraging this feature API. And I'll talk about the feature API in a moment, a little bit more. Now, if you have no file system, for example, or if you can can't afford the dependencies, you might have to downgrade and thankfully that's possible. Using the TSS enhanced system API. Basically, you do not need a file system, but you will need heat memory, and you will link against a crypto lip like opens open SSL. The enhanced system API basically handles TPM sessions for you. So on your host system, you do not need to well do crypto on your own. So if you can't afford this dependency as well, or if you just have no heat memory. So on small grade microcontrollers. You have only bare minimum resources, then you want to use the TSS system API, which is basically a mapping of C functions to TPM commands as specified in the TPM library specification. And if you don't have any bare minimum resources, well, then it is really rocket science to use the TPM. Now, actually, we would have shown you some live demo, but as usual, the demo broke just before the presentation. So it would have been on the Raspberry Pi. But now I'll explain it using the slides. So first of all, you want to install the TPM to hyphen TSS. This TSS features all libraries, which means the feature API, the enhanced system API and the system API. You can just visit your most favorite package manager and usually the TSS is already there. Great. And I think the FAPI is version 3.4 or 6. I'm sorry. You can look at the changelog. And of course, as with many applications, there is a config file, which you can found in the Etsy directory. The message here is the defaults are sane and secure, so you don't have to worry much about it. Basically, there are a bunch of paths where the key store is and where the log files are. You can also see the TCTI option here. That's pretty interesting because you can choose basically the TPM backend. So if you're using a TPM simulator, then you want to use this option. One little word about profiles because there's also an option for setting a profile. Basically, this specifies cryptographic details about your keys. And again, do not worry about it. If you're getting started, the defaults are very much secure and very sane. So, yeah, just leave it as it is. And if you're more advanced or if you have special use cases, you can always change it later. Now, a second word of advice when you're developing with the TSS, use your tools. And by saying tools, I mean the TPM to hyphen tools, which are bash, which are executables, which you can use in your shell. Basically, they're really great for debugging. I have two examples here on this slide. The first being TSS underscore provision. This basically creates the key store and creates some structures inside the TPM. And you have to call this one time only, and then the key store is there and everything is fine. And the second tool, which I probably call most often, is a TSS underscore list. This lists all your keys, policies, and V indices and so on. Basically, it lists everything of importance. And you can see there are multiple lines here. This, I beautified it a little bit so the new lines are added by me. Yeah. Now, this is a little feature API hello world example. So basically creating a key, signing and verifying. Creating a key is pretty simple. You need to specify a path. As you saw in the TSS underscore list slide, every object has a path. In this case, it's the profile, which you do not have to worry about it. And then HS, which means hierarchy for storage and then SRK, which is storage root key. This always stays the same. So just use it and then the name of your signing key. And the type, in this case, sign means it's a key for signing, obviously, and no DA means no protection against dictionary attacks. You can have as much trial and error when typing in your password as you want. Otherwise, the TPM will block you at, I think, the third guess or so. So for debugging, it makes sense. And then signing like self-explanatory, I think you need again the key path and can sign a digest, which in this case is generated using open SSL. And in this case, a public key is also exported by the same command just for convenience because we need the public key to verify the signature in the last step. Great. And I have basically the same example in C and do not worry. It's really not complex. Basically, every step is a function call. And you mostly need strings. So I think only the digest and the signature byte arrays, the rest of the strings. So do not worry. Just read the documentation and you're fine. So, yeah, and these lights are for reference. And of course, when you're using a key, you cannot type in your password always, but you want to use maybe more sophisticated mechanisms for protecting your keys or any TPM object. And that's where Peter comes in again. So, yeah, if you ever dig into the TPM to specification or any article about why TPM to so much superior than TPM wonder to the legacy thing, you probably came across enhanced utterizations. There's fine-grained access control mechanisms to TPM entities. So everything that's a key that's an NV index, something others stuff, everything, every object within a TPM can have this fine digit, finally great access control mechanisms attached to it. And that's the enhanced authorization thing. So, yes, authorizations are specified by using so-called policies. They described what steps need to be done to authorize the usage of this kind of entity. So if I want to use a key or an NV index, I have to, for example, specify my password. It's easy and for some policies, this is actually easy. But if you're doing more complex policies, then of course it involves invoking a lot of TPM to policy commands. You have to create a session, attach the policy to the session, create an object, and specify how that policy is created as a template. And then you make that policy active and all that stuff. So it's a really nice feature of the TPM, but of course a really complicated feature. And the more complicated your policies are, the more complicated it is to set up these enhanced authorizations. So people are really fancying this feature, but in practical use, it's currently not that well in the wild, so to say. But of course, we also have something for you there. Let's explain this in a little bit of an example here. Let's figure out an NV index. And the NV index is, the TPM provides a short, a small amount of memory where it can store arbitrary data and then lock it by these policies. And we create a really, really simple NV index, which can be read by everyone. But if you want to write it, you have to specify a password. So it's a little bit like the change mode 466, so you have to write a password. And just for the sake of explanation here. This really small policy, if you do it in ESAB, I think it's 25 function calls, and I do not want to write 25 function calls. And of course I have to set it up correctly and with every usage of the thing. I have to repeat this 25 function calls. With the introduction of the FAPI layer, things became much more easier. There you can actually specify your policy using a nice little language. But what's even more convenient than using a nice little language to specify a policy is of course a GUI to create your policies. And of course now it's demo time. I hope everything works. Let's see. So I have my little local desktop website. It's just an HTML file. Every policy of course needs a description. Nice description. And of course policy items. Since our policy has two branches, the NV Read and the NV Write, I have to specify a policy or all the policies can be combined using either and or combinations. If I use policy or of course it's an all combination which has two or more branches. So let's create the first branch. There of course I have to specify a nice little name. Let's call it NV Read. For NV Read. Nothing is needed. And I just specify the actual policy for NV Read, which is a policy command code. And there I select my command and we read. So first branch is already done. Let's go to the second branch. I just close this here at my second branch. And we write for NV Write. I have to specify password. So I apply this now to the command code and we write. Of course the list is usually much much longer but for the sake of the demo I shortened it a little bit. Also there are many more other policies command. So the first part of the policy is the command code and the second part of our policy is then the policy password. And here is my full JSON. So this is generated from what I entered on the left hand side of the editor and now I can put it into my system. Let's go to my Raspberry Pi, edit my JSON policy. I cheated a little bit of course to have that already in there. It's really not easy to read. You have everything on the slides. So don't worry about it. It's actually the same policy I just showed. And then I have to import that into my policy storage. Then I have to create my NV. So there the policy became affected for that newly created object. And if I want to write to it. I do not have to specify again the policy because that's attached to the object which I referred to here as the my NV test, which I gave here as a parameter as a path at creation of the object. Of course now it asks me what I want to write. I say, hello. And then of course it asks me what kind of policy I want to fulfill. The policy is evaluated within the TPM. That's why the stack has to ask me which policy branch the user wants to provide to the TPM, because otherwise, for example, I use the password. And if the TPM would try out everything or the stack would try out everything, then you would might be end up in the situation where I actually do a lot of false password autorizations because it was the wrong branch of the policy. So here we have this callback mechanism here. This can be overwritten in the TPM software stack. So you can provide your own callbacks here. But for the sake of here, we have this default handler here which asks you which branch I want to use. I use the NV write here. And then I have to authorize my object with the simple ABC password. And then I've written it. And if I want to read back, I do the same with the TS2 NV read command. I again the path and the output file. And then I select the other branch of my policy, which is the NV read. And if everything works, we get back our little nice string I stored within securely in the TPM. So for reading, I do not need to enter the password for writing. I need to use the password. And this was all possible using that nice little GUI editor. So policies are not that hard anymore. So you can actually use this really, really nice feature of enhanced autorizations. How was this possible? This was possible because the policy with introduction of the FAPI, the TCG has created a nice little policy language which is written in JSON. And you saw that little JSON, it's human readable. It can be imported into the FAPI. So this works quite well. And if you want to have more examples about existing policies, you can of course always go into our repository and see all these kind of policies we are using for testing the TSS stack. Because yes, of course, testing is a vital part of such an open source system, and we're doing extensive testing here. And that GUI editor of policies I just showed you is actually only possible because I wrote a schema against the JSON policy language so we can actually validate the policies you're writing in JSON. With that schema, you can just use that more or less open source standard GitHub JSON editor and provide that really nice click tool to create your own policies. Of course, this was just a really, really, really short and brief introduction of policies and NV indexes. If you're really interested in that topic and I really can recommend it on, I think it's Friday on 29th, Andreas Fuchs, our friend, our colleague from the TPM open source project here has really technical detailed talk about NV indexes and policies, what kind of fun you can all make with them and all that stuff. I can really recommend it. It's highly technical. He starts with all these nitty gritty details, but in the end he also resorts to our new GUI editor here. Back to you. Great. So Peter showed you how to protect your NV index, which is basically storage on the TPM. But this persistent storage in the TPM is very small. So you might want to encrypt your whole SSD or any of disk. So you might wonder if disk encryption is possible. And the answer is yes, of course. There is currently a pull request pending in crypto setup looks. Most of the work was done by Andreas Fuchs already. And after many discussions, the main one of the maintainers took over the efforts and created a known pull request which goes even further. So basically they built in or reworked their plug-in support. So now basically they said they don't want hardware dependencies in their code, which is quite understandable. And since the TPM is such a significant use case, they decided to make loading plugins really easy. This goes for shared libraries. Yeah, and I think also for the command line tool. Yeah, but you can look there. I think it's scheduled for the next major for the 2.4 release, which is the next release. Yeah, exactly. So if you cannot wait, then just use the code from the pull request. Yeah. And I've already also prepared a little sneak peek for you all. So there is a. So if you look into the pull request, there is a crit setup, a hyphen TPM tool, which you can use. This is not the whole man page, but a little sneak peek. So you can see there's really the software support is really going towards a place where everything is brighter and a TPM support is given. And to wrap it up, if you think the TPM is hard, well, you must unlearn what you have learned. Using the TPM is, in fact, really simple. And as Peter already said, maybe your application does already support TPM and you just don't know it. And if it does not use the feature API and the work is minimal, basically. And yeah, one little note about the TSS, which I did not mention yet. If you're developing for embedded platforms, there is now even a pull request in the TSS repository for basically plugging your SPI driver into the TSS. So basically you can set callbacks and basically make the TSS work on any platform. Yeah, so basically if you run the TSS on ESP32, there's a pull request for that. Yes. As always. And the documentation is really good. There's even a tutorial. How to use it. Sorry. So as you have seen, there are quite of many different ways how you can actually use leverage and access the TPM using the TPM to software stack. And what we're really hoping for that we gave a little bit of a feeling that it's really not that hard. And it is actually not that hard because there are these all these projects which are based on top of our stack and our tools and these providers. We are just naming a few here. Crypt setup looks was was already introduced by Johannes just a second ago. And there's also this one thing I want to mention here is the KeyLine project. The KeyLine project by Red Hat is about remote attestation and has just been recently being accepted as a cloud native computing framework platform project, which is a really nice achievement because it just shows how important this feature actually is. And a lot of people, if they read about TPMs, they read about remote attestation and that's a vital feature of a TPM or vital use case of a TPM. And if you want to have a real nice easy way how to do that, head over to the KeyLine.dev webpage and just follow the tutorials. It's plug and play and it's based on our open source software stack. So, yeah, it is actually possible and we are really looking forward for your application to also support TPM from the ground up. And we have this really nice community here, which is also of course there to help you. So, of course, no good presentation stops without having a ridiculous look into the future. I mean, it's the year of the Linux desktop, what can I say. So let me conclude with a look into the future. We just shown you that TPM is not rocket science anymore. Of course, it still has some hard parts, but for the 80% use cases we have solutions there and they can help you building TPM support into your project, into your programs and make the world a secure place. And maybe hopefully in five years time, we do not have to give the presentation anymore about that TPMs are not that hard. They're just there, they're used, they're built in everything. It's like TLS or HTTPS. Nobody talks about that my web server offers their HTTPS servers. It's just there and it works and it's secure and makes our life easier and more protected. And if you think about IoT and all that stuff, there are more and more devices coming up. And let's make them more secure. We have the basics laid out for you. And to make that vision happen, of course, we need your help for that. So basically, yeah, go on develop and help us with realizing that vision. But of course, help does not go only in one direction. Help goes in both direction. We have really nice community where we want to, where we also offer help to you. So basically, if you have any question, if you want to contribute, we have all these kinds of ways with interacting with us, maybe one or two, too many, I don't know, but we wanted to be as accessible as possible for you. So if you only have slack, then you slack. If you want to have browser based solution, use Gitter and if you're old school like me, then use mailing lists and IRC. And of course, there's this really nice tutorial page on the GitHub page. We are always looking for tutorials. So there are many ways you can really help us with our vision. And the last question is, of course, how can I really do it with my platform and this goes to Johannes. Yeah. The TPM is there probably in your laptop as well. The TPM is easy. Now, how do we start hacking? First of all, the TSS recognizes your TPM automatically. If you're not using the lowest system API like level, you do not worry about that. You can use, as I said, the TPM in your laptop or you can use a TPM simulator. And actually, there are a bunch of simulators. So there is a repository by Microsoft, which was repackaged by IBM. So there's the IBM simulator hosted on SourceForge. And there is also the simulator by Stefan Berger on GitHub, which is called SVTPM. The TSS supports both of them out of the box. So again, just install and you can go. If you don't want to use your own TPM for development because, you know, development in production systems, you can use a Raspberry Pi and a TPM to plug on top of your Raspberry Pi. You could either use the radium board here by Infineon or the Let's Trust TPM. Those are two examples. So let's just start hacking. Yeah, it just has to edit one line to enable it on Raspberry Pi. I'm really proud of that feature. So yeah, basically, let's start hacking. And if you have any questions, feel free to come up to us or write us an email, write us a chat, go on to GitHub, whatever we're available for you to make our vision ready. Thank you so much for your attention. Thank you.