Trusted Computing Platforms
Description
How can one trust computation taking place at a remote site, particularly if a party at that site might have motivation to subvert this trust? In recent years, industrial efforts have advanced the notion of a "trusted computing platform" as a building block. Through a conspiracy of hardware and software magic, these platforms attempt to solve this remote trust problem, to preserve various critical properties against various types of adversaries.
However, these current efforts are just points on a larger continuum, which ranges from earlier work on secure coprocessor design and applications, through TCPA/TCG, to recent academic developments. Without wading through stacks of theses and research literature, the general computer science reader cannot see this big picture.
Trusted Computing Platforms : Design and Applications fills this gap. Starting with early prototypes and proposed applications, this book surveys the longer history of amplifying small amounts of hardware security into broader system security - and reports real case study experience with security architecture and applications on multiple types of platforms. The author examines the theory, design, and implementation of the IBM 4758 secure coprocessor platform and discusses real case study applications that exploit the unique capabilities of this platform. The author discusses how these foundations grow into newer industrial designs, and discusses alternate architectures and case studies of applications that this newer hardware can enable. The author closes with an examination of more recent cutting-edge experimental work in this area.
Trusted Computing Platforms : Design and Applications is written for security architects, application designers, and the general computer scientist interested in the evolution and uses of this emerging technology.
More details
Other editions
Additional editions
Person
Content
Chapter 6 PLATFORM ARCHITECTURE (p. 73-74)
Chapter 2 laid out some motivations forTCPs. Chapter 3 surveyed the attack space. Chapter 4 reviewed some early design work in this area. Chapter 5 set the stage that resulted: my group at IBM had the chance to design and build a generic secure coprocessor platform, as a product, to enable TCP applications in the real world (even though IBM thought they were getting a crypto accelerator); however, this design needed to satisfy a range of commercial and security constraints.
This chapter lays out the the security architecture I developed with Steve Weingart to address these problems. One of the lessons I learned from this design experience is that elements of the design cannot be considered in isolation from each other. Consequently, this chapter begins by discussing the overall security architecture that we developed (Section 6.1). It then introduces each individual component: ensuring that secrets are destroyed upon tamper (Section 6.2); ensuring that secrets start out secret (Section 6.3); ensuring that the flaws inevitable in a rich computational environment do not reveal these secrets (Section 6.4, Section 6.5); and enabling developers to develop, deploy, and maintain code (Section 6.6). Section 6.7 then sketches how all these pieces work together.
(Later, Chapter7 will discuss how we ensure the resulting secure coprocessor application can prove it is "the real thing, doing the right thing"; Chapter 8 will discuss the formal modeling and validation techniques we used to increase assurance that the design works.)
6.1 Overview
In order to meet the requirements of Chapter 5, our architecture must ensure secure loading and execution of code, while also accommodating the flexibility and trust scenarios dictated by commercial constraints.
6.1.1 Security Architecture Secrets.
Discussions of secure coprocessor technology usually begin with "physical attack zeroizes secrets." Our security architecture must begin by ensuring that tamper actually destroys secrets that actually meant something. We do this with three main techniques:
* The secrets go away with physical attack. Section 6.2 presents our tamperdetection circuitry and protocol techniques. These ensure that physical attack results in the actual zeroization of sensitive memory.
* The secrets started out secret. Section 6.3 presents our factory initialization and regeneration/recertification protocols. These ensure that the secrets, when first established, were neither known nor predictable outside the card, and do not require assumptions of indefinite security of any given key pair.
* The secrets stayed secret despite software attack. Section 6.4 presents our hardware ratchet lock techniques. These techniques ensure that, despite arbitrarily bad compromise of rewritable software, sufficiently many secrets remain to enable recovery of the device.
Code. Second, we must ensure that code is loaded and updated in a safe way. Discussions of code-downloading usually begin with "just sign the code." However, focusing on code-signing alone neglects several additional subtleties that this security architecture must address. Further complications arise from the commercial requirement that this architecture accommodate a pool of mutually suspicious developers, who produce code that is loaded and updated in the hostile field, with no trusted couriers.
