| 000 | 06906nam a2200457 i 4500 | ||
|---|---|---|---|
| 001 | 01145/2611399 | ||
| 003 | APU | ||
| 005 | 20221028154438.0 | ||
| 007 | cr cn |||m|||a | ||
| 008 | 150428s2014 nyua fob 000 0deng d | ||
| 020 | _a9781627054782 | ||
| 020 | _a9781627054799 | ||
| 020 | _z9781627054775 | ||
| 035 | _a(OCoLC)908155788 | ||
| 035 | _a(CaBNVSL)swl00404864 | ||
| 040 |
_aCaBNVSL _beng _cAPU _dSF |
||
| 050 | 4 |
_aQA76.9.A25 _bP27 2014eb |
|
| 082 | 0 | 4 |
_a005.8 _223 |
| 100 | 1 |
_aParno, Bryan., _947376 |
|
| 245 | 1 | 0 |
_aTrust extension as a mechanism for secure code execution on commodity computers _h[electronic resources] / _cBryan Jeffrey Parno. |
| 260 |
_a[San Rafael, California]: _bMorgan & Claypool Publishers, _cc2014. |
||
| 300 |
_a1 PDF (xvii, 188 pages) : _billustrations. |
||
| 490 | 1 |
_aACM books ; _v#2 |
|
| 504 | _aIncludes bibliographical references (pages 173-188). | ||
| 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. | |
| 506 | _aAbstract freely available; full-text restricted to subscribers or individual document purchasers. | ||
| 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. | |
| 538 | _aMode of access: World Wide Web. | ||
| 538 | _aSystem requirements: Internet connectivity; World Wide Web browser and Adobe Acrobat Reader. | ||
| 650 | 0 | _aComputer security. | |
| 650 | 0 |
_aComputer networks _xSecurity measures. |
|
| 830 | 0 |
_aACM books ; _v#2. _947379 |
|
| 856 | 4 | 8 |
_uhttps://dl-acm-org.ezproxy.apu.edu.my/doi/book/10.1145/2611399 _zAvailable in ACM Digital Library. Requires Log In to view full text. |
| 942 |
_2lcc _cE-Book |
||
| 999 |
_c383687 _d383687 |
||