Desktop version

Home arrow Computer Science arrow A Practical Guide to TPM 2.0

Data Backups

Most PCs today have a lot of extra space on their hard drives. Most enterprises have many PCs with data that should be periodically backed up. It would be ideal if those PCs could back up their data on other PCs in the business. That way, as an enterprise expands with more PCs, the need to back up data and the available space on which to back up the data grow at the same rate. There are algorithms for backing up data in m copies, so that only n of the m copies need to be present to recover the data, and these algorithms can be made space efficient. However, this book doesn't describe those techniques, because we're concerned with another problem with this approach: how do you keep this backed-up data secure?

First, of course, the data must be encrypted in a way that only allows the owner of the data to access it. This can be done by having the TPM create an HMAC key and loading it in the TPM's persistent storage using TPM2_EvictControl. The filename can be HMACed to create a derived AES key that can then be used to encrypt the file before it's backed up.

(This provides a different key for each file and makes it easy to recover the AES key for those with access to use the HMAC key.) Alternatively, you can ask the TPM to generate an AES key (using its random number generator, so the key is unique for each file); that key can be encrypted with a public key whose private key is known to the TPM, and that AES key is used to encrypt the file. In either case, the HMAC key or private key should be backed up to another system's TPM in case of TPM failure.

Separation of Privilege

The end user today has to select and set authorization values for the storage hierarchy (owner authorization) for security, endorsement hierarchy (for privacy administration), and dictionary attack reset parameter (for TPM administration). This splits control of the TPM for different type of administrators. But finer control of these commands (particularly the owner authorization) may be required.

Chapter 10 gave a number of examples of different policies, but didn't examine how a policy for the storage hierarchy can be split. The owner of the storage hierarchy can create NV indexes, create primary storage hierarchies, and make keys persistent (and evict them from persistency), among other things. An administrator may very well want to allow an end user to create primary keys but not make them persistent, or make NV indexes but not evict persistent keys in the storage hierarchy.

If a storage root key (SRK) is made by an administrator and made persistent, then without owner authorization, it isn't possible to change the authorization value associated with this key. This is important, because that authorization is usually the empty buffer, in order to allow any software to use the SRK value stored in the TPM. If malicious code were to evict this key and then re-create it with a different authorization, it would be a type of denial of service attack.

But the end user may wish to allow software to use different algorithms than the default algorithm set chosen for the SRK. In this case, the owner may wish to allow the creation of SRK-like keys with different algorithm sets. As a result, the owner may wish software to be able to use keys created with TPM2_CreatePrimary. However, the owner may not wish to allow those keys to become persistent, because that uses precious resources in the TPM—another form of denial of service.

Finally, the owner may wish to allow software to create some NV RAM indexes that have a limited amount of space. But not all of these things can be done by choosing a correct policy.

To separate privilege, the owner first creates a long, random password for the ownerauthorization value and then makes sure it's held secure. This requires that the end user use the policy to accomplish their goals. Next, branches of that policy are created for each command code that the owner wishes the end user to be able to use. To allow use of TPM2_CreatePrimary, one branch can be TPM2_PolicyCommandCode with TPM2_CreatePrimary as a parameter. To allow only the creation of certain NVRAM indexes, the TPM2_PolicyCpHash command is used, with parameters for TPM2_NV_DefineSpace and specific parameters indicating the index to be created and the public parameters of that index, for each index that the owner wishes the end user to be able to create. (This is similar to opening a port in a firewall—just because it's there doesn't mean it will be used.)

< Prev   CONTENTS   Next >

Related topics