How to trust ICs?
Theoretically, to ascertain what a chip does, you break it apart and reverse-engineer it. In practice, this will be nigh impossible to do. Actually, even for software, for which you have the actual source code, you cannot guarantee that the code really always does what you believe it does (otherwise we would be able to produce bug-free code).
This is not a new problem, and intelligence agencies (an oxymoron) have stumbled upon it many times. When the CIA wants to ascertain that the computers at the White House are not full of Chinese-controlled backdoors, what do they do ? Well, they certainly have a look at the chips for anything obvious (an integrated GSM modem has a minimal size; it can be seen with a X-ray scan of the chip). However, ultimately, they rely on classic investigation methods which have demonstrated their efficiency since the days of Julius Caesar: tracking the source of each component, who designed them, who produced them, who transported them, and so on, with background checks on all involved individuals, and audit of the procedures. This is not very different from "certified software" (e.g. Common Criteria), for which design, specification, developers' background and development methodologies are inspected.
One way to see it is that the hardware is not evil -- people are. So check the people, not the hardware.
In the case of the CIA, this means that they will much prefer chips from Taïwan over chips from mainland China.
Just to make things clear.
Seems to me like there's two distinct questions here: "Do I have to trust my manufacturer?" and "Can a TPM be malicious?".
Here's some comments about the second one:
A TPM just can't do those kinds of things, it's a passive/dumb device. It is typically connected via a standard bus (LPC). While the LPC does have DMA access via the LDRQ# interrupt, the TPM does not have access to that interrupt. In other words, it cannot access the DMA engine nor can it communicate with other devices by itself. Any attack the TPM could pull off would have to be passive, such as a side-channel attack.
New TPMs implemented by Intel are actually running as an application within the Platform Controller Hub formerly Memory Controller Hub aka Northbridge. They're running on top of Intel Management Engine aside AMT and bundled under the vPro flagship. You can see Intel's ME as an operating system running in ring -3 as it is running on a completely separate CPU (not your main CPU) and have complete memory access to your system memory (via Intel UMA). Therefore, someone could argue that those iTPMs (Integrated TPMs, well in fact it's any application running on ME) have the capability of being active and do the kind of thing you describe.
At that point the question is, could someone backdoor Intel ME/AMT? Yes, it's possible. Unlikely, but possible. You would need to exploit it, or you would need the ME signing keys. Also, - back to your first question - could your manufacturer backdoor Intel ME/AMT? Same answer.
p.s. at some point the story behind BadBIOS turned in questioning whether this was actually happening (i.e. very powerful and portable exploit).
I did a talk at Blackhat a few years ago (actually 10 now) that revisited Trusting Trust: http://www.blackhat.com/presentations/bh-usa-04/bh-us-04-maynor.pdf
I followed up with an article written for Linux Journal in 2005: http://www.linuxjournal.com/article/7839
I've been researching this topic for almost 15 years now and I can tell you the takeaway from the Thompson article is that unless you verify EVERY component in your environment, you can't. While logic tells you a trojaned piece of hardware or software might have a suspicious binary blob that does a reverse shell in reality it could be much more subtle. The 2005 article highlighted an example of creating a stub for strncpy and actually using strcpy. If you were to look at the symbols post compile everything would look right but anywhere you think a buffer overflow has been stopped by strncpy now becomes an attack vector.
When it comes to hardware this process is even harder because you can't just run strings on the binary. A combination of IP concern and laws keep a lot of the lower operations of something like a mobile device a secret. Jailbreaking has had some success in opening this blackbox, but not a ton.
Check out this blog I wrote in reaction to the iPhone SMS vulnerability in 2009: http://blog.erratasec.com/2009/07/heres-how-we-do-that-voodoo-that-we-do.html#.UtVBoHk6JFw A lot of knee jerk reactions to this bug was to have AT&T disable the SMS plan for the iPhone and people felt safe. In reality even if you don't have a SMS plan you phone receives special SMS updates from the carrier that do things like network tuning, tower updates, etc... A backdoor in the device could be as something simple as pushing a tower update to your phone telling you the IMSI catheter in your neighbor hood is an official carrier tower and its ok to us it.
In short unless you manufacture every component, write all the software, own the phone company, and are able to pass favorable laws for research you can't know if your device is backdoored.