A 'TPM chip' is:
a secure cryptoprocessor that can store cryptographic keys that protect information
FIPS 140-2 requires a cryptographic module, which can be hardware, software, or both that have been certified.
If I was using Bitlocker as a cryptographic module, would I need a TPM as another piece of that cryptographic module?
Is a TPM required for FIPS 140-2 security level 1 compliance?
What about security level 2?
No, absolutely not. FIPS 140-2 level 1 is essentially a test that your cryptographic module:
Software can be validated at FIPS 140 level 1, there is no need to involve special hardware. FIPS 140 level 1 does not indicate resistance against an attacker with hardware access, unless the hardware is part of the target of evaluation. If you have a requirement for FIPS 140 level 1 compliance, then using Bitlocker (an approved version thereof, under an approved version of Windows operating in FIPS mode) is sufficient, whether or not the secrets are stored in a TPM.
At FIPS 140 level 2, the hardware must be part of the target of evaluation, but the security requirement is limited to tamper-evidence. A TPM is overkill for that (TPMs offer tamper resistance, so in principle a suitably designed TPM-based system could reach FIPS 140 level 3, though there are sticky points, and going beyond level 2 is not likely to be practical). You can browse the list of (non-secret) FIPS-140 validated modules. Note that the list does not include Bitlocker+TPM combinations, and in fact no TPM has been certified at FIPS 140 level 2 so far.
One of the hurdles in certifying a TPM is that it includes a large number of algorithms, many of them non-approved. The TPM does not provide a good way to disable these algorithms or to isolate all FIPS mode data from non-FIPS mode data. Yet this would have to be done, and tracked not only during operation but through the lifetime of the TPM, since the TPM includes non-volatile storage. (How do you know a secret key stored in FIPS mode is not leaked to non-FIPS-mode where it's used to encrypt some data with a broken algorithm?) Another hurdle is that all certified algorithms undergo a self-test when the device boots, and this takes a while (TPMs have pretty slow chips).
By the way, if you do not have a legal or contractual requirement for FIPS conformance, and you don't need to quote FIPS conformance as a commercial argument, then don't worry about FIPS conformance. Especially at level 1, especially when running on a complex, open OS with a poor track record on security like Windows. FIPS conformance is not an indication of security, and AviD's law of regulatory compliance very much applies here: FIPS conformance reduces the risk of the penalties of non-conformance. If you're running under Windows, I recommend using Bitlocker, not because of any conformance, but because it was written by specialists, has been heavily tested, and is being actively maintained. That way, you can concentrate on the real weakness in your overall security, like the fact that 50% of your users are going to use 1234 as their PIN and the other 50% are going to use their birthday.
If you're asking to extend Bitlocker security, the TPM is certainly a good and cheap start. But it will not give you regulatory compliance, and it will also not give you complete security.
Basically, what remains as attack on Bitlocker (apart from passphrase brute-forcing and physically tapping the TPM's LPC bus) are user interface spoofing attacks. E.g. I replace your bootloader to record the password that you type into the bitlocker dialog, or I fake the bitlocker dialog itself. Using a TPM can make such attacks much harder, since the keys are bound to a "correct" bootloader. However, one could still replace the bootloader, store the password for later retrieval, then restore the original bootloader and reboot. As a user, you only see an unexpected reboot and maybe won't wonder much about what just happened.
This "evil maid" attack is well-known, was mentioned in the InvisibleThings blog some time ago and the German Fraunhofer SIT also has a nice video demonstration: http://testlab.sit.fraunhofer.de/content/output/project_results/bitlocker_skimming/
Theoretically, the TPM can be used as a drop-in replacement for a smartcard. The Trousers software stack for Linux actually exports a PKCS#11 interface for that purpose, and AFAIK Windows 8 will enable access to the TPM via their Card Service Provider API. However, in that respect the TPM will only provide you with a basic protection against PIN brute-forcing. Existing TPMs have no guarantees regarding tamper evidence. Moreover, you don't have a secure PIN entry method and no secure display. Anyone can intercept the PIN on its way to the TPM, just like with class 1 smartcard readers. In the future, trusted execution technology (TXT,SVM,TrustZone) might give you secure user I/O, but this is far from usable today.
