kukrimate's comments

Why does the initrd have to keep the PCRs the same after handing off to the root filesystem anyhow?

Capping off the PCRs with any arbitrary value before execing into root would stop this.

It is a hardware feature, but it does basically nothing without its software in flash....

The only code that is inside the silicon is a 128K bootrom that literally just sets thing up for the real firmware to run.

I have the ME11's boot ROM in a disassembler as I write this :)

Absolutely is, one of those exact attacks is being used here to bypass BootGaurd. However all pre-boot attacks I am aware of rely on writing a malicious payload to the system's SPI flash and involve physical access.

While they are genuine vulernabilties, I wouldn't consider this a worse problem than being able to inject rootkits into other parts of the firmware which is also the case here.

Depends on how you define "booting". While its true that the microkernel always boots, and there is one userspace process running, it's a bit more subtle than that imo.

The bringup module always boot which configures the clock controller, bootguard parameters, and releases the CPU core from reset. When in HAP mode, after that it only handles power management events and doesn't really do anything else. No other ring 3 processes are started on the ME in this mode.

Stuff like even the real read-write VFS, fw updater, HECI comms handerl, AMT, PAVP, ISH server, etc are never started in HAP mode. It effectively reduces your runtime attack vector to data in SPI flash only.

I wrote the deguard utility that made this possible. (The vulnerability being used was found by PT Research in 2017 however.)

While yes you cannot strictly disable the ME, what remains of its firmware in this configuration is a bringup module that is stuck in a loop handling power management events.

The network stack, HECI stack, etc are all gone here. Effectively the only way to exploit it is to put your payload into SPI flash, which we are already doing anyways :)

It is also possible to take over the ME firmware and bring up the CPU using open source code, and have full control over the ME at runtime. This isn't implemented currently, but that's the direction this is aiming in.

> eFuses, maybe? Or a bit of battery-backed SRAM. Lots of devices have a small amount of hardened storage for e.g. encryption keys. FPGAs supporting bitstream encryption and Atmel's ATSHA device line are examples.

To clarify, I was referring to the status quo of current discrete TPM implementations, from a bigger picture perspective, there is certainly room for improvement.

Also I am not sure the current TPM standard is compatible with that idea at all. Operating systems set up their own TPM sessions, so there would need to be secret storage only available to a specific operatings system, e.g. similar to what TPM provides, and we are back to the chicken and egg scenario.

Except that was never the purpose of TPMs unlike HDCP

Is anyone here talking about survaillance??

That "attestation" in the full disk encryption case means your disk encryption key only being available to the operating system you chose to install. And disallowing the ability of a laptop thief to change that.

Or remote attestation can be used to restrict access to a corporate network to corporate controlled devices only. No one surveills you, or has access to your device in this scenario either, the TPM there is used to produce a certificate of the device state that can effectively act as access credentials to a resource.

This is about recognising the fact that the person in physical possession of a device isn't necessarily the legitimate owner.

TPMs are a cryptographic coprocessor with added platform state attestation functionality. That can for example be used locally for secure secret storage that is only available in certain platform states, or remotely to certify the state of a device trying to access a corporate network.

Of course TPMs can be (ab)used for DRM, but the same property in general to many ideas in cryptography. We still don't say AES or RSA are tools designed to restrict your rights.

In reality TPMs are almost always used to (attempt to) protect the user's data over restricting them.

I would argue that the discrete chip variation of them aren't very good at this (and even less good at DRM), but a lousy implementation doesn't mean the concept is bad. (As Foxboron mentioned earlier in this thread, discrete TPMs can still act as reasonably good "discounted" SmartCards, but they are bad at platforms state attestation.)

In fact I would have much preferred if the industry embraced the measured boot idea more instead of mainly pushing stricter verified boot schemes.

Because where do you store the CPU side private key after the exchange for future sessions?

The secure storage is the TPM, but here you cannot obviously store the secret in the TPM, it's a chicken and egg problem.

Thus your secret could only be on disk or in flash in and the attacker can just get it.

What you are saying is sound, and I agree it could be done.

But there are multiple caveats: - How do you hide the secret so that only "legitimate" operating systems can use it for establishing their sessions and not "Mate's bootleg totally not malware live USB"? - And unfortunately current CPUs don't implement this. - Additionally don't be so smug to think you need to decap a CPU to extract on-die secrets. Fault injection attacks are very effective and hard to defend against.

I agree the security of this can somewhat be somewhat improved, but if you are building a custom CPU anyhow, you might as well move the TPM on-die and avoid this problem entirely.

Well yes, but there is a difference between a signal being accessible on a PCB trace I can see with my eyes, vs it being accessible only on the inside of a 7nm silicon die.

There is a reason why a lot of system integrate the security processor on the same piece of silicon whose state the security processor is meant to protect.

The reason discrete TPMs exist is supposed compliance with crypto standards, and physical protection against key extraction, but they sort of miss the forest before the trees. What matters to users is the protection of their data, not the TPM's secrets, and discrete TPMs arent very good at the former.

> What are your thoughts on Microsoft Pluton and Google OpenTitan as TPM alternatives/emulators?

I am not familiar enough of the technical details of Pluton or OpenTitan to make a meaningful statement on their security.

> Should system attestation roots of trust be based on open-source firmware?

Yes, and not only root of trusts, I am strong believer in open source firmware in general. I have been developing coreboot as a hobby for a long time. I wish their was more industry support for such things, especially at the lowest levels of modern systems.

No.

But on essentially all existing UEFI systems you can trivially overwrite the "db" keystore in flash and install anything you please.

Also most (all?) UEFI systems are not locked to Windows and allow customizing the keystore via the firmware console interface anyhow.

Unfortunately encrypted sessions without an interactively provided secret like a PIN are no defence against attacker with physical access.

You either need an interactively provided PIN, or a TPM integrated into the CPU/SoC to be secure in such a scenario.

The PIN is the important part there, encrypted sessions (and/or EK cert verification) without PIN are not much more then obfuscation, and defeated by both the interposer attack, and the tweezer attack. (Or the TPM hack to rule them all, e.g. desoldering the chip and connecting it to a microcontroller you control)

I supposse a PIN is a slight improvement over a regular password, but a big appeal of TPM FDE in my opinion is unattended unlock.

I think discrete TPMs don't really have a future in systems that need robust system state attestation (both local and remote) against attackers with physical access. TPMs should be integrated into the CPU/SoC to defend against such attacks.