I was involved with developing the specification from the start. My input takes the form of advice, rather than a narrative of my own personal experience.
The TPM specification combines the styles of both a user manual (Part 1) and a reference manual (Parts 2 and 3). If you have no prior experience with a TPM, or just TPM 1.2 experience, I recommend reading Part 1, or at least the sections relevant to your application. Even if you don't immediately grasp all its complexities, you will become familiar with the technical jargon and the TPM features and gain some sense of how they fit together.
Once you know what you want to do and have some sense of the command flow, Part 3 gives the details for each command. The description and command and response tables should be sufficient. Users in general won't have to read the code in Parts 3 and 4.
I anticipate that most users won't be constructing command streams. Middleware libraries such as a TPM Software Stack (TSS) normally perform those tasks. If you're writing or needing to debug through such middleware, Part 2 gives the details for each structure, with the names of the structure members, data types, and possible parameters. The platform-specific specification goes further, describing the parameters for a TPM implementation.
Part 4 describes, in C code, the details of TPM operation. Application and middleware developers should rarely have to refer to Part 4.
I was part of the development of TPM 1.2 and 2.0 from the start. I ramped up by first reading Part 3. It made perfect sense to me, except that it omitted anything about how to actually authorize a command. So for commands that did not require authorization, like TPM2_GetRandom, Part 3 told me everything I need to know: what parameters needed to go where, what size they were, and so on. The first parameter was a bit of a challenge until I realized that it was always likely to be NO_SESSIONS, because I wasn't going to be auditing the TPM2_GetRandom command. The parameters are described in detail in Part 2 and were mostly pretty easy to understand for commands that don't require authorization.
Next I dug into doing simple authorizations using the password session. This was nice because the password session always exists, and I didn't need to do any encryption/ decryption, salting, or auditing of the session. It was just a simple password, which was in the clear. Reading the section “Password Authorizations” in Part 1 explained these easily. I started by changing the basic passwords associated with taking ownership of the TPM.
Next I tackled creating a key. This was a more complicated task, because I needed to understand the unions for defining the algorithms and other parameters associated with the key I was creating. I started with a key that only had a password authorization (as opposed to a policy or HMAC authorization), because it was easier. Basically I created a storage root key (SRK) for the TPM.
Then I tackled policy authorizations. Because I wanted to create a signing key whose password I could change, I created keys locked to the password of an NV index. That meant I had to create an NV index; and I wanted one that couldn't be removed and re-created with a different password, which is what I did. See Chapter 14 later in this book for a description of how I did this.
I wanted to play with types of sessions, so I authorized a key using an HMAC. Then I audited the command. After successfully auditing, I used a decrypt session to pass in the password. Finally I used a salted HMAC session.
Next I did a more complicated policy, using TPM2_PolicyOr and TPM2_PolicyAuthorize.
At this point I felt like I had a pretty good handle on how things worked.
Other TPM 2.0 Specifications
Platform specifications augment the library specification to enable the creation of TPM definitions that are platform specific. They list what is mandatory, optional, or excluded; define minimum and maximum values; add initialization and provisioning requirements; and detail the physical interface.
You may need to reference the following platform-specific specifications:
• TCG PC Client Platform TPM Profile (PTP) Specification: Defines platform specifics for PCs and server platforms.
• TPM 2.0 Mobile Reference Architecture: “[D]efines a reference architecture for the implementation of a TPM in modern mobile platforms using a Protected Environment (section 7). This type of TPM is known as a TPM Mobile” (TPM 2.0 Mobile Reference Architecture).
Although the climb is steep, you can ramp up on TPM 2.0 much more efficiently with a good overview of the specification and some tips from early explorers. In this chapter we've shared our somewhat hard-earned expertise to assist you. The assimilation process has begun!
The next chapter describes the commonly available execution environments. It prepares you for the code examples that we present in later chapters.