I've written a tutorial on TPMs. One thing I really recommend is thinking of "credential activation" as something rather more general: encryption to a public key but with an arbitrary authorization policy that will be enforced by the holder of the private key (the TPM).
The credential activation primitive was intended for sending things like certificates to targets such that they could recover them IFF they could satisfy some policy, and thus the name "credential activation". But the "credential" needn't be a "credential" -- it can be anything at all.
TPM2_MakeCredential() takes a public key, a cryptographic name of an "activation object", and a plaintext payload, and produces a ciphertext that will be decrypted by TPM2_ActivateCredential() IFF the caller of TPM2_ActivateCredential() has access to the private key object matching the public key argument to MakeCredential and access to a key object that has the same cryptographic name as was used as the activation object by the caller of MakeCredential. The key is that the cryptographic name of the activation object binds its attributes including any authorization policy. Note that the private part of the activation object is not used at all in the process, only its cryptographic name. And TPM authorization policies are extremely flexible.
To recap: to decrypt the ciphertext, the caller of TPM2_ActivateCredential() has to satisfy whatever authorization policy was specified by the sender or otherwise agreed upon ahead of time.
Trammell Hudson figured out that TPM2_Duplicate()/TPM2_Import() can be used to produce much the same asymmetric encryption with TPM-enforced policy for decryption.
The fact that a device as resource-constrained as a TPM can enforce incredibly complex authorization policies is astounding and fascinating, and ultimately comes down the fact that TPM 2.0 extended access policies are Merkle hash trees, so that at any point in policy evaluation a TPM need only have a fixed amount of state + enough memory to evaluate one node of the policy.
TPM is a very large topic. When explaining TPMs to people I like to first cover substance[0] at a very high level, then form[1], then really dive into substance: PCRs and event logs, how all keys created on a TPM are created deterministically from the key's hierarchy's seed and a caller-supplied template (which can include entropy), then cryptographic names of keys, then authorization policies, then finally TPM2_MakeCredential()/TPM2_ActivateCredential(), then TPM2_Quote(), and finally how to put together cryptographic protocols using a TPM.
[0] Some of what all you can do with a TPM.
[1] That it's all request/response commands,
that it has a micro-TLS protocol embodied
in one of those commands, that it is a
mostly-stateless protocol with encrypted
state cookies.
I have learned a fair bit since I wrote it, so I should probably edit it. If you read it and have feedback, feel free to open issues against it or comment here.
BTW, I highly recommend https://tpm.dev/! It's a fantastic community of TPM users and developers, and a great resource for newcomers.
I spent some time a few years ago working with TPM 1.2, but I haven’t caught up on the massive changes in 2.0.
(I was not impressed by the state of the 1.2 ecosystem. I may have had some choice words for the TSPI APIs and the trousers stack. The C APIs were trying to give gets a run for its money.)
TPM 1.2 is not very good. TPM 2.0 is pretty impressive.
I'm also not impressed with the tpm2-tools project. But there's a fair bit of code out there.
The neatest thing about TPM 2.0 is its extended access policies, and how blockchains (before they were called that), and encrypted state cookies (and key derivation templates) all adds up to letting one make do with the very limited memory resources that a TPM has.
I'd really like a high-performance, HSM-like, TPM. Or a high-performance HSM with a TPM 2.0 interface.
The credential activation primitive was intended for sending things like certificates to targets such that they could recover them IFF they could satisfy some policy, and thus the name "credential activation". But the "credential" needn't be a "credential" -- it can be anything at all.
TPM2_MakeCredential() takes a public key, a cryptographic name of an "activation object", and a plaintext payload, and produces a ciphertext that will be decrypted by TPM2_ActivateCredential() IFF the caller of TPM2_ActivateCredential() has access to the private key object matching the public key argument to MakeCredential and access to a key object that has the same cryptographic name as was used as the activation object by the caller of MakeCredential. The key is that the cryptographic name of the activation object binds its attributes including any authorization policy. Note that the private part of the activation object is not used at all in the process, only its cryptographic name. And TPM authorization policies are extremely flexible.
To recap: to decrypt the ciphertext, the caller of TPM2_ActivateCredential() has to satisfy whatever authorization policy was specified by the sender or otherwise agreed upon ahead of time.
Trammell Hudson figured out that TPM2_Duplicate()/TPM2_Import() can be used to produce much the same asymmetric encryption with TPM-enforced policy for decryption.
The fact that a device as resource-constrained as a TPM can enforce incredibly complex authorization policies is astounding and fascinating, and ultimately comes down the fact that TPM 2.0 extended access policies are Merkle hash trees, so that at any point in policy evaluation a TPM need only have a fixed amount of state + enough memory to evaluate one node of the policy.
TPM is a very large topic. When explaining TPMs to people I like to first cover substance[0] at a very high level, then form[1], then really dive into substance: PCRs and event logs, how all keys created on a TPM are created deterministically from the key's hierarchy's seed and a caller-supplied template (which can include entropy), then cryptographic names of keys, then authorization policies, then finally TPM2_MakeCredential()/TPM2_ActivateCredential(), then TPM2_Quote(), and finally how to put together cryptographic protocols using a TPM.