Is there a reason to require a TCTI for policy tools that do not interact with the TPM when they are not invoked with --policy-session? I need to build an policy for create a duplicate object and do not want to be throttled by talking to the physical TPM.

I think you mean trial session. I think policy sessions need to hit the TPM to cause the internal policy state to change for authorizing to the TPM. I was thinking about this the other day and was in the midst of opening a bug, this way trial sessions for generation won't be bound to the policy commands.

As a workaround I can pre-compute the policy hash and hard-code it in the scripts, but that is not as flexible:

echo 'fd32fa22c52cfc8e1a0c29eb38519f87084cab0b04b0d8f020a4d38b2f4e223e' \
        | xxd -p -r > policy.dat

tpm2 duplicate \
        --tcti none \
        -U ek.pub \
        -G rsa \
        -L policy.dat" \
        -k transport-priv.pem \
        -u transport.pub \
        -r transport.dpriv \
        -s transport.seed

This is likely unrelated, but using a 64-byte hex dump instead of the 32-byte binary file "works" for tpm2 duplicate, but the tpm2 import fails with an HMAC size error:

WARNING:esys:src/tss2-esys/api/Esys_Import.c:323:Esys_Import_Finish() Received TPM Error 
ERROR:esys:src/tss2-esys/api/Esys_Import.c:110:Esys_Import() Esys Finish ErrorCode (0x000002d5) 
ERROR: Esys_HMAC(0x2D5) - tpm:parameter(2):structure is the wrong size
ERROR: Unable to run import

I should have phrased that a little differently... I understand why --policy-session interaction requires a TPM; I'm trying to use non-policy / trial sessions to build the policy hashes to provide to the tpm2 duplicate command.

I should have phrased that a little differently... I understand why --policy-session interaction requires a TPM; I'm trying to use non-policy / trial sessions to build the policy hashes to provide to the tpm2 duplicate command.

So no reason except that TPM is convenient. One could implement this with the --tcti=none, proper hashing logic and ensure that no audit session is present in the auxiliary sessions (or error).

Ideally every operation that can be implemented in software should be available as implemented in software so as to avoid needing to spin up a software TPM and resource manager. The list of things to implement in software:

• TPM2_MakeCredential()
• TPM2_Duplicate() (whenever the key being duplicated is a software key)
• TPM2_LoadExternal() when a) loading a public key and b) intending only to use the name (but not qualified name) of the resulting key
• TPM2_LoadExternal() when "loading" a software key only to then TPM2_Duplicate() it
• TPM2_Policy*() executed in trial sessions
• TPM2_StartAuthSession() when starting a trial session
• command and session audit verification
• hash extension (this one is easy using just shell tools anyways)

Use case: encryption to EKpubs with sender-selected policy. There are two ways to encrypt to an EKpub:

• create or load a key (optionally with userWithAuth and the desired policyDigest) duplicate a key pair to the EKpub then encrypt to the public key of that key pair
• make credential a session key to the EKpub and use as the activation object the cryptographic name of a key that optionally has adminwithpolicy and a desired policyDigest

The decrypt side is TPM2_Import() then TPM2_RSA_Decrypt() for the duplicate case, or TPM2_ActivateCredential() for the alternative (with an activation object produced by TPM2_LoadExternal() of an agreed or well-known key with the same cryptographic name (therefore public area) as used by the sender. If a policy was asserted by the sender, then the recipient will have to execute and satisfy that policy in order to call TPM2_RSA_Decrypt() or TPM2_ActivateCredential().

The sender side of all of this can be entirely implemented in software.