Autonomic personal computing is personal computing on autonomic computing platforms. Its goals combine those of personal computing with those of autonomic computing. The challenge of personal autonomic computing is to simplify and enhance the end-user experience, delighting the user by anticipating his or her needs in the face of a complex, dynamic, and uncertain environment. In this paper we identify the key technologies that enable autonomic behavior as distinguished from fault-tolerant behavior. We give some examples of current autonomic behavior and some general considerations for an architecture that supports autonomic personal computing. We identify its challenges to standards and technology developers and conclude with some guidance for future work.Autonomic personal computing is defined here as personal computing on autonomic computing systems. It shares the goals of personal computingresponsiveness, ease of use, and flexibility-with those of autonomic computing-simplicity of use, availability, and security. In most cases these goals are complementary. For example, autonomic computing enhances ease of use because it eliminates or simplifies some user responsibilities. But personal computing implies flexibility of location and of the hardware and software configuration, and this complicates the job of achieving autonomic behavior. It is easier to configure, heal, optimize, and protect a system in an environment that does not change. If we can achieve autonomic behavior while still meeting the unique needs of personal computing, millions of users will benefit worldwide.The intention of this paper, then, is to identify the unique demands and opportunities of autonomic computing with personal devices. Our ground rules are that we seek to achieve autonomic behavior of a personal computing system-personal computers (PCs) and their peers, networks, and servers-not just the PC alone. We also limit our focus to application platforms, not to applications themselves. This distinction is somewhat equivocal and quantitative, however, because yesterday's applications are often tomorrow's platforms.In what follows, we first look deeper into the meaning of the autonomic attributes of personal computing, which are different from fault-tolerant attributes. We then categorize technologies as they relate to achieving autonomic behavior in different variations: within the PC, in PC communities, and in more general systems that include servers. We give some examples of the state of the art and identify missing or incomplete capabilities. We describe some general considerations for an architecture that supports autonomic personal computing, identify some issues, and suggest a direction for future research and development.

Our passion in writing this book is to empower and excite a rising generation of IT managers, security architects, systems programmers, application developers, and average users to use the TPM as the bedrock of increasingly sophisticated security solutions that will stem the rising tide of threats that are being aimed at us, our employers, and our civil institutions. Furthermore, the TPM is just plain cool. How many engineers, as children, played with simple cryptography for fun? The ability to send an encrypted message to a friend appeals to the secretive part of our human nature-the same part that enjoyed playing spy games when we were young. And besides being fun, there's something inherently, morally right about protecting people's assets from being stolen.The TPM 2.0 technology can accomplish this. We believe in this technology and hope to make believers of you, our readers, as well. Our hope is that you'll get as excited about this technology as we are and "go out and do wonderful things" with it, to paraphrase Robert Noyce, one of Intel's founders. Why a Book?Technical specifications are typically poor user manuals, and TPM 2.0 is no exception. One reader of the specification claimed it was "security through incomprehensibility." Although the specification attempts to describe the functionality as clearly as possible, its prime objective is to describe how a TPM should work, not how it should be used. It's written for implementers of TPMs, not for application writers using TPMs.Also, for better or for worse, the detailed operations of the TPM commands are specified in C source code. The structures are defined with various keywords and decorations that permit the Word document to be parsed into a C header file. Microsoft agreed with TCG that the source code in the specification would have an open source license and could be used to implement a TPM. However, although C can describe actions very precisely, even the best code isn't as readable as text. One of the major purposes of this book is to interpret the specification into language that is more understandable to average software developers, especially those who need to understand the low-level details of the specification.Many readers don't need to understand the detailed operation of the TPM and just want to know how to use the various functions. These readers expect TSS (the TCG software stack) middleware to handle the low-level details. They're interested in how to use the new TPM features to accomplish innovative security functions. Thus, this book is just as concerned with describing how the TPM can be used as it is with explaining how it works. Throughout the book, as features are described, use cases for those features are interwoven. The use cases aren't complete-they describe what the TPM 2.0 specification writers were thinking about when those features were designed, but the specification is so rich that it should be possible to implement many things beyond these use cases.

No abstract

We present a Trusted Platform Module (TPM) application protocol that detects a certain man in the middle attack where an adversary captures and replaces a legitimate computing platform with an imposter that forwards platform authentication challenges to the captive over a high speed data link. This revised Cuckoo attack allows the imposter to satisfy a user's query of platform integrity, tricking the user into divulging sensitive information to the imposter. Our protocol uses an ordinary smart card to verify the platform boot integrity through TPM quote requests, and to verify TPM proximity by measuring TPM tickstamp times required to answer the quotes. Quotes not answered in an expected amount of time may indicate the presence of an imposter's data link, revealing the Cuckoo attack. We describe a timing model for the Cuckoo attack, and summarize experimental results that demonstrate the feasibility of using timing to detect the Cuckoo attack over practical levels of adversary link speeds.

Platform Configuration Registers (PCRs) are one of the essential features of a TPM. Their prime use case is to provide a method to cryptographically record (measure) software state: both the software running on a platform and configuration data used by that software. The PCR update calculation, called an extend, is a one-way hash so that measurements can't be removed. These PCRs can then be read to report their state. They can also be signed to return a more secure report, called an attestation (or quote). PCRs can also be used in an extended authorization policy to restrict the use of other objects.The TPM never passes judgment on the measurements. Internally, it doesn't know which measurements are good or bad, or more or less secure or trusted. At the time of measurement, TPM PCRs just record values. Security or trust comes later, when an application uses PCR values in an authorization policy, or a remote party asks for a signed attestation (quote) of the values and judges their trustworthiness.New for TPM 2.0, TPMs no longer hard-code the SHA-1 algorithm for PCRs. The algorithm can be changed. Some implementations include banks of PCRs, with each bank implementing a different algorithm.A TPM implements a number of PCRs: for example, 24 for a PC TPM. The PCRs are allocated by convention to the various software layers, from early boot code to the operating system and applications. They're also allocated for both the software to be run (often the even-numbered PCRs) and the configuration files that customize the boot process (typically the odd-numbered PCRs.) PCR ValueThe primary use case for a PCR is to represent the platform software state, the history of the critical software (and configurations) that have run on the platform until the present. The TPM initializes all PCRs at power on, typically to either all zeroes or all ones, as specified by the TPM platform specification. The caller can't directly write a PCR value. Rather, a PCR value is changed through what the TPM calls an extend operation, as described in Chapter 2. Cryptographically, it is as follows:PCR new value = Digest of (PCR old value || data to extend)