3 ms·

This may be dumb question, but is the parent/child key relationship defined such that parent key wraps the child key?

cryptonector 4y ago
Not a dumb question! The "TPM 2.0 Library part 1: Architecture" spec[0], section 23.2, describes the hierarchical relationships between objects. A child of a derivation parent is derived from the parent, and can be re-derived as needed, therefore it doesn't need to be wrapped. A child of a storage key is wrapped in [a symmetric key derived from a seed associated with] that key. There are also two cryptographic names for each object, one that includes the parent's cryptographic name in the child's name, and one that does not. [0] https://trustedcomputinggroup.org/wp-content/uploads/TCG_TPM2_r1p59_Part1_Architecture_pub.pdf
- cryptonector 4y ago
  I should add that the main reason for this distinction between derivation and storage parents is that for keys generated on the TPM where you find them you just don't have to wrap those keys when you generate them as derived from [ultimately the hierarchy's seed] and a template, but that option is not available when importing keys generated elsewhere. The latter is called 'key duplication'. An entity can create a TPM2_Duplicate() [0] output payload encrypted to a TPM's key that the TPM can then TPM2_Import() then TPM2_Load(), and then that key at that target TPM cannot have a derivation parent since it isn't derived from any key on that TPM, therefore the only way to keep it around is to wrap it in some other key on that TPM, and that's where the storage keys come in. [0] In software, or on another TPM where the key being duplicated is not fixedTPM and fixedParent. Yes, one can generate keys on a TPM that can be extracted or sent to specific other TPMs, or not at all, at the user's choice. Which means that one can set up a ring of TPMs to hold a given key, for example. I.e., TPMs can function as HSMs.

Not a dumb question! The "TPM 2.0 Library part 1: Architecture" spec[0], section 23.2, describes the hierarchical relationships between objects. A child of a derivation parent is derived from the parent, and can be re-derived as needed, therefore it doesn't need to be wrapped. A child of a storage key is wrapped in [a symmetric key derived from a seed associated with] that key. There are also two cryptographic names for each object, one that includes the parent's cryptographic name in the child's name, and one that does not. [0] https://trustedcomputinggroup.org/wp-content/uploads/TCG_TPM2_r1p59_Part1_Architecture_pub.pdf

cryptonector 4y ago
I should add that the main reason for this distinction between derivation and storage parents is that for keys generated on the TPM where you find them you just don't have to wrap those keys when you generate them as derived from [ultimately the hierarchy's seed] and a template, but that option is not available when importing keys generated elsewhere. The latter is called 'key duplication'. An entity can create a TPM2_Duplicate() [0] output payload encrypted to a TPM's key that the TPM can then TPM2_Import() then TPM2_Load(), and then that key at that target TPM cannot have a derivation parent since it isn't derived from any key on that TPM, therefore the only way to keep it around is to wrap it in some other key on that TPM, and that's where the storage keys come in. [0] In software, or on another TPM where the key being duplicated is not fixedTPM and fixedParent. Yes, one can generate keys on a TPM that can be extracted or sent to specific other TPMs, or not at all, at the user's choice. Which means that one can set up a ring of TPMs to hold a given key, for example. I.e., TPMs can function as HSMs.