9

I see that there is an increasing number of PCs shipped with firmware based TPM (fTPM), e.g. the Intel NUC.

As far as I understand, these solutions practically emulate a TPM chip using the CPUs special instructions (ARM TrustZone or Intel SGX). This makes fTPM a cheaper and more simple solution, since there is no need for another chip in the system.

However, discrete TPM chips have some degree of protection against physical attacks, but I don't see how is this possible with current fTPM implementations.

For example in this paper on the subject, the authors explicitly state, that this form of attack was not considered:

[...] However, we do not defend against power analysis or other sidechannel attacks that require physical access to hardware or hardware modifications.

That paper also lists a number of shortcomings for an Intel SGX based approach. Are these limitations addressed by later development? Platform Trust Technology (PTT), maybe?

Or am I missing something, and the private keys generated by the fTPM cannot be read even with physical access?

KovBal
  • 313
  • 2
  • 8
  • 1
    Many motherboards with a hardware TPM are also vulnerable to physical attacks. Even if the TPM itself is hardened — which AFAIK many aren't — the bus between the CPU and the TPM usually isn't, so even if the attacker can't extract the key from the TPM, they can make it believe that the CPU is in a good state and make the TPM sign stuff. – Gilles 'SO- stop being evil' Feb 26 '17 at 18:01
  • @Gilles this question is more about possible offline attacks against fTPM implementations, and not about comparison of software and hardware TPM implementations. – KovBal May 28 '17 at 16:37

1 Answers1

-2

Every software implementation is weaker than the hardware one. If a real chip for tpm is done to be resistant to even physical tampering, the CPU is a general purpose chip and can be easily traced

Alexey Vesnin
  • 1,565
  • 1
  • 8
  • 11
  • 5
    A software implementation is not necessarily weaker, than a hardware one. Bad solutions exists in both software _and_ hardware. Do you have any source that claims that an fTPM solution is not resistant to this form of attack? – KovBal Dec 29 '16 at 13:06
  • I used to see and apply an in-place debuggers, like Periscope back in old 90-s, this debugger takes *out* your entire CPU chip and sockets itself in it's place, the CPU chip is placed on it's board. A *very* useful device, and I'm seriously doubting that it has no successors. In case of using such a devices *everything* your CPU does is traced, so the software TPM keys can be sniffed too. In hardware TPM the chip itself is made to be resistant to key extraction out of it. I don't claim that HW is always better than SW, but this case SW lacks a HW built-in security, I think – Alexey Vesnin Dec 29 '16 at 13:43
  • a little update: a link to Periscope description, so you will have a better understanding what I'm talking about: http://www.os2museum.com/wp/have-you-ever-used-one-of-these/ – Alexey Vesnin Dec 29 '16 at 20:17
  • 2
    @AlexeyVesnin OP mentions TrustZone and SGX, which are not normal instructions you can emulate. They provide a simple but still HW-based root-of-trust the TPM firmware can be buily upon. In other words, an fTPM is not *purely* done in software. – SquareRootOfTwentyThree Dec 31 '16 at 15:27
  • @SquareRootOfTwentyThree the thing is that a hardware CPU debugger does not emulate anything - it just records *every* instruction that is coming to CPU. About emulation you are 100% correct - this kind of debuggers is not emulating at all, so potentially they can wiretap the key used, – Alexey Vesnin Dec 31 '16 at 17:18
  • 6
    SGX and several TZ implementation encrypt the memory bus: wiretapping does not lead any information. As a matter of fact, this potentially makes them more secure than having TPM implemented via a separate chip on the motherboard. – SquareRootOfTwentyThree Jan 03 '17 at 11:57
  • The question is how the encryption and ftpm code is started. If it is stored inside CPU somehow, then you're right. My potential attack vector is wiretapping the code before it is executed, I.e. to encrypt the memory bus you need to load the key. The question is where and how it is stored – Alexey Vesnin Jan 03 '17 at 13:02
  • Any reference material or proof? I don't see why any low-density TPM chip should be better protected than a ultra high integrated protection zone on modern CPUs. – eckes May 27 '17 at 18:48
  • 1
    What do you mean "can easily be traced"? This makes no sense. Not to mention, a dTPM (especially pre-1.2) is vulnerable to platform reset attacks, which do not affect fTPM. – forest Nov 29 '17 at 18:07
  • If by traced you mean tapping the traces, then I will say that would be exceptionally difficult, given the incredible speeds (and insane encoding techniques) they use. There's a reason people use JTAG for debugging now days instead of something like Periscope. Even if you could tap between the chipset and the socket, you wouldn't be able to compromise the TPM through any attacks that are applicable to dTPM on the LPC bus, since the communication between the CPU and the TPM is entirely within the monolithic chipset. – forest Jan 24 '18 at 13:53
  • @forest yes, this kind of tracing I was talking about. The weak spot is that the keys and other stuff are *not* stored inside CPU like in real TPM chips, so - if tracing from the power-on moment - you'll catch it being uploaded to the chip, that's my point. True TPM chips are not just having all this stuff inside them - they're specially made to be tamper-resistant and intrusion-resistant *on a physical chip level*, that's why they're so expensive. – Alexey Vesnin Jan 24 '18 at 16:32
  • 1
    But it _is_ stored inside the CPU. I mean technically it is stored in the chipset (since the CPU is a specific part of the chipset), but it is stored in the physical component itself, which is tamper-resistant. You can't monitor traces to get the keys anymore than you can intercept data between the PCH and CPU. To get the keys, you would have to either 1) attack the CPU to compromise it (glitching, etc), 2) debug it with JTAG, or 3) physically decap it and get at the internal, microscopic traces. There is no exposed bus carrying the keys like there is for the LPC on a dTPM. – forest Jan 25 '18 at 04:48