In this case, because the key is to be duplicated by the TPM, several things must be true. First, the key must be duplicable. This means it isn't a fixedTPM key, and it isn't a fixedParent key. Further, it must have a policy, because only keys with a policy can be duplicated. One of the following must be true for that policy:
• Use TPM2_PolicyCommandCode with TPM2_Duplicate as a parameter
• Use TPM2_PolicyDuplicateSelect
Either of these must be in at least one branch of the policy. You don't want the key to be duplicated beyond the target TPM, so if you use the first option, you have to add a further restriction to that policy branch—perhaps a TPM2_PolicySigned. In this case, the second solution is better: you simply fix the target of duplication (the new parent of
the key) to be the EK public key.
Further, for the IDevID key to act like an AIK, it must be a restricted signing key.
Use TPM2_Create to create the key on the server.
Next you have to use your enterprise CA to make a certificate for this key. Before this is done, the EK's certificate is checked to make certain it's valid. Then the certificate can say that the IDevID belongs to the PC with that EK. Because the key is a signing key, this shouldn't be difficult—a normal CA protocol should work.
To duplicate the key, you now create three files, each of which represents a parameter that will be used to import the IDevID key into the target PC with the specified EK.
You use the TPM (or emulator) with TPM2_Duplicate command to do this. (Of course,
you first have to start and satisfy the branch of the policy that allows duplication.) This command has three outputs, which will be put into three different files:
• TPM2B_PUBLIC: This structure is a description of the IDevID key, including its public part
• TPM2B_PRIVATE: This structure contains the private portion of the IDevID, symmetrically encrypted; and an HMAC value that binds it to the public portion
• An encrypted value that allows a TPM with the correct EK to regenerate a seed
These three outputs are inputs to the TPM2_Import command. The seed is used by the TPM to generate an AES key, which is used to decrypt the private key, and an HMAC key, which is used to verify that the public and private portions of the key haven't been meddled with.
Finally, you send the three files to the target PC. There, if the EK isn't currently resident, it's regenerated using TPM2_CreatePrimary. Then you use TPM2_Import, passing it the three files that were given to the PC as parameters. The TPM2_Import command
returns a normal TPM-encrypted blob, which can be used to load the IDEVID key into the TPM using the TPM2_Load command whenever the EK is present in the TPM.
The advantage of this technique is that the TPM (or emulator) does much of the work. The disadvantage is that the end user has to create a policy and also has to rely on the random number generator of the TPM or emulator. A hardware random number generator may be too slow, and a software one may not be high enough quality.