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

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

IBM 4758 Binary Untrusted Terminal Problem Untrusted Terminals Trusted Terminals

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

Current Approaches Partial Solutions PDAs Visual Crypto Smart Cards

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

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)

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

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

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

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

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

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

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

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

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

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

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 .3ms

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?)

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

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

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%

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

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 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

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

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

$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

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

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