If you want to use a TPM to do duplication, you have to use a policy. But you can create the key entirely outside a TPM and wrap it up like a duplicated key, ready to be imported into the TPM with the referenced EK. If you do this, you don't need to associate a policy (other than the empty buffer) with the key. In this case, you need to write software that creates the three files to be used as parameters in the TPM2_Import command.
The first file contains the public data of the IDevID; the second holds the private data of the IDevID, encrypted with an AES key, together with an HMAC of both the public and private portions of the IDevID; and the third allows the TPM with the referenced
EK to calculate a seed from which the AES key and the HMAC key are derived. If the EK is an RSA key, the third file is merely the seed, encrypted with the public EK. A number of details must be determined to create these files; they're described well in the specification, particularly in parts 1 and 2.
If the IDevID is an RSA public key, it uses the TPM2B_PUBLIC structure (defined in Part 2, section 12.2.5.) This structure refers to a TPMT_PUBLIC structure, which is defined in section 12.2.4. The TPMT_PUBLIC structure in turn refers to a number of other structures and parameters:
• The TPMI_ALG_PUBLIC, which is TPM_ALG_RSA
• The TPMI_ALG_HASH, which is TPM_ALG_SHA256
• A TPMA_OBJECT bitmap, which describes the kind of key (you specify whether it's a signing key, duplicable, and so on, just as though you were creating the key)
The next two parameters in the TPMT_PUBLIC structure are unions:
• TPMU_PUBLIC_PARMS (see section 126.96.36.199). Given that your key is
TPM_ALG_RSA, it becomes TPMS_RSA_PARMS. (188.8.131.52)
• TPMU_PUBLIC_ID (184.108.40.206). Given that your key is TPM_ALG_RSA, it becomes TPMS_PUBLIC_KEY_RSA (the length and contents of the RSA public key).
We create the third file before the second one, though logically the public and private files go together. This is because we will need the third file to encrypt the second one. The third file is a seed encrypted with the new parent object. The seed can be generated using any random number generator (the TPM has a good one), and it should be the size of the hash—in this case, 256 bits long. Once you have this seed, you can use it to calculate two keys: an HMAC key to be used to prove the integrity of the linkage between the public and private sections of the key, and a symmetric encryption key to encrypt the private section. The HMAC key is found using equation 37, in section 22.5 of Part 1:
HMACkey := KDFa (pNameAlg, seedValue, "INTEGRITY", NULL, NULL, bits)
The encryption key you use is found in equation 35, just above the previous one:
symKey := KDFa (pNameAlg, seedValue, "STORAGE", name, NULL, bits)
You now must encrypt the seed with the EK public key. This is done in accordance with the annexes in Part 1. In particular for RSA, B.10.3 indicates that Optimal Asymmetric Encryption Padding (OAEP) using the RSA public key is used (as described in more detail in B.4, using DUPLICATE as the L parameter).
The private data is a TPM2B_PRIVATE structure, found in Part 2 12.3.7. It consists of a size and an encrypted private area. The encrypted private area consists of two pieces: an integrity area and a sensitive area. The sensitive area is calculated first.
The sensitive area consists of a TPMT_SENSITIVE area found in table 188 of 220.127.116.11. This is the TPMU_SENSITIVE_COMPOSITE, which table 187 says (for a TPM_ALG_RSA key) is a TPM2B_PRIVATE_KEY_RSAj. Table 160 specifies that this is one of the two primes, preceded by a 2-byte field containing the number of bits in the prime. It's encrypted using AES in cipher-feedback mode, where the IV is zero. This is found in equation 36, section 22.4, Part 1.
The integrity digest is an HMAC over the public and encrypted private data using the HMAC key calculated from the seed. This is calculated using the following equation:
outerHMAC := SHA256 (HMACkey, encrypted Sensitive area || TPM2B_PUBLIC)
The integrity digest is prepended to the sensitive area, and a size of the result
(2 bytes) is prepended to this, to create the final private data structure. Once this is done, these three files can be sent to the remote client PC, where they are imported using TPM2_Import and the EK as the new parent.
This technique is somewhat complicated, but it lets you create the key in any manner the administrator wishes and is the only way to create a duplicated key that has a null policy. This approach guarantees that it isn't possible to duplicate the key from the target PC's TPM to any other TPM, because the TPM always requires a policy to duplicate a key.
If you would like to generate your IDevID key yourself, perhaps because you have a trusted random number generator, but you don't wish to do the hard part of generating the three files, you can import the key directly into a local TPM (or emulator) and let it do the hard work of duplicating the key. This still requires the end user to generate the public data of the key in TPM format, including having a policy that allows for duplication. But the generation of the seed—deriving an AES key from the seed and encrypting the private portion, generating the HMAC from the seed, and calculating the HMAC of the public and private portions of the data—is left to the TPM to accomplish.
This approach uses the TPM2_LoadExternal command, which doesn't require that the private key be encrypted when it's loaded. At this point the user continues using the same steps in as Technique 1 after the key was created. Then the user loads the public portion of the EK, satisfies the policy for duplication, and duplicates the key to the EK. Doing so produces the three files, which the user can load into the TPM once the user is assured that the EK is indeed loaded on their system.