Key Trees: Keeping Keys in a Tree with the Same Algorithm Set
Although it's technically possible to mix algorithms—make a key with one set of algorithms and then store it under a key with a different set of algorithms—it's a bad practice (and one, as you have seen, that the TSS Feature Application Programming Interface [FAPI] won't allow.) The problem is that the strength of a set of keys is dictated by the strength of the weakest key in a chain. This means not only should algorithm sets not be mixed, but chains of keys (with one key wrapping another one) should generally be kept fairly short. If any key in a chain is broken, then all keys below it are broken. So a key chain of four keys is four times weaker than a chain with one link when exposed to a brute force attack. (Of course, given a reasonable key size, a factor of 4 is unimportant.)
The reason you might decide to have a longer chain is manageability. A user may want to migrate their entire set of keys or a subset of those keys from one system to another system, or duplicate their set of keys among two or more computers. In order to make this easy, it's likely that the user will wish to rewrap only one key—at the top of a tree of keys—with the public key on a different system and then copy the encrypted blobs that represent their other keys to the appropriate location in the other system.
You might want to keep enterprise keys separate from personal keys, and different department keys separate in an enterprise, as shown in Figure 15-1. Nevertheless, it's best to keep key trees as short as possible.
Figure 15-1. Example key tree
In the key tree in Figure 15-1, the keys that might be duplicated are the Personal Key, the Enterprise Key, the Financial Keys (both Personal and Enterprise), the Entertainment Key, or the HR Key. In order to do this, all of these keys must be created to be duplicable, and they must have a policy created for them that has TPM2_Policy_CommandCode
with TPM2_Duplicate selected (along with whatever restrictions are associated with duplicating a key). In most cases, a user creates two different duplication policies—one for personal keys and one for business keys—and associates those policies with a parent personal duplicable key (PDK) and a business duplicable key (BDK).
If a key isn't going to be duplicated, it can be made fixedParent. If a key under the SDK or UDK is going to be duplicated apart from the SDK or UDK, then it also must have a policy that allows for duplication.
With TPM 1.2, it wasn't possible to create a key that could be duplicated only to a few specified new parents and no others. With TPM 2.0, this is now possible using a
command called TPM2_DuplicationSelect. This command allows you to specify exactly
which parent (or parents) a key is targeted to be duplicated to. The main reason for using this command is in conjunction with PolicyAuthorize. By using PolicyAuthorize, an
IT organization can change the target backup key for duplication. So if the organization normally backs up keys to a specified server, and that server dies, then by signing a TPM2_ DuplicationSelect command that selects a new server, the organization can mail out
a new signed policy to employees, knowing that they now are allowed to duplicate their keys to the new server. This allows the new duplication target without allowing employees to back up their keys to their home computers (which may not be trusted).
Because TPM2_Duplicate and TPM2_DuplicateSelect can't be authorized with a password or an HMAC session, in order to duplicate a key, you must first start a policy session and then satisfy the branch of the policy that has the TPM2_PolicyCommandCode linked with TPM2_Duplicate or TPM2_DuplicationSelect. Then you can execute the appropriate command to duplicate the key to a new parent.
In this use case, a set of SSL servers acts as a failover for one another or for load balancing. the company doesn't want users to need to know which server they're connected to—it isn't something users care about. So the company needs the same key to exist on all the servers that are being used to service its web page. (this also means the company has to get only one certificate for this key, instead of a separate key for each server.)
the company creates a duplicable key with a PolicyAuthorize command as the policy and then uses the private key associated with the PolicyAuthorize command to sign several TPM2_DuplicationSelect commands, each of which points to a different server. a user gets this key certified and puts a copy of the certificate on each server. the user then duplicates the key from the original server
to all the other servers, and finally imports the key using TPM2_Import into each of the other servers. at this point, all the servers look identical to an outside user.
1. Create policy p using TPM2_PolicyAuthorize, an enterprise public signing key, and a policyRef of SSL.
2. Create a duplicable key using policy p on the initial SSL server.
3. Create restricted storage keys on all the other SSL servers using TPM2_Create, and call them SrKi.
4. Use the enterprise private key to sign TPM2_PolicyDuplicateSelect, selecting the SrKi public as the target of duplication. Do this once for each SrK.
5. Use TPM2_VerifySignature on the initial SSL server to create a ticket for each signed policy. this allows that signed policy to be used by the initial SSL server for duplication.
6. For each policy, create a duplicated key that can be loaded by SrK by doing the following on the initial SSL server:
a. Load the enterprise public signing key using TPM2_Load.
b. Load the SrK public key into the initial SSL server using TPM2_LoadExternal.
c. Use TPM2_StartAuthSession to start a policy session.
d. execute TPM2_PolicyDuplicationSelect, selecting the SrK of one of the target servers.
e. execute TPM2_PolicyAuthorize, using the policy, a policyRef of SSL, and the Ticket corresponding to SrK
f. execute TPM2_Duplicate, passing it the handle of the loaded SrK public and the handle of the enterprise signing key.
g. the result of the TPM2_Duplicate command is an encrypted version of the enterprise signing key. Send it to the server with SrKi.
h. Import the duplication blob into the server with SrKi.
7. Copy the certificate of the enterprise signing key to that server.
at this point, the key is the same on all the servers and can be used for SSL identification and communication.