In a TPM, if I create a storage key by Storage Root Key (SRK) and store it outside TPM (migratable), the SRK can be its parent key to encrypt it.

If the storage key is generated by SRK and then stored outside TPM, can this storage key used to generate and encrypt a leaf key? Or only non-migratable storage key can be used to encrypt its leaf key?

What are the common case?

1 Answer 1


Migratable doesn't mean it is stored outside the TPM. All keys except the SRK and EK are stored outside the TPM.

The TPM protection comes from the fact that the blob stored outside the TPM are encrypted by the SRK and can only be used when we feed back in the TPM.

The 'migratable' distinction defines that a key is not tie to a specific TPM and can be used (with proper authorization) elsewhere. I suggest reading this document to understand the different migration process options even if it seems a little outdated.

IIRC, only the EK, SRK and Certification Keys cannot be migratable. You define whether a key is migratable or not at creation time.

Updated: Here's two other documents covering the process to different extent.

  • e.g. there is a "parent" key, which is directly below SRK, and its child keys are all migratable. If I want to decrypt and use its child key in the TPM, I must also load the parent key together? because its public key encrypted its child key private? For another example, if I want to migrate this key into another TPM, all its child keys must be migrated together?
    – TJCLK
    Oct 15, 2015 at 6:51
  • 1
    Actually, it would be better to have one migratable key as parent to all child so they can be migrated at once. The migration procedure will unwrap the migratable key from its non-migratable-parent and wrap it with a migration key. I've added two reference which explain in great length each options.
    – northox
    Oct 15, 2015 at 14:32

You must log in to answer this question.

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