1

Suppose we're using secure boot and remote attestation to prove to a server what client software is talking to it.

What stops an attacker from doing this:

  • Start a legitimate copy of the client software on machine A.

  • Get a remote attestation challenge from the server using a modified copy on machine B.

  • Send TPM_Quote to machine A's TPM and forward the signature back via B.

I understand that if the attacker had code running on machine A, the PCR values would be wrong. But is code running on machine A really the only way to talk to its TPM? With physical access, can't he put his own signals on the lines between machine A's CPU and TPM?

Or even simpler, disconnect it from machine A's board and send it arbitrary input from his own hardware, just imitating or replaying a legitimate boot? How do we know that the measurements given to TPM_Extend are actually the software that's sending the messages vs. e.g. replay of something I observed with a logic analyzer?

2

You don't. A TPM only protects against “mild” physical attacks. For example, it does protect against plugging in an alternate hard disk and booting from that. If the disk is encrypted with a key in the TPM, it protects against taking the hard disk out and plugging it into another machine. But it doesn't protect against an attacker who can inject data into the bus between the CPU and the TPM.

Remote attestation answers the questions “am I talking with the computer I think I am?” and “is this computer running the software I think it is?”. If “the computer” is not some monolithic entity and an attacker might have tampered inside it, remote attestation isn't enough, you need local anti-tampering protection.

3
  • I sometimes see the presence of remote attestation as justification for e.g. IDOR vulnerabilities in internet-facing APIs, because queries are assumed to only come from official client software. So that is definitely bunk, assuming an attacker is sophisticated enough to isolate the TPM? Also, does this make TPM-like environments directly integrated into CPUs more secure than separate chips?
    – jacobbaer
    May 10 '20 at 22:27
  • 1
    @jacobbaer Remote attestation doesn't protect you against bugs in clients for which you haven't yet deployed a patch. It doesn't protect you against changes that can be made without being detected (and on a complex system like a typical desktop machine, even heavily locked down, how much do you bet that there is a way to modify how your client works?). So this is bunk even if you aren't worried about physical attacks. May 11 '20 at 9:30
  • 1
    @jacobbaer TPM integrated in the CPU is typically more resistant against mildly invasive physical attacks because it's a lot harder to get between the main processor and the TPM. But it may be more vulnerable to software-initiated attacks such as precise timing or power measurement and power glitches. May 11 '20 at 9:32
0

The scenario you had described and the question that arises from it are both legitimate. In 2020, there exist on-chip implementations of TPM (aka fTPM), which alleviate the issue of attacks directed at the bus. But, you should be asking a different question, namely how does the TPM implementation know that the firmware specifically (and in case of TPM ≥ 2.0 it is necessarily UEFI) has not been tampered with.

A careful programming could solve this issue, if the CPU is only going to execute the UEFI code that was checked by the fTPM implementation before being fed to the CPU. If e.g. a digest of the UEFI firmware, computed by fTPM at bootup, does not match the value stored inside fTPM, then such firmware image should be rejected.

In other words, with fTPMs, the landscape is looking entirely different. All the implementation have to deal with are storage devices, and not the simulation of computation. Thus, fTPMs are much more reliable in that regard.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.