Trusted Platform Module, daughterboard vs onboard TPM?

A daughter card normally implies it is using a LPC (Low Pin Count) bus. This bus is slow and can relatively easily be monitored/manipulated. This is the basis of the famous TPM reset attack on version 1.1.

1.2 introduced the concept of Locality which mitigate this issue but is said to not entirely prevent it (not proven) - the window of attack is way smaller but the communication is not authenticated.

Not all TPMs are made equal and you get to choose your level of security. While a daughter card would likely not mitigate against the physical reset attack, a lot of new TPMs are integrated within the chipset - since 2009 if I recall. Intel provide those TPMs as part of their vPro technology. They run has application within the Management Engine in the Platform Controller Hub on new architecture or northbridge otherwise. In turn, it means the attack surface is most probably null.

The basic idea of the TPM is that it's a hardware-bound identity, meaning it uniquely identifies a single computer. In the PC case, 'computer' means 'motherboard': the TPM needs be integrated into the boot process in a particular way, which requires the cooperation of the BIOS, which lives on the motherboard.

Having a TPM on a daughter card breaks that underlying design assumption: it means a TPM can move between machines, which it's not supposed to be able to do.

Whether that's actually a bad thing... I honestly don't know. It depends on how deeply that assumption is bound up in the design of Trusted Computing protocols. But as someone who's relatively well-versed in TC stuff, putting the thing on a daughter card triggers my 'evil reflex' in a big way.