Trusted Computing Platforms (eBook)

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

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

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.