In our latest blog covering the 25th anniversary of the TPM, we hear from TCG legends Dave Grawrock, Steve Hanna, Monty Wiseman and Dave Challener on the development of the standard and the challenges they had to overcome to bring it to fruition.

Conception
Dave Grawrock: So when we began work on the TPM – it was actually with the TCPA when it started – I was the Chair of the TPM Work Group. So I helped write the spec, and put all the words down! Not all of the ideas were mine, but I certainly did all the writing and leadership within the Work Group and we created the TPM. We then had to try to get people to understand it, and get people to actually try to use it. So it was kind of a fun time.

Steve Hanna: TCG has always been an organization where people bring in novel ideas, and we figure out how to put them into practice – how to make them into standards, how to implement those standards into products, and how to bring those products to market and get them widely deployed. When I first came to TCG, we were working on applications of the TPM. We understood it could be used for securing PCs, but what else could we do with that TPM? Then we realized that it could be used for securing any kind of thing.

Monty Wiseman: We wanted to build a very open environment where there were lots of proprietary solutions that offer similar use cases and solutions. We wanted to have something that any platform could use, including a Windows or Linux-based system, and something that would go cross-platform into networking equipment, servers and industrial systems. That was really the initial goal – to keep things from being proprietary. There were lots of other motivations, but to me, that was the most important, because I believe security should be open.

Dave Challener: Even then, mainframes had a security subsystem and would require one because they were used by banks. PCs were coming along and were being used for e-commerce, and sending your credit card details across the internet has never been safe. It needed to be encrypted if they were to be shared. You also had to protect your system against viruses. Ransomware attacks were actually already showing their head and so people were worried about these things. We needed something to add to our PC to make it more secure.

Challenges
Dave Challener: We were trying to solve all those problems with the TPM, or at least make it possible to solve those problems with the TPM… but we had a number of different challenges.

Dave Grawrock: First off, we didn’t know what we were building. So first you had to figure out how to build it, and what exactly we wanted to build. Then we had a bunch of problems with other companies and organizations, governments who weren’t sure how the thing was going to work. They were looking at the TPM going ‘well, you’re going to do bad things, so we don’t like it!’ So we had to spend a lot of time with outreach trying to get people to understand what we were really developing. The fearmongering that was going on wasn’t really true, and we had to break through that. Then, we had to get people to actually build it, put it on their platforms and start shipping it. Those were the early days of trying to get things to happen.

Monty Wiseman: The initial spec was designed to work with a single interface between the chipset CPU and the TPM, but we had five or six different vendors with five or six different interfaces. The real challenge was to converge them into one so that they all worked with a single interface talking back to the chipset. Trying to negotiate between all of these vendors – who were all competitors – and trying and successfully getting them to agree on a common set of interfaces between them, was the biggest challenge I had in the very early days.

Dave Challener: In terms of technical concerns, we had to work out how we could add time to the TPM. You can’t have a battery inside the TPM, so how do you associate an actual time with when a signature took place? This is important if you’re signing a contract: you need to know when it was signed. We also had limited amounts of non-volatile memory storage inside the TPM. We still do and that makes for oceanfront property we call it. There’s only a limited amount of it and so you have to be very careful with how you use it. So that was one of the big challenges and remains one of the challenges for the TPM.

Development
Monty Wiseman: We knew we’d need a common set of commands so that each one of these systems didn’t have to invent their own set of key management, their own set. We wanted to design an open system that anyone can use, and all the software would be portable across all of these different environments.

Dave Challener: I worked on a lot of different parts. I remember Dave Grawrock and I counting bits that we could store inside a single RSA encryption. I think we were down to three bits left over by the time we got done; we just barely managed to cram everything in. If we needed another byte of data we would not have been able to accomplish it! So he and I sat in front of a blackboard one evening and just counted bits until we could actually do it. That was a lot of fun.

Monty Wiseman: What was amazing was how cooperative everybody was, but we had to make some compromises; we had to do some things that people still look at and say, ‘why did you do it that way?’ Because in the early days, we didn’t have a choice.

Dave Challener:  We actually came up a way of overcoming the time issue by associating the timer with a real-time clock using signatures, as part of a fairly complicated process. But we got it to work.

Monty Wiseman: The TPM is designed to go on any type of platform. That initial platform was the PC Client, and we had to define how exactly it fit, and how the platform configuration registers (PCRs) are populated. The boot sequence – from the initial boot of a PC when you power it on up to the operating system – is actually fairly complex. There’s lots of different components, all coming from various vendors and sources, and we needed to make sure these would be used in some organized fashion, regardless of system design. Everything was reflected in the same set of registers, regardless of who it came from.

Dave Challener: You have to remember that people were actually putting hard drives through shredders to make sure that data was gone! But if all the data is encrypted, all you have to do is destroy the key. So we had opal drives or self-encrypting drives, and when somebody was done with it, we could sanitize it instead of either running a routine that would take hours to overwrite the thing seven times, or running it through the shredder. In an opal drive, you can tell the key to go away and all the data goes away with it in microseconds. Then the hard drive is sanitized – that is cool. It saves money in a way that people understand. We can now do a lot of other things with opal drives but that was the second thing I think that we started working on.

Monty Wiseman: The TPM is designed to go on any type of platform. That initial platform was the PC Client, and we had to define how exactly it fit, and how the platform configuration registers (PCRs) are populated. The boot sequence – from the initial boot of a PC when you power it on up to the operating system – is actually fairly complex. There’s lots of different components, all coming from various vendors and sources, and we needed to make sure these would be used in some organized fashion, regardless of system design. Everything was reflected in the same set of registers, regardless of who it came from.

Security – today and tomorrow
Steve Hanna: One way the TPM really hasn’t changed is that it’s still about taking cutting-edge technology from the research lab and putting it into practice, into standards, into products, and into the field. So if we look at some of the things that we’ve done in the last 25 years, we’ve taken that trusted computing concept and we’ve distilled it down into just its essence and put that in new standards like DICE.

Dave Grawrock: It’s fascinating because you’ve got people asking you, ‘have you done anything?’ And I can go, ‘well, every time you boot the platform, you’re using something I created or I helped create’. It’s really fun, and great to see how many people have used it.

Dave Challener: I really like the policy in TPM 2.0. In previous versions, we had multiple ways of authentication – changing passwords, tying things to PCR values – and it seemed like every object we had within the TPM used a different kind of authentication… which is a bit of a problem! It made it harder for a user writing programs to know how to actually authenticate a particular object they were working on. Now, with the TPM 2.0, we’ve found a way of making it all uniform. We’ve expanded the ways to authenticate – not just PCRs and passwords, but digital signatures that meant we could add in fingerprint readers, and GPS units. You can make a policy and then that’s how you authenticate that particular object. That’s pretty cool.

Steve Hanna: Now we’re moving to the next generation of technologies that are becoming practical, standardized and usable in the real world, not just in the lab. We’re taking the cutting-edge ideas like cyber resilience and the ability for systems to heal themselves like a biological system, even when under attack. I know that TCG will continue to take new ideas that haven’t even been conceptualized yet, and post those into practice.