 Welcome to our talk about the TPM software stack. We try to enable the TPM support or ecosystem on the Linux. Let's see what we're doing. So we are more covering the users-based side, not only the kernel side. What we will be talking about today is a little bit about the background. I think we can skip most of this, the design and the architecture of the TSS, the open source implementation, how we did get this to a successful open source project. And at the end we will show some TSS to use cases and examples of how we can actually use the TSS. Who are we? My name is Peter Huwe, nobody can pronounce that name, even German, so don't worry about this. At daytime I work at Infini and one of the major TPM vendors as a senior staff engineer, so I'm a developer firm that runs on the TPM. I used to be TPM subsystem maintainer until Chaco took over all the work. So thank you for that, Chaco. So that's why they retired this year and I'm a contributor to the TPM software stack as well. I'm Joshua Locke, I work in Intel's open source technology centre, I've been working on the TPM software stack for about six months and before that I was a long-time Yocto project contributor. Yeah, and our main presenter is missing today, which is more or less Philip Tricker. He gave the same talk about the TSS software stack at the Linux summit in North America, but in order to present you the same content we more or less stole his slides and put it into a new format to present it to you, maybe in a different format. Yeah, so thanks a lot to Phil for putting together the slide content. So if there are any errors, it's his mistake, if there are any errors, it's my mistake and if the slides are good, it's of course Phil's contribution there. So thanks a lot. So who here knows the TPM? Who has used the TPM? I think after the previous talk of Chaco, the most stuff was already covered. A few things I definitely want to say still, if you want to get more information about the TPM and how to use it and how it works and all that stuff, I would definitely not recommend reading the TPM library spec as your first thing to do. That's a 3,000 pages thing with additional specs and additional specs and additional specs and the ratas, so I would not really recommend it as a beginners lecture. Ariel has put up some really nice training materials. He has also written some nice book. Also something I really want to mention is the guys at Google did put up a TPM Java script implementation, which is not on this machine. I wanted to show it to you. Where they explain in an interactive tutorial how the TPM is made up, what the different components of a TPM are, how we can use that and all that stuff, so it's a really cool explanation thing that they put up on their website there or it's on GitHub, so you can even look at the source code. And the funny thing is they are actually using our TPM software stack here. And that's all web-based so you can just interact with it all through your browser and you don't have to install the stack or have a TPM or anything to start exploring it. Yeah, so it's really, really pretty cool, so a big shout out to the Google guys there. So if we are always talking about the TPM 2 software stack, I just want to make clear what we are talking about here. It's the TPM 2 software, TSS 2, which means TPM 2 software stack, as defined by the TZG. There are a lot of words for a simple TSS stack that's conforming to the TZG specifications. There are other stacks out there which might be conforming to the TZG spec or might not be conforming to the TZG stack. They all have their purpose, they all have their use cases, they are all good. Let the users decide what is the best. We present here the TZG one or the TZG compliant one as an open source implementation done by a lot of companies, which we'll talk about later. So how is this design coming up? As I already said, the TSS is based on the TZG specifications. So there is a big specification on how to write the TSS that's compliant to the TZG specifications. Inside of the TZG, the trusted computing group, there are so-called work groups. One work group exclusively working on the TSS design and the specification. And in order to come up with a good design of an API, you, of course, have to implement an API to see whether it's actually fitting to your use cases. And this is how this project came about, was more or less a reference implementation that was developed along with the specification by the TZG. So we could try out things in code and see whether it worked out or not. If they worked out, we could put it into the specification and vice versa. This has advantages and this also has disadvantages. If you have something you want to fundamentally change in your design, you have to change spec. So you cannot just simply develop in the void and say, hey, this is cool. You rather have to convince the other guys of the TZG that your idea is really cool and changes spec and spec changes are always not so fun. So the design goal of the TSS by the TZG is definitely a layered design with, provides a lot of abstraction. Of course, abstraction also means a little bit of complexity, but yeah. So it's more to, modernize that you have your transport layer completely different from your, separate from your APIs. So depending on how you use the APIs, you don't really see whether you are talking to a device, talking to a simulator, talking to the TPS on Windows. You have a lot of flexibility there. It also allows you both programming models. You can have synchronous calls or asynchronous calls. So you can do even event-driven programming. And it's also designed that way that a distro, the TZG or your vendor can impose some same defaults. But if you are an expert on TPM and know every detail and want to change something, you can easily change details. So it gives you a fine-grained control about how the TSS works. Also as with every good API or software stack, it's layered. So we really have a lower layer, which is more or less for people who are really into pain because it's more or less a one-on-one-to-one mapping of TPM commands to a C API. But you can use it on any kind of environment. So if you have a really constrained environment, you only need a libc and you can talk to the TPM if you want to. And on top of that, we add more and more layers to make it more and more easy for the users to write their applications. But of course, the more comfort you get, the more dependencies you pull into your system. So for the upper layers, you, for example, need to have a crypto library installed on your system, which might be hard on certain microcontrollers. This is the architecture design as defined by the TCG. It's more or less a simply rip off or out of the spec. Greg is again to Philip Tricker for pulling it out of the spec, so I did not even have to look it up into the spec, which is great. But it shows a little bit how the whole design is layered. At the bottom, we see the TPM device driver, which is not standardized by the TCG. So we can do whatever we want. It can be anything. It can be a simulator. It can be the dev TPM zero. It can be the TBS under Windows, or it can be something completely different. It's not really standardized there. On top of that, we have the TPM access broker and resource manager. That part is more or less standardized by the TCG. And it gives some flexibility around the limitations the TPM has. The TPM is a really resource constrained system. You have so and so many key slots, and if you want to have more than these keys available, somebody has to pull the key out, secure it securely, put in the new key in, and handle all that stuff for you. That is part of the access broker and resource manager. It currently lives partially in the kernel, and you can have, if you want, also a user space resource manager, which we will cover later. Then as I already mentioned, the transport layer is separated from everything else. This is the so-called TCTI, TPM command, transmission interface, TCG abbreviations are always interesting, but that's probably a part of every standardization organization. But it's a really cool feature that it definitely separates your transport layer from the upper API layers. And you can even stack these TCTI layers on top of each other, so whether you're talking to the access broker or directly to the device, you can stack these on top of each other. And then at the upper layer, we see here three APIs or API levels as specified by the TCG. On the left-hand side, we have the system API, which is really an expert layer, which is really only a mapping of, or one-to-one mapping of TPM commands to TSS commands. So if you want to do a TPM to get random, yeah, you call a TSS underscore sys underscore get random. So that's all it provides there. So it allows you to call TPM functionality from a C wrapper, but apart from that, it really does not do that much more. There's some housekeeping, but generally it's really an expert level API, but you have to have it in order to enable certain use cases. It's not dependent on any crypto, so if you want to do some HMAC session authentication, you have to do it yourself, which is, of course, painful. But if you don't have a crypto library, you might be glad. On top of that, there's the enhanced system API, which, as the name says, enhances the system API. It provides some comfort wrapper around it. It helps you to automatically encrypt, have your sessions encrypted. It keeps track of your sessions. You can easily exchange the TCTIs and all that stuff. But of course, there you start to have some malloc calls because it allocates some memory for you. You have the dependency on the crypto library. So it gets a little bit more heavier. And on the right-hand side, the gray box, gray because it's not yet ready, is the FAPI. F stands here not for future, but rather for feature. But it's still not ready yet. The TCT is currently in the process of standardizing this API level, which is a really high abstraction layer. So if my use case in SAPI is like three pages long, it's one page in SAPI, and in FAPI it would be like three lines. So that's the level you get there. But of course, it's not ready yet, so I think maybe in about one year, there will be some implementations or at least first drafts available. And as I said, this is the problem if you're working with the standardization body. You cannot simply implement something and say, hey, this is it, but rather you have to wait and work on the specification first in order to implement your code. It's a little bit tricky there, but yeah, we will get there eventually. And once we have feature API, I think it will be quite cool. If you Google for feature API, you will find a document. You will find a draft document, I guess, from 2014, but I would not recommend reading it because it is definitely stagland and super outdated. It will not bear any resemblance to the final feature API specification. So that's a word of warning. Yeah, how did we implement that? So we have the system API, again, expert level thing, one-to-one mapping of TPM commands. We use for this so-called libtsssys, system API, creative naming there, which more or less translates the C types to TPM commands and backwards. So it's really, really easy. You can use that on microcontrollers. We at Infineon have examples available for our XMC microcontrollers. If you want to fit that on Arduino, you can actually do that. We did that as a proof of concept. So the TSS can work on Arduino microcontroller, which is a really, really constrained environment because we have a few megabytes and not really much horsepower there. But you can attach a TPM to an Arduino if you want. In order to talk to the TPM, we also have the type marshalling layer. Therefore you have to know that the TPM sends more or less compressed or marshalled data over the wire. So in order to save some bytes here and there, they compress data structures and send it in a more or less compressed form over the wire. For much simpler use, we have the libtssmu, which translates these compressed data back into consumable C data structures. Then the Enhanced System API, which was added in about April this year, it's one of the bigger contributions to the TSS stack. In our case, as you can see, it builds on top of our SysLayer and the TPM-Mu. The TPM does not mandate that you are reusing your own code, but of course it makes sense to reuse lower layers, otherwise you would simply just reinvent the wheel. It also exposes all the TPM functionality, so nothing much changed here, but the big change there is that it takes care of your sessions and the encryption of the sessions. This is really, really helpful because you don't have to write a lot of boilerplate code again and again and again for each command. You simply say, I want to have that command open up a session first and then you just pass in a session handle for the rest of your application and the session is carried over from command to command and the sessions are encrypted, so you can have, there you are actually protected against the TPM Chinese stuff, so that's quite good there. But of course, again, as I said, you have to have a crypto library. Some crypto libraries have sane interfaces. Don't have a sane interface, so it's a really, really interesting topic to have the crypto library dependency there. And yeah, I'm really proud to say that this work was actually sponsored by my company and carried out by Fraunhofer. Fraunhofer is a research organization in Germany. They had their own TSS implementation already ready, their own proprietary, and we together with Intel talked to them and said, what can we do to open up your ISRP implementation and base it on to the Intel stack. And they said, yeah, pay us some money, so we did. And with that addition of the ISRP, more or less the usability of the TSS stack as we know it began, because with the ISRP, it's really a pain to write applications. I think Joshua can comment on that. With the ISRP, it gets really okay. It's not super easy. You still have to know a lot about the TPM, but it gets to a level where intermediate developer can do some really good stuff within a short amount of time. So this was also agreed by Intel and the open source community quite a lot that we added that ISRP layer, because if you currently want to write a TPM-aware application, please have a look at the lib TSS eases, not below, unless you are into pain. So yeah, and with the addition of the Fraunhofer stack, we also, the whole community thing started to kick off, but I will come to that later. So yeah, one of the lower layer pieces of the stack is the TCT implementation, which is effectively the IPC or transport layer, and it's nice that it's abstracted out in the spec, because it means that you can support TPMs that are remote devices, simulators. That's all abstracted away in your implementation. It's fairly, I think in open source circles, it's fairly standard that we have decent abstractions of different layers of the system, but in some proprietary stacks, that's not necessarily the way they're designed, so the spec sort of encourages that implementation, which is always good. We've got a reasonable amount of TCT and commentations in our TSS stack nowadays. We can talk straight to the device, we can talk to our access broker and resource manager. We've just had a contribution to our support for Windows TBS, which amazed me how easy it was to add that to our stack, which is really a complement to the way the spec's designed and the way the software stack has been implemented thus far. Facebook came along and dropped like a 650 line patch on the project, and now we can build our stack that was designed for Linux on Windows and use it against the TBS, which is approximately equivalent to our resource manager and access broker demon. So that's really great. We've also got a TCTI that's just being developed by Philip, who's been mentioned a few times, so that you can use the SAPI from inside a UEFI application. So the UEFI spec has some TPM functions. I think it's got like three or four ABI functions for interacting with a TPM, but it's fairly restricted, so this new TCTI enables you to use the full TSS inside UEFI, and it's probably one of the best use cases for something like the SAPI rather than using the ESAPI, which Peter was just talking about. So just on the topic of resource management, as has been mentioned, a few times a TPM is very resource constrained. It's small. It's got relatively little RAM. It doesn't have much space for non-volatile storage. So there's a requirement to do resource management, and the specification has these three functions for loading, saving, and flushing objects from the TPM. We have a user space implementation of a resource manager that can handle these tasks, but we are working with the kernel community to push more of that into the kernel proper so that we do resource management in the kernel. But the additional thing that this demon adds, which is part of the specification, is that it does access programming, so TPM has absolutely no notion of users or isolation of the objects that you're storing in the TPM. So this specification is for part of the software stack to implement some of the protections that we sort of expect in our standard most secure operating system environment. So that's probably always going to require a user space component, but the resource management's moving into the kernel, so if you've got a recent, I think it's like 414 maybe kernel, then you no longer need this demon component, this user space component, if you only want the resource management aspects, which is pretty good for some of the more lightweight use cases. For a general purpose operation system, Linux desktop, then you probably want to have the user space demon, because it introduces the access programming, but otherwise pushing more resource management into the kernel. Yeah, so let's have a look at how we got here. Because, yeah, when I first looked at the TSS project back then, referred to as the Intel TSS stack, it was a mess. And I talked to Philip, who then picked it up, I met him at one of the conferences here, he was sitting in the edge of the room and he told a little bit about his project and how he came about to it. More or less all the other formal maintainers of the stack left Intel at the same time, so there was nobody to ask, nobody to care, and one of his bosses came up to him and said, do you need a new task? And he said, yeah, choose one. He said that TSS stack looks nice, then his boss asked him, do you really want to have a look at that? And he said, yeah, I like it. So he really describes this as a really messy situation back then, and it actually was. If you look at the first commits back then, the implementation was not structured, it was not maintainable, it was really crappy to say. Not to blame, but yeah, it was not high quality. It was a single make-file-based project, so portability was really an issue. There were a lot of stuff in there that was simply not maintainable, and this was the first task Phil took up on. So he started to make it debuggable, to add some debug statements, to add a logging framework, to use the right tools. He chose for outer tools to do the configuring and all that stuff, so a little bit more of portability and also for packet management to get it into a maintainable shape. Of course, there were still a lot of places in the code where he said I would not touch this with a 10-foot pole, so his decision was to simply remove it and say okay, this is code I cannot maintain, I have to delete it and rewrite it. A big part there was the resource management daemon, so if you look at the previous implementation, there also used to be a resource management daemon, but he simply deleted it and said, I will not touch it, that's fundamentally broken, I will rewrite that from scratch. And funny-wise, it actually got him more or less into trouble at Intel because people were actually using that quite limited resource management daemon, but in the end he figured it out and got this new project working. So really the first thing, if you want, and here's the word of advice to other projects, if you want to turn your product or prototype or whatever you have into a real valuable and vibrating open source project, make it maintainable, make it debuggable, make it usable and make it packageable. Make it easy to contribute. Make it easy to contribute. So, yeah, this is exactly what he did because he, with the auto tools things and writing some wrapper scripts and make it bundling and doing correct shared libraries and all this stuff, the project is now more or less ready for pickup by distributions. It's easy to package the standard auto tools based package format and have some wrappers around it and within a few minutes you have your distro package ready, which is quite good. Also, we are using the semantic versioning scheme, so every major number stands for an API break, which we had recently with the 2.0 release. So, yes, make it clear what your version numberings are referring to, what they are expressing. With the semantic versioning scheme we really can recommend that you have the distributions to pick up your stuff and figure out whether any dependencies you are going to break with a new version. Also, when Philip took over the project, the testing was also a mess. No surprise here. It was a 3,000 line single executable which had a lot of test cases intermingled with each other, interdependent on each other. So, if you want to change the test case, everything broke. So, it was not maintainable and especially nobody else was able to add any tests to it. So, yes, it was a large job to convert all these single tests which were interdependent on each other into a real test framework where you have separate test cases who run independent of each other. We also added unit tests there with Simoka. He said I should advocate for it because he is a real fan. There's a learning curve but once you master it, it's a really nice addition there. And for the integration tests, we run it on CI. So, every build or every commit is run against Simulator using the Travis CI. So, every build is checked against the Simulator. We have a really nice code coverage. So, modern open source systems or open source projects are all about badges and statistics and all the stuff. And, yeah, if you add a cover of those things to your badge to read me MD, it gives the users and the distributors quite some confidentiality of how major your software is. We have a code coverage rating currently about over 85% which is quite good for an open source system, I think so. We have clarity static analysis checking we have scanned static analysis checking. So, we are doing all the high level quality measurements which we need or which we demand from such a base technology because if the stack would be flawed in some way it would be a threat. So, we are really pushing forward to have here high quality. And this is, if you are turning your own product into an open source project this is something where you should go to to make it really maintainable and build some confidence with your users. Yeah, and that's how we got it also up and running and that's also where you can find our stuff. We have to hurry up a little bit, sorry. Yeah, we are on GitHub and when the neutral name TPM2 software, so it's not the Intel stack anymore, it's not the Infinion stack, it's not the Fraunhofer stack but it's really the open source TPM, TSS2 software we have to come up with a nice name definitely. So, go there check it out. We have a lot of projects there. One of the latest addition was the PKSS11 engine which is still beta and don't have a full production, but please have a look at it and if you want to contribute we are more than happy for contributions. And you can really see that the community is not made up only by two companies. We have maintainers from Intel Fraunhofer and Red Hat and a lot of contributions from Infinion, Facebook, Alibaba, GE, Red Hat a lot of name dropping there but it shows it's not a single developer thing there it is really a community effort what we are building there is what my open source makes up and even having two different companies standing here and giving a joint presentation I think shows the value we see in that project. So, just a quick we see an increasing downstream reduction in distributions which is really good so the groundwork has been laid so that we can start to rely on this more in downstream software projects we just had a in June we had a major release to 2.0, it added compatibility with a recent GPM spec it added the ESAPI implementation which has made working with the stack a lot more a lot easier effectively and our 2.1 release in October added the Windows support which I mentioned so we've got Windows CI now we build our entire stack on Windows as well as Linux every time we have a commit and we see if there's any breakage and Windows changes relatively minimal it's really nice sort of impression of the stack effectively demonstrates that we're doing the right things I think so I think briefly talk about use cases and examples we're seeing we see quite a lot of times people build the stack and then they don't really know where to start the TPM is great it's a very versatile bit of kit but it's also quite a large abstract set of security primitives that it provides people don't always know what to do once they've started so we we looked at the core functionalities what a TPM is good at and we decided that the cryptography operations are something that we could help people sort of explore the TPM with a bit more there are things that a lot of software projects rely on already whereas the attestation is a lot more abstracts especially in the open source domain so we have a TPM2 tools project which are effectively command line tools that enable you to interact with the TPM software stack without having to write a bunch of code first we've got fairly close to a one-to-one mapping to the TPM2 commands implemented as executable UNIX programs so we can there are a really powerful tool for education and for prototyping so you can string together a bunch of TPM2 tools and prototype a TPM workflow and if you dial up the verbosity of the tools it will also spit out all of the commands that it's sending to the TPM and receiving back which is also really useful in terms of education and prototyping we've got a major release that we're working on right now where we've switched over to the new enhanced system API it's going to enable us to more readily implement some desirable features we're also focusing quite a bit on improving these of use because these are an educational and prototyping tool so we're looking at same defaults we're looking at unifying short options so instead of dash C meaning one thing in one tool a different thing in another we're trying to make the same thing in each tool we also have the ability to import and export objects in standard formats so here's a little example that I'm not going to step through just because we seem to be running out of time but Davide from Facebook gave a talk at FOSO in 2017 where he demonstrated the latest state of the tools and he had like an 11 line example where he was taking the TPM data structures that we were writing out to disk and using DD to extract the parts that he needed to compose a PEM file and stuff and there were lots of options required because none of the defaults there were no defaults effectively every option that the command exposed you had to define a value for so in the next release we've tightened things up a bit so it's seven commands instead of 11 to replicate that example I'm using full long option names instead of short option names so we've got all the defaults on the slide and I think we've made good progress and I think it's probably worse checking out so we have this an SSL engine that we've just started working on really it provides RSA decryptions, RSA signatures ECDSA signatures and it's really going to be once it becomes a little bit more stable and useful it's going to be really nice to see distro ship that and be able to start using TPM out of the box so I've replicated the same example from the tools with the open SSL engine so you can see that we can do effectively the same thing in five steps and what we're doing in both cases I probably should have mentioned is that we are signing we're hashing something with a certificate in the TPM and then verifying that it's valid with an open SSL so it demonstrates the interoperability of the components and then another new thing Peter just mentioned this is our latest addition to the family so to say it's the PKCS 11 provider based on the work by Ivan Timmer and developed it further with his permission current data is beta beta beta beta it has still a lot of bugs but it basically works with open SSL and P11 kits so you can use it but not for production please if you can try and use it and tell us which of your use cases don't work that would be great so any help wanted please please check it out and submit your patches we're more than welcoming patches there I think we're going to have to wrap up there so yeah maybe the last thing there there are a lot of projects already using our stack there maybe the thing that's most interesting is the crypto blocks thing where we're currently also working on to get the full disc encryption ready for for production use so you can actually have that bit locker use case you have on windows analytics system as well we're still working on that also strong swan as one of the leading IPsec VPN client things there and open connect us using our stuff so this comes to our last slide yeah last but one there's a little bit of detail about working with the stack but mostly you know we'd like some help if you've got downstream projects that you think could make use of the VPN the TPM come and talk to us and these are some areas that we think it would be useful valuable to our TPM support so the list is not inclusive you can add your product here and come talk to us so let's thank the speakers