Securely Using Untrusted Terminals and Compromised Machines with

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

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

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

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

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?

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

Binary Untrusted Terminal Problem Trusted Terminals IBM 4758 Untrusted Terminals

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

Current Approaches Partial Solutions Smart Cards Visual Crypto PDAs

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

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

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

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-1 AIK • Manufacturer certificate, for example {KAIK } K-1 IBM

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 Verifier Remote platform

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 Verifier Remote platform 160 bit nonce Sign (H (target_exe, nonce), AIK_priv)

Enabling a Human Verifier Untrusted platform Remote Terminal 160 bit nonce 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

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

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

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 Challenge Expected device memory content External Verifier Checksum of memory Remote Platform Device memory

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

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

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

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

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

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

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

Results – Runtime Difference

Results – Runtime Difference

Results – Runtime Difference

Results – Runtime Difference

Results – Runtime Difference

Results – Runtime Difference . 3 ms

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 (. 3 ms? )

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

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

Challenge-Response Pair Generation and Management § Manufacturer could generate initial pairs IBM 4758 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

Increasing Computation Time § Adversary overhead on x 86 is around 2% • Running checksum longer isn’t reasonable or usable • Even with a 10 min checksum we only see 12 sec overhead – 2% of 10 mins = 12 sec adversary overhead § Solution required a simpler architecture • Redesigned Pioneer for Intel XScale-PXA 255 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%

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

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

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

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

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

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 • tpaskon 20 fa 667 fdf 059980 ace 665 f 453199 a 0 b 30. 2 s § 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 < 42 s § Results: • False Positives • False Negative (delayed execution) • False Negative (incorrect checksum) 0/24 0/12 1/12

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 humanverifiable code execution protocol to ensure correctness of software on voting machine

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

Ongoing Work § Improving usability of software-based technique $2. 99 online § 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

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

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