Smith Trusted Computing Platforms

Design and Applications
2005
ISBN: 978-0-387-23917-0
Verlag: Springer US
Format: PDF
Kopierschutz: 1 - PDF Watermark

E-Book, Englisch, 246 Seiten, eBook

From early prototypes and proposed applications, this book surveys the longer history of amplifying small amounts of hardware security into broader system security

Including real case study experience with security architecture and applications on multiple types of platforms.

Examines the theory, design, implementation of the IBM 4758 secure coprocessor platform and discusses real case study applications that exploit the unique capabilities of this platform.

Examines more recent cutting-edge experimental work in this area.

Written for security architects, application designers, and the general computer scientist interested in the evolution and use of this emerging technology.

Zielgruppe

Research

Autoren/Hrsg.

Smith, Sean W.

Inhaltsverzeichnis

1 Introduction. 1.1 Trust and Computing. 1.2 Instantiations. 1.3 Design and Applications. 1.4 Progression. 2 Motivating Scenarios. 2.1 Properties. 2.2 Basic Usage. 2.3 Examples of Basic Usage. 2.4 Position and Interest. 2.5 Examples of Positioning. 2.6 The Idealogical Debate. 2.7 Further Reading. 3 Attacks. 3.1 Physical Attacks. 3.2 Software Attacks. 3.3 Side-channel Analysis. 3.4 Undocumented Functionality. 3.5 Erasing Data. 3.6 System Context. 3.7 Defensive Strategy. 3.8 Further Reading. 4 Foundations. 4.1 Applications and Integration. 4.2 Architectures. 4.3 Booting. 4.4 The Defense Community. 4.5 Further Reading. 5 Design Challenges. 5.1 Context. 5.2 Obstacles. 5.3 Requirements. 5.4 Technology Decisions. 5.5 Further Reading. 6 Platform Architecture. 6.1 Overview. 6.2 Erasing Secrets. 6.3 The Source of Secrets. 6.4 Software Threats. 6.5 Code Integrity. 6.6 Code Loading. 6.7 Putting it All Together. 6.8 What's Next. 6.9 Further Reading. 7 Outbound Authentication. 7.1 Problem. 7.2 Theory. 7.3 Design and Implementation. 7.4 Further Reading. 8 Validation. 8.1 The Validation Process. 8.2 Validation Strategy. 8.3 Formalizing Security Properties. 8.4 Formal Verification. 8.5 Other Validation Tasks. 8.6 Reflection. 8.7 Further Reading. 9 Application Case Studies. 9.1 Basic Building Blocks. 9.2 Hardened Web Servers 9.3 Rights Management for Big Brother's Computer. 9.4 Private Information. 9.5 Other Projects. 9.6 Lessons Learned. 9.7 Further Reading. 10 TCPA/TCG. 10.1 Basic Structure. 10.2 Outbound Authentication. 10.3 Physical Attacks. 10.4 Applications. 10.5 Experimentation. 10.6 TPM 1.2 Changes. 10.7 Further Reading. 11 Experimenting with TCPA/TCG. 11.1 Desired Properties. 11.2 The Lifetime Mismatch. 11.3 Architecture. 11.4 Implementation Experience. 11.5 Application: Hardened Apache. 11.6 Application: OpenCA. 11.7 Application: Compartmented Attestation. 11.8 Further Reading. 12 New Horizons. 12.1 Privilege Architectures. 12.2 Hardware Research. 12.3 Software Research. 12.4 Current Industrial Platforms. 12.5 Looming Industry Platforms. 12.6 Secure Coprocessing Revisited. 12.7 Further Reading. Glossary. References. About the Author. Index.

Leseproben

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.

Über Autor(innen)

Sean Smith is currently on the faculty of the Department of Computer Science at Dartmouth College, serves as director of the Cyber Security and Trust Research Center at Dartmouth's Institute for Security Technology Studies, and also serves as Principal Investigator of the Dartmouth PKI Lab. His current research and teaching focus on how to build trustworthy systems in the real world. He previously worked as a scientist at IBM T.J. Watson Research Center, doing secure coprocessor design, implementation and validation; and at Los Alamos National Laboratory, doing security designs and analyses for a wide range of public-sector clients. Dr. Smith was educated at Princeton (B.A., Math) and Carnegie Mellon (M.S., Ph.D., Computer Science).