But CPU-side software needs to use it, and without default well-known keys...
You either need an interactively provided PIN, or a TPM integrated into the CPU/SoC to be secure in such a scenario.
The secure storage is the TPM, but here you cannot obviously store the secret in the TPM, it's a chicken and egg problem.
Thus your secret could only be on disk or in flash in and the attacker can just get it.
eFuses, maybe? Or a bit of battery-backed SRAM. Lots of devices have a small amount of hardened storage for e.g. encryption keys. FPGAs supporting bitstream encryption and Atmel's ATSHA device line are examples.
> CryptoAuthentication devices have full metal shields over all of the internal circuitry, so that if an attacker cuts or short circuits any trace in the shield, the product stops functioning.
To clarify, I was referring to the status quo of current discrete TPM implementations, from a bigger picture perspective, there is certainly room for improvement.
Also I am not sure the current TPM standard is compatible with that idea at all. Operating systems set up their own TPM sessions, so there would need to be secret storage only available to a specific operatings system, e.g. similar to what TPM provides, and we are back to the chicken and egg scenario.
fTPM is a firmware-based TPM implemented, usually, by coprocessor (or trustzone style enclave) inside the CPU, yes. It's not related to what TPM standard it implements
You can also have external TPM 2.0 compliant devices (commonly referred to as dTPM, probably brought the naming from iGPU/dGPU), and in fact many options offered for making desktops fully compliant with windows 11 (which requires TPM 2.0) involve a dedicated TPM 2.0 chip.
Ultimately, TPM standard does not care where the chip is, it just provides mechanisms for their use, which do include encrypted tamper protected interface... if one wants to use it.