3

Can I program the TPM chip to execute a piece of code securely just like executing code in the TrustZone area? In particular, the application will be running in the normal world, but parts of it should be run in a secure world, so can I use TPM for this purpose?

forest
  • 65,613
  • 20
  • 208
  • 262
user171201
  • 31
  • 1
  • 1
    This question may be better answered by https://security.stackexchange.com/q/175749/165253. The gist is that TPM does not provide the capabilities you require. Instead, you would need to use something like SGX. – forest Feb 21 '18 at 06:25

3 Answers3

1

No. A TPM offers a fixed set of functionality which does not include arbitrary code execution. The functionality set centers around using keys in the TPM for a fixed set of features, mainly authentication (proving that a value was signed on this particular computer), device-bound storage (encrypting data in such a way that it can only be decrypted on this particular computer) and platform attestation (proving that the computer memory is in a known state). The only way to extend a TPM's functionality set would be to flash a new firmware, and this ability is restricted to the manufacturer and there may only be room for a few patch points anyway.

In contrast, TrustZone is merely an isolation feature. It does not impose any constraint on what (or how much) code runs in the secure world. If the operating system of the secure world allows it, you can install applications that preform arbitrary computation with the device-bound keys. Of course, if you aren't the chip manufacturer, you often won't have the necessary keys to install code in the secure world.

Sufficiently recent Intel chips offer somewhat similar functionality (but with a very different architecture) through TXT. TXT uses the TPM to authenticate the code that runs in a TXT partition and store the partition's data securely, but the application runs on the main CPU, not on the TPM.

Gilles 'SO- stop being evil'
  • 51,415
  • 13
  • 121
  • 180
-1

Depends on the TPM implementation, there are discrete TPMs (dedicated chips) which work similarly to ASICs in that they have defined circuits to efficiently execute consistent operations and are not general purpose chips. They cannot run arbitrary code.

Integrated TPMs are similar in that they are fixed circuits on a board and cannot perform arbitrary functions.

Software TPMs and virtualized TPMs are different, they can be undermined just like any software or virtual machine.

  • If by software TPMs you mean fTPM (firmware), then it cannot be undermined without compromising the CSME (still possible, but not as easy as MITMing the LPC bus or performing a platform reset attack). But you're right in that you can't execute arbitrary code on a TPM, of course. – forest Feb 21 '18 at 06:22
-2

TPM is a general term, not the actual chip. In some documentation it refers generally to the whole system, in others it refers to a general representation of the chip. The chips are specific to each manufacturer.

You cannot program the intel chip (TXT is closed source, so only intel can).

AMD's equivalent (PSP, alter renamed Secure Technology / HVB) stared as an open source so at least in theory can be reprogrammed.

Overmind
  • 8,829
  • 3
  • 19
  • 28
  • 1
    Intel TXT is not a chip. It's the name of a feature provided by the CSME (Management Engine). You actually _can_ reprogram it, given the recent vulnerabilities discovered for v11 and v8. It would affect all of the CSME's functionality, including the fTPM for (CSME-managed) TXT functionality. Additionally, "TPM" is not just a general term, as it must have a valid EK from the TCG. Anyone can make a TPM-like device, but only officially attested and standards-conforming TPM devices (regardless of the IC's manufacturer) can be called TPM. Perhaps you're thinking of HSM, which is a general term. – forest Feb 21 '18 at 09:12
  • As for AMD's technology, I believe only the ISA is open source, being based on ARM, rather than the actual firmware that runs on it. I could be wrong though. Regardless, it is signed with the TCB reduced to hardware so it's unlikely that you could reprogram it, short of using a 0day or obtaining the signing key. – forest Feb 21 '18 at 09:14
  • You cannot reprogram anything. Only intel can. A device-like is not a TPM device is it's not certified. – Overmind Feb 21 '18 at 09:27
  • Yes, you can reprogram it. Were you not there for the recent bugs in firmware v8 and v11 that allowed bypassing the signature verification mechanism, permitting anyone to run any code (ISA is hybrid i486/i586) on it? I think v8 (ISA was ARCCompact) also had a signature bypassing bug, but it might have just been a code execution bug (same end result). – forest Feb 21 '18 at 09:31
  • Updating a firmware is not reprogramming it. Reprogramming it means you writing that firmware or altering it to fit your needs. Not possible as an outsider. – Overmind Feb 21 '18 at 09:33
  • I'm not talking about updating firmware. I am talking about writing your own firmware or modifying the current firmware. That _is_ possible for MEv11. The only reason it was not in the past is because firmware was signed. The bugs that bypass signature verification allow you to avoid that issue. – forest Feb 21 '18 at 09:35
  • Again, overwriting the firmware with another (unsigned) does not mean writing your own. How can you write it if it's a closed source / proprietary system ? When you find an intel TPM editor, inform us,we'd be glad. – Overmind Feb 21 '18 at 09:47
  • What exactly do you believe is closed? The ISA is public, being an i486/i586 hybrid. You could trivially compile code for it. All that is closed source is the _firmware_ itself. Writing new firmware does not require being able to understand the previous firmware. All it requires is bypassing signature verification so it actually runs, which we now are able to do. Even modifying the existing firmware is possible with reverse engineering (as has been done before in conjunction with signature verification bypasses). – forest Feb 21 '18 at 09:48
  • Then go ahead and prove it. – Overmind Feb 21 '18 at 09:56
  • [OK](https://blog.rapid7.com/2017/11/21/intel-sa-00086-security-bulletin-for-intel-management-engine-me-and-advanced-management-technology-amt-vulnerabilities-what-you-need-to-know/) [here](https://andreafortuna.org/technology/how-to-hack-a-turned-off-computer-using-intel-management-engine/) [you](https://www.blackhat.com/docs/eu-17/materials/eu-17-Goryachy-How-To-Hack-A-Turned-Off-Computer-Or-Running-Unsigned-Code-In-Intel-Management-Engine.pdf) [go](https://news.ycombinator.com/item?id=16015539) (hover over each word). This explains how you can run unsigned, custom firmware. – forest Feb 21 '18 at 10:00
  • Vulnerabilities and exploits don't prove your point, and further, from ME12 intel won't even allow firmware downgrades...so that caps it. – Overmind Feb 21 '18 at 10:11
  • Vulnerabilities _do_ prove my point, as they show how you can run unsigned firmware. Just because a future version of CSME firmware will attempt to prevent downgrades is irrelevant. I'm not sure how this isn't getting through to you. It was a big deal months ago when people actually showed that you _can_ run unsigned code on the CSME. As Intel obviously wants to prevent this, it is naturally a vulnerability. Still allows running unsigned code. – forest Feb 21 '18 at 10:12
  • Vulnerabilities and exploits are not supported features. The question asks if you can program it, not exploit it. – Overmind Feb 21 '18 at 11:54
  • If you believe that programming something after bypassing restrictions is not "real" programming, then I'm not sure what I can do to help you, so I don't think I have anything more to say on this matter. – forest Feb 22 '18 at 03:06
  • Vulnerabilities and exploits get fixed. Bypassing something in one version (that is also due to be upgraded) does not mean you can do it at any time on any version. That's the difference. – Overmind Feb 22 '18 at 06:36
  • Then you should change your answer to say "You cannot program the CSME on future up-to-date firmware versions, though you can for 99% of existing ones". The truth is that you can reprogram it on the _majority_ of systems. The fact that there are a few rare exceptions is splitting hairs. – forest Feb 22 '18 at 06:39
  • I disagree. If you hack into it it's no longer a 'Trusted' PM, it's a 'Some' PM, which defeats the purpose of its existence. The only way to keep it trusted is to obtain the certifications and signatures. – Overmind Feb 22 '18 at 07:42
  • I was only talking about reprogramming the processor which runs (part of) the Intel TXT logic. I agree that it is harder to be sure that an fTPM is trustworthy when it is part of a system that has vulnerabilities that allow reprogramming. That is one reason I prefer a dTPM, despite the risks of attacks on the LPC bus. – forest Feb 22 '18 at 07:51