It’s all built on top of the concept of “a chain of trust”, starting at the hardware level.
(as mentioned) TPM is a chip that’ll store encryption keys at a hardware level and retrieval of these keys can only happen if the hardware is unmodified.
I assume that part of this key is derived from aspects of your OS (ie: all device drivers are signed by MS).
The OS will fetch this key, if it’s valid - the OS knows that the hardware is untampered, it can then verify that the OS is unmodified, which can then be used by application to determine that their not modified, etc.
Now you could spoof your own TPM chip (similar to how Switch 1’s are chipped/nodded), but the deal-breaker is that when you add your key to the TPM chip, you sign it with a hardware vendor specific public key. And that vendor private key is baked into the hardware (often into the CPU, so the private key never crosses the hardware bus).
What’s preventing spoofing this with a fake implementation?
To expand on this a bit:
It’s all built on top of the concept of “a chain of trust”, starting at the hardware level.
(as mentioned) TPM is a chip that’ll store encryption keys at a hardware level and retrieval of these keys can only happen if the hardware is unmodified.
I assume that part of this key is derived from aspects of your OS (ie: all device drivers are signed by MS).
The OS will fetch this key, if it’s valid - the OS knows that the hardware is untampered, it can then verify that the OS is unmodified, which can then be used by application to determine that their not modified, etc.
Now you could spoof your own TPM chip (similar to how Switch 1’s are chipped/nodded), but the deal-breaker is that when you add your key to the TPM chip, you sign it with a hardware vendor specific public key. And that vendor private key is baked into the hardware (often into the CPU, so the private key never crosses the hardware bus).
Cryptography.