[ValdikSS]

Sure, why not? You have a reference implementation for both TrustZone OP-TEE (from Microsoft!) and in-Linux-kernel. No need to code anything, everything is already there, tested and ready to work.

https://github.com/OP-TEE/optee_ftpm

Or you mean dedicated TPM?

[stefan_]

As I understand it, you can not actually deploy a fTPM (in embedded and other scenarios) unless you run your own full PKI and have your CA signed off by Microsoft or some other TPM consortium member. So sure the code exists, but it's also just a dummy implementation, and for any embedded product that is not super cost conscious I will forever recommend to just buy the $1 chip, connect it via SPI and live happily ever after. Check the box, in embedded most non-technical people can't even begin to understand what FDE means anyway.

If you don't need the TPM checkbox, most vendors have simple signing fuses that are a lot easier than going fTPM.

[jhallenworld]

I mean a separate chip.

[ValdikSS]

Well, you have much more control of lower-level boot process on ARM chips, and each of the SoC manufacturers have their own implementation of Trusted Boot which relies on the cryptography and secrets inside the SoC rather than TPM as in x86/UEFI boot process.

In context of trusted boot — not much. If your specific application doesn't require TPM 2.0 advanced features, like separate NVRAM and different locality levels, then it's not worth to use dedicated chip.

However if you want something like PIN brute force protection with a cooldown on a separate chip, dTPM will do that. This is more or less exactly why Apple, Google and other major players have separate chip for most sensitive stuff—to prevent security bypasses when the attacker gained code execution (or some kind of reset) on the application processor.

[bri3d]

> their own implementation of Trusted Boot which relies on the cryptography and secrets inside the SoC rather than TPM as in x86/UEFI boot process.

TPM and x86 trusted boot / root of trust are completely separate things, linked _only_ by the provision of measurements from the (_presumed_!) good firmware to the TPM.

x86 trusted boot relies on the same SoC manufacturer type stuff as in ARM land, starting with a fused public key hash; on AMD it's driven by the PSP (which is ARM!) and on Intel it's a mix of TXE and the ME.

This is a common mistake and very important to point out because using TPM alone on x86 doesn't prove anything; unless you _also_ have a root of trust, an attacker could just be feeding the "right" hashes to the TPM and you'd never know better.

[ValdikSS]

On ARM, you control the whole boot process on many SoCs, and can make your own bespoke secure/trusted/measured boot chain, starting from bootrom to the very latest boot stages (given that your SoC manufacturer has root of trust and all the documentation on how to use it), without TPM.

You more or less can't do that on x86, and have to rely on existing proprietary code facilities to implement measured boot using TPM (as the only method), for which you can implement trusted boot, using TPM and all the previous measures proprietary code made to it.

[bri3d]

You can do that on x86 too, the main difference is a combination of openness and who you need to sign an NDA with (which, granted, is a big difference, since most ARM vendors are more likely to be your friend than Intel). However, there are a ton of x86 based arcade machines, automotive systems, and so on which have secured root of trust and do not use UEFI at all. On Intel, you get unprovisioned chips and burn your KM hash into the PCH FPFs to advance the lifecycle state at EOM, which is basically the same thing you'd do with most ARM SoCs.

[ValdikSS]

I cracked into many x86-based arcade machines (and non-arcade gambling machines), and none of them used anything really bespoke. I never seen non-BIOS/UEFI x86 system in my life.

Not going to say they are non-existent, but probably the only mention of not using UEFI on Intel chips was in the presentation of Linux optimization for automotive from Intel itself, where they booted Linux in 2 seconds from the cold boot.