Take Control of TCPA
Some TPM commands require authorization. Owner-related commands normally require authorization based on knowledge of the owner authorization 160-bit secret. Similarly, the use of keys may require authorization based on the key's authorization secret. Normally, this is done in the form of a hash of password, or PIN, applied to the key when it is created.
The TPM supports two protocols for this authorization: Object Independent Authorization Protocol (OIAP) and Object Specific Authorization Protocol (OSAP). Both protocols are similar in that they create an authorization context with a handle returned to the user, and they both use rolling nonces. The main difference is OIAP creates a long-term session with a new session secret key, and it can be used across multiple objects within a session. OSAP relates to a single object, such as a given key. In the case of TPM_TakeOwnership, OIAP must be used because the objects and secrets have not yet been established. In most other cases, either authorization protocol may be used.
TPM_OIAP and TPM_OSAP both create authorization handles that should be terminated (freed) when finished. This is done with the TPM_Terminate_Handle command.
We are ready to perform the essential TPM_TakeOwnership. This command executes four critical functions: it installs the owner-supplied owner authorization secret, creates the SRK, applies the owner-supplied SRK authorization secret and, optionally, returns the Public SRK portion to the owner. With the SRK available, we now have a functional TPM and are able to create and use signature and encryption keys.
TPM_CreateWrapKey generates a new RSA key on the chip, using the hardware RNG. A key must be typed as being either for signing or for encryption/decryption. The TPM does not allow a signature key to encrypt or an encryption key to sign, as this can lead to attacks. A key optionally may be given a secret that it is required to produce to use the key in the future. In addition, keys can be wrapped to specified PCR values. If this is done, both the authorization data and specified PCR data must match to use the key. All keys must have a parent key—it may be the SRK—that is used to encrypt the private part of the key, before the key structure is returned to the user. The returned key data must be stored by the user for future loading.
TPM_LoadKey is used to load a key into one of the volatile key storage slots in the TPM. This command requires the authorization password for the parent key; once loaded, the TPM uses the parent key to decrypt the loaded key's private data for use. If the key has an authorization secret, it is not needed to load the key, but it is required for any subsequent command that tries to use the key for encryption or signing.
Because a limited number of key slots are available in the TPM, when a key is no longer needed, it must be evicted to make the slot available for other keys.
The TPM_Sign command uses a loaded key to sign presented data, normally the hash of the actual data. TPM_Seal is used to perform RSA encryption of data; it requires a loaded encryption key and any authorization secret for that key. TPM_Seal also may specify PCR values to be used in the seal. If a future unseal is attempted without matching PCR values, the unseal fails. TPM_Seal also applies a used supplied data authorization value (password) to the sealed data. Thus, to unseal the data, the user may require the password for the sealing key and for the data, and the PCR values may have to match. TPM_Unseal performs the corresponding unseal operation.
The IBM TCPA tutorial package provides source code for five major components: device driver, libtcpa, examples, GRUB patch and loopback patch.
The device driver code allows you to compile a tpm.o loadable module for your kernel. The libtcpa code provides easy-to-use C interfaces for the application level TPM commands discussed in this article. The example programs demonstrate how to use libtcpa to do common actions, including taking ownership, creating keys, loading keys, signing, sealing and unsealing. The GRUB patch is a source code patch to the GRUB bootloader. It adds support for PCR measurement of grub itself and of any designated files, such as the kernel. The loopback patch is a source code patch to the loopback driver and associated utilities. This patch allows the loopback encryption key to be stored in TPM sealed form and releases it only if presented with the corresponding password and only if the PCR values match. With this patch installed, loopback mounting appears normal; it asks for a password, but this password is used to authorize only the unsealing of the actual loopback key data.
So, what does the use of the TCPA chip for signing and sealing/unsealing do for us? Our private keys are created on the chip, and they never leave the chip unless encrypted under a protected public key. The use of the PCRs also can protect our keys by refusing to authorize their use if the system has not been booted in the proper way, or if the integrity of measured files has been compromised. Sealing a loopback key similarly can protect against alternative booting and compromised software.
|Speed Up Your Web Site with Varnish||Jun 19, 2013|
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?