The following table summarizes test results of certain TPMs v1.1b we have tested using our TPM compliance test suite:

TPM Chip	Infineon SLD 9630	Atmel AT97SC3201	National Semiconductor	STM ST19 WP18	Infineon SLB 9635
Mainboard	Intel D865 GRH	IBM Thinkpad T41p	IBM Thinkpad T43	Intel D945	Intel D865 GLC
operating system	Linux 2.6.16-rc1	Linux 2.6.14	Linux 2.6.15-mm4	Linux 2.6.12-rc1	Linux 2.6.16-rc1
General Information:
TPM version	1.1b	1.1b	1.1b	1.2	1.2
TPM vendor	Infineon (IFX)	Atmel (ATML)	National Semiconductor (NSM)	ST Microelectronics (STM)	Infineon (IFX)
TPM firmware version	1.1.1.6	1.1.0.6	1.1.4.22	1.1.0.0	1.1.0.0
Platform Configuration Registers (PCRs)	16	16	16	24	24
Data Integrity Registers (DIRs)	16	2	2	1	1
Available keyslots	4	10	9	9	10
precalculated keys	yes	no	yes	no	yes
concurrent OIAP sessions	20	2	8	12	32
concurrent. OSAP sessions	20	2	8	6	32
TCG Compliance:
compliant to specification (upon the tests we performed)	no	no	yes	no	yes
bugs (for bug description see below)	TPM 1.1b ET_SRK bug	TPM 1.1b AuthDataUsage bug		TPM 1.2 handle bug
		TPM 1.1b second key return bug		TPM 1.2 monotonic counter return bug
		TPM success return bug		TPM 1.2 monotonic counter timing bug
				TPM success return bug
bugs patchable	yes, via libtpm patch	partly, via trousers	/	no	/
Algorithms:
supported	RSA, SHA1, HMAC	RSA, SHA1, HMAC	RSA, SHA1, HMAC	RSA, SHA1, HMAC	RSA, SHA1, HMAC
not supported	DES, 3DES, AES	DES, 3DES, AES	DES, 3DES, AES	DES, 3DES, AES	DES, 3DES, AES
Security related:
session handle description	The session handle do partly increase in minor or major steps. If a session handle is freed, it is immidiately assigned to the next session.	The session handles always start at 0x00000000. If a session handle is freed, it is immidiately assigned to the next session.	The session handles always start at 0x00000000. If a session handle is freed, it is immidiately assigned to the next session.	The session handles always start at 0x00000000. If a session handle is freed, it is immidiately assigned to the next session.	The session handles are conform to the TCG specification handle requirement (Ref. TPM Spec 1.2, Rev. 85, Level 2, page 12)
key handle description	The key handles do partly increase in minor or major steps.	Randomized key handles	The keyhandles have an ever-increasing value starting with key handle 0x00000001. After a TPM restart, the key handle still has its last value. Only after some hours of powered down state, the key handles are set back to 0	The key handles always start at 0x00000100. If a key handle is freed, it is immidiately assigned to the next key.	The key handles are conform to the TCG specification handle requirement (Ref. TPM Spec 1.2, Rev. 85, Level 2, page 12)
Countermeasure against dictionary attack	not present	not present	present	present	present
Dictionary Attack description:	/	/	After 10 invalid attempts, the TPM refuses any further command. After some seconds and a valid authentication, the TPM allows only one command in a timeframe of 5 seconds. After 10-30 minutes, the TPM works normal again	In case of a dictionary attack, the TPM starts increasing its answer time. The first 15 responses are received immidiately, then every 2 commands the return time is increased by one second. After about 40 faulty authentication tries, the TPM response time is at about 10 seconds.	In case of a dictionary attack, the TPM cancelles the execution after 10 invalid attempts. After further attempts, the TPM increases the time frame, in which a valid command can be executed.
Dictionary Attack countermeasure resettable	/	/	no	yes, the dictionary attack countermeasure resets itself after one succesful authentication.	no
Bug description:
TPM 1.1b ET_SRK bug:	The TPM does not differ between ET_KEYHANDLE and ET_SRK. Therefore, an authentication error occurs for keytype 0x0004. Fixable via TPM Firmware Update or libtpm-patch
TPM 1.1b AuthDataUsage bug:	The TPM does change the authdata-field inside the SRK-blob after taking ownership. For details refer to trousers-bugfix in trousers/src/tspi/spi_tpm.c
TPM 1.1b second key return bug:	The TPM does not check, whether the authorisation data failes for the first or the second key. If the second key authorisation fails, the TPM has to return „TPM_AUTH2FAIL“ instead of „TPM_AUTHFAIL“
TPM 1.2 handle bug:	TPM Spec 1.2, Rev. 85, Level 2, page 12: The three LSBs of the handle MUST contain the collision resistance values. The TPM MUST provide protection against handle collision. ... The three last LSB of the handle MUST be generated randomly.
TPM 1.2 monotonic counter timing bug:	„The TPM must support an increment rate of once every 5 seconds.“ (as specified in TCG spec 1.2)
TPM 1.2 monotonic counter return bug:	If requesting an invalid countId via TPM_readCounter, the TPM has to return TPM_BAD_COUNTER (69). Here TPM_BAD_PARAMETER (3) is returned
TPM success return bug:	By invalidating the send-buffer by modifying one parameter, the TPM returns TPM_SUCCESS (0) instead of an error. See table „Integrity tests“ for details and the failed testcase.