The second use case for a security chip embedded on systems was to provide a means of encrypting keys that were used in turn to encrypt files on the hard drive or to decrypt files that arrived from other systems. Export regulations made putting a bulk encryption/ decryption engine in the security chip a nonstarter; but using the chip to store encryption keys was allowed, so that functionality was included. The chip already had to do public/ private encryption in order to perform cryptographic signing, so it was inexpensive to add the ability to decrypt a small amount of data containing a key that was encrypted with a public key, if the chip knew the private portion of the key.
Once this basic capability was available, it enabled a number of scenarios such as the following:
• File and folder encryption on a device
• Full disk encryption
• Encryption of passwords for a password manager
• Encryption of files stored remotely
One basic question the designers of the TPM had for possible users was, “How many keys do you think people will want to use with this chip?” If the answer had been “One or two,” there would have been sufficient room in the chip to store those keys. However, the answer received was “More than three.” Thus cost reasons made it infeasible to store all the keys on the chip, as was done in a smart card. However, the chip is used in PCs, which have hard disks and hence almost unlimited storage for keys—and TPG decided to make use of that fact.
The TPM has access to a self-generated private key, so it can encrypt keys with a public key and then store the resulting blob on the hard disk. This way, the TPM can keep a virtually unlimited number of keys available for use but not waste valuable internal storage. Keys stored on the hard disk can be erased, but they can also be backed up, which seemed to the designers like an acceptable trade-off. Cheap keys associated with a TPM enable a number of scenarios like these:
• Privacy-sensitive solutions that use different keys to provide only a minimum of information to a requestor: You don't need a single identity key that includes a user's age, weight, marital status, health conditions, political affiliation, and so on.
• Different keys for different security levels: Personal, financial, and business data as well as data that is contractually restricted all require different levels of confidentiality.
• Different keys for multiple users of the same PC: Sometimes several people share a computer. If that is the case, they typically don't want to give each other complete access to their files.
• “Hoteling” of PCs in an office: Keys are stored on a server and downloaded and used on a PC as required.