Take Control of TCPA
The Trusted Computing Platform Alliance (TCPA, www.trustedcomputing.org) has published open specifications for a security chip and related software interfaces. The TCPA chip is designed to provide client machines with a minimal but essential hardware base for client-side security. It provides two important security functions: secure storage of signature and encryption keys and system software integrity measurement. TCPA's secure storage can be used to protect an individual's RSA authentication private key or a loopback filesystem's master key from theft or disclosure. TCPA's integrity measurement can be used to detect software compromise, such as a rooted kernel, and to lock down use of protected keys and data if a compromise is found.
IBM is now shipping models of ThinkPad and desktop machines with TCPA chips. IBM has published a set of open-source tutorial code for TCPA, available at www.research.ibm.com/gsal/tcpa. This tutorial package is intended to help teach people about TCPA and to introduce programming of the TCPA chip under Linux.
In this article, we try to help you better understand the TCPA specification and tutorial package by introducing the fundamentals of TCPA, describing the IBM open-source TCPA tutorial package for Linux and explaining how you can use TCPA to sign documents and store the key for an encrypted loopback filesystem.
A TCPA security subsystem includes both hardware and software components. Functions provided by hardware are called TPM (trusted platform module) functions; those provided by software are TSS (trusted support services). From a programmer's perspective, the IBM version of the TPM (or TCPA chip) looks like Figure 1.
The TPM includes five cryptographic functional units. It has a hardware random number generator (RNG), which provides a source of high-quality random numbers for on-chip key generation, as well as for application use. It has a hash unit (SHA-1) and an associated hashing for message authentication calculator (HMAC). It also has the ability to generate RSA keys of up to 2,048 bits on the chip, based on random numbers supplied by the RNG. Finally, it has an RSA engine that can perform signatures, encryption and decryption. The TPM does not do signature verification, as this is not a sensitive operation and can be done more easily and quickly with software.
The TPM stores three important keys in non-volatile memory. The endorsement key is a 2,048-bit RSA public and private key pair, which is created randomly on the chip at manufacture time and cannot be changed. The private key never leaves the chip, while the public key is used for attestation and for encryption of sensitive data sent to the chip, as occurs during the TPM_TakeOwnership command. Because this key is sensitive from a privacy perspective, its use can be disabled completely by the TPM owner.
The storage root key (SRK) is a 2,048-bit RSA key pair. It is initially empty and is created as part of the TPM_TakeOwnership command. This key never leaves the chip. It is used to encrypt (wrap) private keys for storage outside the TPM and to decrypt them when they are loaded back into the TPM. The SRK can be cleared by the system owner.
The Owner Authorization secret key is a 160-bit secret shared with the owner of the TPM. The owner loads it into the TPM as part of the TPM_TakeOwnership command. This secret key is used to authorize sensitive owner command requests.
The volatile memory section contains ten slots for temporary storage of RSA key pairs. Any number of wrapped keys can be stored externally and loaded as needed into these slots for use. Although loaded keys are considered volatile and are not guaranteed to persist across power down, in the case of the IBM chip version, keys normally do persist and may need to be evicted to make room for the loading of new ones.
The volatile memory section also contains 15 platform configuration registers (PCRs). These registers contain 160-bit measurements (hashes) of software integrity. During system boot, measurements are taken of the BIOS, extension BIOSes, MBR, GRUB bootstrap stages and any designated files, such as the kernel. These measurements are added to various PCRs. The BIOS actively resets all PCR values at boot time power-on. When a system resumes from a suspended state, the BIOS tries to start the TPM in a mode that restores saved PCR values. For this to work, the TPM device driver must have issued a TPM_SaveState command right before the chip was suspended.
Volatile memory also is used to store two types of handles. Key handles are used to give temporary names to loaded keys, so subsequent commands can indicate which key should be used, if multiple keys are loaded. Key handles are cleared when the respective key is evicted. Authorization session handles are used to identify authorization state data across multiple commands. Authorization handles are created by TPM_OSAP and TPM_OIAP authorization commands, and they must be cleared with a TPM_Terminate_Handle command when no longer needed.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- Returning Values from Bash Functions
- My +1 Sword of Productivity
- Tech Tip: Really Simple HTTP Server with Python
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Doing for User Space What We Did for Kernel Space
- Rogue Wave Software's Zend Server
- Parsing an RSS News Feed with a Bash Script
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide