5

I know that the endorsement key (EK) of TPM is stored in non-volatile memory (e.g. EEPROM), which is non-migratable to ouside the TPM. Like EK, the Storage Root Key (SRK) is also non-migratable.

What makes them non-migratable? It is achieved by some protective code or the design of the internal IC structure?

Improve this question

3 Answers 3

Reset to default
2

It's the job of the firmware (the software running inside the TPM) to implement constraints such as non-migratability. A TPM is supposed to be physically protected, so the only way to extract a key is to use the commands that it implements. If none of the commands that the software implements returns the EK, then the EK is non-migratable.

You could say that it's a combination of both. The hardware protection makes all keys non-migratable by hardware means. The software running inside the protection boundary makes some keys migratable; it's designed so that EK are not included. But really, the useful answer to “what makes EK non-migratable” is the component that implements the policy, which is the software.

Improve this answer
2
  • For the hardware protection you mentioned, is it the physical security circuit (or other similar name) in those TPM products? e.g. If the attacker want to read the non-volatile memory by physical means, the protective circuit will make the TPM unreadable or cannot work anymore?
    – TJCLK
    Commented Oct 14, 2015 at 3:41
  • 4
    @LiDong That depends on the TPM's level of resistance against physical attacks, which I think varies between manufacturers. The protection isn't in the circuit itself but in the wrapping around it. Some of them are essentially bolted-on smartcards with a chip that's inside a protective layer which dissolves the chip in acid if exposed to air. Some of them are just ordinary chips. The biggest weak point in a TPM is the bus between it and the processor — attacks on that bus break a lot of TPM uses, but doesn't help if what you want is the EK.
    – Gilles 'SO- stop being evil'
    Commented Oct 14, 2015 at 11:56
3

Careful, the terminology is really getting fishy here.

I know the mistake is an honest one, but it doesn't make sense to even ask about the migratability of these keys.

The Endorsement Key is not "non-migratable". The idea of migration doesn't even apply to this keys. It is special. Its private portion is completely inaccessible outside of the TPM. Discussing its candidacy for migration is patently incorrect, imho.

That said, your question becomes ambiguous.

If you are asking "why can't I transfer the EK to another TPM", that is enforced by the TPM spec from TCG, the design abstractly considers this key as the root identity of a discrete chip.

If you are asking "how does a TPM keep this special key safe", then the other answers addressed this; the implementation is vendor specific. A physical IC TPM will probably be designed to physically secure the key in some way, and a software TPM will obviously have (well tested I hope) code that doesn't provide a code-path to output the key.

EDIT: I have edited my answer above to only discuss the EK. Previously I included the SRK also in those terms. However in A Practical Guide to Trusted Computing, chapter 3, the authors do discuss the SRK in terms of being non-migrateble. They do not, however, discuss the EK in these terms, suggesting, as I propose, that this key is unique.

Improve this answer
2
  • Yes, what I want is "how does a tpm keep these special keys safe". a further question is: what are the common ways to physically secure the keys?? now only one example I know is depending on the package of the chip. once the chip cover is opened, the internal circuit stuff will be damaged. but I'm not sure whether this is dependable, as the damaged circuit may be fixed?
    – TJCLK
    Commented Dec 10, 2015 at 3:59
  • 2
    This becomes a general discussion of photo-lithography, chip fabrication, and physical properties thereof. It is definitely NOT uniquely related to the TPM. However I think it is within the scope of this SE, just in another question. Then you can assume that a TPM manufacturer might use one of the techniques on their chip, but there is for sure no single answer related to the TPM, this concept is not in the TCG scope. In fact, the TPM spec is generally understood to NOT protect against adversary physical presence or physical attacks, making this discussion EVEN MORE out of TPM scope ;)
    – Wilbur Whateley
    Commented Dec 10, 2015 at 18:52
2

That is implementation specific and would depend on the manufacturer.

  • Physical TPM might use physical protection while;
  • Software-based TPMs will use code logic.
    • e.g. Intel's TPM implemented as Management Engine's (ME) application within the Platform Controller Hub (PCH).
Improve this answer
3
  • This is misleading. Even in a “proper” (physical) TPM, it's the firmware that implements migratability policies.
    – Gilles 'SO- stop being evil'
    Commented Oct 13, 2015 at 20:39
  • Does the TCG provide some specification about the code logic of migratability? or those manufacturers just establish their own designed code logic?
    – TJCLK
    Commented Oct 14, 2015 at 3:58
  • @LiDong Yes, absolutely. The rules about commands and policies are specified by TCG, I think this is in the library specification.
    – Gilles 'SO- stop being evil'
    Commented Oct 14, 2015 at 11:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .