Taking into account a Root of Trust in a device using a TPM.
My understanding is that the bootloader, firmware, operating system, applications etc. are all verified on startup by validating signatures with the vendors public key.
The TPM Endorsement Key is unique to a particular TPM. What role does this play if any in the verification of software on startup? If this is a completely unique key which should never be exposed, does the public key get used externally in any way? Thanks in advance.
TPM is generally used for two purposes: prove the system is in a trusted state and the secure storage of keys.
For the first purpose, it is necessary to prove the software/firmware is talking to the real TPM hardware, not an imposter (e.g. snooper on the I2C/SMBus). A mechanism similar to HTTPS is used: each TPM, like a web server, is issued with a unique EK private-public pair (and an associated certificate).
The verification code uses the public key of the EK to communicate with the TPM. Since only the TPM knows the private key, only it can decode the commands and send the correct response.
(The EK public key will be put in the verifier's storage during provisioning or loaded from the TPM after verifying the certificate is signed by a trusted manufacturer.
Endorsement keys (EK) are part of endorsement hierarchy in TPM. Generally, the private part (EK private) of endorsement keys is hard-wired into the TPM (NVRAM) along with the public part (EK public). These Endorsement keys are created by manufacturer and EK Private is non-migratable/exportable and never leaves the TPM. EK certificate can be created which contains the EK public. This EK certificate is signed by either known CA or internal CA (Private PKI). Now, using EK certificate, TPM identity can be verified and trust in TPM can be established.
NOTE: EK is used to identify the platform, so it is only used for a limited number of procedures because of security concerns. For, e.g., EK is not used for signing purpose.
Now the trust in TPM is established, we can provision other keys for, e.g., attestation keys also known as AIK (attestation identities keys). Generally, AIK keys are cryptographically bound with private EK for e.g., wrapping the AIK key with EK public, this ensures that AIK is bound with trusted TPM. These AIK keys can be used to generate signatures. One of the use cases is signing the contents of PCR register.
AIK can also be certified by external or internal CA, and both AIK and EK can be cryptographically verified via a trusted third party. So, in case of trusted boot, PCR's can be signed by AIK and AIK can be verified cryptographically via third party CA and with TPM EK.
In conclusion, TPM EK helps to ensure that the device, software/application or system configuration is attested by trusted platform and not by some imposter. Remote attestation uses EK and AIK to establish such trust.
NOTE: Trusted and secure boot can be achieved without requiring the signing key, e.g., AIK. This is known as local attestation, and such attestation is useful for self attestation of the system. Although, EK can still be used to verify the TPM is from a trusted vendor and not tempered.
