Is it possible to make a custom firmware build that enables fTPM on Intel boards?
no.
fTPM is a fused option, and is disabled from the factory on ChromeOS boards. There is no way to re-enable it.
Thanks for the info. The TPM via the google security chip is slightly pointless for PCR attestation stuff, as the root of trust appears to be the AP firmware. The TPM itself doesn’t appear to measure it’s own firmware or the AP firmware.
I guess that setup only makes sense for ChromeOS, as the RO section of the AP firmware can be trusted. But if you’re running custom firmware you can’t use it as a root of trust.
you can, it just requires some configuration changes
I know you can get the firmware to measure stuff, but in that case the firmware becomes your root of trust. And the problem is that you can’t trust it. Someone could flash different firmware on it that just “fakes” the measurements. With Intel’s fTPM this is prevented because the ME firmware will be the first that measures both itself and portions of the AP firmware. So as long as you can trust the signature validation of the ME firmware the system is safe.
On stock ChromeOS devices this problem is prevented by AP RO validation. But with custom firmware you can’t use that feature.
So, it’s not like you “can’t use it as a root of trust”, but that it doesn’t make that much sense.
I don’t see why you couldn’t, just no one that I know of has tried it yet.
Maybe all you would have to turn on is CONFIG_TPM_MEASURED_BOOT. Then the firmware would start to measure stuff into the tpm pcrs. But as evidenced by these current pcr values on my machine:
$ tpm2_pcrread
sha256:
0 : 0x0000000000000000000000000000000000000000000000000000000000000000
1 : 0x0000000000000000000000000000000000000000000000000000000000000000
2 : 0x0000000000000000000000000000000000000000000000000000000000000000
3 : 0x0000000000000000000000000000000000000000000000000000000000000000
4 : 0x0000000000000000000000000000000000000000000000000000000000000000
5 : 0x0000000000000000000000000000000000000000000000000000000000000000
6 : 0x0000000000000000000000000000000000000000000000000000000000000000
7 : 0x0000000000000000000000000000000000000000000000000000000000000000
8 : 0x0000000000000000000000000000000000000000000000000000000000000000
9 : 0x0000000000000000000000000000000000000000000000000000000000000000
10: 0x0000000000000000000000000000000000000000000000000000000000000000
11: 0x0000000000000000000000000000000000000000000000000000000000000000
12: 0x0000000000000000000000000000000000000000000000000000000000000000
13: 0x0000000000000000000000000000000000000000000000000000000000000000
14: 0x0000000000000000000000000000000000000000000000000000000000000000
15: 0x0000000000000000000000000000000000000000000000000000000000000000
16: 0x0000000000000000000000000000000000000000000000000000000000000000
17: 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
18: 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
19: 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
20: 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
21: 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
22: 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
23: 0x0000000000000000000000000000000000000000000000000000000000000000
The GSC itself didn’t measure anything before the firmware got up. So if nothing is measured before the firmware starts up, it will act as the root of trust. So the trust in the pcr values will depend entirely on your trust of the firmware. Since we have to run without AP RO verification, the firmware can’t actually be trusted. Anyone with root on the device (or physical access) could overwrite it. This makes it just as “good” as it would be run a tpm emulator as root in userspace in Linux (when it comes to PCR values, e.g. sealing secrets against PCR values).
I don’t see why you couldn’t build coreboot with vboot enabled and use ap ro verificationc
AP RO verification only allows the system to boot if the ro section is signed by Google, right? Or can you enroll your own keys somehow.
By AP RO verification I’m referring to AllowUnverifiedRo:never in Ti50
You should be able to generate your own RO hash and replace the stock google one. Not too sure how to do it though.
Just skimmed coreboot/3rdparty/vboot/README, that seems to talk about the generating and using the public key that is placed in the RO section and used to verify the RW section. That document doesn’t seem to talk about AllowUnverifiedRo at all.
But conceptually I’m working on the understanding that the public key that is used to verify the RO section is stored on the GSC (or it’s firmware…) and can’t be changed.
Tanget: I’d be interested in finding out how AllowUnverifiedRo deals with “time of check to time of use” vulnerabilities. Imagine using a modified SPI chip that returns a good RO section when the GSC verifies it but then returns a malicious RO section when the AP actually starts running the RO section. Is there any caching going on? Or are Chromebooks vulnerable to this type of attack?
I believe the verification happens at GSC reset. So if you flash externally you should be able to bypass it.
That appears to match the behavior I saw in this topic: Relationship between AllowUnverifiedRo and software write protect - #5 by cydox
Those successful boots happened even though the write protect registers were not in the correct state to pass AP RO verification. Would make sense if AP RO verification only happens at GSC reset. Also indicates that the AP RO verification is vulnerable to “time of check to time of use”.
Just tested this and it works (on craasneto). It measures stuff into pcr 2. Don’t see a tpm eventlog at the normal location in sysfs, but this is some progress.
The problem of how you can trust the firmware is still there though. I think the best possible posture would be to protect it by HW/SW write protect but not AP RO verification.
There are no measurements from edk2 (I’m assuming), as only pcr 2 has stuff in it atm.
In retrospect, the fact that Intel PTT / fTPM is not configurable by the AP firmware makes complete sense for two reasons.
- Intel PTT does its first measurements before the firmware even runs
- If the firmware could still somehow disable it, that would completely break the chain of trust. It would turn the firmware into the root of trust instead.