Trust extension as a mechanism for secure code execution on commodity computers [electronic resources] / Bryan Jeffrey Parno.
Material type: TextSeries: ACM books ; #2.Publication details: [San Rafael, California]: Morgan & Claypool Publishers, c2014Description: 1 PDF (xvii, 188 pages) : illustrationsISBN: 9781627054782; 9781627054799Subject(s): Computer security | Computer networks -- Security measuresDDC classification: 005.8 LOC classification: QA76.9.A25 | P27 2014ebOnline resources: Available in ACM Digital Library. Requires Log In to view full text.Item type | Current library | Collection | Call number | Copy number | Status | Date due | Barcode |
---|---|---|---|---|---|---|---|
General Circulation | APU Library Online Database | E-Book | QA76.9.A25 P27 2014eb (Browse shelf (Opens below)) | 1 | Available |
Includes bibliographical references (pages 173-188).
1. Introduction -- 1.1 Insecure computers in a hostile world -- 1.2 A vision for a better world -- 1.3 Overview: building up from a firm foundation -- 1.4 Bootstrapping trust in a commodity computer -- 1.5 Securely executing code on a commodity computer -- 1.6 Leveraging secure code execution to improve network protocols -- 1.7 Secure code execution despite untrusted software and hardware -- 1.8 Summary of contributions --
2. Background and related work in trust establishment -- 2.1 What do we need to know? Techniques for recording platform state -- 2.1.1 Recording code identity -- 2.1.2 Recording dynamic properties -- 2.1.3 Which property is necessary? -- 2.2 Can we use platform information locally? -- 2.2.1 Secure boot -- 2.2.2 Storage access control based on code identity -- 2.3 Can we use platform information remotely? -- 2.3.1 Prerequisites -- 2.3.2 Conveying code measurement chains -- 2.3.3 Privacy concerns -- 2.4 How do we make sense of platform state? -- 2.4.1 Coping with information overload -- 2.4.2 Focusing on security-relevant code -- 2.4.3 Conveying higher-level information -- 2.5 Roots of trust -- 2.5.1 General-purpose tamper-resistant and tamper-responding devices -- 2.5.2 General-purpose devices without dedicated physical defenses -- 2.5.3 Special-purpose minimal devices -- 2.5.4 Research solutions without hardware support -- 2.5.5 Cryptographic protocols -- 2.6 Validating the process -- 2.7 Applications -- 2.7.1 Real world -- 2.7.2 Research proposals -- 2.8 Human factors and usability -- 2.8.1 Trustworthy verifier device -- 2.8.2 Using your brain to check a computer -- 2.8.3 Pairing two trustworthy devices -- 2.9 Limitations -- 2.9.1 Load-time vs. run-time guarantees -- 2.9.2 Hardware attacks -- 2.10 Additional reading -- 2.11 Summary --
3. Bootstrapping trust in a commodity computer -- 3.1 Problem definition -- 3.1.1 Informal problem description -- 3.1.2 Formal model -- 3.2 Potential solutions -- 3.2.1 Removing network access -- 3.2.2 Eliminating malware -- 3.2.3 Establishing a secure channel -- 3.3 Preferred solutions -- 3.4 Summary --
4. On-demand secure code execution on commodity computers -- 4.1 Problem definition -- 4.1.1 Adversary model -- 4.1.2 Goals -- 4.2 Flicker architecture -- 4.2.1 Flicker overview -- 4.2.2 Isolated execution -- 4.2.3 Multiple flicker sessions -- 4.2.4 Interaction with a remote party -- 4.3 Developer's perspective -- 4.3.1 Creating a PAL -- 4.3.2 Automation -- 4.4 Flicker applications -- 4.4.1 Stateless applications -- 4.4.2 Integrity-protected state -- 4.4.3 Secret and integrity-protected state -- 4.5 Performance evaluation -- 4.5.1 Experimental setup -- 4.5.2 Microbenchmarks -- 4.5.3 Stateless applications -- 4.5.4 Integrity-protected state -- 4.5.5 Secret and integrity-protected state -- 4.5.6 Impact on suspended operating system -- 4.5.7 Major performance problems -- 4.6 Architectural recommendations -- 4.6.1 Launching a PAL -- 4.6.2 Hardware memory isolation -- 4.6.3 Hardware context switch -- 4.6.4 Improved TPM support for flicker -- 4.6.5 PAL exit -- 4.6.6 PAL life cycle -- 4.6.7 Expected impact -- 4.6.8 Extensions -- 4.7 Summary --
5. Using trustworthy host-based information in the network -- 5.1 Problem definition -- 5.1.1 Architectural goals -- 5.1.2 Assumptions -- 5.2 The assayer architecture -- 5.2.1 Overview -- 5.2.2 Assayer components -- 5.2.3 Protocol details -- 5.2.4 User privacy and client revocation -- 5.3 Potential attacks -- 5.3.1 Exploited clients -- 5.3.2 Malicious clients -- 5.3.3 Rogue verifiers -- 5.3.4 Rogue filters -- 5.4 Case studies -- 5.4.1 Spam identification -- 5.4.2 Distributed denial-of-service (DDoS) mitigation -- 5.4.3 Super-spreader worm detection -- 5.5 Implementation -- 5.5.1 Client architecture -- 5.5.2 Client verification -- 5.5.3 Traffic annotation -- 5.5.4 Filter -- 5.6 Evaluation -- 5.6.1 Client verification -- 5.6.2 Client annotations -- 5.6.3 Filter throughput -- 5.6.4 Internet-scale simulation -- 5.7 Potential objections -- 5.7.1 Why not collect information on the local router? -- 5.7.2 Is this really deployable incrementally? -- 5.8 Summary --
6. Verifiable computing: secure code execution despite untrusted software and hardware -- 6.1 Overview -- 6.2 Cryptographic background -- 6.2.1 Yao's garbled circuit construction -- 6.2.2 The security of Yao's protocol -- 6.2.3 Fully homomorphic encryption -- 6.3 Problem definition -- 6.3.1 Basic requirements -- 6.3.2 Input and output privacy -- 6.3.3 Efficiency -- 6.4 An efficient verifiable-computation scheme with input and output privacy -- 6.4.1 Protocol definition -- 6.4.2 Proof of security -- 6.4.3 Proof of input and output privacy -- 6.4.4 Efficiency -- 6.5 How to handle cheating workers -- 6.6 Summary --
7. Conclusion -- Bibliography -- Author's biography.
Abstract freely available; full-text restricted to subscribers or individual document purchasers.
As society rushes to digitize sensitive information and services, it is imperative that we adopt adequate security protections. However, such protections fundamentally conflict with the benefits we expect from commodity computers. In other words, consumers and businesses value commodity computers because they provide good performance and an abundance of features at relatively low costs. Meanwhile, attempts to build secure systems from the ground up typically abandon such goals, and hence are seldom adopted.
Mode of access: World Wide Web.
System requirements: Internet connectivity; World Wide Web browser and Adobe Acrobat Reader.
There are no comments on this title.