3 ms·

> fTPMs can be relied on. dTPMs can't be, but mainly because of bootstrapping issues that keep the BMC/BIOS from using encrypted and audit sessions to protect a

> fTPMs can be relied on. dTPMs can't be, but mainly because of bootstrapping issues that keep the BMC/BIOS from using encrypted and audit sessions to protect against passive and active on-bus attacks. Microsoft seems to disagree with you. https://docs.microsoft.com/en-us/windows/iot-core/secure-your-device/tpm https://docs.microsoft.com/en-us/windows/iot-core/secure-you... Firmware TPM (fTPM) requires special Processor/SoC support that is not currently implemented on Raspberry Pi 2 or 3. MinnowBoard Max needs firmware version 0.80 or higher. DragonBoard410c provides fTPM capabilities out of the box enabled by default. Discrete TPM (dTPM) is considered the utmost trustworthy solution by all means Software TPM (sTPM) is also referred to as TPM Simulator. It is platform-independent, supported on Windows IoT Core. sTPM is intended for development purposes only and does not provide any real security benefits. Chips are just as vulnerable, but its currently harder and not impossible to hack them.

cryptonector 4y ago
Well, they're wrong. The problem is that unless the BMC and BIOS doing all the TPM2_PCR_Extend() calls are securely (like, on some bit of memory or register that apps can't get to until much later when the secure boot sequence has completed) recording the TPM's resetCount or an audit digest of their commands, then an attacker can reset the TPM at a later point and extend the PCRs with values that are approved, and none will be the wiser. Another problem is that reading out a bitlocker key from the TPM after satisfying a policy is nice, but if it is not read over an encrypted session, then it can be read by any physical attacker than can watch the bus. The fundamental problem, ultimately, is that in order to defeat the bus attacks, the BMC and BIOS and early OS boot stages need secure volatile storage for storing the TPM's resetCount, and long-term non-volatile storage for storing the public key of some primary on the TPM for keying encrypted sessions. An fTPM has no external bus to worry about. Ergo fTPMs are fine.
- Terry_Roll 4y ago
  Half these problems would go away if we went back to a single core cpu.

cryptonector 4y ago

Well, they're wrong. The problem is that unless the BMC and BIOS doing all the TPM2_PCR_Extend() calls are securely (like, on some bit of memory or register that apps can't get to until much later when the secure boot sequence has completed) recording the TPM's resetCount or an audit digest of their commands, then an attacker can reset the TPM at a later point and extend the PCRs with values that are approved, and none will be the wiser. Another problem is that reading out a bitlocker key from the TPM after satisfying a policy is nice, but if it is not read over an encrypted session, then it can be read by any physical attacker than can watch the bus. The fundamental problem, ultimately, is that in order to defeat the bus attacks, the BMC and BIOS and early OS boot stages need secure volatile storage for storing the TPM's resetCount, and long-term non-volatile storage for storing the public key of some primary on the TPM for keying encrypted sessions. An fTPM has no external bus to worry about. Ergo fTPMs are fine.

Terry_Roll 4y ago
Half these problems would go away if we went back to a single core cpu.