Smith Trusted Computing Platforms

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

E-Book, Englisch, 246 Seiten

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.

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).

Autoren/Hrsg.

Smith, Sean W.

Inhaltsverzeichnis

1;Contents;5
2;List of Figures;13
3;List of Tables;15
4;Preface;17
5;Acknowledgments;19
6;Chapter 1 INTRODUCTION;21
6.1;1.1 Trust and Computing;22
6.2;1.2 Instantiations;22
6.3;1.3 Design and Applications;25
6.4;1.4 Progression;27
7;Chapter 2 MOTIVATING SCENARIOS;29
7.1;2.1 Properties;29
7.2;2.2 Basic Usage;30
7.3;2.3 Examples of Basic Usage;32
7.4;2.4 Position and Interests;34
7.5;2.5 Examples of Positioning;35
7.6;2.6 The Idealogical Debate;38
7.7;2.7 Further Reading;38
8;Chapter 3 ATTACKS;39
8.1;3.1 Physical Attack;41
8.1.1;3.1.1 No Armor;42
8.1.2;3.1.2 Single Chip Devices;43
8.1.3;3.1.3 Multi-chip Devices;43
8.2;3.2 Software Attacks;44
8.2.1;3.2.1 Buffer Overflow;45
8.2.2;3.2.2 Unexpected Input;45
8.2.3;3.2.3 Interpretation Mismatches;46
8.2.4;3.2.4 Time-of-check vs Time-of-use;47
8.2.5;3.2.5 Atomicity;48
8.2.6;3.2.6 Design Flaws;49
8.3;3.3 Side- channel Analysis;50
8.3.1;3.3.1 Timing Attacks;50
8.3.2;3.3.2 Power Attacks;53
8.3.3;3.3.3 Other Avenues;54
8.4;3.4 Undocumented Functionality;55
8.4.1;3.4.1 Example: Microcontroller Memory;56
8.4.2;3.4.2 Example: FLASH Memory;57
8.4.3;3.4.3 Example: CPU Privileges;58
8.5;3.5 Erasing Data;58
8.6;3.6 System Context;59
8.7;3.7 Defensive Strategy;61
8.7.1;3.7.1 Tamper Evidence;61
8.7.2;3.7.2 Tamper Resistance;61
8.7.3;3.7.3 Tamper Detection;61
8.7.4;3.7.4 Tamper Response;62
8.7.5;3.7.5 Operating Envelope;62
8.8;3.8 Further Reading;62
9;Chapter 4 FOUNDATIONS;63
9.1;4.1 Applications and Integration;63
9.1.1;4.1.1 Kent;64
9.1.2;4.1.2 Abyss;64
9.1.3;4.1.3 Citadel;65
9.1.4;4.1.4 Dyad;66
9.2;4.2 Architectures;68
9.2.1;4.2.1 Physical Security;68
9.2.2;4.2.2 Hardware and Software;69
9.3;4.3 Booting;70
9.4;4.4 The Defense Community;72
9.5;4.5 Further Reading;72
10;Chapter 5 DESIGN CHALLENGES;75
10.1;5.1 Context;75
10.1.1;5.1.1 Personal;75
10.1.2;5.1.2 Commercial;76
10.2;5.2 Obstacles;77
10.2.1;5.2.1 Hardware;77
10.2.2;5.2.2 Software;79
10.3;5.3 Requirements;83
10.3.1;5.3.1 Commercial Requirements;83
10.3.2;5.3.2 Security Requirements;84
10.3.3;5.3.3 Authenticated Execution;86
10.4;5.4 Technology Decisions;87
10.5;5.5 Further Reading;91
11;Chapter 6 PLATFORM ARCHITECTURE;93
11.1;6.1 Overview;93
11.1.1;6.1.1 Security Architecture;94
11.2;6.2 Erasing Secrets;95
11.2.1;6.2.1 Penetration Resistance and Detection;96
11.2.2;6.2.2 Tamper Response;96
11.2.3;6.2.3 Other Physical Attacks;97
11.3;6.3 The Source of Secrets;98
11.3.1;6.3.1 Factory Initialization;98
11.3.2;6.3.2 Field Operations;99
11.3.3;6.3.3 Trusting the Manufacturer;101
11.4;6.4 Software Threats;101
11.4.1;6.4.1 Software Threat Model;102
11.4.2;6.4.2 Hardware Access Locks;102
11.4.3;6.4.3 Privacy and Integrity of Secrets;105
11.5;6.5 Code Integrity;105
11.5.1;6.5.1 Loading and Cryptography;106
11.5.2;6.5.2 Protection against Malice;106
11.5.3;6.5.3 Protection against Reburn Failure;107
11.5.4;6.5.4 Protection against Storage Errors;108
11.5.5;6.5.5 Secure Bootstrapping;109
11.6;6.6 Code Loading;110
11.6.1;6.6.1 Authorities;111
11.6.2;6.6.2 Authenticating the Authorities;112
11.6.3;6.6.3 Ownership;112
11.6.4;6.6.4 Ordinary Loading;113
11.6.5;6.6.5 Emergency Loading;116
11.7;6.7 Putting it All Together;117
11.8;6.8 What’s Next;119
11.9;6.9 Further Reading;119
12;Chapter 7 OUTBOUND AUTHENTICATION;121
12.1;7.1 Problem;121
12.1.1;7.1.1 The Basic Problem;122
12.1.2;7.1.2 Authentication Approach;122
12.1.3;7.1.3 User and Developer Scenarios;123
12.1.4;7.1.4 On-Platform Entities;124
12.1.5;7.1.5 Secret Retention;124
12.1.6;7.1.6 Authentication Scenarios;125
12.1.7;7.1.7 Internal Certification;127
12.2;7.2 Theory;128
12.2.1;7.2.1 What the Entity Says;129
12.2.2;7.2.2 What the Relying Party Concludes;129
12.2.3;7.2.3 Dependency;130
12.2.4;7.2.4 Soundness;131
12.2.5;7.2.5 Completeness;132
12.2.6;7.2.6 Achieving Both Soundness and Completeness;132
12.2.7;7.2.7 Design Implications;133
12.3;7.3 Design and Implementation;134
12.3.1;7.3.1 Layer Separation;135
12.3.2;7.3.2 The Code-Loading Code;135
12.3.3;7.3.3 The OA Manager;136
12.3.4;7.3.4 Naming;139
12.3.5;7.3.5 Summary;139
12.3.6;7.3.6 Implementation;140
12.4;7.4 Further Reading;141
13;Chapter 8 VALIDATION;143
13.1;8.1 The Validation Process;144
13.1.1;8.1.1 Evolution;144
13.1.2;8.1.2 FIPS 140-1;145
13.1.3;8.1.3 The Process;146
13.2;8.2 Validation Strategy;146
13.3;8.3 Formalizing Security Properties;149
13.3.1;8.3.1 Building Blocks;150
13.3.2;8.3.2 Easy Invariants;151
13.3.3;8.3.3 Controlling Code;151
13.3.4;8.3.4 Keeping Secrets;152
13.4;8.4 Formal Verification;154
13.5;8.5 Other Validation Tasks;156
13.6;8.6 Reflection;158
13.7;8.7 Further Reading;159
14;Chapter 9 APPLICATION CASE STUDIES;161
14.1;9.1 Basic Building Blocks;161
14.2;9.2 Hardened Web Servers;162
14.2.1;9.2.1 The Problem;162
14.2.2;9.2.2 Using a TCP;164
14.2.3;9.2.3 Implementation Experience;169
14.3;9.3 Rights Management for Big Brother’s Computer;172
14.3.1;9.3.1 The Problem;172
14.3.2;9.3.2 Using a TCP;173
14.3.3;9.3.3 Implementation Experience;174
14.4;9.4 Private Information;175
14.4.1;9.4.1 The Problem;175
14.4.2;9.4.2 Using a TCP: Initial View;177
14.4.3;9.4.3 Implementation Experience;178
14.4.4;9.4.4 Using Oblivious Circuits;180
14.4.5;9.4.5 Reducing TCP Memory Requirements;183
14.4.6;9.4.6 Adding the Ability to Update;185
14.5;9.5 Other Projects;187
14.5.1;9.5.1 Postal Meters;187
14.5.2;9.5.2 Kerberos KDC;187
14.5.3;9.5.3 Mobile Agents;187
14.5.4;9.5.4 Auctions;187
14.5.5;9.5.5 Marianas;188
14.5.6;9.5.6 Trusted S/MIME Gateways;189
14.5.7;9.5.7 Grid Tools;189
14.6;9.6 Lessons Learned;190
14.7;9.7 Further Reading;191
15;Chapter 10 TCPA/ TCG;193
15.1;10.1 Basic Structure;195
15.2;10.2 Outbound Authentication;198
15.3;10.3 Physical Attacks;199
15.4;10.4 Applications;200
15.5;10.5 Experimentation;200
15.6;10.6 TPM 1.2 Changes;201
15.7;10.7 Further Reading;201
16;Chapter 11 EXPERIMENTING WITH TCPA/TCG;203
16.1;11.1 Desired Properties;204
16.2;11.2 The Lifetime Mismatch;204
16.3;11.3 Architecture;205
16.4;11.4 Implementation Experience;209
16.5;11.5 Application: Hardened Apache;210
16.6;11.6 Application: OpenCA;211
16.7;11.7 Application: Compartmented Attestation;213
16.8;11.8 Further Reading;214
17;Chapter 12 NEW HORIZONS;215
17.1;12.1 Privilege Architectures;215
17.2;12.2 Hardware Research;217
17.2.1;12.2.1 XOM;217
17.2.2;12.2.2 MIT AEGIS;218
17.2.3;12.2.3 Cerium;219
17.2.4;12.2.4 Virtual Secure Coprocessing;219
17.2.5;12.2.5 Virtual Machine Monitors;219
17.2.6;12.2.6 Others;220
17.3;12.3 Software Research;221
17.3.1;12.3.1 Software-based Attestation;222
17.3.2;12.3.2 Hiding in Plain Sight;222
17.4;12.4 Current Industrial Platforms;223
17.4.1;12.4.1 Crypto Coprocessors and Tokens;223
17.4.2;12.4.2 Execution Protection;223
17.4.3;12.4.3 Capability-based Machines;224
17.5;12.5 Looming Industry Platforms;224
17.5.1;12.5.1 LaGrande;224
17.5.2;12.5.2 TrustZone;226
17.5.3;12.5.3 NGSCB;226
17.6;12.6 Secure Coprocessing Revisited;228
17.7;12.7 Further Reading;229
18;Glossary;231
19;References;241
20;About the Author;255
21;Index;257

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.