Trusted Platform Module (TPM) versions 1.2 vs 2.0 and header number of pins

I am trying to understand the TPM header on a motherboard I have, which is an Asrock "H170m Pro4" It has a TPMS1 header on the motherboard, and it has 9x2 pins with 1 missing.

In searching the web, I see a 14-1 pin TPM module, other references to 20 pins. what's the deal?

here is a link to the manufacturer's site for the specific mobo I am trying to get a TPM chip for. You can download the manual from here: https://www.asrock.com/mb/Intel/H170M%20Pro4/

in H170M Pro4.pdf on pages 6 & 7 it shows the TPMS1 header location and on page 22 it states 17 pin TPMS1 and what each pin does

1. PCICLK bottom row left most
2. FRAME bottom row going right
3. PCIRST#
4. LAD3
5. +3v
6. LAD0
7. no pin
8. +3VSB
9. GND bottom row right most
10. GND top row left most
11. SMB_CLK_MAIN
12. SMB_DATA_MAIN
13. LAD2
14. LAD1
15. GND
16. S_WRDWN# this is above the empty pin #7
17. SERIRQ
18. GND top row right most

what concerns and confuses me is the use of TPMS1 and here at their site https://www.asrock.com/mb/spec/card.asp?Model=TPM-S%20Module referring to these 3 things:

• TPM-S module (V 1.2)
• TPM-s module (V 2.0)
• TPM2-S module (V 2.0)

can anyone make sense of this?

TL;DR: This is a trash pile and there's no good answer.

As there's no good answer, I'll at least address some nuance around the question: what's the deal?

My apologies as it's not the answer to the question (I believe) you intended (i.e. Based on the promises of the TPM... that is purchasing the device that I want from the manufacturer that I prefer based on their security stance and implemented functionality, what is the pin-out of the motherboard so that I can hook up the TPM I desire to the board).

Alas, I can address this question but (as mentioned) this will do much more to cover the meta concern: "what's the deal?"

TPM Background

To catch up future readers as to what this post is even about let's cover the basics:

First and foremost, the Trusted Platform Module (aka TPM) is an implementation of a specification created and maintained by the Trusted Computing Group.

The TPM's purpose is to act as a secondary computing device to execute certain operations completely independently of the main processor. The communications between the main processor and the TPM generally occur over a Low Pin Count (LPC) interface or (more recently) Serial Peripheral Interface¹ (SPI).

There are two primary versions of the specification 1.2 and 2.0. The 2.0 specification was (more or less a re-write from the ground up²).

Within the 2.0 specification there are four defined areas:

1. Architecture:

TPM 2.0 Part 1 contains a narrative description of the properties, functions, and methods of a TPM. Unless otherwise noted, this narrative description is informative. TPM 2.0 Part 1 contains descriptions of some of the data manipulation routines that are used by this specification. The normative behavior for these routines is in C code in TPM 2.0 Part 3 and TPM 2.0 Part 4. Algorithms and processes described in this TPM 2.0 Part 1 may be made normative by reference from TPM 2.0 Part 2, TPM 2.0 Part 3, or TPM 2.0 Part 4. 2. Structures -

TPM 2.0 Part 2 contains a normative description of the constants, data types, structures, and unions for the TPM interface. Unless otherwise noted: (1) all tables and C code in TPM 2.0 Part 2 are normative, and (2) normative content in TPM 2.0 Part 2 takes precedence over any other part of this specification.

3. Commands -

TPM 2.0 Part 3 contains: (1) a normative description of commands, (2) tables describing the command and response formats, and (3) C code that illustrates the actions performed by a TPM. Within TPM 2.0 Part 3, command and response tables have the highest precedence, followed by the C code, followed by the narrative description of the command. TPM 2.0 Part 3 is subordinate to TPM 2.0 Part 2. A TPM need not be implemented using the C code in TPM 2.0 Part 3. However, any implementation should provide equivalent or, in most cases, identical results as observed at the TPM interface or demonstrated through evaluation. 4. Supporting Routines -

TPM 2.0 Part 4 presents C code that describes the algorithms and methods used by the command code in TPM 2.0 Part 3. The code in TPM 2.0 Part 4 augments Parts 2 and 3 to provide a complete description of a TPM, including the supporting framework for the code that performs the command actions. Any TPM 2.0 Part 4 code may be replaced by code that provides similar results when interfacing to the action code in TPM 2.0 Part 3. The behavior of TPM 2.0 Part 4 code not included in an annex is normative, as observed at the interfaces with TPM 2.0 Part 3 code. Code in an annex is provided for completeness, that is, to allow a full implementation of the specification.

Mentally, I prefer to juxtapose these to the four main aspects to a functioning TPM³:

The software running on the main CPU which will use the TPM (e.g. Bitlocker, OpenSwan, etc)

The platform which desires to consume the functionality implemented by a TPM (this is generally the intellectual property developed or licensed by a manufacturer). Often times this is more of an interface between the main CPU and the TPM itself.

The integrated circuit providing the embedded system which implements the required hardware to satisfy the architecture in TPM 2.0 Part 1 (e.g. the Optiga line of system on chip devices from Infineon or similar devices from ST or Nuvoton.

Finally, the firmware running on the integrated circuit. As of 2020, this is normally the "TSS" (TPM2 Software Stack). This can be libre/open source (as is the case with the reference implementation TrouSerS as well as TPM2-TSS and Microsoft's TSS.MSR) or proprietary implementations.

So what IS the deal?

::sigh:: In the best case scenario we're left with pseudo standards. With TPM 1.2 devices many vendors implemented a 20 pin (19 pins with 1 keying pin) or 14 pin (13 pins with 1 keying pin) connector. The choice of how to implement this was left up to a combination of the "platform" vendor (e.g. MSI, Asus, SuperMicro, etc) and the implementer of the TPM hardware (see the list above).

This level of choice was maintained with the implementation of TPM 2.0, with the addition that as the security of platforms becomes more important and there are more technologists with experience (and opinions) about how a TPM should be used there is a growing amount of variation.

Let's look at the document "TPM 2.0: A brief introduction" published by the Trusted Computing Group. In this document the author calls out:

As such a TPM can be completely integrated and non field serviceable, accessible via a pluggable pin header, or via 100% software.

Now as to the pin-out of the 14 pin variant I was able to locate a number of images with common pin-outs (hence why I call this a pseudo standard), e.g.:

and

Of course, then again... the reason why I'm even here is trying to figure out the pin-out for SuperMicro's AOM-TPM-9670 which is based on an Infineon 9670... with a 10 pin header.

I was puzzling over the 10 pin implementation, until I saw this on page 288 of part one of the TPM 2.0 implementation specification:

A TPM may have one or more I/O pins that inputs or outputs a logic state. TPM2_NV_Read and TPM2_NV_Write may be used to access the value of GPIO using normal access controls. A platform-specific specification defines the mapping of NV Indices to individual General Purpose I/O (GPIO). Whether the TPM reserves any NV storage for the indicated GPIO is platform specific.

This... to the best of my understanding, the varying pin counts (and in some rare cases pin layouts) is a function of this "choice" provided to platform implementer allowing for things like secondary tamper evidence or out of band interaction with other hardware devices.

Notes / Citations

¹: A variant of SPI (the "enhanced Serial Peripheral Interface" or "eSPI") was developed by Intel as a successor to LPC.

²: From "A Practical Guide to TPM 2.0" (Chapter 1: History of the TPM):

It is said that the best designs come about when the architects make a design and then, having learned all the problems they will encounter, throw away the first design and start over with a second. TPM 2.0 gave the architects the opportunity to do this. However, they still had to make sure that the opportunities for software development that were enabled by the TPM 1.2 design were not lost with the new architecture.

Arthur W., Challener D., Goldman K. (2015) History of the TPM. In: A Practical Guide to TPM 2.0. Apress, Berkeley, CA. https://doi.org/10.1007/978-1-4302-6584-9_1

³: This example breaks down in the case of "virtual" TPMs like those implemented by QEMU and on some mobile phones and other embedded devices. For more information on virtual TPMs check out this paper from the 15th USENIX Security Symposium: vTPM: Virtualizing the Trusted Platform Module.