000 07156nam a2200541 i 4500
001 01145/2611399
005 20260528133338.0
006 m eo d
007 cr cn |||m|||a
008 150428s2014 nyua fob 000 0deng d
020 _a9781627054782
_qebook
020 _z9781627054799
_qePub
020 _z9781627054775
_qprint
024 7 _a10.1145/2611399
_2doi
035 _a(OCoLC)908155788
040 _aCaBNVSL
_beng
_erda
_cCaBNVSL
_dCaBNVSL
050 4 _aQA76.9.A25
_bP277 2014
082 0 4 _a005.8
_223
035 _a(CaBNVSL)swl00404864
100 1 _aParno, Bryan.,
_eauthor.
245 1 0 _aTrust extension as a mechanism for secure code execution on commodity computers /
_cBryan Jeffrey Parno.
250 _aFirst edition.
264 1 _a[New York] :
_bAssociation for Computing Machinery ;
_a[San Rafael, California] :
_bMorgan & Claypool,
_c2014.
300 _a1 PDF (xvii, 188 pages) :
_billustrations.
336 _atext
_2rdacontent
337 _aelectronic
_2isbdmedia
338 _aonline resource
_2rdacarrier
490 1 _aACM books ;
_v#2
504 _aIncludes bibliographical references (pages 173-188).
506 _aAbstract freely available; full-text restricted to subscribers or individual document purchasers.
588 _aTitle from PDF title page (viewed on April 28, 2015).
538 _aMode of access: World Wide Web.
538 _aSystem requirements: Adobe Acrobat Reader.
505 0 _a1. 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 --
505 8 _a2. 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 --
505 8 _a3. 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 --
505 8 _a4. 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 --
505 8 _a5. 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 --
505 8 _a6. 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 --
505 8 _a7. Conclusion -- Bibliography -- Author's biography.
520 3 _aAs 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.
530 _aAlso available in print.
650 0 _aComputer security.
650 0 _aComputer networks
_xSecurity measures.
776 0 8 _iPrint version:
_z9781627054775
830 0 _aACM books ;
_v#2.
856 4 8 _3Abstract with links to full text
_uhttp://dx.doi.org/10.1145/2611399
999 _c352
_d352