1 / 48

Securely Using Untrusted Terminals and Compromised Machines with Human-Verifiable Code Execution

This paper explores the problem of securely using devices that cannot be trusted, such as terminals in an Internet cafe or compromised devices. It presents a solution called Human-Verifiable Code Execution (HVCE), which aims to provide a guarantee that target executables are invoked in an untampered environment, without the direct assistance of another computational device and verifiable by a human.

phyllisa
Download Presentation

Securely Using Untrusted Terminals and Compromised Machines with Human-Verifiable Code Execution

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Securely Using Untrusted Terminals and Compromised Machines with Human-Verifiable Code Execution Jason Franklin, Mark Luk, Arvind Seshadri, Adrian Perrig

  2. How can we trust our devices? • How do I securely use a device I don’t trust? • Terminal in an Internet café or conference • What about compromised devices? • My PDA, home/work/car computer

  3. Human-Verifiable Code Execution (HVCE) • How can I know what is executing on my PDA? • Example: encrypted data stored on PDA, how can I be assured that no malware steals password? • Goal: human-verifiable code execution to prevent malware from undetectably interfering with application

  4. Human-Verifiable Code Execution • Problem Statement • Provide a human verifier with a guarantee that a target executable has been invoked for execution in an untampered environment, such that no other code can interfere with its execution • Guarantee must be obtained without direct assistance of another computational device and be verifiable by a human

  5. Past Human-Verifiable Code Execution • We had human-verifiable code execution in the past! • On punchcard-based mainframes, programmer could hear when his program was executing! • Or, in modern times, my machine acts “strange”…I quickly type: • > ps auwx • Can we achieve secure human-verifiable code execution on today’s platforms?

  6. Outline • Vision • Untrusted Terminal Problem • Binary and Generalized • Hardware-based HVCE • Software-based HVCE • Building verifiable applications • User study • Ongoing Work • Conclusion

  7. IBM 4758 Binary Untrusted Terminal Problem Untrusted Terminals Trusted Terminals

  8. Trusted Hardware and Software Trusted Hardware Completely Untrusted Terminals Generalized Untrusted Terminal Problem • Levels of trust exist beyond completely trusted and untrusted

  9. Current Approaches Partial Solutions PDAs Visual Crypto Smart Cards

  10. Outline • Vision • Untrusted Terminal Problem • Binary and Generalized • Hardware-based HVCE • Software-based HVCE • Building verifiable applications • User study • Ongoing Work • Conclusion

  11. Hardware-Based HVCE • Based on AMD’s Pacifica and Intel’s LT • Next generation platforms for secure virtualization • Include hardware Trusted Platform Module (TPM) • New instructions: skinit (AMD) and senter (Intel) • Provide guarantee of externally-verifiable code execution • Guarantee not useful to human verifier • Require modifications to allow human verifier

  12. Non-Volatile Storage (EK AIK, SRK) Platform Configuration Register (PCR) I/O LPC bus Crypto RSA Key Generation Random Number Generator Secure Hash SHA-1 DIP Packaging or integrated into SuperIO chip TCG Trusted Platform Module (TPM)

  13. Basic TPM Functionality • TPM contains 16 program configuration registers (PCRs) to store integrity measurements • Operations on PCRs • TPM_Extend(N, S): PCRN = SHA-1(PCRN | S) • TPM_Read(N): Return contents of PCRN • TPM contains private key to sign attestations and manufacturer certificate • Tamper resistant storage for private key K-1AIK • Manufacturer certificate, for example {KAIK }K-1IBM

  14. Externally-Verifiable Code Execution • On call to skinit(target_exe_p) • CPU transfers executable image to TPM over LPC bus • TPM hashes executable image and stores in PCR • CPU sets up untampered execution environment • Disables interrupts • Sets up memory protections to disable DMA writes to memory locations containing target executable • CPU jumps to target executable and executes Remote platform Verifier

  15. Verifier Remote platform 160 bit nonce Sign (H (target_exe, nonce), AIK_priv) Externally-Verifiable Code Execution • Verifier sends 160 bit nonce to remote platform • Remote platform returns signed hash of target executable and nonce • Verifier uses remote platform’s public attestation identity key to check signature and verifies that correct executable has been invoked

  16. 160 bit nonce Enabling a Human Verifier Verifier Untrusted Terminal Remote platform Sign (H (target_exe, nonce), AIK_priv) H(target_exe) • Human needs list of challenge response pairs • Generating pairs requires access to AIK_priv • Only available to TPM • Can’t trust software on device to generate pairs • Solution: Add verify button and utilize existing secure I/O functionality • Verify button directly invokes skinit on fixed memory location containing executable and arguments • Human verifies hash of target executable displayed in trusted area of screen • Eliminates need for challenge response pairs • Requires further modifications to next generation hardware

  17. Outline • Vision • Untrusted Terminal Problem • Binary and Generalized • Hardware-based HVCE • Software-based HVCE • Building verifiable applications • User study • Ongoing Work • Conclusion

  18. Software-Based Approach • Extend current software-based attestation primitives • Establish trusted input and output paths for human verifier • Advantages of software technique: • Works on legacy devices • Software-based solutions can be fixed if vulnerability discovered • TPMs require hardware changes to fix vulnerabilities (SHA-1) • Avoids privacy concerns with remote attestation • Disadvantages • Difficult to reason about security

  19. Challenge Checksum of memory Software-based Attestation Overview • External, trusted verifier knows expected memory content of device • Verifier sends challenge to untrusted device • Assumption: attacker has full control over device’s memory before check • Device returns memory checksum, assures verifier of memory correctness Remote Platform Expected device memory content External Verifier Device memory

  20. Verifiable Code Execution with Pioneer • First step to address untampered code execution on untrusted legacy hosts • Implemented on Intel Pentium IV • Approach • Verify code integrity through software-based attestation • Set up untampered code execution environment • Execute code

  21. Assumptions and Attacker Model • Assumptions on verifier • Knows hardware configuration of remote device • Assumptions on device (untrusted host) • Hardware and firmware is trustworthy • Can only communicate with verifier: no proxy attacks • Attacker controls device’s software and OS before verification

  22. Design of Pioneer Function Root of Trust Checksum Code Hash Function Verification Function • Compute checksum • Set up untampered • execution environment Measure Integrity Invoke Target Code

  23. t1: nonce, input nonce cksum nonce hash t2: cksum hash output input output The Pioneer Protocol Remote Platform Verifier • Successful verification if: t2 – t1 < expected time && cksum == exp. cksum Checksum Code Hash Function Target Code

  24. Checksum Requirements • Optimal implementation: code cannot be optimized • Denali project @ HP labs provides proof of optimal implementation of short pieces of code • GNU superopt • Open challenge to prove optimality of checksum function • No algebraic optimizations • Checksum has to be computed in entirety • Given a memory change, checksum cannot be “adjusted” without recomputation

  25. Desired Security Property • Verifier’s check is successful if and only if • Verification function is unmodified • Untampered execution environment is established • Intuition: Checksum is incorrect or checksum computation slows down if attacker • Modifies verification function and forges correct checksum, or • Fakes creation of untampered code execution environment

  26. Challenges on Modern CPUs • Execution time non-determinism • Out-of-order execution • Cache and virtual memory • Dynamic CPU clock speed scaling • DMA-based attacks from malicious peripherals • Interrupt-based attacks • Non-maskable interrupts • Attacks using exceptions • Virtualization-based attacks

  27. Results – Runtime Difference

  28. Results – Runtime Difference

  29. Results – Runtime Difference

  30. Results – Runtime Difference

  31. Results – Runtime Difference

  32. Results – Runtime Difference .3ms

  33. Enabling a Human Verifier • Humans have limited powers of perception and computation • Challenges • Can’t create secure random nonces • Can’t compute correct checksum • Can’t accurately time checksum computation (.3ms?)

  34. Enabling a Human Verifier • Provide user access to list of challenge response pairs and detection threshold • Similar to two factor authentication in European online banking systems • Increase time of checksum computation • Human measures checksum time using stopwatch

  35. Challenge-Response Pair Generation and Management • Pairs must be unpredictable and secret • Threats to generation process include: • Pair creator could be malicious • Legitimate challenge-response pair leaked • Only require one pair to bootstrap creation of list • Issue challenge to device • Check response • Generate additional pairs in untampered execution environment • Recommend maintain a list of challenge-response pairs

  36. IBM 4758 Challenge-Response Pair Generation and Management • Manufacturer could generate initial pairs and include with device • Use isolated machine with tamper-evident hardware and specialized software • Does not require additional trusted entities • Already trust manufacturer • Could provide out-of-band method to acquire additional pairs • Phone, mail, or SMS

  37. Increasing Computation Time • Adversary overhead on x86 is around 2% • Running checksum longer isn’t reasonable or usable • Even with a 10min checksum we only see 12sec overhead • 2% of 10mins = 12sec adversary overhead • Solution required a simpler architecture • Redesigned Pioneer for Intel XScale-PXA255 processor • 16 general purpose registers, 2 processor status registers, seven processor modes • Simple architecture reduces number of possible attacks and increases adversary overhead • Fastest known attack on XScale implementation (memory copy attack) has overhead of close to 40%

  38. Implementation • Sharp Zaurus PDA SL-6000 • Intel XScale CPU • Linux kernel 2.4.19 • Implemented as kernel module • Checksum loop is assembly, remainder is C • Using 80-bit challenges and responses

  39. Security Analysis • Probabilistic guessing attacks • Device attempts to gain pre-computation advantage by guessing remaining characters of challenge as it is input • Exploits fact that humans may slowly input challenge • Countermeasure: Use realistic bounds on attacker’s overhead • Challenge-response pair secrecy, integrity, and freshness • Various threats including malicious printers and eavesdropping • Social engineering attacks • Malicious program ask user to press return after entering challenge • Malicious program beeps “early” to signal completion • Denial of Challenge Attack • Malicious software consistently crashes the device after observing challenges

  40. Outline • Vision • Untrusted Terminal Problem • Binary and Generalized • Hardware-based HVCE • Software-based HVCE • Building verifiable applications • User study • Ongoing Work • Conclusion

  41. Secure Digital Signature Application • Scenario: User wants to sign a message using a private key encrypted under a password • Steps to sign message with PGP application • Start signature application and enter password • Application decrypts private key using password • Application uses decrypted private key to sign message • Application erases decrypted key in memory and exits • Avenues of attack include: • Malware can steal password used to decrypt private key • Malware can capture decrypted private key in memory • Malware can perform a message substitution attack and sign a different message

  42. Secure Digital Signature Application • Developed verifiable digital signature using software-based HVCE • Implemented as a kernel module • User loads kernel module and issues challenge • User checks response and execution time • Digital signature application executes in an untampered execution environment • Untampered execution environment provides guarantee that malware did not steal password or private key through eavesdropping or memory monitoring

  43. Digital Signature Application User Study • 12 users with various levels of experience with PDAs • 7 male and 5 female • 5 between 18-22, 5 between 23-30, and 2 older than 31 • Implementation: Linux kernel of Sharp Zaurus PDA • Provided list of challenge-response pairs • asjmxk 20fa667fdf059980 30.2s • tpaskon ace665f453199a0b 30.2s • Provided four test scripts to user • 2 used correct verification function • 1 maliciously computed correct checksum with a delay • 1 maliciously returned incorrect checksum on time • Told users to accept if checksum if correct and running time < 42s • Results: • False Positives 0/24 • False Negative (delayed execution) 0/12 • False Negative (incorrect checksum) 1/12

  44. Verification of Voting Machines • Challenge: verify correctness of software on voting machine • Incident: wrong software was executing on voting machine on election day • Approach: leverage human-verifiable code execution protocol to ensure correctness of software on voting machine

  45. Verification of Voting Machines • County generates challenge-response pairs • Generated by isolated computer • Can be validated by public after election • Challenge-response pair lists sent to poll workers • Poll workers periodically tests voting machine SW • Type challenge into voting machine • Measure computation time • Verify response • Provides stronger guarantees than random auditing of machines

  46. $2.99 online Ongoing Work • Improving usability of software-based technique • Developing techniques to check a thin security-visor which then enforces policy on programs • Increases TCB • Increase the number of verifiable applications • Beginning standardization with NIST

  47. Conclusions • Described design of hardware and software-based systems for human-verifiable code execution • Software-based human-verifiable code execution feasible on simple architectures • HVCE can provide trusted path for input and output • Strong guarantees even to a human verifier • HVCE enables development of verifiable applications • Described a sample verifiable application to securely sign messages on a untrusted terminal • Software-based HVCE can be used today to enable verification of voting machine software integrity without hardware changes

  48. Related Work • Hardware-based untampered execution • Cerium: µkernel running inside caches of a tamper-resistant CPU [Chen et al.] • XOM: Mutually untrusting applications execute on (possibly) malicious OS [Lie et al.] • Mondrix: Fine-grained memory protection for Linux using the Mondriaan system [Witchel et al.] • HW-based attestation • Load-time attestation using TCG specs [Sailer et al.] • Terra: Use trusted VMM for attestation [Garfinkel et al.] • Copilot: Use add-in PCI card for attestation [Petroni et al.] • Software-based attestation • Genuinity: Uses CPU architecture features to distinguish between execution on actual hardware and a simulator [Kennell et al.] • Software tamperproofing

More Related