 Alright, our next talk is TPM, the explosion. Our speaker is Daniel, he's very much a software enthusiast and a software developer. He is involved with operating system development and in particular with various distributions and will tell us how the different TPM ideas increased in the last 20 years, how it gained more complexity and basically what this ad was about this year for the Windows 11 start. Thank you Daniel and welcome. Thank you for the quick introduction. So you might have seen me before, I have talked about a few other related topics to TPM. If you are not familiar with that term I will be given a bit of an explanation later on here. I also talked about something called ME or management engine, controversial topic that is something from Intel and today we're going to also reference a few vendors here and companies that you may know very well and I'm trying to be as neutral as possible here really just evaluating from outside. So the agenda for today I will give a bit of an introduction to what the topic actually is and what I'm going to cover. We're going to look at the history of the so-called TPM and then we will see what the development of the specifications looked like because it wasn't just one thing invented at one point in time but it's being revised over and over and then we will see about standardization and about projects all around the TPM and eventually come to a bit of a discussion also involving Windows 11 which is how many people get to know the term TPM after all. So just to introduce me very quickly even though we had a small introduction already as I have very many different backgrounds and I'm also involved in very many different fields. One of the strong ones currently being firmware development and that's where I also run into TPMs and not just because of the Windows 11 topic but also because friends of mine are involved with the development around TPMs and firmware I started to look into that and I even did so years ago. So I found a book it's called a practical guide to TPM 2.0 and it's giving us a bit of a problem statement which I'm going to cite here and saying that hardware security is not an easy topic to begin with which I frankly agree with and it doesn't help to have a specification that is hard to understand. A good starting place to understand the technology is the history of its development. But let's look at the current state first and then go back in time. This is a report from Microsoft from this very year stating that more than 80% of enterprises have experienced at least one firmware attack in the past two years and how TPMs are related with firmware at large is something we're going to look a bit into in detail later. So let's see about the history and first let's see what actually is a TPM now. There is a definition or a bit of a vague definition actually given in that book that I already touched a bit and they're saying a trusted platform module that's what it's short for also known as a TPM is a cryptographic co-processor that is present on most commercial PCs and servers. Now the problem is we're defining something but many people don't really know most of these terms which are being introduced at the same time here. One of them being a platform, one being trusted. What does it mean specifically? It's something that we talk about sometimes when we talk about people and how they are in a relationship with each other. Trust is a very strong statement about the relationship. And now we're talking about processors and even co-processors here. We're talking about cryptography and those are all very, very large topics for themselves. I don't want to go too much into detail but please be aware that everything we're talking about here is not really easily defined just as the statement we had before. So I tried to find a more general description and that's also what I put in the abstract. The general idea of a TPM is to have an isolated or constrained environment to offload trust establishment in a larger computing environment. I'm not exactly sure if that's even more or less understandable but I'm trying to be a bit more general here. So we're talking about isolation, that's one concept and we're talking about constraints and keep that in mind for everything that is coming now. Now, people may say, well, this is something that we have also heard but as a bit of a different concept or maybe an overlapping concept in a way. So still having the same idea here, we're talking about something people call a trusted execution environment, an environment that is specifically made for computations which are sensitive, an environment where you could store something like key material for example for encryption and there are many more different use cases. So these are the two concepts, TPM and TEE. The TPM there is an image here in the left hand side that you can also find on Wikipedia that is basically like a high level perspective on TPMs and their main functionalities. It's talking about the cryptography as we already saw in the previous definition, the processor. So people may know processors mainly from just doing computations. The so-called CPU that you have in most machines which is really just doing computations but this here is a more special purpose processor. So it's not about general computations but it's really tailored towards cryptography so it knows very specific things like random number generation for example which is a very very important thing in cryptography. As I already said it's also made for storing key material that is in the so-called persistent memory here. Sometimes you also hear a slightly different term that's called NV nonvolatile memory but it's basically the same thing. So the idea is that you can store information. And the third one is the versatile memory and that's something which is giving us lots of new opportunities which we're going to touch a bit later on. Now there are many implementations of the so-called TPM which are in actual hardware but there are also other implementations as part of a so-called trusted execution environment. There is implementations from AMD and Intel which are what most people know from the processors in their machines but there is also something from ARM that you mainly see in phones but it's also coming in other places now. There is now a new ISA called Risk 5. If you haven't heard about it never mind right now but what I'm saying is that the concept is being transferred and it's across platforms. So now let's come back to the definition of a TPM and let's find a new one. I hope this one is slightly better. So I'm now saying that a TPM is a hardware security module and now I'm emphasizing hardware a bit and it's designed for providing an environment for trusted computing. But of course there are some remarks here because hardware can also be emulated and so can a TPM and it can even be simulated. So if you want to play around with one there is some implementation from Google that you can test in your web browser just to get an understanding of the concept behind it, click around and so on. Okay but that's not the history. Where did we come from? Even before this day, like 30 years ago or even earlier, we already had some co-processors in the IBM mainframes. They already had very interesting ideas around computing back then and they were mainly focused on business. So if you know the abbreviation, I think IBM was actually a short for international business machines. So they were selling hardware for computation and it was meant for different customers and they also had to think about trust establishment at that point. And then there were also the so-called smart cards. That's what many people have in their hands these days be it for public transport like in this image here for example. But it can also be for different other purposes like authentication at a machine. It can be the card that you use for banking and so on. And that brings us to an interesting topic and that's safety. And the safety question is often something like is it safe to enter a password on a given machine here? Like this laptop that I have right before me, it is my own laptop. I usually keep my eyes on it. So I can pretty much assume that it's a safe device to enter my credentials into like when I browse the web, I go to some website I need to log in. I enter a password. But how can I be sure that there is not something extra in my hardware or in my operating system or even below my operating system between the hardware and the operating system that is sniffing the passwords that I'm entering? So we need to look at all the different layers. We have applications like web browsers for example. We have very good protection measures for those. We have malware scanners. We can sign applications so that we know that we can trust them. We have the operating system secured pretty much. There are different kernel protection mechanisms and all the major operating systems at this point in time. But there could be more protection from firmware and that is part of what a TPM can cover. The firmware itself, again, is actually also just software, right? So that can be protected again by a lower level and that would be the hardware level and that's the hardest one. So hardware is something that is not very easy to change. You can throw out a laptop and get a new one but it's for most people quite expensive. There have been cases already and it's been shown a few times where people were able to put something in hardware called an implant, which was not easy to detect. Of course, it's also not easy to do either, so it's not something that everyone could just do right away. But it's definitely possible. So here's the big problem. What we can do is we can make devices very, very secure. But the problem is we have general purpose devices and they're meant to be connected to each other, like through the internet, where basically everyone is connected and all the devices. We have the plugability so we can put add-ons on the machines that we have. Like extra graphics cards, for example. We can customize the machines, we can change settings. And we have the extensibility, so basically we can write our own applications or download and install applications and stuff like that. So we're talking about something that is very, very volatile by nature. And well, there was this piece of news, I think it was also this year, where there was a mouse driver that was capable of giving you root access or administrator access as it's called on Windows. Well, we had all the measures here, right? So the driver was probably signed by Microsoft. So it was installed, it was trusted. The operating itself, the operating system itself seemed all okay. But yeah, that wasn't really everything. So there can still be loopholes everywhere. Now this is a sort of software bug that we're not going to cover here. But always be aware that every extension, every modification that we do to machines can make them insecure again. But what is a platform anyway? This image here is coming from a specification that we're going to look a bit closer. So yeah, so the TCG is looking at a motherboard. So that's what we see here in the picture zoomed in, where you have many different hardware components. There are so-called embedded devices, that's the different controllers that you have directly on the board, which are talking to other peripherals. There is a USB controller, for example. There is the user output and input. Of course, like we have mouse and keyboard and so on. And then you have the processor or processors, if you will, because there can be very many of them. And that is where the firmware is stored and where the TPM is actually part of the surface now. So the TPM can be just alongside the CPUs we saw in an earlier definition, a co-processor, that can also be connected somehow from the outside. So the TCG, the trusted computing group, that's what it's short for. They're publishing standards and specifications for a secure computing. And they're actually the ones who define the so-called TPM. So be aware that it's actually more of a product name or marketing term, if you will, it's not something that is too formal. It's formal, of course, as an industry thing. And now let's refresh the security goals again, because when we talk about security, we talk about very many different applications. One core thing is confidentiality, so we want to keep data secure from other people looking at it. We want integrity. That means that we don't want people to be able to manipulate data without being detected, and we want authenticity. So we want to be able to validate the data indeed comes from the source it's claiming to come from. And that's what all those specifications and a lot of insecurity is basically based on. So that was the first iteration. When you see this fancy number here, the TPM 1.1B, it's at 1.0, but you can already see some nuance here, right? So it wasn't really like done in a day or something, but it was conceptualized over time and revised and reviewed again. And they came up with the first features. One of them is so-called PCRs, platform configuration registers. A bit of an elaboration will be falling later. Device health attestation, that means you can verify that a device is indeed in its secure state as you want it to be. They established a PKA, a public key infrastructure. That means that you have multiple parties being involved so that you can do verification on different layers and also authentication. It was supposed to prevent, well, not from physical attacks that was left to manufacturers, but it was meant to protect data in general. So it was widely deployed at some point in 2005. Remember this year for the next slides. There were some issues with that. One of them was the API wasn't really 100% specified, so there were different implementations and they were not really compatible with each other. The pinouts for the hardware were also slightly different from vendor to vendor. Keep that in mind also. You could, well, just root for is a key password. So the problem is we still need to rely on some easy mechanisms for people to unlock things like keys and so on. So that's where we use passwords, but that's something that can always make a system very insecure, very easily. Like when people use fancy, simple passwords like, well, just password is the password, for example. There were privacy issues, so keys were not necessarily anonymous. There were endorsement keys. They are part of the concept of device health. And well, they put them on external storages. And the problem is if you do that in a large company where there is IT administrators who buy lots of machines, usually they will just wipe the hard drives and install a new operating system and so on. But that hard drive they had, well, it was storing the keys, so they actually lost the key here. So they had to learn how to not do that. And there was a dual ownership issue. So these IT admins were one party administering a machine and there was then the actual user, so someone in a company like a secretary, for example. Okay, so that was a bit of an entertainment. And that's one thing that people in security always keep in mind. The solutions that we come up with, they are never complete. They always work in progress just by nature because we always find new issues. So they came up with something new. TPM 1.2 brought a lot of improvements. The software interface was now standardized. So now we could actually have something like compatibility in software, right? There was mostly a standard package pinout, so if you remember the previous one, we're still not 100% compatible here, right? So you can use two different TPMs from different vendors and they will have different pins on hardware. The dictionary attack problem, so guessing passwords, that was solved a bit. It was improved, but it wasn't really solved yet. And then there were a lot of other new improvements and I'm going to skip a bit through here now. The release was in 2005, back then when TPM 1.1B was established. But 2005 also brought some other news. The SHA-1 algorithm that was used for hashing was then already facing its first attacks. Now the problem is in this specification, well, we have a fixed algorithm, which is already not a good choice, but back then we didn't really have much to choose from. Okay, so people had to come up with new concepts. Here is an example image that's one of the TPM 1.2 chips that I found on one of my machines. And I bought it used, I think it was from about 10 years ago. So yeah, we're still a bit stuck with that. You can still buy machines today with these sort of chips. Now the next big step was TPM 2.0. There came new solutions. And one key thing was flexibility with the algorithm. So in cryptography, what you can now do on TPMs is you can use different hash algorithms, but you can also use different algorithms for the actual computations. So previously there was just RSA, and now you could also use other ones. So the other key idea was to have a compilable specification. And that's why Microsoft took the opportunity to write an emulator at the same time. So if in doubt, you could always look at the emulator as a reference implementation if something was ambiguous in the specs. There were now multiple key hierarchies. So they were also growing over time so the TPM could have more and more purposes. Okay, so there is this reference implementation also from Microsoft that you can still find on GitHub today and that is still being maintained. Great, now we have a specification. We talked about the so-called platform configuration registers. And this graphic here is again coming from the specification documents. Those registers are being connected to the different components that we have in firmware and also in part the hardware. So at some point the hardware is starting a machine, right? It's loading its first programs and executing them. That's what we usually call the firmware. And there are so many components in this firmware that we can, well, at best do something like hashing each and every piece and storing some information. And that is what the platform configuration registers are for. So these different components are stored, well, they are hashing then the hashes are being stored in different registers. Some are in the same register and you may now wonder how there is something you can say like an update mechanism. So you can store multiple hashes in the same register and then eventually read them back from a log. Now because this is a bit hard to understand, there is also a table also in the specifications which is listing the components and the specific register they belong to. And what you can also see here is a strong relationship with the idea of UEFI which is a firmware interface standard. That has also been developed over the years and also being revised over time. And it's also still an active development by the UEFI forum. So the relationship is as follows or one relationship is as follows. In TPMs, we have the so-called PCRs that we just saw that's where we store the hashes of the platform state that's where we basically store the current health state. And in UEFI, there is something called the platform configuration database. That's where the settings are being stored. Like when you enter a firmware menu on your machine, then you have different settings that you can change there that is stored inside database. And that can influence the boot flow, right? So that's where the PCRs may change over time. Okay, great. Now we have a specification but a specification is really just a start. You also need to standardize on top of that. There are different projects. So one thing to look at is the boot flow that I already teased a bit. And the boot flow is basically like this. There is some root component that starts and it's loading the next one, executing that, loading the next one, executing that and so on. And if you're implemented properly with a TPM, then you would do the very same step for the whole chain. Each component will always take a hash of the next component stored in the TPM and then hand over the computation and the chain will continue until you end up in the operating system. So around this boot integrity, there are lots of additional specifications now on top of the simple TPM specification. And all of that is also coming from TCG, the trusted computing group. And it's still being extended over time. So if you look at the link here, for example, February 20th, that's 2020 this year, when this variant of the client platform firmware integrity measurement specification came out. Okay, it's a bit of a big term. Anyway, it comprises basically all the different parts of the firmware boot flow. And it's being split up again into several other sub-manuals, if you will. Okay, that's great. There are lots of more specifications and standards now. And now other parties are looking at that. One of them is being governments in larger institutes like the National Institute for Standards and Technology. They release a special publication. It's called the Platform Firm Resiliency Guidelines. Those guidelines are all around the boot flow. They're meant to define how you can actually secure what people know as BIOS or what is implemented in UEFI these days. There is a reference implementation from NSA, or, well, let's say something to get you started with. It's called HIRS, the host integrity at runtime and startup tool. That is also something to look into. It gives you the idea of validation policies. We have hardware. There is an attempt being made by LPN Plant. They're trying to make a universal TPM because as stupid as it sounds, even these days we don't have a standardized hardware interface, even with TPM 2.0, you can still, you know, you can buy a motherboard from, let's say, ASUS, and then you want to put a TPM on it, let's say from MSI. If it won't fit, we'll have a different pinout and it may even be a different pitch, so it can be like two and whatever, 2.5 millimeters. So what LPN Plant is doing, they're documenting and they're putting out an open source implementation and they're also selling hardware along with that. There is the OpenTitan project. That's also a security processor and that's being made at Google. In cooperation with a company called Low Risk. That's an open source hardware implementation of a so-called root of trust. That's a term that you may also hear very often with TPMs. Just means that that's where you establish your boot chain security, basically. There are command line interfaces and different libraries. Very public and well-known is the TPM 2.0 tools. That's what many people are using currently. And then there is also other implementations like Nine Elements Cyber Security's TPM tool. That's something I also started to look into and they also made a larger suite called the Converged Security Suite. Okay, I thought these were great tools. And if you remember my introduction from last year, I'm working on firmware tooling. So what I wanted to do is I wanted to be able to display what the TPM is actually doing. And so I made a log viewer. This can now show you what happened during the boot flow. The command line interfaces can do the same thing but I want to go a bit beyond that. And one thing that you can already see here is coming from a TPM 2.0. So you can have different hashes from different hash algorithms. In this case here, it's SHA-1 and SHA-256. Okay, another project of mine that I just vaguely started so far. Microsoft has a hypervisor called Hyper-V. So I'm starting Project HyperX. I'm taking the firmware for that hypervisor. I'm trying to emulate that in QMU. And if you look at the screenshot here, it didn't really work well at the first time. So yeah, it just errored somewhere. And now the question is, so can I do something to be really able to emulate that in the QMU emulator? And does it actually want to talk to some sort of TPM on the host machine? If anyone's interested, please feel free to contact me and let's have a look at that. Now let's conclude a bit with a discussion. So there is one issue that is management. The management issue is the following. If you are administrating lots of machines in a large company, like an enterprise with, I don't know, 1,000 people in a building, 1,000 people in another building, and so on, and all your flots of TPMs deployed along, and what you want to be able to is, you want to be able to keep things updated. Now there will always be issues like these here, where an issue is not just in the software or the operating system that is updated through the regular routines, but actually in the firmware. There was one issue that was with, I think it was Surface Laptops. The issue was called Card Blanche. Well, they forgot to implement the hashing, so, or well, at least in a bunch of places. So when the machine was booting up, in that case, the measurements that were supposed to be made were not, right? So that gave us room for being able to compromise those machines in a way. Now there is a write up on that and I put the link here to archive work just in case things may get lost from the original place. There was another issue that was with TPMs made by Infineon, and they were having a bit of an issue in the key generator. Roka here, that's for return of Coppersmith attack, famous mathematician who also did a lot in crypto. Well, the issue here is if you have only a key size that is, well, half of the desired key size, well, then frankly, you are able to restore the entire key. That's like the brief summary. But it's an issue that was still in software, well, in this case, firmware, so it could still be fixed. But be aware, if you need to manage machines, then these are the sorts of issues you need to be able to deal with. There are some solutions to some shortcomings. So if you have a real hardware issue and you cannot do anything but swap out the module, be aware, there is something in the hardware that is called the so-called maskrom that is like hard-coded programs, which are really part of the actual hardware module. You can't get rid of those, they are just fixed. So in that case, if you have pin compatibility, if you can swap out the module, you win. If you don't have these properties, well, bad luck. Another thing is availability. So for cryptography keys, it's always important not to just have the data and the keys somewhere, but also to have a backup of those keys. And the more you have those keys stored in a hidden place like in firmware or in a hardware module, then the harder it is to recover those. So the best thing to do is to have a backup. And that backup has to be, well, at least the same level of security as the original copy. If you make it less secure, if you, for example, don't encrypt your backup at all, then you're not winning much because a potential attacker would just take the unencrypted backup, right? So those are things to be kept in mind. And that's when Microsoft said, okay, we want to mandate all of these things for the Windows 11 operating system. They wanted to have all the features that we got through TPM 2.0, and they even released a very nice and funny video about that. The screenshot here is from said very video. They were basically explaining also a lot of these things that I just explained here, but the news came. So the question was, of course, why did we actually have this mandate now out of a sudden for like every installation of Windows 11? Well, the operating system does need a trust anchor. We already said that, well, if you don't have it at runtime, if the operating system cannot rely on the firmware, then, well, you are missing the protection from the lower layers, right? So in that sense, it makes a lot of sense, and we don't actually need to discuss anything here. We already said that as a precondition. Now, the thing is as widely deployed as TPM 2.0, maybe not everyone does have it. So some people like in the photo I showed earlier still have an older one, a TPM 1.2. They are still able to opt out, right? So they can choose during the installation of Windows 11, they can set some registry key, and well, then they can still install the operating system, but still Microsoft is suggesting very strongly to have the TPM 2.0 module to back you up. And I would, well, recommend the same thing from my side as well. And even if you're using other operating systems, it's still a very good idea. Now the issue is it's still a bit of a young field. So maybe this also gives you some motivation to look further into it, especially if you are also interested in firmware and low level stuff. And eventually there is this bit of a discussion of who can actually trust the TPM and the TEE because it can have many, many different parties relying on it. We already talked a lot about the operating system and we talked about applications, right? We talked about users and all people operating in the machines, but there are also other parties. For example, if you want to watch a video and it's protected by something called DRM, then well, the owner of that does not want you to be able to copy what you're seeing. They only want to allow you to see it maybe only once even. That is something that can also be backed by a TPM or a trusted execution environment. Then in the online gaming world, anti-cheat can also be backed by these implementations, especially the trusted execution environment, as well as vendor secrets. So for example, in a camera firmware these days, the firmware itself might be encrypted and it might rely on a trusted execution environment to only unlock for very specific computations and do so without anyone able to interfere. So yeah, there are quite some problems. There is a lot of marketing involved here and there are lots of close components that we cannot really look at. Those are things that are being found over time and because there is a lot of confusion around this, I hope I could give a bit of an insight with this talk here. And well, eventually I want to conclude. I want to show you a bit, well, a bit of a rundown. So, how is firmware made anyway? There are many parties involved. So it's not like the components are closed, but there are many, many different parties implementing things. There is the manufacturers of the machines, there is the manufacturers of the operating systems and all the different parts and components that are also part of the machines that can be involved here. And well, some of them can even be just unknown third parties that you never would actively run into. On the dashero.com website, there is also a bit of an introduction to that. Now, at this point I want to stop here. Here are some references in addition, some advanced topics. If you look at the slides again later on, you can skim through and watch these websites here a bit more closely. Some of them are around practicalities and possible issues that have been found. And now I would like to open the room for a few questions if there are any. Indeed, there are two questions from the RSC network. Well, the first one is, how do these chips communicate with the processor? Is that ITC, is it SPI, JTAG, or something proprietary that's used here? Yep, okay, so yeah, JTAG is actually meant for testing and debugging. So that's hopefully not what any company is using as an interface here. So there are different implementations. Some are using the SPI interface. That is a current trend, I would say. Some are based on I-squared C and the other ones were using the LPC interface, the low pin count bus. But that's only for the dedicated hardware. So if you have a coprocessor that is part of the package, it might be a totally different proprietary bus, which I don't officially know about or cannot tell you about. Thank you. The second question is, is there an operating system API that an application could use, for instance, to create a use and RSA key pair? Yes, so I already mentioned a few tools, the command line tools, TPM tools too, for example, and also TPM tool. I strongly suggest looking into those and there are also libraries written in Golang, which are also able to do this. Thanks a lot and thank you very much for your talk. Yeah, thank you a lot for having me. And if you had issues following the stream, you can also follow the stream on either Twitch or YouTube, if these happen to be more stable at wherever you're located. The next talk on this stage will be in German, the OM Krisenmodus. What does that mean for the future? Thanks again, Daniel. Thank you. And with that, thanks a lot. I'll see you guys in the next one. Bye.